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. 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
signature.asc
Description: OpenPGP digital signature
