[gentoo-dev] Policy for late/slow stabilizations

[gentoo-dev] Policy for late/slow stabilizations

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

Hi

As many of you have already noticed, there are some arches that are quite
slow on stabilizations. This leads to deprecated stabilizations e.g a
package is stabilized after 60 days which makes that version of
the specific package obsolete and not worth to stabilize anymore.

I would suggest to introduce a new rule where a stabilization bug may close
after 30 days. Arches that fail to stabilize it within this timeframe
they will simply don't have this package stable for them.

Moreover, slow arches introduce another problem as well. If a package is
marked stabled for their arch, but this package is quite old, and they fail to
stabilize a new version, we ( as maintainers ) can't drop the very old
( and obsolete ) version of this package because we somehow will break
the stable tree for these arches. How should we act in this case?
Keep the old version around forever just to say that "hey, they do have
a stable version for our exotic arch".

Whilst I do understand that these arches are understaffed and they can't keep
up with the increased stabilization load like x86/amd64 do, I still
think that slow stabilization leads to an obsolete stable tree which I
doesn't make sense to me after all.

Thoughts?

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Patrick Lauer]

On 06/27/10 17:04, Markos Chandras wrote:
[snip]
> Whilst I do understand that these arches are understaffed and they can't keep
> up with the increased stabilization load like x86/amd64 do, I still
> think that slow stabilization leads to an obsolete stable tree which I
> doesn't make sense to me after all.
> 
> Thoughts?
> 

I see two scenarios - either we get the "slow" arches enough cpu- and
manpower, or we remove their stable keywords.

If possible I think we should try to keep stable keywords. So how can we
help? I'm not sure how I could help e.g. PPC - I don't have any hardware
I can test on, and I'm not aware of remotely accessible dev boxen.

So - how can we improve this situation?

Re: [gentoo-dev] Policy for late/slow stabilizations

[Tony "Chainsaw" Vroon]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Sun, 2010-06-27 at 17:45 +0200, Patrick Lauer wrote:
> If possible I think we should try to keep stable keywords. So how can we
> help? I'm not sure how I could help e.g. PPC - I don't have any hardware
> I can test on, and I'm not aware of remotely accessible dev boxen.

There are options, an older Playstation III with a faulty Blu-Ray drive
is still usable as a PPC64 (32UL) test box. For developers that actively
want to help, perhaps the arch teams can recommend hardware that is
relatively easy to acquire and guaranteed to be supported/stable from a
kernel point of view.
I've done my best to supply an example.

Regards,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
> Moreover, slow arches introduce another problem as well. If a package is
> marked stabled for their arch, but this package is quite old, and they fail to
> stabilize a new version, we ( as maintainers ) can't drop the very old
> ( and obsolete ) version of this package because we somehow will break
> the stable tree for these arches. How should we act in this case?
> Keep the old version around forever just to say that "hey, they do have
> a stable version for our exotic arch".

I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then
just drop the old ebuild. These arches will slowly lose stable keywords
until their stable tree gets to a size that they can manage. And
everyone will be winners. That said, when dropping the old keywords, you
have to be careful to drop the stable keyword on all dependencies too so
as to not drop break the tree for them.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

On Sun, Jun 27, 2010 at 11:47:49AM -0400, Olivier Crête wrote:
> On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
> > Moreover, slow arches introduce another problem as well. If a package is
> > marked stabled for their arch, but this package is quite old, and they fail to
> > stabilize a new version, we ( as maintainers ) can't drop the very old
> > ( and obsolete ) version of this package because we somehow will break
> > the stable tree for these arches. How should we act in this case?
> > Keep the old version around forever just to say that "hey, they do have
> > a stable version for our exotic arch".
> 
> I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then
> just drop the old ebuild. These arches will slowly lose stable keywords
> until their stable tree gets to a size that they can manage. And
> everyone will be winners. That said, when dropping the old keywords, you
> have to be careful to drop the stable keyword on all dependencies too so
> as to not drop break the tree for them.
>
When dropping an old *stable* ebuild, which in most cases this will be the
only stable ebuild that these arches will have for this packages, the
next world update will be ugly since there will be no *stable *
candidates for that package anymore. In this case, stable users will
start filling package.keywords leading to ~testing migration. So I am
not sure if this is the correct approach to deal with this but I can't
think of anything else
> -- 
> Olivier Crête
> tester@gentoo.org
> Gentoo Developer



-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

On Sun, 2010-06-27 at 18:54 +0300, Markos Chandras wrote:
> On Sun, Jun 27, 2010 at 11:47:49AM -0400, Olivier Crête wrote:
> > On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
> > > Moreover, slow arches introduce another problem as well. If a package is
> > > marked stabled for their arch, but this package is quite old, and they fail to
> > > stabilize a new version, we ( as maintainers ) can't drop the very old
> > > ( and obsolete ) version of this package because we somehow will break
> > > the stable tree for these arches. How should we act in this case?
> > > Keep the old version around forever just to say that "hey, they do have
> > > a stable version for our exotic arch".
> > 
> > I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then
> > just drop the old ebuild. These arches will slowly lose stable keywords
> > until their stable tree gets to a size that they can manage. And
> > everyone will be winners. That said, when dropping the old keywords, you
> > have to be careful to drop the stable keyword on all dependencies too so
> > as to not drop break the tree for them.
> >
> When dropping an old *stable* ebuild, which in most cases this will be the
> only stable ebuild that these arches will have for this packages, the
> next world update will be ugly since there will be no *stable *
> candidates for that package anymore. In this case, stable users will
> start filling package.keywords leading to ~testing migration. So I am
> not sure if this is the correct approach to deal with this but I can't
> think of anything else

That's ok. That way those users will know that no one from the arch team
maintains that packages and they will know it has a lower level of QA.
And the users will be able to make a choice. Instead of pretending that
it is maintained.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Sun, Jun 27, 2010 at 02:21:13PM -0400, Olivier Crête wrote:
> 
> That's ok. That way those users will know that no one from the arch team
> maintains that packages and they will know it has a lower level of QA.
> And the users will be able to make a choice. Instead of pretending that
> it is maintained.
> 
> -- 
> Olivier Crête
> tester@gentoo.org
> Gentoo Developer

+1. This is what I am trying to say

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Samuli Suominen]

On 06/27/2010 06:47 PM, Olivier Crête wrote:
> On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
>> Moreover, slow arches introduce another problem as well. If a package is
>> marked stabled for their arch, but this package is quite old, and they fail to
>> stabilize a new version, we ( as maintainers ) can't drop the very old
>> ( and obsolete ) version of this package because we somehow will break
>> the stable tree for these arches. How should we act in this case?
>> Keep the old version around forever just to say that "hey, they do have
>> a stable version for our exotic arch".
> 
> I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then
> just drop the old ebuild. These arches will slowly lose stable keywords
> until their stable tree gets to a size that they can manage. And
> everyone will be winners. That said, when dropping the old keywords, you
> have to be careful to drop the stable keyword on all dependencies too so
> as to not drop break the tree for them.
> 

+1

Re: [gentoo-dev] Policy for late/slow stabilizations

[Jeroen Roovers]

On Sun, 27 Jun 2010 11:47:49 -0400
Olivier Crête <tester@gentoo.org> wrote:

> I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and
> then just drop the old ebuild. These arches will slowly lose stable
> keywords until their stable tree gets to a size that they can manage.
> And everyone will be winners. That said, when dropping the old
> keywords, you have to be careful to drop the stable keyword on all
> dependencies too so as to not drop break the tree for them.

+1

Dead arches need to be allowed to die.


     jer

Re: [gentoo-dev] Policy for late/slow stabilizations

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

On Sun, 27 Jun 2010 18:04:45 +0300
Markos Chandras <hwoarang@gentoo.org> wrote:
> Whilst I do understand that these arches are understaffed and they
> can't keep up with the increased stabilization load like x86/amd64
> do, I still think that slow stabilization leads to an obsolete stable
> tree which I doesn't make sense to me after all.

Which does Gentoo care about more: slightly increased convenience for
most developers, or considerably increased inconvenience for users of
minority archs?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

On Sun, Jun 27, 2010 at 05:38:34PM +0100, Ciaran McCreesh wrote:
> On Sun, 27 Jun 2010 18:04:45 +0300
> Markos Chandras <hwoarang@gentoo.org> wrote:
> > Whilst I do understand that these arches are understaffed and they
> > can't keep up with the increased stabilization load like x86/amd64
> > do, I still think that slow stabilization leads to an obsolete stable
> > tree which I doesn't make sense to me after all.
> 
> Which does Gentoo care about more: slightly increased convenience for
> most developers, or considerably increased inconvenience for users of
> minority archs?
> 
> -- 
> Ciaran McCreesh
I don't follow you. Increased convenience just for the devs? How?All I
want is to have packages stabled ~60 days after the initial commit on
tree instead of ~5 months. If arches can't do that then I don't want to
mark that obsolete package stable at all. Whats the point?
Also I would prefer to be able to drop ancient stable packages from the
tree even if that means that there wont be any other stable version for
this package to use. I 'd prefer a working tiny stable tree
than a huge ancient one


-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

On Sun, 27 Jun 2010 20:22:33 +0300
Markos Chandras <hwoarang@gentoo.org> wrote:
> > Which does Gentoo care about more: slightly increased convenience
> > for most developers, or considerably increased inconvenience for
> > users of minority archs?
> > 
> I don't follow you. Increased convenience just for the devs? How?

Not having to keep old versions around for a few archs is slightly more
convenient for most people.

Having to deal with dropped keywords is a huge inconvenience for users
on minority archs.

> All I want is to have packages stabled ~60 days after the initial
> commit on tree instead of ~5 months. If arches can't do that then I
> don't want to mark that obsolete package stable at all. Whats the
> point?

The point is for users of minor archs to have something that works.

> Also I would prefer to be able to drop ancient stable packages
> from the tree even if that means that there wont be any other stable
> version for this package to use. I 'd prefer a working tiny stable
> tree than a huge ancient one

The problem with that is that presumably some minority arch users are
using the packages you'd be dropping. When that happens, dropped
keywords are a considerable cost to them.

Which is the decision to make: make things very difficult for minority
arch users, who get screwed over royally every time keywords are
dropped, or make things slightly more inconvenient for developers, who
have to keep some things around for longer. It's all down to whether
you think happy users are more important than happy developers.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

On Sun, Jun 27, 2010 at 06:43:30PM +0100, Ciaran McCreesh wrote:
> 
> Which is the decision to make: make things very difficult for minority
> arch users, who get screwed over royally every time keywords are
> dropped, or make things slightly more inconvenient for developers, who
> have to keep some things around for longer. It's all down to whether
> you think happy users are more important than happy developers.
> 
> -- 
> Ciaran McCreesh

Please explain me why keeping foobar-1.0 ( Released in 10/12/2009 ) is
in favor of a ppc64 stable user when amd64/x86 has foobar-2.1.3 (
Released 60 days ago ) already stabled for them

What if a foobar-1.0 bug pops up? What kind of support will that user
get from the gentoo or upstream maintainer. The most frequent answer
would be "Please update to 2.1.3. 1.0 is 0ld". Yes, not droppping the
keywords is convenient for users but in this case their stable tree gets
obsolet and unsupported

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]

On Sun, 27 Jun 2010 19:01:13 +0100
Markos Chandras <hwoarang@gentoo.org> wrote:
> Please explain me why keeping foobar-1.0 ( Released in 10/12/2009 ) is
> in favor of a ppc64 stable user when amd64/x86 has foobar-2.1.3 (
> Released 60 days ago ) already stabled for them

Because it's known to work. That's the point of stable.

> What if a foobar-1.0 bug pops up? What kind of support will that user
> get from the gentoo or upstream maintainer. The most frequent answer
> would be "Please update to 2.1.3. 1.0 is 0ld". Yes, not droppping the
> keywords is convenient for users but in this case their stable tree
> gets obsolet and unsupported

When that happens, *then* stabling foobar can become a priority, and
the user in question can help with it. However, given the finite amount
of development time available, you need to bear in mind that foobar is
nowhere near as special as you'd like to think, that Debian is still
running foobar 0.0.1, and that something that is known to work is, for
many users, better than something that might work.

Which, again, is the point: to what extent do you care about users? If
you're prepared to tell users to expect annoying breakages that take a
lot of work to fix as things get keyworded every now and again because
it makes things marginally easier for developers, then go ahead and
unkeyword a package plus lots of deps. If you think users are the
distribution's primary asset, however, then it's worth inconveniencing
yourselves slightly every now and again to save them a lot of pain.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Policy for late/slow stabilizations

[Duncan]

Ciaran McCreesh posted on Sun, 27 Jun 2010 18:43:30 +0100 as excerpted:

> On Sun, 27 Jun 2010 20:22:33 +0300
> Markos Chandras <hwoarang@gentoo.org> wrote:
>> > Which does Gentoo care about more: slightly increased convenience for
>> > most developers, or considerably increased inconvenience for users of
>> > minority archs?
>> > 
>> I don't follow you. Increased convenience just for the devs? How?
> 
> Not having to keep old versions around for a few archs is slightly more
> convenient for most people.
> 
> Having to deal with dropped keywords is a huge inconvenience for users
> on minority archs.

As already stated on the other sub-threads, that's not the point at all.  
Rather, it's a simple matter of letting an arch's stable tree dynamically 
and realistically adjust to the level of arch support they have.  If the 
stable set gets small enough, it's probably time to officially reduce the 
arch status to testing tree support only, not security supported, etc.  
But well before that point, it's likely a core package set can be 
maintained at stable, with perhaps certain arch-usage specific area stable 
support as well, while still being unrealistic to try to keep a stable 
version of (nearly) all at-one-point-known-to-work packages available.

If the arch support simply isn't there, it really is better to have that 
reflected in the size of the stable set, such that users actually know 
that and know what's being actively supported on their arch and what 
isn't, than to try to fake it, which is what's going on now.  It's not a 
question of more convenience vs less, but of having arch keyword status 
reflect arch support reality.

That said, if there's not already a simple way to get the info out of VCS 
(perhaps there is, I don't know), archs may wish to maintain a list of 
packages and versions that once were stable, along with comments on 
specific destabilization reason (it didn't work with gcc-vX on that arch, 
for instance) if known, so it'll be somewhat easier to expand stable 
coverage again if we happen to pickup a few new devs with a strong 
interest in the arch.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Policy for late/slow stabilizations

[Auke Booij]

On Sun, Jun 27, 2010 at 5:04 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> Thoughts?

If Gentoo doesn't seem to have time to maintain the stable tree, why
have it in the first place? What really is the advantage of having a
stable tree?

Re: [gentoo-dev] Policy for late/slow stabilizations

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

On Sun, Jun 27, 2010 at 06:53:56PM +0200, Auke Booij wrote:
> On Sun, Jun 27, 2010 at 5:04 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> > Thoughts?
> 
> If Gentoo doesn't seem to have time to maintain the stable tree, why
> have it in the first place? What really is the advantage of having a
> stable tree?
> 
What? I am talking about exotic arches and I didn't say to drop to
entire stable tree. Just to shrink it in order to keep it up to date
more easily
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Auke Booij]

On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> What? I am talking about exotic arches and I didn't say to drop to
> entire stable tree. Just to shrink it in order to keep it up to date
> more easily
But my question stands: what really is the advantage of having a
stable tree, when you could better invest your time in keeping the
testing tree up to date and working? Most production systems are
running x86, right? Are stable versions of minority architecture
installations really that much more stable than testing versions?

PS: this is by no means a rhetorical question.
PPS: bonus points for the person who can tell me a good opposite of
"rhetorical".

Re: [gentoo-dev] Policy for late/slow stabilizations

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Sun, Jun 27, 2010 at 08:15:32PM +0200, Auke Booij wrote:
> On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> > What? I am talking about exotic arches and I didn't say to drop to
> > entire stable tree. Just to shrink it in order to keep it up to date
> > more easily
> But my question stands: what really is the advantage of having a
> stable tree, when you could better invest your time in keeping the
> testing tree up to date and working? Most production systems are
> running x86, right? Are stable versions of minority architecture
> installations really that much more stable than testing versions?
Because a stable tree it is supposed to work. Testing tree on the other
hand is vulnerable to breakages from time to time. We can't always
ensure a working testing tree. We are people not machines. We tend to
brake things and this is way we have the testing branch. 
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Thilo Bangert]

[-- Attachment #1: Type: Text/Plain, Size: 1065 bytes --]

Markos Chandras <hwoarang@gentoo.org> said:
> On Sun, Jun 27, 2010 at 08:15:32PM +0200, Auke Booij wrote:
> > On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras <hwoarang@gentoo.org> 
wrote:
> > > What? I am talking about exotic arches and I didn't say to drop to
> > > entire stable tree. Just to shrink it in order to keep it up to
> > > date more easily
> > 
> > But my question stands: what really is the advantage of having a
> > stable tree, when you could better invest your time in keeping the
> > testing tree up to date and working? Most production systems are
> > running x86, right? Are stable versions of minority architecture
> > installations really that much more stable than testing versions?
> 
> Because a stable tree it is supposed to work. Testing tree on the other
> hand is vulnerable to breakages from time to time. We can't always
> ensure a working testing tree. We are people not machines. We tend to
> brake things and this is way we have the testing branch.

also the stable tree implies security support (GLSAs etc).

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Mart Raudsepp]

On E, 2010-06-28 at 09:49 +0200, Thilo Bangert wrote:
> Markos Chandras <hwoarang@gentoo.org> said:
> > On Sun, Jun 27, 2010 at 08:15:32PM +0200, Auke Booij wrote:
> > > On Sun, Jun 27, 2010 at 7:16 PM, Markos Chandras <hwoarang@gentoo.org> 
> wrote:
> > > > What? I am talking about exotic arches and I didn't say to drop to
> > > > entire stable tree. Just to shrink it in order to keep it up to
> > > > date more easily
> > > 
> > > But my question stands: what really is the advantage of having a
> > > stable tree, when you could better invest your time in keeping the
> > > testing tree up to date and working? Most production systems are
> > > running x86, right? Are stable versions of minority architecture
> > > installations really that much more stable than testing versions?
> > 
> > Because a stable tree it is supposed to work. Testing tree on the other
> > hand is vulnerable to breakages from time to time. We can't always
> > ensure a working testing tree. We are people not machines. We tend to
> > brake things and this is way we have the testing branch.
> 
> also the stable tree implies security support (GLSAs etc).

Stable tree does NOT imply security support. I can understand why users
might think that, though.
A few architectures that have a stable tree are not security supported
(GLSAs waiting for them, etc), as can be seen from comparing the arches
with stable trees to the security supported architectures list over at
http://www.gentoo.org/security/en/vulnerability-policy.xml
(at least arm, ia64 and sh by my quick comparison)


-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://blogs.gentoo.org/leio

Re: [gentoo-dev] Policy for late/slow stabilizations

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1704 bytes --]

2010-06-27 17:04:45 Markos Chandras napisał(a):
> Hi
> 
> As many of you have already noticed, there are some arches that are quite
> slow on stabilizations. This leads to deprecated stabilizations e.g a
> package is stabilized after 60 days which makes that version of
> the specific package obsolete and not worth to stabilize anymore.
> 
> I would suggest to introduce a new rule where a stabilization bug may close
> after 30 days. Arches that fail to stabilize it within this timeframe
> they will simply don't have this package stable for them.
> 
> Moreover, slow arches introduce another problem as well. If a package is
> marked stabled for their arch, but this package is quite old, and they fail to
> stabilize a new version, we ( as maintainers ) can't drop the very old
> ( and obsolete ) version of this package because we somehow will break
> the stable tree for these arches. How should we act in this case?
> Keep the old version around forever just to say that "hey, they do have
> a stable version for our exotic arch".
> 
> Whilst I do understand that these arches are understaffed and they can't keep
> up with the increased stabilization load like x86/amd64 do, I still
> think that slow stabilization leads to an obsolete stable tree which I
> doesn't make sense to me after all.
> 
> Thoughts?

+1.
The period of waiting might be extended to 60 days.

This period should be counted from the first ignored stabilization request.
Stabilizations of some packages are filed e.g. once per month and some
architectures don't manage to stabilize older versions before stabilization
requests of new versions.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Tony "Chainsaw" Vroon]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
> As many of you have already noticed, there are some arches that are quite
> slow on stabilizations. This leads to deprecated stabilizations e.g a
> package is stabilized after 60 days which makes that version of
> the specific package obsolete and not worth to stabilize anymore.

So you would suggest to be like Ubuntu and say "we can not be bothered
to support any minority architectures anymore". This effectively
disbands all architecture teams except AMD64 and X86; it should be
subject to the same scrutiny (I suggest a council vote) as a GLEP or
EAPI change.
Personally I would like to hear stronger reasons then "it inconveniences
me when a bug I file is open longer then a month" to destroy the current
diversity of supported architectures (be it PowerPC or a prefix
installation on OS X).

Regards,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]

On Sun, Jun 27, 2010 at 07:37:39PM +0100, Tony Chainsaw Vroon wrote:
> On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote:
> > As many of you have already noticed, there are some arches that are quite
> > slow on stabilizations. This leads to deprecated stabilizations e.g a
> > package is stabilized after 60 days which makes that version of
> > the specific package obsolete and not worth to stabilize anymore.
> 
> So you would suggest to be like Ubuntu and say "we can not be bothered
> to support any minority architectures anymore". This effectively
> disbands all architecture teams except AMD64 and X86; it should be
> subject to the same scrutiny (I suggest a council vote) as a GLEP or
> EAPI change.
> Personally I would like to hear stronger reasons then "it inconveniences
> me when a bug I file is open longer then a month" to destroy the current
> diversity of supported architectures (be it PowerPC or a prefix
> installation on OS X).
> 
> Regards,
> Tony V.

Oh come on. I never said to stop supporting those arches. I just said to
shrink their stable tree. What do you suggest? Pretend to have active
exotic arches just to look shiny and pretty?

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On Sun, 27 Jun 2010 22:55:42 +0300
Markos Chandras <hwoarang@gentoo.org> wrote:
> Oh come on. I never said to stop supporting those arches. I just said
> to shrink their stable tree. What do you suggest? Pretend to have
> active exotic arches just to look shiny and pretty?

Claiming to support an exotic arch but forcing people to run ~arch on
it is not supporting it at all. One of the problems with exotic archs
is that they are much more likely to show up bugs than things that are
commonly used, and so knowing that something has been properly tested
is a lot more important there.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

On Sun, Jun 27, 2010 at 09:01:55PM +0100, Ciaran McCreesh wrote:
> On Sun, 27 Jun 2010 22:55:42 +0300
> Markos Chandras <hwoarang@gentoo.org> wrote:
> > Oh come on. I never said to stop supporting those arches. I just said
> > to shrink their stable tree. What do you suggest? Pretend to have
> > active exotic arches just to look shiny and pretty?
> 
> Claiming to support an exotic arch but forcing people to run ~arch on
> it is not supporting it at all. One of the problems with exotic archs
> is that they are much more likely to show up bugs than things that are
> commonly used, and so knowing that something has been properly tested
> is a lot more important there.
> 
> -- 
> Ciaran McCreesh

Ok then according to your definition that supported arches == stable
tree, I can safely assume that we cannot support those arches
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Nirbheek Chauhan]

On Sun, Jun 27, 2010 at 8:34 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> As many of you have already noticed, there are some arches that are quite
> slow on stabilizations. This leads to deprecated stabilizations e.g a
> package is stabilized after 60 days which makes that version of
> the specific package obsolete and not worth to stabilize anymore.
>
> I would suggest to introduce a new rule where a stabilization bug may close
> after 30 days. Arches that fail to stabilize it within this timeframe
> they will simply don't have this package stable for them.
>

I disagree that just 30 days is enough to make a package obsolete and
not worth stabilizing. Infact, I think you're suggesting the number in
jest. GNOME for instance has a 6 month cycle, and we stabilize 1-4
months after the release (depending on the bugs, and our manpower).
For instance, the current release is 2.30 (~arch, released in March
'10, added to tree just a month ago), the previous release was 2.28
(stable, released in Sept '09), but the stable version on every arch
except amd64/x86 is 2.26 (released in March '09). And that's OK since
it got stable updates for a long time after release, and works
wonderfully. In essence, GNOME packages don't become obsolete unless
it's been 2 years since they were released.

I'm saying that a 30 days rule is too strict for most packages and
herds. I don't think such a rule will fly very far. Even a 90 day rule
or a 6 month rule is too strict for GNOME packages. I personally
empathize with the needs of users enough that I (and most of the gnome
team) are willing to wait for arches that cannot handle stabilization
bugs. We really don't want our users to have a bad experience because
of *us*. We'll do whatever is in our power.



> Moreover, slow arches introduce another problem as well. If a package is
> marked stabled for their arch, but this package is quite old, and they fail to
> stabilize a new version, we ( as maintainers ) can't drop the very old
> ( and obsolete ) version of this package because we somehow will break
> the stable tree for these arches. How should we act in this case?
> Keep the old version around forever just to say that "hey, they do have
> a stable version for our exotic arch".
>

Now *this* is a problem. We have some bugs, some security bugs that
have been completely ignored by some arches. Mips as usual is one, but
recently hppa (and to a much lesser extent, ppc64) have become slow.

To fix this, I suggest the following heuristic:

* If an arch cannot stabilize *security bugs* after 3 months, the
maintainers are free to drop the vulnerable version.
* If an arch cannot stabilize versions which fix major bugs after 6
months, the maintainers are free to drop the broken version.
* If an arch cannot stabilize a feature/minor bugfix stable request
after 12 months, the maintainers can nuke stable keywords from their
package.

In all cases, the time is to be counted from the original
stabilization request. Exceptions may be made in case newer
stabilization requests add extra dependencies to be stabilized.

Similar (but laxer) rules can be made for KEYWORDREQ bugs as well.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Policy for late/slow stabilizations

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

On Mon, Jun 28, 2010 at 01:59:42AM +0530, Nirbheek Chauhan wrote:
> 
> I'm saying that a 30 days rule is too strict for most packages and
> herds. I don't think such a rule will fly very far. Even a 90 day rule
> or a 6 month rule is too strict for GNOME packages. I personally
> empathize with the needs of users enough that I (and most of the gnome
> team) are willing to wait for arches that cannot handle stabilization
> bugs. We really don't want our users to have a bad experience because
> of *us*. We'll do whatever is in our power.
> 
The '30 days' was just an example. Any reasonable timeframe could do
> 
> 
> > Moreover, slow arches introduce another problem as well. If a package is
> > marked stabled for their arch, but this package is quite old, and they fail to
> > stabilize a new version, we ( as maintainers ) can't drop the very old
> > ( and obsolete ) version of this package because we somehow will break
> > the stable tree for these arches. How should we act in this case?
> > Keep the old version around forever just to say that "hey, they do have
> > a stable version for our exotic arch".
> >
> 
> Now *this* is a problem. We have some bugs, some security bugs that
> have been completely ignored by some arches. Mips as usual is one, but
> recently hppa (and to a much lesser extent, ppc64) have become slow.
> 
> To fix this, I suggest the following heuristic:
> 
> * If an arch cannot stabilize *security bugs* after 3 months, the
> maintainers are free to drop the vulnerable version.
What if this version is the only one that is stabled for this arch. Can
you imagine the possible breakage that this action might cause?

The problem is exactly here. 

If a package has only one version stable for an exotic arch, you cannot
drop it because:

* you will break packages that depend on it
* you will make users angry

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Policy for late/slow stabilizations

[Nirbheek Chauhan]

On Mon, Jun 28, 2010 at 3:08 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
> On Mon, Jun 28, 2010 at 01:59:42AM +0530, Nirbheek Chauhan wrote:
>> Now *this* is a problem. We have some bugs, some security bugs that
>> have been completely ignored by some arches. Mips as usual is one, but
>> recently hppa (and to a much lesser extent, ppc64) have become slow.
>>
>> To fix this, I suggest the following heuristic:
>>
>> * If an arch cannot stabilize *security bugs* after 3 months, the
>> maintainers are free to drop the vulnerable version.
>
> What if this version is the only one that is stabled for this arch. Can
> you imagine the possible breakage that this action might cause?
>
> The problem is exactly here.
>
> If a package has only one version stable for an exotic arch, you cannot
> drop it because:
>
> * you will break packages that depend on it
> * you will make users angry
>

I agree. I didn't mean to imply that these heuristics were in any way
complete. I wrote them in a hurry; I only wanted to give an idea of
what my opinion on the matter is. We can add the following:

* For each arch, stable keywords are to be removed from
vulnerable/broken versions one week after newer versions are
stabilized on that arch.
* If removing stable keywords will lead to a large cascading effect of
reverse dependencies losing stable keywords, the 3 month wait should
be extended to 6 months or 12 months depending on the brokenness and
no. of packages that will get their keywords dropped.
* Maintainers are free to wait as long as they wish for arches, the
above guidelines merely give a lower bound to the wait time.
* In extenuating circumstances (critical vulnerabilities, complete
brokenness, etc), with the permission of the QA team, the wait can be
shortened, but it should never be less than a month.

This means that old broken/vulnerable ebuilds are not visible to any
arches except those that are slow. And if an arch cannot take out the
time to stabilized a vulnerable and/or badly broken version for a full
year, there's nothing we can do. If this is a chronic problem, we
should consider marking the arch as "Experimental".

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team