On 20 May 2011 00:48, Jörg Schaible <joerg.schai...@gmx.de> wrote: > sebb wrote: > >> On 19 May 2011 06:34, Phil Steitz <phil.ste...@gmail.com> wrote: >>> On 5/18/11 9:36 PM, Henri Yandell wrote: >>>> The following rule seems unnecessary to me: >>>> >>>> http://wiki.apache.org/commons/CommonsEtiquette#Commons_Etiquette >>>> >>>> "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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
