Sean Silva <silvas at purdue.edu> writes:>> For example, say github's llvm-mirror was a contributor's fork. The review >> process might look like this: >> >> Contributor: >> Please review my patch: >> https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 >> >> Maintainer: >> Adds inline comments with online tool. Then when patch is looking good: >> $ git fetch https://github.com/llvm-mirror/llvm.git >> $ git cherry-pick 4823be3be1d87632fbd51ce8e51a58ee5e44b115 >> $ git push > > Most development is not "some contributor's fork".Well, in the git model every developer has a fork.> What you suggest works great for the occasional drive-by > contributors, but most development is not from drive-by's.Not sure what you mean by "drive-by" but in git this is really irrelevant, I think. -David
>> Most development is not "some contributor's fork". > > Well, in the git model every developer has a fork. > >> What you suggest works great for the occasional drive-by >> contributors, but most development is not from drive-by's. > > Not sure what you mean by "drive-by" but in git this is really > irrelevant, I think.Sorry for the lack of clarity. I was trying to contrast with the status quo. By "drive-by" I *roughly* mean "people without commit access" (i.e. that aren't consistently delivering patches). In his scenario there is "contributor" and "maintainer". What I was trying to get across is that most development (in the status quo) is actually done by people that are closer to the "maintainer" role, so making it easy for "contributor" is not a gigantic priority; although, (and I speak from my own experience from before I had commit access), when you're not a committer, it really *seems* like the "contributor" role is the only one that matters. Also, "contributor" is not going to be sending in huge changes, so the overhead of git-fetch'ing from github or wherever is probably going to be greater than git-apply of an attached patch. -- Sean Silva On Thu, Nov 15, 2012 at 6:53 PM, <dag at cray.com> wrote:> Sean Silva <silvas at purdue.edu> writes: > >>> For example, say github's llvm-mirror was a contributor's fork. The review >>> process might look like this: >>> >>> Contributor: >>> Please review my patch: >>> https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 >>> >>> Maintainer: >>> Adds inline comments with online tool. Then when patch is looking good: >>> $ git fetch https://github.com/llvm-mirror/llvm.git >>> $ git cherry-pick 4823be3be1d87632fbd51ce8e51a58ee5e44b115 >>> $ git push >> >> Most development is not "some contributor's fork". > > Well, in the git model every developer has a fork. > >> What you suggest works great for the occasional drive-by >> contributors, but most development is not from drive-by's. > > Not sure what you mean by "drive-by" but in git this is really > irrelevant, I think. > > -David
Sean Silva <silvas at purdue.edu> writes:>>> What you suggest works great for the occasional drive-by >>> contributors, but most development is not from drive-by's. >> >> Not sure what you mean by "drive-by" but in git this is really >> irrelevant, I think. > > What I was trying to get across is that most development (in the > status quo) is actually done by people that are closer to the > "maintainer" role, so making it easy for "contributor" is not a > gigantic priority;See, I think this assumption is false. Any organization that has a private branch (we do here at Cray) is going to look more like a "contributor" than a "maintainer" and we do in fact do significant development. Much of it we cannot release for legal/NDA reasons but we do have quite a bit of code we'd like to integrate upstream. And doing that is *painful*. Now I know all the arguments about developing based on trunk and I understand them, BUT for organizations such as ours, controlling when changes to the base software happens is critical. We like to keep as up-to-date as possible but we need to be able to monitor and control when we upgrade. There are too many moving parts to simply track trunk all the time.> Also, "contributor" is not going to be sending in huge changes, so the > overhead of git-fetch'ing from github or wherever is probably going to > be greater than git-apply of an attached patch.Again, I think this assumption is unwarranted when you consider the whole LLVM community instead of just the current regular contributors to trunk. -David