Re: [gentoo-dev] Re: Re: aging ebuilds with unstable keywords - how can we help?

[Chris Gianelloni]

On Thu, 2006-07-27 at 12:19 +0000, Duncan wrote:
> "Chris Bainbridge" <chris.bainbridge@×××××.com> posted
> 623652d50607270200h14bae69ai360777afc3d725ae@××××××××××.com, excerpted
> below, on  Thu, 27 Jul 2006 10:00:39 +0100:
>
> > The testing is supposed to be for the ebuild, not the package itself,
> > so there's not much point in holding back packages with simple ebuilds
> > from being stabilised.
>
> While ~arch is supposed to be stable upstream, testing the ebuild, in
> practice there's more to it than that.  "Ebuild" in this case is shorthand
> for "Gentoo aspects of a package, including not only the ebuild script,
> but how the build process functions and the interaction with the various
> available Gentoo gcc/glibc/binutils/etc packages, and how it runs in a
> Gentoo system, including not only file system layout, but how it actually
> runs against the various current Gentoo versions of all its dependencies.

Correct.

If Gentoo had a third tree state, besides arch and ~arch, then *most* of
the ~arch packages would truly belong in the new state.  With the
current tree, this would mean they would be masked in package.mask,
rather than simply being in the tree under ~arch.

> In fact, a specifically enumerated part of an arch-tester's job is to test
> not only build-time success, but that it actually runs reasonably well
> also.  While an arch-tester can't be expected to always be familiar enough
> with the app to test all the little corner cases, when they say it's ready
> to stabilize, they are in effect reporting that it not only compiled, but
> ran "as advertised" with no glaring issues or instabilities thru a
> reasonable test of its runtime functionality as well, such that it should
> be safe to keyword stable, and therefore be available to those that
> actually depend on the app for "mission critical" functionality (whether
> that mission is as a public server, or blasting the other team in an online
> frag-fest).

Well, the idea for the arch team is that the team is responsible for
ensuring that the package works correctly on the given architecture, and
does not interfere with other packages on the architecture.  This is
because not all developers have access to every architecture, and are
also not required to run fully stable systems.  As a side-effect of this
process, the ebuild gets at least a second set of eyes and testing, and
with the arch testers in place, sometimes several extra sets of eyes.

Since the introduction of the x86 architecture team, we have had a
significant slowdown in the "stabilization" of packages in the tree.
However, we have also gotten numerous emails and messages from users who
have said that their systems are much more stable and are highly
appreciative of it.  The thing with stabilization such as this, is it is
a balancing act between the people who want "new" and the people who
want it to "always work" once it is stable.  I tend to think that our
quality has improved dramatically on x86 due to this.  Most of the other
architectures already had this higher level of quality (and many times
lagged behind x86 prior to the x86 arch team) that we have come to know
and love.  I can attest that this extra testing, as well as the
increased efforts of the newly-energized QA project, have made this
release a much more smooth affair than any previous release.  I would
definitely call this a success.  Will it make all of our users happy?
Of course not, but at this point, I don't think that is even a feasibly
attainable goal, since our user base is so diverse.  Our only sane
course of action is to try to appease the majority, and do what we feel
is best for them and for ourselves.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux