hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McGrady <m...@michaelmcgrady.com>
Subject RE: @author tags
Date Fri, 12 Mar 2004 15:14:37 GMT
We all love Roland.  No issue there.  However, I really cannot see how the 
@author tag hides any contributions.  Maybe on that issue I am lost?  That 
is another matter altogether.  I was discussing the legal ramifications solely.

At 05:19 AM 3/12/2004, you wrote:

> > Love yah, Roland, but this is not your shining hour.
>
>Actually Roland shines when it comes to giving feedback to proposed 
>changes, patches, answering questions, and helping people on the mailing. 
>He is precisely the reason I (as a HttpClient project committer) would 
>like to have a better attribution structure that goes beyond @author tag. 
>The @author may be a very misleading indicator of one's contribution and 
>its value. Roland contribution is currently MASSIVELY understated within 
>the existing attribution structure. As much as I would regret to see 
>@author go, at the same time I would whole-heartedly welcome a better 
>system of giving due credits to the regular contributors like Roland. If 
>the board comes up with viable substitution to the @author tag, so be it
>
>Oleg
>
>
>-----Original Message-----
>From: Michael McGrady [mailto:mike@michaelmcgrady.com]
>Sent: Friday, March 12, 2004 13:38
>To: Commons HttpClient Project
>Subject: Re: @author tags
>
>
>Roland Weber wrote:
>
> >I don't see that either. But if some of the top Apache guys
> >feel, believe or know otherwise, that's good enough for me.
>
>Know what?  This has become a recreation of illusions and delusions.  This
>
>is like Franz Kafka's book The Trial.  There are vague and unsubstantiated
>
>reasons for changing the entire attribution structure of the open source
>
>community.  This is not good thinking.
>
> >If the only purpose of the tags is to feature contributor names
> >in a prominent place - namely the source code - then the
> >real question becomes whether we can achieve this goal
> >in some other way with reasonable effort.
>
>This is NOT the only goal.  That is not even close to accurate.
>
>
>
> >Concerning the CVS log, you have to be aware that the
> >committer is not always the contributor. A contributor
> >may put a patch in bugzilla, which is then comitted by
> >someone else.
>
>Well, in the paranoid sort of talk we are having, then the "committer"
>
>becomes subject to these imagined but unreal legal assaults.  Indeed, where
>
>an "author" is hidden, the Foundation would become liable for a
>
>"conspiracy" of hiding the real culprits.  This is all silly from a legal
>
>standpoint.
>
>
> >In general, I don't believe that the removal of author tags
> >is to disguise from where the code came. Rather, some
> >people may be afraid to find their name in the author tag
> >of code which has no longer anything to do with what
> >they actually contributed long ago.
>
>This is yet another reason?  This is also not right.  The @author tags keep
>
>track of rather than obscure people's relation to existing code.  The
>
>destruction of this useful device will create rather than solve anything
>
>akin to this imagined problem.
>
> >Then it would become
> >their problem to dig through the CVS logs, bugzilla, and
> >the mailing list archives to prove that they are *not* the
> >author.
>
>To whom?  This is just imaginary.  This is Alice in Wonderland thinking.
>
>Love yah, Roland, but this is not your shining hour.  Really, there is no
>
>legal difficulty, but this recommendation might create one.  Microsoft
>
>could not have come up with a better way to screw up the code.
>
>
>***************************************************************************************************
>The information in this email is confidential and may be legally 
>privileged.  Access to this email by anyone other than the intended 
>addressee is unauthorized.  If you are not the intended recipient of this 
>message, any review, disclosure, copying, distribution, retention, or any 
>action taken or omitted to be taken in reliance on it is prohibited and 
>may be unlawful.  If you are not the intended recipient, please reply to 
>or forward a copy of this message to the sender and delete the message, 
>any attachments, and any copies thereof from your system.
>***************************************************************************************************
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: 
>commons-httpclient-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message