commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [DISCUSS] Putting several unmaintained components to dormant
Date Mon, 14 Oct 2013 16:18:01 GMT
The nice thing about Hen's solution is, that I expect it to be better
structured. When 20 people begin voting on 30 different components it will
get confusing in that thread. Having one single file which contains the
result of the vote would be very easy.

How do you want to reach non commons committers? By announcing on
community@? Or were you talking about those who lurk around on the ML
anyway :-)

Benedikt


2013/10/14 Phil Steitz <phil.steitz@gmail.com>

> On 10/14/13 2:04 AM, Henri Yandell wrote:
> > Wearing my old Attic fart hat - something is dead when there is no one
> left
> > to turn the light out. Something is inactive when it couldn't pass a vote
> > to keep the project alive (ie: 3 +1s).
> >
> > So that's one way to do this. Make a file in SVN. Put each component in
> it
> > (include the sandbox perhaps). Ask everyone to vote by putting their name
> > next to a component.
> >
> > Any component failing to get 3 names is a goner [aka up for debate, but
> the
> > point of the debate is to convince others to add their name to the
> > component]. Any component with zero names is a goner, kaput, deceased.
>
> Sounds good to me, with some slight changes. I think non-committers
> - especially ASF committers who are not commons committers - should
> be able to vote (with meaning as described below).  I was about to
> propose something similar to get the initial pruning done, and then
> an ongoing process like:
>
>  0) Anyone can present a "dormancy challenge" at any time for a
> component that they think might be dormant.   Just start a thread
> with subject [DORMANT][FOO] (content optional).
>  1) We allow a nice long time for people to chime in - say two
> weeks. If an ASF committer volunteers to RM a (future) release, or
> if at least 2 people signal intent to do material work on [FOO], the
> challenge fails and [FOO] remains active; otherwise it is lazily
> deemed dormant.
>  2) Reviving a dormant component requires nothing more than the
> action awaited in 1). Dormant components stay put in svn, but their
> websites and the main commons site designate them as dormant.
>
> So basically, you are presenting a challenge for "all" components to
> start.  I am +1 for that.  The key question is what exactly does it
> mean to vote +1 for a component.  It can't mean "we should keep it
> alive."  To be meaningful, it has to mean "I am going to work on
> it."  I would rather be more hard core on what +1 means and tolerant
> of only 2 +1s, especially if one of them is stepping up to RM.
>
> Phil
>
> Hen On Wed, Oct 9, 2013 at 12:17 PM, Benedikt Ritter
> <britter@apache.org> wrote:
> >> Hi,
> >>
> >> I think Phil came up with the idea to try to focus on the components
> that
> >> we are able to maintain and put all other stuff to dormant. Here is the
> >> list of components that I think really are proper:
> >>
> >> - CLI
> >> - Codec
> >> - Collections
> >> - Compress
> >> - Configuration
> >> - CSV
> >> - Daemon
> >> - DBCP (?)
> >> - Email
> >> - Functor
> >> - Imaging (?)
> >> - IO
> >> - JCI
> >> - Lang
> >> - Logging
> >> - Math
> >> - Net
> >> - Pool (?)
> >> - Proxy
> >> - SCXML (after recent interest)
> >> - VFS
> >> - Weaver
> >>
> >> All other stuff can go dormant because there is currently nobody who
> >> maintains it. Still a pretty long list. Thoughts? Anything missing?
> >>
> >> Benedikt
> >>
> >> --
> >> http://people.apache.org/~britter/
> >> http://www.systemoutprintln.de/
> >> http://twitter.com/BenediktRitter
> >> http://github.com/britter
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>  <dev-help@commons.apache.org>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message