"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
