Author Tags (was: geronimo-dev Digest 12 Aug 2003 07:13:43 -0000 Issue 31)

[Greg Stein <gs...@lyra.org>]

On Tue, Aug 12, 2003 at 07:13:43AM -0000, geronimo-dev-digest-help@incubator.apache.org wrote:
>...
> From: Henri Yandell <ba...@generationjava.com>
> Subject: Re: Author Tags
> To: geronimo-dev@incubator.apache.org
> Date: Mon, 11 Aug 2003 21:09:13 -0400 (EDT)
>...
> Code ownership is bad. But only in terms of the old corporate concept that
> only Mr X can change a piece of code. Code responsibility is important
> however. I've found that when you throw away code ownership, you often end
> up with no one caring.
> 
> Code responsibility means that even though anyone may leap in and hack on
> a piece, the long term future of a piece of code is the responsibility of
> known people. Effectively code-ownership [bad] is implementation while
> code responsibility [good] is design. Author tags signify code
> responsibility.
>...
> From: "Daniel F. Savarese" <df...@savarese.org>
> Subject: Re: Author Tags 
> To: geronimo-dev@incubator.apache.org
> Date: Mon, 11 Aug 2003 22:02:58 -0400
>...
> Although I agree with the conclusion, I disagree with the reasons.
> Whether it's author tags or change logs, the reason you list names
> is to maintain accountability, not to give credit.  The
>...
> Can you explain it to me so I can make this change?"  Anyway, that's my
> possibly misguided take on the Apache Way: it's not recognition
> that matters, but responsibility.

The Project Management Committee (PMC) is responsible for the code. Period.
That is very clear and is quite specific. The entire point of the ASF is to
ensure that that happens, which is also the reason that all active
committers need to be on the PMC.

Why? Because the PMC (i.e. the committers) operates at the direction of the
ASF. Thus, the code is developed and maintained at the direction of the ASF.
Thus, the ASF can defend those developers against any legal attacks on the
codebase by saying, "they're just following our instructions/desires; they
did not act independently, so you cannot say they are at fault."

If there is any way for a third party [bringing suit against us] to show
that a specific developer is "responsible" for a chunk of code, then there
isn't much the ASF can do to help that person. The ASF exists (primarily) to
provide code to the public, but our secondary responsibility is to provide
an environment where that is possible. And that means to operate within a
legal context. The structure of the ASF and its PMCs is a way to establish
that shield without imposing a burden on the developers.

Lastly, recall that the ASF exists to provide a _LONG_TERM_ home to code.
The ASF exists to provide a place for code to outlive any individual
contributor. Many developers will be interested in some code, but eventually
will move on to other things. This is part of why the ASF cares so much
about the community -- it outlives individual developers. If you can build
an effective community, then it doesn't matter that a developer moves on.
The community is there to pick up and continue where that person left off.
Because of the natural shift in the developer base, it is not possible to
assign any kind of (long term) responsibility to individuals. That
responsibility must fall to the PMC. Only the PMC will exist in the long
term to provide the necessary care and feeding of the codebase.

Maybe there are reasons to have author tags, but I would *really* discourage
their use as a mechanism to establish responsibility for any piece of code.

I think the real problem that you want to solve is how to build a community
that cares about the code, no matter who may happen to have contributed it
in the first place, or who happens to change it the most. To build a
community where everybody feels responsible for the code, and who feels
empowered to make the necessary changes.

Cheers,
-g

p.s. to clarify for those who haven't seen me post much: this post was from
gstein@lyra.org meaning "me"; when I post from gstein@apache.org, then I'm
speaking with an ASF hat on; in other words, my opinions (above) don't
represent the ASF, although my comments about the structure and purpose of
the ASF are "real" rather than personal opinion.

-- 
Greg Stein, http://www.lyra.org/

Re: SVN?

[Paul Hammant <Pa...@ThoughtWorks.net>]

>>Want to try using SVN?  Is it ready?
>>
>>    
>>
>
>Would love to if it isn't too hard to get people up and running. My biggest
>concern would be client support (availability of IDE integration etc), but
>maybe the server-side benefits (like move :-) outweigh that.
>
>Do we have any SVN experts around?
>  
>
We are using it inside of Thoughworks for an intranet (code and content 
management). It is ready for use for the brave, but not released.  It 
would be up to Apache's board to roll it out; not so much for Geronmio 
developers to choose it (I think). For others though I really recommend it.

- Paul

-- 
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...

RE: SVN?

["Noel J. Bergman" <no...@devtech.com>]

Bruce Snyder wrote:
> Jeremy Boynes said:
> > Noel J. Bergman wrote:
> > > Want to try using SVN?  Is it ready?
> > Would love to if it isn't too hard to get people up and running. My
biggest
> > concern would be client support (availability of IDE integration etc),
but
> > maybe the server-side benefits (like move :-) outweigh that.
> > Do we have any SVN experts around?

> I agree. I've been thinking about installing it on one of my servers at
home
> to play with it. I'd love to be able to use it.

Yes, Subversion is around for testing.  I don't know if it is considered
suitable enough, but the impression I have is that *IF* SVN were to be used,
it would be better to start with it, and not migrate.  I get the feeling
that the Subversion core is more ready than the CVS migration tools.
However, I am not an SVN expert, and there are others here who are, which is
why I phrased my message as a question.

Client support includes http://rapidsvn.tigris.org/,
http://tortoisesvn.tigris.org/, and of course, the svn command line
interface.

	--- Noel

Re: SVN?

[Brian McCallister <mc...@forthillcompany.com>]

We experimented briefly with SVN a month or so ago and decided it 
wasn't ready for production use yet:

1) None of the servers we were willing to certify for production met 
its requirements for up-to-dateness of packages (it takes a lot of 
brand new, with particular patches, packages).

2) Database corrupts far too often. It is an "easy to fix" corruption, 
and they include the tool to do it, but... no thank you.

Other than that it worked nicely.

-Brian

On Tuesday, August 12, 2003, at 01:45 PM, Bruce Snyder wrote:

> This one time, at band camp, Jeremy Boynes said:
>
> JB>Noel J. Bergman wrote:
> JB>> Want to try using SVN?  Is it ready?
> JB>>
> JB>
> JB>Would love to if it isn't too hard to get people up and running. My 
> biggest
> JB>concern would be client support (availability of IDE integration 
> etc), but
> JB>maybe the server-side benefits (like move :-) outweigh that.
> JB>
> JB>Do we have any SVN experts around?
> JB>
> JB>Is there a sandbox?
>
> I agree. I've been thinking about installing it on one of my servers 
> at home
> to play with it. I'd love to be able to use it.
>
> Bruce
> -- 
> perl -e 'print 
> unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
>
> The Castor Project
> http://www.castor.org/
>
> Apache Geronimo
> http://incubator.apache.org/projects/geronimo.html
>
>

Re: SVN?

[Bruce Snyder <fe...@frii.com>]

This one time, at band camp, Jeremy Boynes said:

JB>Noel J. Bergman wrote:
JB>> Want to try using SVN?  Is it ready?
JB>>
JB>
JB>Would love to if it isn't too hard to get people up and running. My biggest
JB>concern would be client support (availability of IDE integration etc), but
JB>maybe the server-side benefits (like move :-) outweigh that.
JB>
JB>Do we have any SVN experts around?
JB>
JB>Is there a sandbox?

I agree. I've been thinking about installing it on one of my servers at home
to play with it. I'd love to be able to use it. 

Bruce
-- 
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

The Castor Project 
http://www.castor.org/

Apache Geronimo 
http://incubator.apache.org/projects/geronimo.html

SVN?

[Jeremy Boynes <je...@coredevelopers.net>]

Noel J. Bergman wrote:
> Want to try using SVN?  Is it ready?
>

Would love to if it isn't too hard to get people up and running. My biggest
concern would be client support (availability of IDE integration etc), but
maybe the server-side benefits (like move :-) outweigh that.

Do we have any SVN experts around?

Is there a sandbox?

--
Jeremy

RE: Author Tags (was: geronimo-dev Digest 12 Aug 2003 07:13:43 -0000 Issue 31)

["Noel J. Bergman" <no...@devtech.com>]

> CVS is a problematic repository, we all know that. There is no CVS move.
> So while the code in some of the Jakarta Commons packages have moved N
> times, it has not lost its @author tags to tell you where it came from.

Want to try using SVN?  Is it ready?

	--- Noel

Re: Author Tags (was: geronimo-dev Digest 12 Aug 2003 07:13:43 -0000 Issue 31)

[Henri Yandell <ba...@generationjava.com>]

On Tue, 12 Aug 2003, Greg Stein wrote:

> On Tue, Aug 12, 2003 at 07:13:43AM -0000, geronimo-dev-digest-help@incubator.apache.org wrote:
> >...
> > From: Henri Yandell <ba...@generationjava.com>
> > Subject: Re: Author Tags
> > To: geronimo-dev@incubator.apache.org
> > Date: Mon, 11 Aug 2003 21:09:13 -0400 (EDT)
> >...
> > Code responsibility means that even though anyone may leap in and hack on
> > a piece, the long term future of a piece of code is the responsibility of
> > known people. Effectively code-ownership [bad] is implementation while
> > code responsibility [good] is design. Author tags signify code
> > responsibility.
>
> The Project Management Committee (PMC) is responsible for the code. Period.

I think you're warping my use of the word responsible. I take what you say
to mean that the PMC is legally responsible, whereas I am trying to argue
for design responsibility.

In a project such as Geronimo, responsibility is even more important.
There are large tomes of specifications to be met, is it expected that
every committer will be aware of each one? Or will there be small fiefdoms
of groups who are experts on each.

Then again, I was raised in the warped PMC world of Jakarta which still is
not what you envision a PMC as, so it might be that you do mmean that the
PMC makes design decisions.

> Thus, the ASF can defend those developers against any legal attacks on the
> codebase by saying, "they're just following our instructions/desires; they
> did not act independently, so you cannot say they are at fault."

Good point. If having author tags is a liability to the ASF's ability to
legally protect, then I'm all for removing them. Is this something you're
able to say with your Apache hat on so it can become gospel?

> Lastly, recall that the ASF exists to provide a _LONG_TERM_ home to code.

Strengthens my side on @author tags :) CVS is a problematic repository, we
all know that. There is no CVS move. So while the code in some of the
Jakarta Commons packages have moved N times, it has not lost its @author
tags to tell you where it came from. Sometimes the @author is 'The Turbine
Project' etc etc and not a single person.

> Maybe there are reasons to have author tags, but I would *really* discourage
> their use as a mechanism to establish responsibility for any piece of code.

It's not perfect I agree. A nice responsibility document would be best.
For example in Geronimo I'd like to see a document saying which committers
are in charge of which specs.

> I think the real problem that you want to solve is how to build a community
> that cares about the code, no matter who may happen to have contributed it
> in the first place, or who happens to change it the most. To build a
> community where everybody feels responsible for the code, and who feels
> empowered to make the necessary changes.

The real problem is that in my communities the @author tags are
performing a vital role. They're not perfect for that role, but they're
doing the job. I'm happy to lose the tags, but not the role.

Hen