My +1 to the 2nd camp. For me it's about transparency. I don't see an issue if a podling release has some significant flaws. For me, the ideal would be if it is easy for podling members, reviewers, and downstream users to easily determine whether such flaws are known and what they are. It can be as simple as a line in the release notes or release email and/or an easily findable issue or two.
On Mon, Jun 24, 2019 at 9:01 PM Jim Jagielski <j...@jagunet.com> wrote: > ++1. I agree w/ Rich and Roman > > > On Jun 23, 2019, at 11:25 PM, Roman Shaposhnik <ro...@shaposhnik.org> > wrote: > > > > On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rbo...@rcbowen.com <mailto: > 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 > <mailto:general-unsubscr...@incubator.apache.org> > > For additional commands, e-mail: general-h...@incubator.apache.org > <mailto:general-h...@incubator.apache.org> >
