Agreed, this sounds like a great way to do this. As IPMC members reviewing releases, you now have better guidelines on how to go about reviewing a podling release.
On Fri, Jul 12, 2019 at 17:59, Jim Jagielski <j...@jagunet.com> wrote: > This is a great idea... +1 > > > On Jul 12, 2019, at 6:31 PM, Craig Russell <apache....@gmail.com> wrote: > > > > Hi, > > > > I understand I'm a bit late to this particular discussion, but perhaps > we can consider two different disclaimers that podlings can choose: > > > > The standard disclaimer that does not disclaim licensing issues; or, > > > > The proposed new disclaimer to be used by podlings' first releases until > they sort their licensing issues > > > > This "split roll" allows "mature" podlings the ability to assuage their > downstream that they have their licensing issues in hand. > > > > Use of the current disclaimer means that any licensing issues found > during release voting would cancel the release and require a respin. > > > > Use of the proposed new disclaimer would allow new-ish podlings to get > on with releasing while they sort any licensing issues. > > > > And we can add to the Maturity Model a section that discusses that the > podling has had at least one release with the standard disclaimer. > > > > Regards, > > > > Craig > > > >> On Jul 10, 2019, at 2:44 PM, Justin Mclean <jus...@classsoftware.com> > wrote: > >> > >> Hi, > >> > >>> Speaking as a member of a currently-incubating project (Apache Druid) > where > >>> we have always strived to do releases with no known licensing issues, > the > >>> text sounds needlessly scary to downstream consumers. > >> > >> And that may be the problem with a one solution fits all process. It > has been suggested before we let podlings choose which release process they > want. However that may get too complex and make voting on releases > inconsistent. > >> > >>> IMO this disclaims too much, and would chill adoption of incubating > >>> software by people that care about having clean licensing. PPMCs > should be > >>> able to say "we believe this release is clean and have vetted it using > a > >>> normal Apache vetting process" or maybe even "we have vetted this > release > >>> and it is clean other than the following list of known issues". If they > >>> can't say one of those two statements, then maybe it's not time to do > their > >>> first release yet. > >> > >> The idea is to allow podlings to make releases that may not comply with > policy. Have a hard switch from your releases doesn’t comply to everything > must comply is too difficult for some podlings. > >> > >>> And yeah, as a few others have mentioned, I believe that a more > streamlined > >>> voting process > >> > >> That I think is a different issue, ands may be best to start another > thread on that. The main issue here is that IPMC members votes are binding, > and not all mentors (who are IPMC members) vote on releases, so podlings > need votes from the wider IPMC members to make releases (in about 90%+ of > cases). There been a few ideas on how to improve this, including one > approved method (but no podlings have take that up yet). > >> > >> Thanks, > >> Justin > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >> For additional commands, e-mail: general-h...@incubator.apache.org > >> > > > > Craig L Russell > > c...@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 > > -- Matt Sicker <boa...@gmail.com>
