On Wednesday 04 of April 2012, Chandler Carruth wrote: > I'm sorry you feel this way, and got this impression. > > We definitely do want the feature and more contributors. Providing detailed > code review of new features is actually a very time consuming activity. It > would be much faster to just reformat the patch ourselves and submit it, > but that doesn't build up new contributors or give them experience with the > coding conventions used within the Clang project. It also doesn't scale -- > we can't afford to spend all of our time reformatting other people's > contributions. Instead, we're trying to teach you *how* to make a > contribution to the Clang codebase.
I've done contributions to a number of projects, so I know this, regardless of the project it's always a variation of getting it to compile, making a patch, posting it for review to wherever the right place is, fixing problems that have been pointed out, and repeating until it's either accepted or until the effort does not seem worth it. That wasn't the problem, the problem was that the 'not worth it' impression rather skyrocketed. A large stick and no carrot in sight. That also didn't seem to build up new contributors in this case. > Now, if you're not interested in on-going contributions, that's fair. It is > absolutely a lot of work to learn and internalize the style and coding > conventions we use. I'm sorry if I misled you in encouraging you to dive in > and implement this, and learning the conventions and style used within > Clang isn't a useful investment of your time. If this is how you see it, then indeed you do not view me as a possible contributor, because you apparently expect a devotion to the project, which I can't and don't want to do. Nor I think it should be necessary. For a project where all users are developers, I'd expect it to be quite likely for users to just turn up, scratch their itch and disappear again, without really being interested in such trivialities like where exactly you must or mustn't put your spaces (I myself use 2 coding styles regularly and several more occassionally as I touch other projects, and I really have no interest in internalizing another style, especially if, honestly, I don't quite like it). So yes, this is an unappreciated waste of time. That said, this is not even necessary, because there can be an easy technical solution, at least for the coding style problem. If I was just given a command to format the code the want you want it, I'd just have done it and be done with it. Clang seems quite capable at rewriting code and I've noticed some mentions of GSoC code reformater task, so just make sure it's usable for Clang itself too and it should save a lot of time on both sides. A tool won't help with blocking a patch because of other issues, such as the reused already existing Clang code (I'd be most probably quite happy to improve it in a followup patch in both places), having requirements that even core developers don't apparently follow (I can read just a couple of mails on this very list to see that new code is not rigidly doxygen-marked everywhere), performance improvements that didn't even improve anything, or even the absurdity of first asking me to rename a temporary variable away from 'I' to something more descriptive and later asking to have a reasonably-named variable renamed to 'I', but if you value one perfect patch more than a possible contributor and all the followup patches, that's your choice. > > session > > would feel like taking over the patch, just go ahead. I don't think > > there's any technical problem with it and I've been using it extensively > > in the last > > few weeks (and I'd be willing to have a look at it if somebody finds an > > actual technical problem in it after all). > > Again, we have a reasonable amount of experience that indicates coding > conventions, style, and other such factors are critically important to > long-term maintainability of a large codebase. We consequentially have very > high standards here. I have a reasonable amount of experience indicating that too much is sometimes way too much, and I'm not going for another iteration of tedious and frustrating manual review of my code for compliancy with a large code standard and even larger codebase, sorry. > To sum up: I think this functionality is good, and eventually someone will > hopefully have time to pick it up and make the necessary style > improvements. I can understand if you don't have the time to finish this, > but until someone can find the time and finish cleaning it up, the patch > isn't ready to be submitted. Too bad it won't make it into 3.1, but at this pace it probably wasn't going to anyway. -- Lubos Lunak [email protected] _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
