Re: [gentoo-dev] Determining ebuild stability and the 30 day suggestion (was: QA issue: No stable skype in Tree)

2007-06-19 Thread Chris Gianelloni
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


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Determining ebuild stability and the 30 day suggestion (was: QA issue: No stable skype in Tree)

2007-06-18 Thread Mart Raudsepp
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: [EMAIL PROTECTED]
Weblog: http://planet.gentoo.org/developers/leio


signature.asc
Description: This is a digitally signed message part