>"Valik" <firstname.lastname@example.org> writes:
>>>We are generally willing to fix up stylistic problems. What we need
>>>to do is make it *clear* that we are willing to do so, and that our
>>>comments are usually meant to convey a sentiment like: "If you're
>>>resubmitting this (for substantive reasons) anyway, would you mind
>>>fixing these stylistic issues as well?".
>>I think you need to "get with the boys" on this one. Branko clearly
>>states, "...because even a technically perfect patch wouldn't be
>>accepted if style wasn't correct" which is contrast to what you are
>>saying above. I think one of the minor problems is there isn't an
>>official stance on the matter and it's up to an individual committer as
>>to how much effort they are willing to expend.
>No, "the boys", or rather, the boy, needs to get with me :-).
>Branko was simply wrong. And I'll bet he will admit that if he
>happens read this followup. (*He* might not apply such a patch, but
>many, many such patches have been applied. And, actually, he probably
>would too, if it were good in other ways.)
Oh well, to quote my original response to Mark:
> But I certainly see the techincal side as being more important than
> the stylistic side; if I didn't, I'd have made the final tweaks myself
> and committed the patch by now.
So it seems that a lot of this conversation ie about something that
hasn't happened, nor is it likely to happen.
Now about this style thing: When I contribute to a project, I always put
in that extra 1% effort to get the coding style consistent. Project
policies range from "no consitency" (e.g., Samba) through "reasonable
consitency" (e.g., APR or HTTPD or Subversion -- for the record,
Subversion's style is _not_ my natural style, so I have to put in that
bit of effort when I code for SVN, too) to "Use Emacs with the GNU style
or else", such as GCC. And yet the effort to keep the style of the
contribution consistent is never significant, *if* one gets it through
their head that projects /do/ have a preferred style and that they have
a reason for that. That reason is usually to make the code more
maintainable (I think most people will agree that having all the code in
a consistent style _does_ make it more maintainable).
In this context, the coding style is (almost) as important as giving a
good explanation of what your patch does and why, providing a good log
message (again, project requirements for those differ), and of course
making the actual implementation right.
Doing only part of the work and then expecting others to do the rest, as
I've seen suggested elswhere in this thread, strikes me as being
slightly rude. So are remarks about how one doesn't _have_ to write
patches, implying that every patch is a royal gift that we should grovel
over. Both tend to ignore the fact that the vast majority of the
contributors to this project are doing it in their free time; I really
don't see why they should support other people's lazyness.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jul 26 08:55:38 2005