commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [VOTE] Revised dormancy policy
Date Tue, 17 May 2011 08:31:33 GMT

----- "Phil Steitz" <phil.steitz@gmail.com> a écrit :

> On 5/16/11 4:21 PM, sebb wrote:
> > On 17 May 2011 00:07, Gary Gregory <garydgregory@gmail.com> wrote:
> >> On Mon, May 16, 2011 at 5:57 PM, Paul Libbrecht <paul@hoplahup.net>
> wrote:
> >>
> >>> So we should relaunch a vote?
> >>> (or... I should vote a no and relaunch?)
> >>>
> >>> paul
> >>>
> >>>
> >>> Le 16 mai 2011 à 23:44, Phil Steitz a écrit :
> >>>
> >>>>>>   d) svn remains open (but no commits without revival vote)
> >>>>> It seems slightly too harsh to me.
> >>>>> Since jelly is among the heaviest targeted ones here, I think
> the whole
> >>> dormancy aspect would fit but preventing commits sounds like the
> best way to
> >>> "cap off any attempt of revival".
> >>>>> Couldn't we say
> >>>>>
> >>>> Good point.  I would be OK with that change.
> > +1 to allowing SVN changes.
> >
> >>>> Phil
> >>>>>>   d) svn remains open (but no release without revival vote)
> >> Dormant status feels like a death sentence of sorts or at least
> another
> >> barrier to entry.
> >>
> >> If a committer wants to fiddle with POMs for example across all of
> commons,
> >> he or she should be able to do so. Even a casual change like fixing
> typos
> >> would not be allowed.
> >>
> >> I wonder if the opposite would not be more interesting: showing
> which
> >> projects are Active.
> >>
> >> The whole dormant/active deliberation could be remedied with a page
> ranking
> >> project activity by commit + ML activity + last release date for
> example.
> >>
> >> The audience can decide what is active based on this table: Project
> Name,
> >> Commits Last Week/Month/Year | ML msg count week/month/year | Last
> Release
> >> and Date
> > Mature and stable components will tend to have low activity, but
> > should not be marked dormant.
> >
> > It would be useful to know which projects have outstanding bugs
> that
> > are not being addressed - that seems more likely to indicate
> dormancy.
> >
> 
> I agree with your points, but I am very hesitant to get into the
> maintaining metrics game, partly because maintaining them requires
> work but more because I don't really believe they can tell us what
> we need to know to make these decisions.  Some active components,
> for some periods, have big backlogs and relatively slow response. 
> Some bugs get "attention" but no resolution for a long time.  And as
> you said, some stable, but still active components have few issues
> and commits during some periods.
> 
> What I wanted to capture in "dormancy" was community consensus that
> nothing was - currently - going on with the component.  The best way
> to determine that is to ask the question, "is anyone planning to do
> any work on this any time soon?"  Voting -1 on a dormancy vote as I
> have described it effectively means "yes" or at least "maybe."   I
> bet we can relatively quickly get to consensus on some really
> "dormant" stuff (e.g. [attributes]) and any that are in any way
> debatable, (e.g. [jelly]), we leave as active and revisit now and
> then if there are no signs of life.  My idea here was to make this a
> "small reversible step" for us as a community, not a radical change
> and not something that will create a lot of work or noise.

I agree with the proposal including the change to svn commits, and I agree
with Phil's view in the paragraph above.

Luc

> 
> Phil
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message