[cfe-commits] [PATCH] -rewrite-includes

[Lubos Lunak]

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
 l.lunak at suse.cz