FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-27-2010, 03:04 PM
Markos Chandras
 
Default Policy for late/slow stabilizations

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
 
Old 06-27-2010, 03:45 PM
Patrick Lauer
 
Default Policy for late/slow stabilizations

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?
 
Old 06-27-2010, 03:47 PM
Olivier Crête
 
Default Policy for late/slow stabilizations

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
 
Old 06-27-2010, 03:54 PM
Markos Chandras
 
Default Policy for late/slow stabilizations

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
 
Old 06-27-2010, 04:30 PM
Samuli Suominen
 
Default Policy for late/slow stabilizations

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
 
Old 06-27-2010, 04:38 PM
Ciaran McCreesh
 
Default Policy for late/slow stabilizations

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
 
Old 06-27-2010, 04:53 PM
Auke Booij
 
Default Policy for late/slow stabilizations

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?
 
Old 06-27-2010, 05:16 PM
Markos Chandras
 
Default Policy for late/slow stabilizations

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
 
Old 06-27-2010, 05:22 PM
Markos Chandras
 
Default Policy for late/slow stabilizations

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
 
Old 06-27-2010, 05:43 PM
Ciaran McCreesh
 
Default Policy for late/slow stabilizations

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
 

Thread Tools




All times are GMT. The time now is 06:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org