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