[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev]  Re: Proposal for how to handle stable ebuilds
From:       Ryan Hill <dirtyepic () gentoo ! org>
Date:       2008-11-30 22:59:35
Message-ID: 20081130165935.276a512c () halo ! dirtyepic ! sk ! ca
[Download RAW message or body]


On Mon, 10 Nov 2008 13:13:34 -0500
Mark Loeser <halcy0n@gentoo.org> wrote:

> Instead of addressing archs as being slackers or not, this addresses
> it as a more granular layer of looking at ebuilds.  Thanks to Richard
> Freeman for the initial proposal that I based this off of.  Please
> give me feedback on this proposal, if you think it sucks (preferably
> with an explanation why), or if you think it might work.
> 
> Ebuild Stabilization Time
> 
> Arch teams will normally have 30 days from the day a bug was filed,
> keyworded STABLEREQ, the arch was CCed, and the maintainer either
> filed the bug or commented that it was OK to stabilize (clock starts
> when all of these conditions are met).
> 
> Security bugs are to be handled by the policies the Security Team has
> established.
> 
> Technical Problems with Ebuild Revisions
> 
> If an arch team finds a technical problem with an ebuild preventing
> stabilization, a bug will be logged as a blocker for the keyword
> request.  The bug being resolved resets the time for the 30 days the
> arch team has to mark the ebuild stable.
> 
> Removing Stable Ebuilds
> 
> If an ebuild meets the time criteria above, and there are no
> technical issues preventing stabilization, then the maintainer MAY
> choose to delete an older version even if it is the most recent
> stable version for a particular arch.
> 
> If an ebuild meets the time criteria above, but there is a technical
> issue preventing stabilization, and there are no outstanding security
> issues, then the maintainer MUST not remove the highest-versioned
> stable ebuild for any given arch without the approval of the arch
> team.
> 
> Security issues are to be handled by the recommendations of the
> Security Team.
> 
> Spirit of Cooperation
> 
> Ebuild maintainer and arch teams are encouraged to work together for
> the sake of each other and end users in facilitating the testing and
> maintenance of ebuilds on obscure hardware, or where obscure
> expertise is needed.  Package maintainers are encouraged to use
> discretion when removing ebuilds in accordance with this policy.

Since I completely stalled out this conversation I guess it's only fair
that I try to restart it.  I'm in favor of the above.

I know it's not directly related to stabilization, but lately people
have been removing the only keyworded package for the mips arch, under
the excuse that's it's been over 30 days since they opened a keywording
bug.  This has been happening on bugs where there are technical issues
and on bugs where we just haven't replied (in which case i can see the
justification).  I don't think this is acceptable, just as I don't
think removing the only stable version of a package on an arch is
be acceptable, barring the circumstances Mark outlined above.

Yes?  No?  Get out of our treehouse?


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]