[gentoo-dev] Re: [RFC] Non-Dev Contributors and the Tree
Kent Fredric wrote: Comments? ~mcummings As a non-dev with not a lot of free time, I applaud this suggestion. However, my core fear is the potential for it becoming subject to abuse, and people insisting on repeatedly uploading patches that are not actually wanted / necessary for the project, despite the package maintainer saying 'dude , stop' Well presumably if the maintainer has said it in bugzilla/ whichever tracking mechanism you use, then it's on record. If it's transparent, it's hard for people to argue about it other than on the merits. And users and devs share a common interest in getting the software working optimally. Basically, if a non-maintainer wants maintenance rights, how do they go about attaining them? , an automated service, or some vetting process? Dunno what the procedure might end up becoming, but my understanding is commit right to the sunrise overlay, from where a dev has to commit it to the main tree. It seems like a logical extension of sunrise, and i am sure there are stats on who has submitted what to sunrise in the past. So there is a baseline for whom to invite to become insertNameOfNewPosts. How do we go about handling the problem with the predicted increase in collisions? I guess it depends on what the predicted increase would be. Maybe one of the infra bods can enlighten us? (I'm guessing you'd take the writes of the users automatically selected and see how many collisions there would have been with the ebuilds they contributed to. A patch that got accepted wouldn't count, of course, if it were possible to track same,) Is CVS fast enough / flexible enough for such a massive change in users? (forgive me if I've made a misunderstanding, but im a SVN man, not a CVS'er ) Well aiui CVS is a lot less resource-intensive than SVN and additionally the proposal was to utilise existing infra slightly differently. It doesn't sound like more workload for the servers involved. TBH it sounds more like the kernel model than anything; each individual is responsible for the commits they make with their signature. If they have come from elsewhere is irrelevant (apart from a legal viewpoint.) Code responsibility lies with one, when one presses send. kk or Enter -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [RFC] Non-Dev Contributors and the Tree
Steve Long wrote: Dunno what the procedure might end up becoming, but my understanding is commit right to the sunrise overlay, from where a dev has to commit it to the main tree. It seems like a logical extension of sunrise, and i am sure there are stats on who has submitted what to sunrise in the past. So there is a baseline for whom to invite to become insertNameOfNewPosts. Snrise already has such an extension. A portage-review/ subdirectory, where ebuilds from the gentoo-x86 + changes can be posted. A dev then takes those and reviews them to the main tree and removes them again from the dir The process has worked really good so far. I suggest you to read up on how this is currently being done on overlays.gentoo.org/proj/sunrise and if you are interested I invite you to join #gentoo-sunrise to see how it is done. The current log: http://overlays.gentoo.org/proj/sunrise/log/portage-review You will notice the regular in portage, now reviewed, in cvs messages Best regards, Stefan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [RFC] Non-Dev Contributors and the Tree
Wulf C. Krueger [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 07 Jun 2007 16:50:54 +0200: I mostly agree with your arguments but seeing what we have in the Sunrise overlay I don't think we need another one. Today, people can get involved by submitting ebuilds to (and maintaining them in) Sunrise rather easily. As easily as devs can take ebuilds from there and add them to the official tree. What would/should be different compared to that if we implemented your suggestion? The difference, as I read the proposal, is that while Sunrise is about packages that are /not/ in the main tree yet (if it's moved to the tree, it's out of sunrise, tho it might move to another overlay if appropriate), this proposal would extend that to packages that are in the tree as well. (Vetted) users could commit to in-tree packages, but only in the (main) development overlay. It'd be Sunrise, but just as devs watch what's going on there with the eventual goal of getting some of the ebuilds into the tree, so here, devs would watch and make commits to the (mirrored) tree from the development overlay. I've not read the rest of the responses yet, but the question I had was... OK, but won't that result in either (a) developers getting /more/ bump/test/grind, not less, since more of it would be taking commits already made by users and applying them to the mirrored tree (the committing users get more of the creativity, the devs end up being just shuttle monkeys, vetting then shuttling from the dev tree to the mirrored tree), or (b) the mirrored tree eventually falling seriously behind? IMO there may need to be mechanisms to prevent it from going one way or the other, as I don't otherwise see the proposed situation of dev then mirrored tree as being stable over time -- it'll lean toward a or b above. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [RFC] Non-Dev Contributors and the Tree
Duncan wrote: The difference, as I read the proposal, is that while Sunrise is about packages that are /not/ in the main tree yet (if it's moved to the tree, it's out of sunrise, tho it might move to another overlay if appropriate), this proposal would extend that to packages that are in the tree as well. Thanks for the clarification. (Vetted) users could commit to in-tree packages, but only in the (main) development overlay. It'd be Sunrise, but just as devs watch what's going on there with the eventual goal of getting some of the ebuilds into the tree, so here, devs would watch and make commits to the (mirrored) tree from the development overlay. Makes sense, although it does sound like sunrise could be extended for this purpose. Of course i have nfc about how sunrise works behind-teh-scenes.. I've not read the rest of the responses yet, but the question I had was... OK, but won't that result in either (a) developers getting /more/ bump/test/grind, not less, since more of it would be taking commits already made by users and applying them to the mirrored tree (the committing users get more of the creativity, the devs end up being just shuttle monkeys, vetting then shuttling from the dev tree to the mirrored tree), Hmm good point. I was thinking it might fit more with the suggestion for users[1] to be involved with patches etc. This all sounds like the wine triage thing[2] tho, which would need perhaps a more streamlined usage of bugzilla so that discussions don't take place there, but on the m-l (see the recently linked FOSS book about this exact issue.) Of course discussions with no useful purpose need to be proactively filtered.. or (b) the mirrored tree eventually falling seriously behind? IMO there may need to be mechanisms to prevent it from going one way or the other, as I don't otherwise see the proposed situation of dev then mirrored tree as being stable over time -- it'll lean toward a or b above. Well it's always a balancing act, but neither of those poles sounds attractive. Personally i think use of Deskzilla and development of a Free equivalent would really help, along with useful posts like yours of course ;) Regards, igli #friendly-coders @ irc.freenode.org We're still here for you. ;D [1] Solely in the interests of avoiding self-mutilation by the more fragile members of this community ;p [2] http://kegel.com/wine/qa/#triage -- [EMAIL PROTECTED] mailing list
