Re: [gentoo-dev] Project Sunrise -- Proposal

[Dan Meltzer]

On 6/10/06, Markus Ullmann <jokey@g.o> wrote:
> Okay, so after figuring out open problems (thanks to kloeri and various
> other people for help here), we now have a resolution that should
> satisfy all involved parties here. This should adress dostrow's demands
> as well.
>
> 1) m-w / m-n requirement
>
> Only ebuilds that are reported to bugzie (valid bug#) and set to
> maintainer-wanted are allowed here as well as maintainer-needed ones.
>
> maintainer-needed are only allowed if they're removed from the tree and
> moved over to sunrise (and thus end up as maintainer-wanted again).
>
> 2) Not one large tree but subdirs, one per herd
>
> to help herds better keeping track of which parts are alive in the
> overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be
> a netmon/ dir with net-analyzer/specialapp below it.
>

If its unofficially part of a herd, then isn't it no longer a m-w/m-n ebuild?

> 3) a yes from herds required, keeping a timeout to avoid bugspam
>
> after a comment has been placed on a maintainer-wanted bug in bugzie,
> there's a grace time of two weeks for herds to either leave a comment on
> whether they're fine with take over or not. When this time is over and
> it is assigned to maintainer-wanted, then and only then it is implied as
> an OK to keep it also in the sunrise project.
>
> 4) work needed by herds
>
> - take a look at the homepage of the new program
> - take a look at the ebuild
>
> If you're at least partly happy with the new app, drop a note on the bug
> or just ping sunrise that you're ok with it. Then sunrise takes it over
> and improves the ebuild together with the contributor so that it reaches
> a level where it could theoretically be committed to the tree.
> Herds are more than welcome to help here if they feel like it but basic
> checks whether the app should ever be on gentoo will be sufficient.
>
> 5) commit access to the overlay
>
> We implement two levels of commit rights:
>
> 1. As there are people out there who just want to maintain one app for
> start, the ebuild should reach a level that project devs are fine with
> it, then the user is given permission to commit on that single app. An
> automated check makes sure that he doesn't commit anywhere else. If
> violations arise, the access is revoked immediately.
>
> 2. People who contribute good ebuilds over a certain period of time are
> allowed upon decision by project devs to actively help maintaining the
> project. They'll be given commit rights for the project then. Same frome
> above applies here: If we notice any abuse, we revoke access immediately.
>
> 6) QA assurance
>
> Of course there are minor issues with the ebuilds, otherwise they could
> be committed straight forward. Important thing is that it only finds the
> way into overlaye if the trusted committers (project devs and users who
> are given permission explicitely, see above) are fine with it.
> Additional note on arch issues: initially, just ~x86 and ~amd64 may be
> set. The rest would need successful test reports for other ~arch
> keywords. Stable keywording isn't permitted at all, there will be some
> automated check to make sure no one does it (by accident) here.
>
> Additional note: we won't start adding this to layman and making it
> available easier until the QA checks have been implemented.
>
> 7) tag on bugs
>
> All ebuilds that are made available on sunrise get an InOverlay KEYWORDS
> entry on bugs.g.o so that everyone, who looks at the bug, knows about it.
>
> 8) Grace time also given from the go point on.
>
> When we see that this gets a bit fine-tuning / acceptance among devs, we
> will explicitely call out a two weeks notice for ebuilds currently
> assigned to maintainer-wanted so that herds can keep an eye on them and
> either comment as given, reject take over permission completely, close
> as WONTFIX in case they're against the app for the tree in futures or
> just drop a note that they're fine with the take over and the
> development can be started on the ebuild.
> Remember the way they need to be reviewed as said in 4). The ebuild is
> subject to development, the sunrise devs do help with it in case your
> herd lacks time to completely take care of it.
>
> 9) Security
>
> In this early stage we have no security liaison on board yet. If one is
> willing to help out here, we'd be  more than glad on welcoming him  :)
>
>
> Greetz,
> Jokey
>
>
>
>


I think this is a much improved//thought out version of the proposal.
>From the looks of things sunrise should never make it to layman
however, because as we all know, anything that makes things more
easily accessible to users is going to be (mis)used by more of them.
>From what I understand, you see Sunrise as an overlay for users to
improve their ebuilds because they are insufficient quality to be in
the main tree.  If they are of this poor quality, they should be no
where near users hands, this doesn't make sense.

If on the other hand you saw sunrise as a way for more packages to be
available to users due to there being a lack of maintainers, asking
herds to check out ebuilds as part of the proposal seems
counterproductive to the cause.

Maybe you should expand on the goal of the sunrise project, what
exactly do you want it to do?
-- 
gentoo-dev@g.o mailing list