On Jun 1, 2008, at 3:24 PM, nathan binkert wrote:
the point is that people can pull, not so they can push. it's so we
don't
have this "i'm getting this error" on the mailing list and ali
says, "we
sent this patch for it out, let me find it, here it is." people
can always
have the most up to date stable code, instead of us saying, 'we've
fixed it
in our tree, please wait until we release b5' because we know that
takes....like years longer than we say it will :).
it's not for people to push stuff back, unless we trust them, we fo
sho want
to maintain ultimate control over the repo. no one taints nate's
baby with
shitty code :)."hg h
Exactly. :) Mercurial also makes it pretty easy for people to manage
their own trees and send patches to us using patchbomb (the "hg email"
command)
http://www.selenic.com/mercurial/wiki/index.cgi/PatchbombExtension
We will absolutely accept changes from others once they've been
reviewed by someone with commit access. In general, commiters should
also get their own code reviewed before committing it. You'll notice
that any time Steve, Gabe, or I have big changes, we allow people a
chance to review them before committing. This is especially important
for code that many people use, e.g. the "sim" directory or the "mem"
directory. For things like in progress x86 support, it's not as
necessary, but still makes sense.
If you look at how any other "big" open source project operates
normally the number of people who can commit code is < 10. That is
even true is Linux for example. All the patches get filtered normally
at two levels. First by some area maintainers and then when those
people are happy they send the patches to Linus and friends and
they're the ones who actually put code in the tree. If anyone and
everyone had commit access I don't think M5 would continue to compile
for more than 3 days.
Ali
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
