| 1 |
El lun, 10-11-2008 a las 13:13 -0500, Mark Loeser escribió: |
| 2 |
> |
| 3 |
> Ebuild Stabilization Time |
| 4 |
> |
| 5 |
> Arch teams will normally have 30 days from the day a bug was filed, keyworded |
| 6 |
> STABLEREQ, the arch was CCed, and the maintainer either filed the bug or |
| 7 |
> commented that it was OK to stabilize (clock starts when all of these |
| 8 |
> conditions are met). |
| 9 |
|
| 10 |
> |
| 11 |
> Removing Stable Ebuilds |
| 12 |
> |
| 13 |
> If an ebuild meets the time criteria above, and there are no technical issues |
| 14 |
> preventing stabilization, then the maintainer MAY choose to delete an older |
| 15 |
> version even if it is the most recent stable version for a particular arch. |
| 16 |
> |
| 17 |
> If an ebuild meets the time criteria above, but there is a technical issue |
| 18 |
> preventing stabilization, and there are no outstanding security issues, then |
| 19 |
> the maintainer MUST not remove the highest-versioned stable ebuild for any |
| 20 |
> given arch without the approval of the arch team. |
| 21 |
> |
| 22 |
> Security issues are to be handled by the recommendations of the Security Team. |
| 23 |
> |
| 24 |
|
| 25 |
If this proposal had been approved a year ago as is, amd64 stable |
| 26 |
keywords could have been dropped all over the place, making stable tree |
| 27 |
unsupported on amd64 de facto (guess how many users would have left |
| 28 |
Gentoo) and agravating our past workload problems. |
| 29 |
|
| 30 |
So the consequences of this policy being applied on a regular basis can |
| 31 |
be far worse than arches lagging behind. |
| 32 |
|
| 33 |
Regards, |
| 34 |
-- |
| 35 |
Santiago Moisés Mola |
| 36 |
Jabber: cooldwind@×××××.com | GPG: AAD203B5 |
Archives