> 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. Make sense? Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
