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 [email protected] Gentoo Developer
signature.asc
Description: This is a digitally signed message part
