incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: New disclaimer text
Date Fri, 12 Jul 2019 22:58:49 GMT
This is a great idea... +1

> On Jul 12, 2019, at 6:31 PM, Craig Russell <apache.clr@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 <justin@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
> 
> Craig L Russell
> clr@apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message