| 1 |
On 5/31/14, 8:30 PM, Tom Wijsman wrote: |
| 2 |
> On Sat, 31 May 2014 19:50:20 +0200 |
| 3 |
> ""Paweł Hajdan, Jr."" <phajdan.jr@g.o> wrote: |
| 4 |
>> This is one of my points: I don't remember a single chromium bug filed |
| 5 |
>> in Gentoo that would be caught by a test or that a failing test |
| 6 |
>> actually detected. |
| 7 |
> |
| 8 |
> Your point covers the lack of tests, or tests that are non-fatal; |
| 9 |
> however, it doesn't cover tests that are fatal, what if they fail? |
| 10 |
|
| 11 |
I'm confused by the distinction of fatal and non-fatal tests. Neither |
| 12 |
upstream nor the Gentoo chromium package makes that distinction. |
| 13 |
|
| 14 |
>> By the way, I don't remember seeing many reports about font issues or |
| 15 |
>> tab crashes. Please make sure to file them when they occur, or just |
| 16 |
>> point me to them in case I somehow missed them. |
| 17 |
> |
| 18 |
> They usually go straight to upstream, though I've managed to somehow |
| 19 |
> fix it up; as for Gentoo, some people create forum threads about them. |
| 20 |
|
| 21 |
I can't speak for other people, but please consider reporting issues to |
| 22 |
Gentoo first. Our bug queue is under 30 bugs, while upstream is several |
| 23 |
thousand. Once we can confirm a bug clearly belongs to upstream, we can |
| 24 |
tell the reporter to file bug upstream or do that ourselves, but keeping |
| 25 |
Gentoo out of the loop seems to increase the time needed to fix a bug. |
| 26 |
|
| 27 |
> (One was due to a library compiled with a less common flag, the other |
| 28 |
> due to fontconfig being a regression magnet; both fun to debug, the |
| 29 |
> former a test wolud've caught, the latter is due to the lack thereof) |
| 30 |
|
| 31 |
If there's something that could be changed e.g. in chromium's |
| 32 |
dependencies, please let me know. There are cases where we require |
| 33 |
certain USE flags to be set on dependencies for things to work properly. |
| 34 |
|
| 35 |
About the issue that a test would have caught: was that a chromium test? |
| 36 |
If so, which one? |
| 37 |
|
| 38 |
>>> While I don't run tests myself; the need for them is clear, for |
| 39 |
>>> those that aim for more production ready systems (eg. university |
| 40 |
>>> network PCs). |
| 41 |
>> |
| 42 |
>> This seems too theoretical to me. I'd be fine with someone |
| 43 |
>> volunteering to maintain chromium's src_test in Gentoo. Unless we |
| 44 |
>> have such a person though, it seems to mostly take valuable focus |
| 45 |
>> away from bugs that definitely *do* affect our users, for no provable |
| 46 |
>> benefit for Gentoo. |
| 47 |
> |
| 48 |
> What about provable benefit for upstream? Does upstream /dev/null them? |
| 49 |
|
| 50 |
Effectively yes. For an example see |
| 51 |
https://bugs.gentoo.org/show_bug.cgi?id=497512 and |
| 52 |
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/OdX7ShsOqsM/-R9sexJAEa4J |
| 53 |
|
| 54 |
The failure is not Gentoo-specific, and is not a bug in code but problem |
| 55 |
with the test (it makes assumptions about internal glibc |
| 56 |
implementation). It actually fails on the latest Ubuntu LTS Trusty Tahr, |
| 57 |
which means the test will have to be fixed or disabled upstream. But 6 |
| 58 |
months of no reaction is not really a good sign IMHO. |
| 59 |
|
| 60 |
Paweł |
Archives