| 1 |
Hi |
| 2 |
|
| 3 |
As many of you have already noticed, there are some arches that are quite |
| 4 |
slow on stabilizations. This leads to deprecated stabilizations e.g a |
| 5 |
package is stabilized after 60 days which makes that version of |
| 6 |
the specific package obsolete and not worth to stabilize anymore. |
| 7 |
|
| 8 |
I would suggest to introduce a new rule where a stabilization bug may close |
| 9 |
after 30 days. Arches that fail to stabilize it within this timeframe |
| 10 |
they will simply don't have this package stable for them. |
| 11 |
|
| 12 |
Moreover, slow arches introduce another problem as well. If a package is |
| 13 |
marked stabled for their arch, but this package is quite old, and they fail to |
| 14 |
stabilize a new version, we ( as maintainers ) can't drop the very old |
| 15 |
( and obsolete ) version of this package because we somehow will break |
| 16 |
the stable tree for these arches. How should we act in this case? |
| 17 |
Keep the old version around forever just to say that "hey, they do have |
| 18 |
a stable version for our exotic arch". |
| 19 |
|
| 20 |
Whilst I do understand that these arches are understaffed and they can't keep |
| 21 |
up with the increased stabilization load like x86/amd64 do, I still |
| 22 |
think that slow stabilization leads to an obsolete stable tree which I |
| 23 |
doesn't make sense to me after all. |
| 24 |
|
| 25 |
Thoughts? |
| 26 |
|
| 27 |
-- |
| 28 |
Markos Chandras (hwoarang) |
| 29 |
Gentoo Linux Developer |
| 30 |
Web: http://hwoarang.silverarrow.org |
Archives