On Thu, 2006-07-27 at 12:19 +0000, Duncan wrote: > "Chris Bainbridge" <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], 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
signature.asc
Description: This is a digitally signed message part
