Big +1! On Fri, Jul 12, 2019 at 4:08 PM Matt Sicker <boa...@gmail.com> wrote: > > 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>
--------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
