From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: [RFC] Non-Dev Contributors and the Tree
Date: Thu, 7 Jun 2007 22:38:11 +0000 (UTC) [thread overview]
Message-ID: <pan.2007.06.07.22.38.11@cox.net> (raw)
In-Reply-To: 200706071650.54612.philantrop@gentoo.org
"Wulf C. Krueger" <philantrop@gentoo.org> posted
200706071650.54612.philantrop@gentoo.org, 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
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2007-06-07 22:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-07 11:43 [gentoo-dev] [RFC] Non-Dev Contributors and the Tree Michael Cummings
2007-06-07 14:50 ` Wulf C. Krueger
2007-06-07 22:38 ` Duncan [this message]
2007-06-08 1:50 ` [gentoo-dev] " Steve Long
2007-06-07 18:02 ` [gentoo-dev] " Chris Gianelloni
2007-06-07 18:34 ` Vlastimil Babka
2007-06-07 18:51 ` Wulf C. Krueger
2007-06-08 7:01 ` Kent Fredric
2007-06-08 14:39 ` [gentoo-dev] " Steve Long
2007-06-08 17:46 ` Stefan Schweizer
2007-06-10 19:16 ` Steve Long
2007-06-08 18:17 ` [gentoo-dev] " Elias Probst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2007.06.07.22.38.11@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox