Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: Brian Harring <ferringb@×××××.com>
Cc: scarabeus@g.o, gentoo-dev@l.g.o, chromium@g.o
Subject: Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
Date: Fri, 11 Nov 2011 12:36:13
Message-Id: CAGfcS_nSP_N-Abb-JBvfZtTe48Tt74w3OMvwhHREHhz_wV-7+Q@mail.gmail.com
In Reply to: Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly by Brian Harring
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