commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Unnecessary etiquette rule
Date Fri, 20 May 2011 01:18:53 GMT
On 20 May 2011 00:48, Jörg Schaible <> wrote:
> sebb wrote:
>> On 19 May 2011 06:34, Phil Steitz <> wrote:
>>> On 5/18/11 9:36 PM, Henri Yandell wrote:
>>>> The following rule seems unnecessary to me:
>>>> "each committer who commits to a component must add their name to the
>>>> STATUS file" (or pom.xml)
>>>> I've never done this, have touched every component (give or take a
>>>> component or two) and have never had negative feedback*. Either
>>>> everyone's being very polite or it's not actually a necessary piece of
>>>> etiquette :)
>>> Well, now that you mention it, your wanton pillaging has left a
>>> trail of devastation and fear in the hearts of Commoners across the
>>> realm  - he he.
>>> Seriously, I think that as stated, the rule is obsolete; but the
>>> spirit of it is good.  When that was originally written, components
>>> were all independently built using Ant, sites were, lets just say
>>> "diverse," mostly built using Anakia, and most of what people worked
>>> on was actual code internal to the components.  So when you started
>>> committing to a component, that meant you were going to really get
>>> into its code and join the little subcommunity that was working on
>>> it.  You signaled that by adding yourself to the STATUS file.
>>> Partly because we have added complexity and inter-dependency to the
>>> build and site generation processes, partly because people have
>>> shown willingness and interest in doing these things, we now have a
>>> decent incidence of people "touching" components without really
>>> jumping in to the code that deeply.  I think that is a *good thing*
>>> as it helps keep the code and sites in better shape.
>>> I still think it is a good idea for us to keep something like a
>>> STATUS file up to date indicating who the active committers are for
>>> each component.  I am not sure, honestly, if the pom.xml team list
>>> is the right place for this, though; as it is more
>>> externally-facing, gets published as part of releases, etc.  The
>>> current poms are also full of references to people who have not
>>> contributed in quite a while.  The value of having a team list that
>>> committers add themselves to and drop off of is that adding oneself
>>> is a statement of real interest in the component and willingness to
>>> help move it forward.  There are some old Wiki pages somewhere where
>>> we started to track this kind of thing; but IMO the component's svn
>>> is a better place.
>>> So bottom line is I think the rule should stand with s/commits to a
>>> component/makes a nontrivial change to a component/ and  s/STATUS
>>> file (or pom.xml)/not sure, maybe stay with pom/
>>> I also think we agree to take ourselves off of the lists when we are
>>> no longer contributing or seriously thinking about it - similar to
>>> the unwritten rule about taking yourself off a PMC.
>> I think it's reasonable for developers to add their own name (if they
>> wish) to the pom if they have made a non-trivial contribution to the
>> component.
>> The list of developers and contributors will of course grow over time.
>> I see the pom as being a way of recognising developers and
>> contributors (rather than the deprecated @author tags) so it's
>> important that the list is historic, not just current.
>> If we really need to record who is currently working on a component
>> (generally that's obvious from SVN commits and the dev list), then I
>> agree that a STATUS file or similar would be better than the Wiki. But
>> I'm not sure it's essential.
>> How do names get removed when they are no longer active?
> A committer is a committer, but we can utilize the role element on the Maven
> pom.

Sorry, I've no idea what you mean here. Can you explain please?

> - Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message