I think the email trail will be fairly clear one way or the other, and hence still oppose adding more labels to the situation.
----- Original Message ----- > From: Daniel Shahaf <d...@daniel.shahaf.name> > To: "general@incubator.apache.org" <general@incubator.apache.org> > Cc: > Sent: Sunday, January 15, 2012 12:37 PM > Subject: Re: Parking Projects [WAS Re: -1 on this months board report (was: > Small but otherwise happy podlings)] > > 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...@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 > <robertburrelldon...@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 >> > <ru...@intertwingly.net> wrote: >> >> >> On Wed, Jan 11, 2012 at 6:32 PM, Stuart Monteith >> > <stuk...@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-unsubscr...@incubator.apache.org >> >> > For additional commands, e-mail: > general-h...@incubator.apache.org >> >> > >> >> >> >> > --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> >> For additional commands, e-mail: > general-h...@incubator.apache.org >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > For additional commands, e-mail: general-h...@incubator.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
