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