incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Parking Projects [WAS Re: -1 on this months board report (was: Small but otherwise happy podlings)]
Date Sun, 15 Jan 2012 17:37:57 GMT
Relevant difference: when we reject a project we do that on public
lists, when you apply to a university the fact you did so is private.

Joe Schaefer wrote on Sun, Jan 15, 2012 at 09:03:45 -0800:
> I don't see why.  When you apply to a university you either
> receive an acceptance letter or a letter of regret; we don't
> have to make any other distinctions regarding our internal
> reasons either.  Simply part ways amicably and help them
> thru the exit door, no matter if they were chronic policy
> violators or simply didn't muster a sufficient dev community.
> 
> 
> 
> ----- Original Message -----
> > From: Daniel Shahaf <d.s@daniel.shahaf.name>
> > To: general@incubator.apache.org
> > Cc: 
> > Sent: Sunday, January 15, 2012 12:00 PM
> > Subject: Re: Parking Projects [WAS Re: -1 on this months board report (was: Small
but otherwise happy podlings)]
> > 
> > Joe Schaefer wrote on Sun, Jan 15, 2012 at 08:48:02 -0800:
> >>  Why do we need these obscure notions to characterize a failed incubation
> >>  effort?  Can't we be adults and say it simply didn't work out, no
> >>  harm no foul, best of luck in your future endeavors elsewhere?
> >>  I sure hope we aren't going to get into the business of promising
> >>  zombie projects a perpetual home in the incubator.
> >> 
> > 
> > For that to work we should be able to make a (public) distinction
> > between projects that failed to graduate due to 'negative' reasons
> > (say: having dev discussions off-list) and for 'non-positive' reasons
> > (say: failed to maintain 3 active PMCers).
> > 
> > And clarify if/how projects that were leaved may ask to reenter.
> > 
> >> 
> >>  ----- Original Message -----
> >>  > From: Robert Burrell Donkin <robertburrelldonkin@gmail.com>
> >>  > To: general@incubator.apache.org
> >>  > Cc: 
> >>  > Sent: Sunday, January 15, 2012 11:31 AM
> >>  > Subject: Parking Projects [WAS Re: -1 on this months board report 
> > (was: Small but otherwise happy podlings)]
> >>  > 
> >>  > On Wed, Jan 11, 2012 at 11:55 PM, Sam Ruby 
> > <rubys@intertwingly.net> wrote:
> >>  >>  On Wed, Jan 11, 2012 at 6:32 PM, Stuart Monteith 
> > <stukato@stoo.me.uk> 
> >>  > wrote:
> >>  > 
> >>  > <snip>
> >>  > 
> >>  >>>  I'll back up what Ant said - Robert and Ant have shown 
> > heroic 
> >>  > patience as mentors on this project. The situation will resolve itself

> > one way 
> >>  > or the other soon.
> >>  >> 
> >>  >>  If the question is whether Robert and Ant are good guys, there is

> > no
> >>  >>  question, they both have my vote on that question.
> >>  > 
> >>  > As a Kato mentor, I see my role as ensuring that the Foundation is
> >>  > safe and that Kato is run the Apache Way, not fixing all that's 
> > broken
> >>  > in the Incubator.
> >>  > 
> >>  >>  If the question is whether or not a podling can essentially copy

> > and
> >>  >>  paste the same report quarter after quarter, year after year, 
> > with
> >>  >>  little or no change, then I strongly object.
> >>  > 
> >>  > ATM Incubation works well only for main sequence projects. The IPMC
> >>  > has collectively failed to account in its system for podlings that
> >>  > encounter unusual issues that force them from the sequence.
> >>  > 
> >>  > IMO it is the responsibility of the IPMC to fix the system when it
> >>  > breaks, not the Mentors of the podling. For month after month, Kato
> >>  > has been flagged in the reports as stalled but no one in the IPMC
> >>  > community thought to even discuss how to fix this before now.
> >>  > 
> >>  > (And now the IPMC seems to have brought only one club: terminate any
> >>  > podling which leaves the main sequence...)
> >>  > 
> >>  > Kato is not the first podling to be stalled. It will not be the last.
> >>  > A 'parked' status (freezing the podling but allowing an 
> > efficient
> >>  > restart) is IMO the right way to manage this.
> >>  > 
> >>  > Robert
> >>  > 
> >>  > ---------------------------------------------------------------------
> >>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>  > For additional commands, e-mail: general-help@incubator.apache.org
> >>  >
> >> 
> >>  ---------------------------------------------------------------------
> >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>  For additional commands, e-mail: general-help@incubator.apache.org
> >> 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message