geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject author tags (was: geronimo-dev Digest 12 Aug 2003 11:49:06 -0000 Issue 33)
Date Wed, 13 Aug 2003 21:08:53 GMT
On Tue, Aug 12, 2003 at 11:49:06AM -0000, wrote:
> From: Henri Yandell <>
> Subject: Re: Author Tags (was: geronimo-dev Digest 12 Aug 2003 07:13:43 -0000
>  Issue 31)
> To:
> Date: Tue, 12 Aug 2003 06:24:34 -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.

I mean both. See below.

> 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.

There will always be experts on various areas. For example, in httpd, I'm
very familiar with the I/O filtering and the DAV code (to name a couple).
But the proxy stuff? No clue. But I *do* know that Graham Legett knows the
proxy stuff code, but (vice versa) he doesn't really know the DAV code.

That will naturally happen, but it doesn't cause any problems *unless* you
attempt to enforce a partitioning. If you begin any sort of a document or
code attribution or whatever which says "John Doe is responsible for <X>"
then you're creating an environment where somebody might not feel empowered
to "cross the line". But we need that empowerment because at some point,
John Doe is going to leave, and we need others to fill in behind him.

> 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.

The PMC should be comprised of the active committers, so yes: the PMC makes
the technical/design decisions. To enable the legal oversight and
commensurate responsibility for the code, this is required. If somebody
besides the PMC is making the choices, then (obviously) that means the PMC
is *not* which means the ASF is *not* which then means the ASF cannot assume
its responsibility to provide the legal umbrella over that code.

> > 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?

I've put the question to the board for an official position. We'll discuss
this week, and (hopefully) have an official position after our board meeting
next Wednesday.

> > Lastly, recall that the ASF exists to provide a _LONG_TERM_ home to code.
> Strengthens my side on @author tags :)

Hunh? Not the way that I see it. John Doe *really* doesn't want to receive
an email 10 years from now, asking about some twiggly little class he wrote
in a project that he abandoned years before.

> 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.

All that information is in the CVS log messages. I still see no point in
recording that kind of information within the files.

> > 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.

In charge of specs... great. But sections of code? See above :-)

> 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.

"vital" ... I'm still not seeing that. ??  I believe that you've gotten used
to having them, sure, but I wouldn't think their presence is "vital".


Greg Stein,

View raw message