commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <sandy...@apache.org>
Subject Re: [all] Line width and such minutiae
Date Tue, 28 Mar 2006 16:56:31 GMT
On 3/28/06, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 3/27/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> > On 3/27/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> > > On 3/27/06, Sandy McArthur <sandymac@apache.org> 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.

> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message