Re: [gentoo-dev] Arches marking ebuilds stable before maintainer

[Ciaran McCreesh]

On Sat, 19 Jun 2004 01:27:50 +0200 Carsten Lohrke <carlo@g.o>
wrote:
| > If an ebuild is missing significant things or conflicting with other
| > packages, it should be in package.mask. ~ isn't a dumping ground for
| > known broken ebuilds, it's an indication that the package is a
| > candidate for stable after testing.
| >
| As Donnie said: package.mask'ed ebuilds most likely result either in
| less bug reports or more users whining about broken stuff, because a
| lot of them would unmask nearly everything then. When becoming a dev I
| was told, that an ebuild can/should be marked stable thirty days after
| the last known bug is fixed. Does every arch team member adhere this
| rule and look at bugs.g., if there is an open bug report left and if
| the last ebuild change is from a month ago, before declaring an ebuild
| stable on xyz?

Thirty days? No. What we consider a reasonable period based upon the
scope of the package and the degree of the change? Yes. We keep
toolchain and base system components ~ for a lot longer than thirty
days. On the other hand, a minor bug fix for a non-critical application
might go stable after a week. That "30" is a rough guideline, not a hard
rule.

Surpisingly enough, the arch teams do know what they're doing here. We
don't go around marking all kinds of broken packages stable. However, we
*will* mark things stable before what Foser calls the "indicator arch"
if we feel that it is appropriate. Remember, the core system can be very
different version-wise between different archs.

What we're doing works. We know from user feedback that stable sparc and
mips *are* stable (well, to the extent possible given how b0rked the
kernel can be...). Unlike x86, who don't currently have a dedicated
team maintaining the stable tree, we don't get people on mailing lists
and the forums saying "you might as well run ~arch, it's just as likely
to be broken".

Case in point: the "indicator arch" for xorg-x11 would be considered
x86. If we were to wait for x86 to mark xorg-x11 stable before it went
sparc, we would still be stuck with xfree 4.3.0 which (on sparc) doesn't
work with 2.6.x kernels, doesn't have working opengl and doesn't have
working DRM. As it is, by going ahead of the "indicator arch", we have a
far more stable X server which, although it has a few small issues
remaining, works a hell of a lot better than the previous version.

Or, if you'd like a non-core example... dnsmasq 1.x had strange issues
with dhcp on certain sparc boxes, whereas the 2.x series didn't. The
same problem didn't appear on x86, so the maintainer was in no
particular hurry to switch over 2.x to x86. sparc went ahead of the
"indicator arch", resulting in non-broken dhcp for sparc users. Yes, we
hit one minor issue because of this, but the more serious problem was
fixed as a result.

| - From an organizational point of view it would be better, if the arch
| teams would file a (P1) request via bug.g.o, giving the maintainer
| (herd/s) the possibility to comment it. On the other hand I don't
| think Gentoo has enough developers yet, to add another bit of
| overhead. :-/

If in doubt, the relevant person is consulted on IRC or by email first.

This isn't a case of us consistently going around marking dodgy things
as stable. We keyword *as is appropriate*, and the system works.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm