incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: Podlings, the Incubator, relationships and Apache
Date Mon, 24 Jun 2019 16:09:13 GMT
On Sun, Jun 23, 2019 at 11:26 PM Roman Shaposhnik <roman@shaposhnik.org> wrote:
>
> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rbowen@rcbowen.com> wrote:
> >
> > A couple of thoughts:
>
> And a couple of thoughts on top of that.
>
> > Podlings are not permitted to call themselves "Apache Foo" because they are
> > not yet full Apache projects.
>
> Correct. The I way I see this thread is this: *when it comes to
> releases*, there's
> always been two camps in Incubator. One thinks that Incubator is a TLP just
> like Apache Commons that happens to produce release artifacts that have
> nothing in common (just like Apache Commons'  JXPath has very little to do
> with Compress and). A second camp thinks that Incubator is actually a special
> construct within a foundation (after all, if it was just like Apache Commons why
> would we make them put DISCLAIMER into release tarballs?).
>
> It seems that David is closer to the 1st camp, and Rich and I are
> closer to the 2nd.
>

Hmmm, I must be poorly communicating.
I feel like I am closer to the second camp.
I think I explicitly said that my belief is that management of the
incubating products has been delegated to the Incubator, and the
incubator should be making 'business decisions' that balance the
interest of complying with the rules (perfection) with the inertia of
the community.



> Looking at the community benefits, I really think we should acknowledge that
> Incubator is a special construct and optimize that special construct
> for a particular
> outcome: which is effectiveness of the graduation process.
>
> > While in the incubator we should expect podlibgs to fail at the rules.
> > They're new to them and many of them feel arbitrary, even capricious, to
> > those coming in from outside. We should make it safe to fail until they are
> > ready to graduate. We should nurture them as long as they are moving
> > towards that goal.
>
> Yup.
>
> > I cannot disagree with your reading of our resolutions. But I wonder if
> > that reality is producing good citizen projects or a bunch of resentful
> > people following rules they don't understand or embrace because they know
> > they have to.
> >
> > Zipkin is only the latest project which clearly didn't get it and has left
> > angry. I would rather a project realize that they don't fit and be able to
> > leave with their dignity without having also to leave hating what we stand
> > for.
> >
> > I want our new graduates to love and understand the ASF not merely tolerate
> > it.
> >
> > I want the incubator to respond to failure with gentle correction rather
> > than scoldings.
> >
> > Specifically I think podlings should be able to produce releases that are
> > not asf complient and have them clearly labeled as such. Because they are
> > not TLPs yet and so cannot be held to the same standard. This must be
> > accompanied by a movement towards being a TLP, not some eternal incubation.
>

Yep - I think a large part of this should be the mentors working with
the project on a path towards meeting the standard of the TLP. I think
far too often the current path we tell projects is 'work towards the
first release - and then expecting the first release to meet all of
the standards. The first project I brought to the incubator spent 7
months trying to reach that acceptable state for release, so I am
familiar with the pain and the antagonism it breeds.


> With my IPMC member hat on -- huge +1 to the above.
>
> With my VP Legal hat on: I have no dog in this race. The IPMC needs to make
> a *business* (well, community in this case) decision and then we can work
> with a risk profile of that decision.

I wholeheartedly agree with you, and appreciate you making this
statement with the hat on.
IMO this should settle any concerns that the IPMC has about their
level of authority to make those decisions.

--David

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


Mime
View raw message