Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Olivier Crête <tester@g.o>
Subject: Re: Policy for late/slow stabilizations
Date: Sun, 27 Jun 2010 14:21:13 -0400
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@g.o
Gentoo Developer
Attachment:
signature.asc (This is a digitally signed message part)
Replies:
Re: Policy for late/slow stabilizations
-- Markos Chandras
References:
Policy for late/slow stabilizations
-- Markos Chandras
Re: Policy for late/slow stabilizations
-- Olivier Crête
Re: Policy for late/slow stabilizations
-- Markos Chandras
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Policy for late/slow stabilizations
Next by thread:
Re: Policy for late/slow stabilizations
Previous by date:
Re: Policy for late/slow stabilizations
Next by date:
Re: FYI: Rules for distro-friendly packages


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.