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
