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 |