You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rahul Akolkar <ra...@gmail.com> on 2006/03/28 08:59:32 UTC
[all] Line width and such minutiae
On 3/27/06, Rahul Akolkar <ra...@gmail.com> wrote:
> On 3/27/06, Sandy McArthur <sa...@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. 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.
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.
I find listening to the variety of opinions on almost all things here
at the ASF makes me richer.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Line width and such minutiae
Posted by Martin Cooper <ma...@apache.org>.
On 3/28/06, Sandy McArthur <sa...@apache.org> wrote:
>
> On 3/28/06, Phil Steitz <ph...@gmail.com> wrote:
> > On 3/27/06, Rahul Akolkar <ra...@gmail.com> wrote:
> > > On 3/27/06, Rahul Akolkar <ra...@gmail.com> wrote:
> > > > On 3/27/06, Sandy McArthur <sa...@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.
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Line width and such minutiae
Posted by Henri Yandell <fl...@gmail.com>.
On 3/28/06, Martin Cooper <ma...@apache.org> wrote:
> On 3/28/06, Henri Yandell <fl...@gmail.com> wrote:
> >
> > On 3/28/06, Sandy McArthur <sa...@apache.org> wrote:
> >
> > > I have searched some and the arguments don't hold water with me.
> >
> > Main reasons I cba to put my name on stuff I touch or create nowadays:
> >
> > * Private emails asking questions, offering patches etc. It starts to add
> > up.
> > * It's an effort to put @author in. I'm lazy. Lots of names in one
> > file does start to feel spammy.
> > * It's pretty minor in terms of recognition.
> >
> > > 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.
> >
> > Until we decide as a community to remove the @author bits
>
>
> Hmm, I thought we'd made that decision some time ago. Am I spacing?
Probably not. I got sucked into the chair crap and lost my way. I
probably missed the thread etc.
If we have decided that, then I'm happy to script them all out (and
into team list files etc). And we should probably make sure that we
take care of disagreements now rather than later.
> , you're
> > welcome to keep adding them in. I'm pretty sure we've not made any
> > community decisions as that thread would have stretched on for a long
> > time.
> >
> > It's not a case of borg btw; the alternative to @author appears to be
> > listing the people involved in a project somewhere. Might be
> > interesting to do that per release :) Very Sesame St; "Commons Lang
> > 2.2 came to you via the work of ....".
>
>
> We already list the developers on the component web sites. For Pool, for
> example:
>
> http://jakarta.apache.org/commons/pool/team-list.html
Sorry, bad wording on my part. I rewrote that bit a few times and lost
the project.xml and other ways in which it's already done because I
was too interested in the idea of a list per release :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Author tags [was Line width and such minutiae]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2006-04-04 at 09:16 -0700, Henri Yandell wrote:
> On 4/2/06, Martin Cooper <ma...@apache.org> wrote:
> > On 4/2/06, Sandy McArthur <sa...@apache.org> wrote:
> > >
> > > For me that falls apart in two places:
> > > 1. authorship != ownership, this is made clear by the file's header.
> > > 2. subversion contains enough information to target critical
> > > contributors. In my mind that is like worrying about a second story
> > > window that may be unlocked when your front door is off the hinges.
> >
> >
> > Subversion does indeed contain plenty of information. However, lawyers don't
> > understand source control systems, but they do understand plain text. A
> > technical perspective isn't what's important here; what lawyers understand,
> > and what is supported by legal precedent, is. That's where the board is
> > coming from, backed by legal advice.
>
> There's also a difference between push and pull, I believe. We are
> publishing/distributing the author names in the javadoc/source - we
> don't publish the subversion data.
AIUI copyright is not the key issue here and (so) not ownership or
authorship. the ASF tries to ensure that there is a public record of the
entire process so that this should be clear and transparent. so,
ownership and authorship should not be in doubt. however, the intent may
be. use of the author tag was thought to increase the chance of a court
ruling that when the source was created, the contributor intended to
work for themselves rather than on the ASF's behalf. not sure how strong
this argument would be but (since it was only a recommendation) quite
possibly not very.
but if you're interested in the legal side of this issue, it might be
worth raising this on legal discuss when things are a little quieter
than now...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Author tags [was Line width and such minutiae]
Posted by Henri Yandell <fl...@gmail.com>.
On 4/2/06, Martin Cooper <ma...@apache.org> wrote:
> On 4/2/06, Sandy McArthur <sa...@apache.org> wrote:
> >
> > For me that falls apart in two places:
> > 1. authorship != ownership, this is made clear by the file's header.
> > 2. subversion contains enough information to target critical
> > contributors. In my mind that is like worrying about a second story
> > window that may be unlocked when your front door is off the hinges.
>
>
> Subversion does indeed contain plenty of information. However, lawyers don't
> understand source control systems, but they do understand plain text. A
> technical perspective isn't what's important here; what lawyers understand,
> and what is supported by legal precedent, is. That's where the board is
> coming from, backed by legal advice.
There's also a difference between push and pull, I believe. We are
publishing/distributing the author names in the javadoc/source - we
don't publish the subversion data.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Author tags [was Line width and such minutiae]
Posted by Martin Cooper <ma...@apache.org>.
On 4/2/06, Sandy McArthur <sa...@apache.org> wrote:
>
> On 4/2/06, robert burrell donkin <ro...@blueyonder.co.uk>
> wrote:
> >
> > > > Gary Gregory wrote:
> > > > > Based on the February 18, 2004, Apache Software Foundation Board
> > > > > of Directors Meeting Minutes, author tags are "discouraged".
> >
> > <snip>
> >
> > > > Sandy McArthur wrote:
> > > > >I have searched some and the arguments don't hold water with me.
> > > > :-) Many things from lawyers and the board don't make sense ;-)
> >
> > here's the only convincing argument i know of:
> >
> > what worries the board (and other open source folks) is the effective
> > destruction of open source projects by targeting (with individual
> > lawsuits) the limited number of critical contributors who do crucial
> > things such as cutting releases. if these individuals are acting on
> > their own behalf, as a non-profit the ASF cannot help them. if they are
> > acting for the ASF then the ASF can defend them in court.
> >
> > so, the trick is setting up a structure which imposes as little friction
> > on development as possible but which allows developers to develop for
> > the ASF rather than on their own behalf. PMC'ers are part of the ASF
> > organisation by their membership of an ASF committee and can bind the
> > ASF to a particular course of action. they should therefore be protected
> > from disruptive litigation by the ASF legal umbrella. committers are
> > not. so, it's important for PMC's so recognise those who make important
> > contributions to the ASF in a reasonably prompt fashion.
> >
> > the question of the policy on author tags is related to this. it was
> > felt that PMC'ers may be weakening the legal argument (that they acting
> > on behalf on the ASF) if they added author tags to the code. might look
> > to a lawyer as if they were working for themselves. that's why
> > recognition elsewhere is fine.
>
> For me that falls apart in two places:
> 1. authorship != ownership, this is made clear by the file's header.
> 2. subversion contains enough information to target critical
> contributors. In my mind that is like worrying about a second story
> window that may be unlocked when your front door is off the hinges.
Subversion does indeed contain plenty of information. However, lawyers don't
understand source control systems, but they do understand plain text. A
technical perspective isn't what's important here; what lawyers understand,
and what is supported by legal precedent, is. That's where the board is
coming from, backed by legal advice.
> note that this argument is only valid for PMC'ers and is not relevant
> > for author tags for other developers. when committing patches from
> > developers who are not committers, it is important that the source of
> > the patch is noted in the commit (so that it can be tracked).
> >
> > > > >I'm proud of the code I've contributed and I think an @author tag
> is
> > > > >proper recognition.
> > > > I suppose that five years ago when I joined, I felt something
> similar.
> > > > At that time author tags were allowed, so it wasn't a problem. Over
> > > > time, that desire for such 'base' recognition has gone.
> > >
> > > You're probably right eventually. When I'm married and have kids I
> > > probably won't even remember this but until then I do care with
> > > respect to my own contributions.
> >
> > the maven generated team list and commit emails are better indexed (and
> > analysed) than the source. so, as a form of recognition, these generally
> > work better. author tags also seem to attract the wrong kind of
> > recognition: spam from uneducated users (who should be posting their
> > questions to the user list). we've also had arguments in the past about
> > authors who no longer wished to be associated with particular classes.
> > life is usually easier without them.
> >
> > > I think the best "policy" is to stay true to yourself and be tolerant
> > > of people with different policies. In my mind that will work today,
> > > tomorrow, and up until the earth is swallowed by the sun.
> >
> > that's pretty much my approach. i generally leave author tags alone. for
> > new classes, i add apache as the author. but my opinion is in the
> > minority and i can understand why components with classes with long
> > author lists prefer to insist on the maven team list.
>
> Well, IDEs with code folding make that irrelevant and those list of
> @author tags not need be so long as the @author can can be either one
> name per tag (common) or many comma separated names per tag (seemingly
> unknown).
Not everyone uses an IDE, and we shouldn't be basing decisions on the
assumption that everyone is. Many of us prefer to work with the same tools
we've been using for years, and we're just as productive with those tools as
others might be with an IDE.
--
Martin Cooper
--
> 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
>
>
Re: [all] Author tags [was Line width and such minutiae]
Posted by Sandy McArthur <sa...@apache.org>.
On 4/2/06, robert burrell donkin <ro...@blueyonder.co.uk> wrote:
>
> > > Gary Gregory wrote:
> > > > Based on the February 18, 2004, Apache Software Foundation Board
> > > > of Directors Meeting Minutes, author tags are "discouraged".
>
> <snip>
>
> > > Sandy McArthur wrote:
> > > >I have searched some and the arguments don't hold water with me.
> > > :-) Many things from lawyers and the board don't make sense ;-)
>
> here's the only convincing argument i know of:
>
> what worries the board (and other open source folks) is the effective
> destruction of open source projects by targeting (with individual
> lawsuits) the limited number of critical contributors who do crucial
> things such as cutting releases. if these individuals are acting on
> their own behalf, as a non-profit the ASF cannot help them. if they are
> acting for the ASF then the ASF can defend them in court.
>
> so, the trick is setting up a structure which imposes as little friction
> on development as possible but which allows developers to develop for
> the ASF rather than on their own behalf. PMC'ers are part of the ASF
> organisation by their membership of an ASF committee and can bind the
> ASF to a particular course of action. they should therefore be protected
> from disruptive litigation by the ASF legal umbrella. committers are
> not. so, it's important for PMC's so recognise those who make important
> contributions to the ASF in a reasonably prompt fashion.
>
> the question of the policy on author tags is related to this. it was
> felt that PMC'ers may be weakening the legal argument (that they acting
> on behalf on the ASF) if they added author tags to the code. might look
> to a lawyer as if they were working for themselves. that's why
> recognition elsewhere is fine.
For me that falls apart in two places:
1. authorship != ownership, this is made clear by the file's header.
2. subversion contains enough information to target critical
contributors. In my mind that is like worrying about a second story
window that may be unlocked when your front door is off the hinges.
> note that this argument is only valid for PMC'ers and is not relevant
> for author tags for other developers. when committing patches from
> developers who are not committers, it is important that the source of
> the patch is noted in the commit (so that it can be tracked).
>
> > > >I'm proud of the code I've contributed and I think an @author tag is
> > > >proper recognition.
> > > I suppose that five years ago when I joined, I felt something similar.
> > > At that time author tags were allowed, so it wasn't a problem. Over
> > > time, that desire for such 'base' recognition has gone.
> >
> > You're probably right eventually. When I'm married and have kids I
> > probably won't even remember this but until then I do care with
> > respect to my own contributions.
>
> the maven generated team list and commit emails are better indexed (and
> analysed) than the source. so, as a form of recognition, these generally
> work better. author tags also seem to attract the wrong kind of
> recognition: spam from uneducated users (who should be posting their
> questions to the user list). we've also had arguments in the past about
> authors who no longer wished to be associated with particular classes.
> life is usually easier without them.
>
> > I think the best "policy" is to stay true to yourself and be tolerant
> > of people with different policies. In my mind that will work today,
> > tomorrow, and up until the earth is swallowed by the sun.
>
> that's pretty much my approach. i generally leave author tags alone. for
> new classes, i add apache as the author. but my opinion is in the
> minority and i can understand why components with classes with long
> author lists prefer to insist on the maven team list.
Well, IDEs with code folding make that irrelevant and those list of
@author tags not need be so long as the @author can can be either one
name per tag (common) or many comma separated names per tag (seemingly
unknown).
--
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
Re: [all] Author tags [was Line width and such minutiae]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
> > Gary Gregory wrote:
> > > Based on the February 18, 2004, Apache Software Foundation Board
> > > of Directors Meeting Minutes, author tags are "discouraged".
<snip>
> > Sandy McArthur wrote:
> > >I have searched some and the arguments don't hold water with me.
> > :-) Many things from lawyers and the board don't make sense ;-)
here's the only convincing argument i know of:
what worries the board (and other open source folks) is the effective
destruction of open source projects by targeting (with individual
lawsuits) the limited number of critical contributors who do crucial
things such as cutting releases. if these individuals are acting on
their own behalf, as a non-profit the ASF cannot help them. if they are
acting for the ASF then the ASF can defend them in court.
so, the trick is setting up a structure which imposes as little friction
on development as possible but which allows developers to develop for
the ASF rather than on their own behalf. PMC'ers are part of the ASF
organisation by their membership of an ASF committee and can bind the
ASF to a particular course of action. they should therefore be protected
from disruptive litigation by the ASF legal umbrella. committers are
not. so, it's important for PMC's so recognise those who make important
contributions to the ASF in a reasonably prompt fashion.
the question of the policy on author tags is related to this. it was
felt that PMC'ers may be weakening the legal argument (that they acting
on behalf on the ASF) if they added author tags to the code. might look
to a lawyer as if they were working for themselves. that's why
recognition elsewhere is fine.
note that this argument is only valid for PMC'ers and is not relevant
for author tags for other developers. when committing patches from
developers who are not committers, it is important that the source of
the patch is noted in the commit (so that it can be tracked).
> > >I'm proud of the code I've contributed and I think an @author tag is
> > >proper recognition.
> > I suppose that five years ago when I joined, I felt something similar.
> > At that time author tags were allowed, so it wasn't a problem. Over
> > time, that desire for such 'base' recognition has gone.
>
> You're probably right eventually. When I'm married and have kids I
> probably won't even remember this but until then I do care with
> respect to my own contributions.
the maven generated team list and commit emails are better indexed (and
analysed) than the source. so, as a form of recognition, these generally
work better. author tags also seem to attract the wrong kind of
recognition: spam from uneducated users (who should be posting their
questions to the user list). we've also had arguments in the past about
authors who no longer wished to be associated with particular classes.
life is usually easier without them.
> I think the best "policy" is to stay true to yourself and be tolerant
> of people with different policies. In my mind that will work today,
> tomorrow, and up until the earth is swallowed by the sun.
that's pretty much my approach. i generally leave author tags alone. for
new classes, i add apache as the author. but my opinion is in the
minority and i can understand why components with classes with long
author lists prefer to insist on the maven team list.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Author tags [was Line width and such minutiae]
Posted by Rahul Akolkar <ra...@gmail.com>.
On 3/28/06, Sandy McArthur <sa...@apache.org> wrote:
> On 3/28/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
<snip/>
> >
> > AFAIR we haven't ever voted on this, as removing existing author tags is
> > always been a touchy subject when brought up. At present, its a
> > component-level choice.
> >
<snap/>
And this will keep coming back and eating into our cycles. IMO,
[codec] took the right step. So, we're content with leaving this open
i.e. we are resigned to this fate since the belief is that no
consensus is ever possible?
> > I believe that it is general practice in commons to refer to the author
> > in commit comments, and to use the maven team list facility, but I could
> > be wrong.
> >
<snip/>
If its not, it should be the general practice -- or someone should
post objections.
> > Certainly [collections] still has author tags, although I had recently
> > considered proposing their removal as I now find them a hassle.
> >
<snap/>
"Join the club".
> > Sandy McArthur wrote:
<snip/>
>
> I think the best "policy" is to stay true to yourself and be tolerant
> of people with different policies. In my mind that will work today,
> tomorrow, and up until the earth is swallowed by the sun.
>
<snap/>
I believe thats the crux -- freedom, personal conviction and tolerance
are *not* mutually exclusive in any combinations thereof.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Author tags [was Line width and such minutiae]
Posted by Sandy McArthur <sa...@apache.org>.
On 3/28/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Henri Yandell wrote:
> > If we have decided [to remove author tags], then I'm happy to
> > script them all out
> > (and into team list files etc). And we should probably make sure
> > that we take care of disagreements now rather than later.
>
> Gary Gregory wrote:
> > Based on the February 18, 2004, Apache Software Foundation Board
> > of Directors Meeting Minutes, author tags are "discouraged".
>
> AFAIR we haven't ever voted on this, as removing existing author tags is
> always been a touchy subject when brought up. At present, its a
> component-level choice.
>
> I believe that it is general practice in commons to refer to the author
> in commit comments, and to use the maven team list facility, but I could
> be wrong.
>
> Certainly [collections] still has author tags, although I had recently
> considered proposing their removal as I now find them a hassle.
>
> Sandy McArthur wrote:
> >I have searched some and the arguments don't hold water with me.
> :-) Many things from lawyers and the board don't make sense ;-)
>
> >I'm proud of the code I've contributed and I think an @author tag is
> >proper recognition.
> I suppose that five years ago when I joined, I felt something similar.
> At that time author tags were allowed, so it wasn't a problem. Over
> time, that desire for such 'base' recognition has gone.
You're probably right eventually. When I'm married and have kids I
probably won't even remember this but until then I do care with
respect to my own contributions.
I think the best "policy" is to stay true to yourself and be tolerant
of people with different policies. In my mind that will work today,
tomorrow, and up until the earth is swallowed by the sun.
> IMHO, the true recognition is from the peers in your community. As a
> peer, I can say that we have already recognised your contributions so
> far (by voting you a committer for example). I personally also greatly
> appreciate the new life that you have instilled in both pool and dbcp.
>
> It is a balance though. Martin's 'egoless programming' comment is
> essentialy correct. I am here because I want to code, I want to learn,
> because I enjoy the community and I want to share. It is possible that I
> may benefit career-wise, or perhaps not.
>
> What I do know is that I don't feel any need to shout my contribution
> via an author tag - there are plenty of other outlets to mention the
> work I do (maven team-list, blog, Javalobby, the server side...) if and
> when I feel it appropriate.
>
> In summary however, I still think a board-level command 'no author tags'
> was a bit silly as it just created lots of wasted man-hours on debate
> instead of code. But, c'est la vie.
>
> Stephen
--
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
Re: [all] Author tags [was Line width and such minutiae]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Henri Yandell wrote:
> If we have decided [to remove author tags], then I'm happy to
> script them all out
> (and into team list files etc). And we should probably make sure
> that we take care of disagreements now rather than later.
Gary Gregory wrote:
> Based on the February 18, 2004, Apache Software Foundation Board
> of Directors Meeting Minutes, author tags are "discouraged".
AFAIR we haven't ever voted on this, as removing existing author tags is
always been a touchy subject when brought up. At present, its a
component-level choice.
I believe that it is general practice in commons to refer to the author
in commit comments, and to use the maven team list facility, but I could
be wrong.
Certainly [collections] still has author tags, although I had recently
considered proposing their removal as I now find them a hassle.
Sandy McArthur wrote:
>I have searched some and the arguments don't hold water with me.
:-) Many things from lawyers and the board don't make sense ;-)
>I'm proud of the code I've contributed and I think an @author tag is
>proper recognition.
I suppose that five years ago when I joined, I felt something similar.
At that time author tags were allowed, so it wasn't a problem. Over
time, that desire for such 'base' recognition has gone.
IMHO, the true recognition is from the peers in your community. As a
peer, I can say that we have already recognised your contributions so
far (by voting you a committer for example). I personally also greatly
appreciate the new life that you have instilled in both pool and dbcp.
It is a balance though. Martin's 'egoless programming' comment is
essentialy correct. I am here because I want to code, I want to learn,
because I enjoy the community and I want to share. It is possible that I
may benefit career-wise, or perhaps not.
What I do know is that I don't feel any need to shout my contribution
via an author tag - there are plenty of other outlets to mention the
work I do (maven team-list, blog, Javalobby, the server side...) if and
when I feel it appropriate.
In summary however, I still think a board-level command 'no author tags'
was a bit silly as it just created lots of wasted man-hours on debate
instead of code. But, c'est la vie.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Line width and such minutiae
Posted by Martin Cooper <ma...@apache.org>.
On 3/28/06, Henri Yandell <fl...@gmail.com> wrote:
>
> On 3/28/06, Sandy McArthur <sa...@apache.org> wrote:
>
> > I have searched some and the arguments don't hold water with me.
>
> Main reasons I cba to put my name on stuff I touch or create nowadays:
>
> * Private emails asking questions, offering patches etc. It starts to add
> up.
> * It's an effort to put @author in. I'm lazy. Lots of names in one
> file does start to feel spammy.
> * It's pretty minor in terms of recognition.
>
> > 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.
>
> Until we decide as a community to remove the @author bits
Hmm, I thought we'd made that decision some time ago. Am I spacing?
, you're
> welcome to keep adding them in. I'm pretty sure we've not made any
> community decisions as that thread would have stretched on for a long
> time.
>
> It's not a case of borg btw; the alternative to @author appears to be
> listing the people involved in a project somewhere. Might be
> interesting to do that per release :) Very Sesame St; "Commons Lang
> 2.2 came to you via the work of ....".
We already list the developers on the component web sites. For Pool, for
example:
http://jakarta.apache.org/commons/pool/team-list.html
--
Martin Cooper
To refer directly to Rahul's "some of us believe" bit; I also believe
> that 50% of javadoc is a distraction to the code :) I doubt we're
> going to change that.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Line width and such minutiae
Posted by Henri Yandell <fl...@gmail.com>.
On 3/28/06, Sandy McArthur <sa...@apache.org> wrote:
> I have searched some and the arguments don't hold water with me.
Main reasons I cba to put my name on stuff I touch or create nowadays:
* Private emails asking questions, offering patches etc. It starts to add up.
* It's an effort to put @author in. I'm lazy. Lots of names in one
file does start to feel spammy.
* It's pretty minor in terms of recognition.
> 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.
Until we decide as a community to remove the @author bits, you're
welcome to keep adding them in. I'm pretty sure we've not made any
community decisions as that thread would have stretched on for a long
time.
It's not a case of borg btw; the alternative to @author appears to be
listing the people involved in a project somewhere. Might be
interesting to do that per release :) Very Sesame St; "Commons Lang
2.2 came to you via the work of ....".
To refer directly to Rahul's "some of us believe" bit; I also believe
that 50% of javadoc is a distraction to the code :) I doubt we're
going to change that.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Line width and such minutiae
Posted by Sandy McArthur <sa...@apache.org>.
On 3/28/06, Phil Steitz <ph...@gmail.com> wrote:
> On 3/27/06, Rahul Akolkar <ra...@gmail.com> wrote:
> > On 3/27/06, Rahul Akolkar <ra...@gmail.com> wrote:
> > > On 3/27/06, Sandy McArthur <sa...@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
Re: [all] Line width and such minutiae
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> On 3/28/06, Henri Yandell <fl...@gmail.com> wrote:
>>For the record, I like 120 column line widths. Java's a verbose
>>language, 80 feels cramped. People can print in landscape :)
>>On 3/28/06, Phil Steitz <ph...@gmail.com> wrote:
>>>My personal preference is 80 column line widths, partly because this
>>>makes diffs readable.
Martin Cooper wrote:
> For me, printing is not the issue, side-by-side diffs are the issue. I hate
> having to scroll horizontally all the time to see the actual diffs. That's
> why I'm with Phil on 80 character widths.
Ah, the joy of a line width debate.
My choice is a 80 character basic width extending to 120+ when it make
it more readable.
But in the big scheme of things, its not that important.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Line width and such minutiae
Posted by Martin Cooper <ma...@apache.org>.
On 3/28/06, Henri Yandell <fl...@gmail.com> wrote:
>
> On 3/28/06, Phil Steitz <ph...@gmail.com> wrote:
>
> > My personal preference is 80 column line widths, partly because this
> > makes diffs readable.
>
> Sorry, forgot to add this to the other email.
>
> For the record, I like 120 column line widths. Java's a verbose
> language, 80 feels cramped. People can print in landscape :)
For me, printing is not the issue, side-by-side diffs are the issue. I hate
having to scroll horizontally all the time to see the actual diffs. That's
why I'm with Phil on 80 character widths.
--
Martin Cooper
Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [all] Line width and such minutiae
Posted by Henri Yandell <fl...@gmail.com>.
On 3/28/06, Phil Steitz <ph...@gmail.com> wrote:
> My personal preference is 80 column line widths, partly because this
> makes diffs readable.
Sorry, forgot to add this to the other email.
For the record, I like 120 column line widths. Java's a verbose
language, 80 feels cramped. People can print in landscape :)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Line width and such minutiae
Posted by Phil Steitz <ph...@gmail.com>.
On 3/27/06, Rahul Akolkar <ra...@gmail.com> wrote:
> On 3/27/06, Rahul Akolkar <ra...@gmail.com> wrote:
> > On 3/27/06, Sandy McArthur <sa...@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 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 ;-)
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org