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