1 |
On Fri, Nov 11, 2011 at 4:32 AM, Brian Harring <ferringb@×××××.com> wrote: |
2 |
> On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom???? Chv??tal wrote: |
3 |
> One thing that is less obvious is that there are essentially two |
4 |
> flavors of unstable chromium- dev and beta. Currently beta is 17.*, |
5 |
> dev is 16.*. If you don't want bleeding edge, but want faster than |
6 |
> stable, pmask 17.*. |
7 |
|
8 |
I agree that the solution to this particular problem is to run stable. |
9 |
However, it is worth noting that chromium deviates from the normal |
10 |
gentoo testing workflow quite a bit. |
11 |
|
12 |
For a typical package new builds are introduced as a higher version, |
13 |
stay in the tree for a month, and then get marked stable. Often not |
14 |
every version makes it to stable, so there is little churn in the |
15 |
stable version. |
16 |
|
17 |
For chromium new builds are introduced as a higher version for the |
18 |
unstable branches, but never make it to stable. Instead, typically |
19 |
stable gets updated as a result of security/bugfixes with new versions |
20 |
being introduced into the tree and quickly being stabilized. Since |
21 |
the new versions are lower than the existing unstable versions nobody |
22 |
but the developers ever actually test them. So, the stable branch of |
23 |
chromium doesn't benefit from extended testing by the ~arch community. |
24 |
The only way it could get tested is if a particular build was |
25 |
released from dev to beta without any changes, and then from beta to |
26 |
stable without any changes - which never happens. |
27 |
|
28 |
Now, this is mitigated to an extent by the fact that Google is |
29 |
following a relatively strict upstream QA process. A similar |
30 |
situation exists with the kernel where new stable LTS versions get |
31 |
introduced and yet never hit the ~arch users who are using versions |
32 |
beyond them. |
33 |
|
34 |
I'm not sure the current situation is "broken" per se and needs |
35 |
fixing. But, the interaction of upstream QA and Gentoo QA is |
36 |
something that we might want to think about. Since most upstream |
37 |
projects have nowhere near the level of QA as either chromium or the |
38 |
kernel this isn't going to be a widespread issue. |
39 |
|
40 |
Rich |