| 1 |
On Mon, 10 Nov 2008 13:13:34 -0500 |
| 2 |
Mark Loeser <halcy0n@g.o> wrote: |
| 3 |
|
| 4 |
> Instead of addressing archs as being slackers or not, this addresses |
| 5 |
> it as a more granular layer of looking at ebuilds. Thanks to Richard |
| 6 |
> Freeman for the initial proposal that I based this off of. Please |
| 7 |
> give me feedback on this proposal, if you think it sucks (preferably |
| 8 |
> with an explanation why), or if you think it might work. |
| 9 |
> |
| 10 |
> Ebuild Stabilization Time |
| 11 |
> |
| 12 |
> Arch teams will normally have 30 days from the day a bug was filed, |
| 13 |
> keyworded STABLEREQ, the arch was CCed, and the maintainer either |
| 14 |
> filed the bug or commented that it was OK to stabilize (clock starts |
| 15 |
> when all of these conditions are met). |
| 16 |
> |
| 17 |
> Security bugs are to be handled by the policies the Security Team has |
| 18 |
> established. |
| 19 |
> |
| 20 |
> Technical Problems with Ebuild Revisions |
| 21 |
> |
| 22 |
> If an arch team finds a technical problem with an ebuild preventing |
| 23 |
> stabilization, a bug will be logged as a blocker for the keyword |
| 24 |
> request. The bug being resolved resets the time for the 30 days the |
| 25 |
> arch team has to mark the ebuild stable. |
| 26 |
> |
| 27 |
> Removing Stable Ebuilds |
| 28 |
> |
| 29 |
> If an ebuild meets the time criteria above, and there are no |
| 30 |
> technical issues preventing stabilization, then the maintainer MAY |
| 31 |
> choose to delete an older version even if it is the most recent |
| 32 |
> stable version for a particular arch. |
| 33 |
> |
| 34 |
> If an ebuild meets the time criteria above, but there is a technical |
| 35 |
> issue preventing stabilization, and there are no outstanding security |
| 36 |
> issues, then the maintainer MUST not remove the highest-versioned |
| 37 |
> stable ebuild for any given arch without the approval of the arch |
| 38 |
> team. |
| 39 |
> |
| 40 |
> Security issues are to be handled by the recommendations of the |
| 41 |
> Security Team. |
| 42 |
> |
| 43 |
> Spirit of Cooperation |
| 44 |
> |
| 45 |
> Ebuild maintainer and arch teams are encouraged to work together for |
| 46 |
> the sake of each other and end users in facilitating the testing and |
| 47 |
> maintenance of ebuilds on obscure hardware, or where obscure |
| 48 |
> expertise is needed. Package maintainers are encouraged to use |
| 49 |
> discretion when removing ebuilds in accordance with this policy. |
| 50 |
|
| 51 |
Since I completely stalled out this conversation I guess it's only fair |
| 52 |
that I try to restart it. I'm in favor of the above. |
| 53 |
|
| 54 |
I know it's not directly related to stabilization, but lately people |
| 55 |
have been removing the only keyworded package for the mips arch, under |
| 56 |
the excuse that's it's been over 30 days since they opened a keywording |
| 57 |
bug. This has been happening on bugs where there are technical issues |
| 58 |
and on bugs where we just haven't replied (in which case i can see the |
| 59 |
justification). I don't think this is acceptable, just as I don't |
| 60 |
think removing the only stable version of a package on an arch is |
| 61 |
be acceptable, barring the circumstances Mark outlined above. |
| 62 |
|
| 63 |
Yes? No? Get out of our treehouse? |
| 64 |
|
| 65 |
|
| 66 |
-- |
| 67 |
gcc-porting, by design, by neglect |
| 68 |
treecleaner, for a fact or just for effect |
| 69 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |
Archives