| 1 |
On Tue, 2007-06-19 at 05:32 +0300, Mart Raudsepp wrote: |
| 2 |
> Hey, |
| 3 |
> |
| 4 |
> On E, 2007-06-18 at 11:34 -0700, Chris Gianelloni wrote: |
| 5 |
> > Also, remember that stabilization is *supposed* to be about the |
| 6 |
> > stabilization of the *ebuild* and not the *package* itself. |
| 7 |
> |
| 8 |
> This sentence made me personally start looking at the policy in a |
| 9 |
> different way as far as stabilization and waiting for a set amount of |
| 10 |
> days is concerned. |
| 11 |
> |
| 12 |
> Does this mean that, when for example there are pure bug fix releases in |
| 13 |
> GNOME packages with no ebuild changes whatsoever, then we can consider, |
| 14 |
> without hesitation so much, to ask stabilization of these much sooner |
| 15 |
> than 30 days? Or the new version just has updated translations, which is |
| 16 |
> cool too (unless it's a very long building package) to get into the |
| 17 |
> hands of our world-wide users earlier with no practical chance of |
| 18 |
> breakage. |
| 19 |
|
| 20 |
Honestly, yes. It means exactly that. If you, as the maintainer, feel |
| 21 |
that it can go stable sooner, then ask for it. Just remember that in |
| 22 |
the end, it is you that is responsible for the package and to your |
| 23 |
users, so use your best judgement. I wouldn't recommend this for a |
| 24 |
large number of packages, but, as you said, if it were a few updated |
| 25 |
translations or something else that is fairly trivial, I see no real |
| 26 |
reason to wait some predetermined amount of time for what is really no |
| 27 |
more than a simple data change. |
| 28 |
|
| 29 |
> Right now it is a rare exception to ask stabilization earlier than 30 |
| 30 |
> days, but should we do that more often for cases like I made an example |
| 31 |
> of (upstream following a strict bug-fixes/translations only rule as well |
| 32 |
> for the versions in question)? |
| 33 |
|
| 34 |
Again, it is really up to you, as the maintainer. I have asked for |
| 35 |
stabilization of packages in the past very quickly if the changes were |
| 36 |
quite minor. There have been a couple cases where the only change from |
| 37 |
upstream was applying the patches we were already applying in the tree |
| 38 |
to the official release and pushing out a new tarball. Think of it like |
| 39 |
this. You have foo-0.4.1 in the tree. You find a couple bugs, patch |
| 40 |
them up, and send them to upstream. You make foo-0.4.1-r1 with your |
| 41 |
patches, and it eventually becomes stable. Now, upstream makes |
| 42 |
foo-0.4.2, which is just your patches applied to 0.4.1 and the version |
| 43 |
number bumped. How much additional testing do you think that this |
| 44 |
needs? After all, the code is the same (minus the version stamp... ;p) |
| 45 |
so there's nothing new to test. |
| 46 |
|
| 47 |
This is why the discretion is left up to the maintainer. We expect the |
| 48 |
maintainer to be aware of things like this and act accordingly, using |
| 49 |
their own judgement and (un)common sense. |
| 50 |
|
| 51 |
-- |
| 52 |
Chris Gianelloni |
| 53 |
Release Engineering Strategic Lead |
| 54 |
Alpha/AMD64/x86 Architecture Teams |
| 55 |
Games Developer/Council Member/Foundation Trustee |
| 56 |
Gentoo Foundation |
Archives