Re: [gentoo-dev] Project Sunrise -- Proposal
On Sat, Jun 10, 2006 at 01:37:15PM +0200, Markus Ullmann 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. While I do think this proposal is much better than the previous non-existing proposal, it still doesn't address the problem of having the sunrise overlay hosted on a non *.gentoo.org address to make it 100% clear to the public that it is unsupported. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpf03IBTNUlw.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise -- Proposal
Henrik Brix Andersen wrote: On Sat, Jun 10, 2006 at 01:37:15PM +0200, Markus Ullmann 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. While I do think this proposal is much better than the previous non-existing proposal, it still doesn't address the problem of having the sunrise overlay hosted on a non *.gentoo.org address to make it 100% clear to the public that it is unsupported. Regards, Brix So, move it to this.is.unsupported.and.will.blow.your.box.gentoo.org if you feel it will help anybody. I feel it's completely irrelevant, but that's just me. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise -- Proposal
Henrik Brix Andersen wrote: While I do think this proposal is much better than the previous non-existing proposal, it still doesn't address the problem of having the sunrise overlay hosted on a non *.gentoo.org address to make it 100% clear to the public that it is unsupported. It's no more or less supported than anything else on overlays.gentoo.org. The word overlays ought to be enough. I suppose you oppose the whole concept, anyhow? Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise -- Proposal
On Sun, Jun 11, 2006 at 09:43:01AM -0700, Donnie Berkholz wrote: It's no more or less supported than anything else on overlays.gentoo.org. The word overlays ought to be enough. I suppose you oppose the whole concept, anyhow? No, I am certainly not opposed to overlays in general. I even maintain my own public overlay of packages I work on in portage, an overlay I consider moving to overlays.g.o when I have more time. However, as has been pointed out several times in this thread already, back when the devloper community agreed to the overlays project it was also agreed that projects similar to what is now known as Project Sunrise was not be present on overlays.gentoo.org. I believe this was why many developers agreed to having the overlays project in the first place. The idea was to have a central repository for the team and developer specific overlays that already are available on e.g. dev.gentoo.org. Overlays that are far more limited in contents and where the ebuilds are written and reviewed by people who actually know the packages in question. Instead of following this consensus, the people behind Project Sunrise choose to ignore this and went ahead and implemented the project - without even presenting the idea to the developer community before announcing it's presence to the world; perhaps thinking it would be easier to get pardon than permission. As I see it we have already agreed that an overlay of this type should not be hosted on the overlays project back when the overlays project was agreed upon. Yet a small number of developers ignored this and implemented it anyhow behind the back of the rest of the developers, disregarding their public stated oppinion. As this is a project that has the potential of affecting the entire project I find this very problematic. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpml7nyTSUpF.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise -- Proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: | However, as has been pointed out several times in this thread already, | back when the devloper community agreed to the overlays project it was | also agreed that projects similar to what is now known as Project | Sunrise was not be present on overlays.gentoo.org. Can you provide a reference to this, please? I've been through my -dev M/L archive several times, and cannot find an email where I agreed to this. Best regards, Stu - -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ ~ http://blog.stuartherbert.com/ GnuPG key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEjFivDC+AuvmvxXwRAungAKCejd72YGbpZ5bzFjtg2ezAu8XwswCeK2PP GwYPr/RE79+j4iiZMbcA3zM= =ZOKP -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise -- Proposal
On Sun, Jun 11, 2006 at 06:53:51PM +0100, Stuart Herbert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: | However, as has been pointed out several times in this thread already, | back when the devloper community agreed to the overlays project it was | also agreed that projects similar to what is now known as Project | Sunrise was not be present on overlays.gentoo.org. Can you provide a reference to this, please? I've been through my -dev M/L archive several times, and cannot find an email where I agreed to this. Perhaps not in those exact words, I admit. But the general consensus in my eyes, and I'm not alone with this view according to other replies to this thread, was that the purpose of overlays.gentoo.org would be to provide a common place to host project and developer overlays - not a place to host Joe User's ebuild contributions (except for users regularly contributing to specific teams/herds and devs-in-spee). [1] [2] [3] You could argue that Project Sunrise *is* a specific project. Fact is that nobody at that time could predict that a small group of developers would go ahead and create a project with the single goal of providing Joe User's bugzilla-contributed ebuilds to end-users through overlays.gentoo.org. In my opinion, creating a new project with this purpose should not have been allowed. I fear that perhaps creating the project was just an attempt to circumvent the policy of overlays.gentoo.org, which states that only project teams and individual Gentoo developers can have an overlay on overlays.gentoo.org. It seems that the developers who started Project Sunrise already planed to use overlays.gentoo.org as a free-for-all overlay with no QA and policy checks back when the idea of an official overlays project was discussed. [4] [5] The security issues of having an official overlay of unsupported ebuilds was also raised back then. [6] [7] [8] [9] [10] As was the concerns about potential damage to the reputation of Gentoo as a whole. [11] [12] On the other hand, having team/herd specific overlays with commit access from a select few end-users (as was written in the original proposal) was seen as a good idea. [13] [14] I've spent tonight reading through the entire thread that let to the creation of the overlays project, and I still come out in the end with the feeling that a consensus of having overlays.gentoo.org for hosting the already existing developer and herd/team overlays in a central place was reached. It also looks to me like the idea of having a free-for-all or a user-contrib overlay hosted there would not be acceptable due to security issues and risk of damaging the reputation of Gentoo as a whole. I know this doesn't provide solid evidence that this is how it was, but truth is - we hardly ever see an email on the developers list stating This is what we agreed on. Due to the nature of the media we tend to have a lot of input and discussion back and forth after which a general consensus is found. This consensus, as I see it, is reflected in the policy for overlays.gentoo.org. [15] I urge people to read through the initial thread that fostered overlays.gentoo.org as well - if only to refresh peoples memory on the stuff that was discussed back then. You can start at http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09877.html Sincerely, Brix [1]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09913.html [2]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09921.html [3]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09983.html [4]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09962.html [5]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09966.html [6]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09918.html [7]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09959.html [8]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09884.html [9]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09964.html [10]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09963.html [11]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09910.html [12]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09946.html [13]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09948.html [14]: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg09972.html [15]: http://www.gentoo.org/proj/en/overlays/policy.xml -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgp3PFucKP198.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise -- Proposal
On 6/10/06, Markus Ullmann [EMAIL PROTECTED] 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
Re: [gentoo-dev] Project Sunrise -- Proposal
Comments inline ...
On Sat, 2006-06-10 at 13:37 +0200, Markus Ullmann 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).
Fine.
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.
Fine.
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.
I'm 100% against implicit acceptance. If someone from the sunrise
project wishes to add an ebuild to the overlay they should have to get
an explicit OK from the team in question. The sunrise project could of
course keep a list of teams that have given a blanket OK and of those
that have totally opted out. For those teams in between an OK per
package sought by the sunrise project's team members is needed. I'm
sorry but the leg work to track this stuff and get acceptance has to be
100% on your projects head. Your proposal adds a need for me to actually
look at bugs for packages that I may have no interest in. I don't pay
any attention to maintainer-wanted now I don't want to pay any attention
to a subset of that ever.
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.
So long as this is voluntary and the level of acceptance that I
described above is met I'm OK with it.
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.
Again so long as the team that would have to maintain it in the tree
says OK *explicitly* then sure.
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.
Erm...no! See that is the thing about item #1 on my list...there is
nothing preventing Joe User from checking out the overlay and adding say
a ppc64 keyword or a mips keyword to ${random_ebuild} meaning that bugs
*will* be generated for arch teams for packages that are not in the
tree.
Also note I'm not talking necessarily about the Hey, I installed
${package} and it broke. bugs because if ${package} isn't in the tree
bug-wranglers can catch it and off you go...the arch teams aren't
involved. What I am talking about is Hey, my ppc64 started doing weird
things yesterday, ${daemons} are no longer working. having that bug
assigned to the arch team, and then spending a long time only to track
down that the user installed some random library from sunrise seven days
ago and there just happened to be upgrades to
