+1 to 2nd camp. And even less requirements than have been suggested, I would offer. For example: if the tarball is missing a LICENSE or NOTICE file? Who cares. It's still a legal release. Just hard for downstream users to consume. But they *can*. Nothing stopping somebody from trying out the tarball.
Cheers, -g On Sun, Jun 23, 2019 at 10:53 PM Dave Fisher <dave2w...@comcast.net> wrote: > Thanks Roman! > > +1 to the 2nd camp! > > Regards, > Dave > > Sent from my iPhone > > > On Jun 23, 2019, at 8:25 PM, Roman Shaposhnik <ro...@shaposhnik.org> > wrote: > > > >> On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rbo...@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. > > > > 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. > > > > 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. > > > > Like I said -- the decision to make is: 1st vs. 2nd camp. > > > > Thanks, > > Roman. > > > > --------------------------------------------------------------------- > > 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 > >
