Mailing List Archive

Determining ebuild stability and the 30 day suggestion (was: QA issue: No stable skype in Tree)
Hey,

On E, 2007-06-18 at 11:34 -0700, Chris Gianelloni wrote:
> Also, remember that stabilization is *supposed* to be about the
> stabilization of the *ebuild* and not the *package* itself.

This sentence made me personally start looking at the policy in a
different way as far as stabilization and waiting for a set amount of
days is concerned.

Does this mean that, when for example there are pure bug fix releases in
GNOME packages with no ebuild changes whatsoever, then we can consider,
without hesitation so much, to ask stabilization of these much sooner
than 30 days? Or the new version just has updated translations, which is
cool too (unless it's a very long building package) to get into the
hands of our world-wide users earlier with no practical chance of
breakage.

Right now it is a rare exception to ask stabilization earlier than 30
days, but should we do that more often for cases like I made an example
of (upstream following a strict bug-fixes/translations only rule as well
for the versions in question)?


--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
Re: Determining ebuild stability and the 30 day suggestion [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mart Raudsepp wrote:
> Hey,
>
> On E, 2007-06-18 at 11:34 -0700, Chris Gianelloni wrote:
>> Also, remember that stabilization is *supposed* to be about the
>> stabilization of the *ebuild* and not the *package* itself.
>
> This sentence made me personally start looking at the policy in a
> different way as far as stabilization and waiting for a set amount of
> days is concerned.
>
> Does this mean that, when for example there are pure bug fix releases in
> GNOME packages with no ebuild changes whatsoever, then we can consider,
> without hesitation so much, to ask stabilization of these much sooner
> than 30 days? Or the new version just has updated translations, which is
> cool too (unless it's a very long building package) to get into the
> hands of our world-wide users earlier with no practical chance of
> breakage.
>
> Right now it is a rare exception to ask stabilization earlier than 30
> days, but should we do that more often for cases like I made an example
> of (upstream following a strict bug-fixes/translations only rule as well
> for the versions in question)?
>
>

I use to ask for stabilization of the new version of a package
immediately if it is supposed to fix an *important* security problem in
the package, so that way we spread as soon as possible the new fix to
our users.

Not sure if this is documented somewhere as an exception to the 30 days
rule, but i have not had problems so far and the stabilization teams
have been willing to help me in such a cases.

Regards,

- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGd15QaTNpke9pJcURAiIeAJ9IP9To0xwSU86eWyjOO+N6WQCQjwCeIXxG
+wFGE1phct8Dtzg/0P33+Dk=
=tcgj
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
Re: Determining ebuild stability and the 30 day suggestion [ In reply to ]
On Tuesday 19 June 2007 06:40, Luis Francisco Araujo wrote:
> I use to ask for stabilization of the new version of a package
> immediately if it is supposed to fix an *important* security problem in
> the package, so that way we spread as soon as possible the new fix to
> our users.
>
> Not sure if this is documented somewhere as an exception to the 30 days
> rule, but i have not had problems so far and the stabilization teams
> have been willing to help me in such a cases.

We (the security team) ask for stabilization sooner than 30 days according to
our policy¹. AFAIR it has only resulted in a few glitches now and then. When
they happen they should be assigned to us to fix any regression.

¹ http://www.gentoo.org/security/en/vulnerability-policy.xml
--
Sune Kloppenborg Jeppesen
Gentoo Linux Security Team
--
gentoo-dev@gentoo.org mailing list
Re: Determining ebuild stability and the 30 day suggestion (was: QA issue: No stable skype in Tree) [ In reply to ]
On Tue, 2007-06-19 at 05:32 +0300, Mart Raudsepp wrote:
> Hey,
>
> On E, 2007-06-18 at 11:34 -0700, Chris Gianelloni wrote:
> > Also, remember that stabilization is *supposed* to be about the
> > stabilization of the *ebuild* and not the *package* itself.
>
> This sentence made me personally start looking at the policy in a
> different way as far as stabilization and waiting for a set amount of
> days is concerned.
>
> Does this mean that, when for example there are pure bug fix releases in
> GNOME packages with no ebuild changes whatsoever, then we can consider,
> without hesitation so much, to ask stabilization of these much sooner
> than 30 days? Or the new version just has updated translations, which is
> cool too (unless it's a very long building package) to get into the
> hands of our world-wide users earlier with no practical chance of
> breakage.

Honestly, yes. It means exactly that. If you, as the maintainer, feel
that it can go stable sooner, then ask for it. Just remember that in
the end, it is you that is responsible for the package and to your
users, so use your best judgement. I wouldn't recommend this for a
large number of packages, but, as you said, if it were a few updated
translations or something else that is fairly trivial, I see no real
reason to wait some predetermined amount of time for what is really no
more than a simple data change.

> Right now it is a rare exception to ask stabilization earlier than 30
> days, but should we do that more often for cases like I made an example
> of (upstream following a strict bug-fixes/translations only rule as well
> for the versions in question)?

Again, it is really up to you, as the maintainer. I have asked for
stabilization of packages in the past very quickly if the changes were
quite minor. There have been a couple cases where the only change from
upstream was applying the patches we were already applying in the tree
to the official release and pushing out a new tarball. Think of it like
this. You have foo-0.4.1 in the tree. You find a couple bugs, patch
them up, and send them to upstream. You make foo-0.4.1-r1 with your
patches, and it eventually becomes stable. Now, upstream makes
foo-0.4.2, which is just your patches applied to 0.4.1 and the version
number bumped. How much additional testing do you think that this
needs? After all, the code is the same (minus the version stamp... ;p)
so there's nothing new to test.

This is why the discretion is left up to the maintainer. We expect the
maintainer to be aware of things like this and act accordingly, using
their own judgement and (un)common sense.

--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation