On 3/28/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > On 3/28/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > > On 3/27/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > On 3/27/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > > On 3/27/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > > <snip/> > > > > > > P.S.- [pool] code is quite hard to read with all that horizontal > > > > > > scrolling. Irrespective of the code already in place, maybe we > should > > > > > > stick to a reasonable (80?) character line width for new code? > > > > > > > > > > The code I contribute to apache is code I wrote for pleasure. The > code > > > > > I contribute is in the form that was most pleasurable for me to > write > > > > > in. > > > > When contributing to a community code base, you also need to think > > about how approachable your code is to other contributors, many / most > > of whom may not currently be working on the project. > > > > >>>I impose no restrictions on how others choose to write their code. > > > > > If you wish to compensate me to write code differently or reject > my > > > > > contributions because of such trivial issues, that is fine. The > ASL > > > > > grants anyone the right reformat ASL licensed code however they > see > > > > > fit. I only request that I am not stripped of attribution for my > > > > > contributions. > > > <snap/> > > > > > > The comment wasn't about imposing restrictions, that would never work > > > anyway. Even while writing for pleasure, a lot of components still > > > check for style (I think its valuable). The line width style criteria > > > has some valid reasons, not the least of which is its accessibility > > > implication that those more fortunate tend to not realize. So, I am > > > implicitly -0 for any *new* commits that are needlessly and > > > consistently too wide which indicates my personal preference (a -1 > > > ofcourse would be an attempt to impose a restriction). And I will > > > always respect your opinion, even if it doesn't match mine. > > > Compensation never comes to my mind in face of any discussions on > > > these mailing lists, that bit was a no-brainer. > > > > +1 - regarding style issues, we have been fairly consistent in the > following: > > > > * When contributing code to an existing component, follow the style of > > the surrounding code > > * Decisions to change the coding style or set checkstyle / pmd / other > > rules for style checking are made by (lazy) consensus at the component > > level, with opinions of those actively working on the code having > > greatest weight > > * Separate reformatting commits from commits that change behavior and > > try to avoid "extraneous diffs" in commits. > > > > My personal preference is 80 column line widths, partly because this > > makes diffs readable. > > > > > > > > As a sidebar, since attribution got mentioned -- its an old, widely > > > discussed topic at the ASF. Some of us believe that author tags in > > > source code are a distraction (doesn't mean we want everyone to change > > > their opinion). It has to do with issues arising out of how you define > > > the least unit of work that warrants an author tag, the tedium of > > > having to remember to add an author tag while applying a patch, and > > > issues of fairness (should the author tags be ordered by size of > > > contribution to the source file, name, chronology). A lot of older > > > projects traditionally had author tags, so its more effort to > > > discontinue, but for newer projects, I personally have begun to prefer > > > the no author tags policy. Accordingly, I will likely -1 a patch to > > > the [scxml] code if the author insists on having an author tag. And > > > maybe that means [scxml] will miss out on some valuable contributions > > > from talented folks purely for that reason, but that is perhaps "the > > > lesser of the two evils". Attribution then, gets handled via commit > > > messages and the team page. All commit messages contain attribution as > > > the case may be, and anyone who contributes any code -- be it a line > > > or a million -- gets listed on the team page. > > > > +1 and search the archives for lots of discussion about why we should > > not be adding new @author tags. > > I have searched some and the arguments don't hold water with me. > > I'm proud of the code I've contributed and I think an @author tag is > proper recognition. I feel strongly enough about this that I'd rather > not contribute to apache at all than loose that recognition. We are > not the "Apache Borg". We are a group of individuals that enjoy > programming. I am not willing to be assimilated and if the rest of > apache has a problem with that then revoke my commit rights.
All of us are proud of our contributions here. But the ASF is not about egos, and it is not about recognition. I don't know who came up with the phrase, but "egoless programming" is an appropriate term for the way we work. If you came here for the recognition, then I'm afraid you made a mistake. Perhaps we need to make a more prominent statement about author tags somewhere, for the benefit of potential future contributors. -- Martin Cooper > > I find listening to the variety of opinions on almost all things here > > > at the ASF makes me richer. > > > > And thats the kind of "compensation" that keeps us all coming back ;-) > > -- > Sandy McArthur > > "He who dares not offend cannot be honest." > - Thomas Paine > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
