I'm +0 about it. I think it's nice to know who wrote a piece of code before you modify it, so you can ask a quick question to the author. The main example I can find in Trinidad is the use of Hashtable and Vector every now and then, was it because of the old 1.2 codebase or was synchronization required? A simple mail to the author would have answered that question. Then again, I can see Craig's point as well as ASF concerns. The best compromise I can find is maintaining a history of changes in the Javadoc with the author names, but I really don't think many of us (starting with me) will have the patience to keep such a thing up-to-date, hence the +0.
On 2/28/07, Adam Winer <[EMAIL PROTECTED]> wrote:
I agree as well. There's something a little nice about @author tags as a way of giving credit to the people who aren't the obvious people on a project. But they're rarely kept up to date, and the implication of ownership is not very OSS-friendly. -- Adam On 2/26/07, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 2/26/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > > -1 for removing them. I don't see this as an "ownership" issue. It's > > helpful to know who in the community might be able to answer questions > > on a particular piece of code. I know with the Portal work I did, it > > was very handy to know WHO had written a piece of code, especially since > > they may not me monitoring the lists. > > > > This argument does not scale in the long term. My own experience is a > case in point -- my name is still splattered over lots of the Catalina > sources inside Tomcat, even though: > > * I have not worked on them for four years (but I still get >20 personal > emails for Tomcat help every week). > > * In many cases, the number of lines of code that were "mine" originally > is less than half of the total -- so the tag is totally misleading. > > * The real people you want to talk to are the ones who have been making > recent commits, not whoever wrote the code in the first place. > > I am strongly i+1 on removing @author tags, for the community related > reasons that have been previously published. > > Craig McClanahan >
