>>> It is *way* beyond the quality of any other tool in 'contrib/' and even >>> some tools in the core, like 'git-request-pull' (which has known bugs), >>> and probably even 'git-pt'. >> >> Junio, can you comment on this? I understand this probably doesn't >> really affect the issue at hand, but it'd help clarify if it's ever >> possible to move out of contrib/ nowadays. > > I was originally led to believe that its code quality was good > enough, and that was why I merged the bottom three patches of the > series even down to 'next' in the first place. But after seeing the > "Of course" response that led to [*1*], which made me recall many > patch-review interactions with him, I have started to have doubts. > > The code quality of Git that many projects have come to trust their > code with is much more than just "the code at each moment keeps > working for the users as long as the original author is around". > The maintainer of a port to the platform X may lose access to the > platform after switching jobs, the maintainer of a bridge to the > foreign system Y may stop needing to talk to the foreign system > after completing the switch to Git. Anybody can be hit by a bus, > get sick, or simply lose interest in his past creations. > > By reading "git log contrib/remote-helpers" and comparing it with > the logs for the rest of the system, you would realize that the > former would not lead to a quality discussion similar to the one > that led to [*2*], which was only possible because the change was > adequately described to allow anybody to understand the original > issue the change was meant to solve. The commit that made the > original change made it easy to ask a critical question: "You are > improving B but at the same time breaking A. Can we do better to > help both A and B?" And it allowed us to move forward without > having to rob Peter to pay Paul. > > Granted, these contrib/ patches were applied with the understanding > that contrib/ stuff can be substandard, because having anything is > often better than having nothing, and you cannot go back in time to > update the history to make these commits more useful to others who > will come later. But I would be lying if I said that I would expect > that things will suddenly improve and that the codebase will be > maintained for the long haul in a healthy way the minute we move it > out of contrib/ to the core. Especially after seeing [*1*], which > is just one of the examples that illustrate that there clearly is no > will to explain the changes to help others who come later to help > maintaining the code. "I'll take good care of the codebase", "I've > spend the time to make it better", "Me, me, me", is not what the > open source process is about. Thanks for the explanation. I think it underlines well the A) technical issues (quality commits) and the B) social issues (ability to communicate in a friendly way & respond constructively), which we discovered are both *essential* for contributing to git. Neglate one or the other, and sooner or later people will refuse to collaborate with you, because it's just too much "work" to deal with the downsides. My hope is that for future events of this nature to be detected sooner and dealt with more rigidly, e.g by making it clear this or that behavior is not acceptable. I think part of the problem here is that we let the situation install itself, by accepting B-side issues just because A-side was ok, hopeful that B-side would solve itself. Philippe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html