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
