New disclaimer text

[Justin Mclean]

Hi,

I put up suggested text changes for an incubator disclaimer here [1]. Comments 
and feedback welcome. Text changes have been highlighted in yellow.

Note that a disclaimer can’t remove any licence or other rights a user may 
have, the intent here it to just inform them that some podling releases may 
have issues. 

It also been suggested than any known issues be listed in the disclaimer.

Thanks,
Justin

1. 
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Incubator+Disclaimer
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New disclaimer text

[Daniel Shahaf]

Justin Mclean wrote on Sun, Jun 30, 2019 at 09:39:22 +1000:
> I put up suggested text changes for an incubator disclaimer here [1].

Fullquote of the link:

> Apache Podling-Name is an effort undergoing incubation at The Apache Software
> Foundation (ASF), sponsored by the name of Apache TLP sponsor. Incubation is
> required of all newly accepted projects until a further review indicates that
> the infrastructure, communications, and decision making process have
> stabilized in a manner consistent with other successful ASF projects. While
> incubation status is not necessarily a reflection of the completeness or
> stability of the code, it does indicate that the project has yet to be fully
> endorsed by the ASF.
> 
> Some of the project releases may not follow ASF policy or have incomplete or
> unknown licensing conditions.

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

Re: New disclaimer text

[Bertrand Delacretaz]

Hi,

On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  wrote:
> ...I put up suggested text changes for an incubator disclaimer here [1]...

Basically just adding this, right?

> Some of the project releases may not follow ASF policy or have
> incomplete or unknown licensing conditions

It works for me but I'd say "incubating project" to be clearer.

> ...It also been suggested than any known issues be listed in the disclaimer...

I don't think that works as modifying the disclaimer to list issues
will change the digests of the archive that's being voted on - and
those shouldn't change IMO.

As Paul suggests in a different thread I'd go for easy to find tickets
to describe those changes. The disclaimer might point to
http://incubator.apache.org/release-issues which in turn points to
those tickets, keyed by release name and version number. Or something
like that - a permalink that points to the details.

-Bertrand

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

Re: New disclaimer text

[Justin Mclean]

Hi,

>> Some of the project releases may not follow ASF policy or have
>> incomplete or unknown licensing conditions….

Yes just that line added, I put it own the wiki and highlighted any changes.

> It works for me but I'd say "incubating project" to be clearer.

Will change.

> I don't think that works as modifying the disclaimer to list issues
> will change the digests of the archive that's being voted on - and
> those shouldn't change IMO.

I think the intent was to only list known issues, so yes issues found in the 
current RC may not be listed and that may be an issue. I’m not against other 
ideas.

> As Paul suggests in a different thread I'd go for easy to find tickets
> to describe those changes. The disclaimer might point to
> http://incubator.apache.org/release-issues which in turn points to
> those tickets, keyed by release name and version number. Or something
> like that - a permalink that points to the details.

The problem wth that is that content at that URL would change, it hard to 
compare what has changed between releases, or without careful tagging anyway.

Thanks,
Justin



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

Re: New disclaimer text

[Dave Fisher]

Hi -

> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz  
> wrote:
> 
> Hi,
> 
> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
> wrote:
>> ...I put up suggested text changes for an incubator disclaimer here [1]...
> 
> Basically just adding this, right?
> 
>> Some of the project releases may not follow ASF policy or have
>> incomplete or unknown licensing conditions
> 
> It works for me but I'd say "incubating project" to be clearer.

How is this?

“Some of the incubating project’s releases may not be fully compliant with ASF 
policy. For example, releases may have incomplete or unreviewed licensing 
conditions. Known issues will be described on the project’s status page."

> 
>> ...It also been suggested than any known issues be listed in the 
>> disclaimer...
> 
> I don't think that works as modifying the disclaimer to list issues
> will change the digests of the archive that's being voted on - and
> those shouldn't change IMO.
> 
> As Paul suggests in a different thread I'd go for easy to find tickets
> to describe those changes. The disclaimer might point to
> http://incubator.apache.org/release-issues which in turn points to
> those tickets, keyed by release name and version number. Or something
> like that - a permalink that points to the details.

I would suggest that in a revamping of podling status pages that the podling 
can list current issues with each release.

The link to that page is easy: http://incubator.apache.org/projects/

BTW - I’ve changed my thoughts on a Whimsical version of the status data and am 
planning to put these in as AsciiDoc pages / YML into the Incubator’s Git.

Regards,
Dave

> 
> -Bertrand
> 
> -
> 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

Re: New disclaimer text

[Daniel Shahaf]

Dave Fisher wrote on Tue, 02 Jul 2019 10:28 -0700:
> > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
> >  wrote:
> > 
> > Hi,
> > 
> > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
> > wrote:
> >> ...I put up suggested text changes for an incubator disclaimer here [1]...
> > 
> > Basically just adding this, right?
> > 
> >> Some of the project releases may not follow ASF policy or have
> >> incomplete or unknown licensing conditions
> > 
> > It works for me but I'd say "incubating project" to be clearer.
> 
> How is this?
> 
> “Some of the incubating project’s releases may not be fully compliant 
> with ASF policy. For example, releases may have incomplete or unreviewed 
> licensing conditions. Known issues will be described on the project’s 
> status page."

I think the meaning you guys are after is "The artifact may not be in
compliance with Apache's policies (CatA/CatB/CatX, etc)", but what you
actually drafted so far can be read as "We do not promise to you that the
LICENSE file is complete and accurate", which would be a deal breaker to
downstreams.

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

Re: New disclaimer text

[Greg Stein]

On Tue, Jul 2, 2019 at 1:55 PM Daniel Shahaf  wrote:

> Dave Fisher wrote on Tue, 02 Jul 2019 10:28 -0700:
> > > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
> > >
> > > Hi,
> > >
> > > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <
> jus...@classsoftware.com> wrote:
> > >> ...I put up suggested text changes for an incubator disclaimer here
> [1]...
> > >
> > > Basically just adding this, right?
> > >
> > >> Some of the project releases may not follow ASF policy or have
> > >> incomplete or unknown licensing conditions
> > >
> > > It works for me but I'd say "incubating project" to be clearer.
> >
> > How is this?
> >
> > “Some of the incubating project’s releases may not be fully compliant
> > with ASF policy. For example, releases may have incomplete or unreviewed
> > licensing conditions. Known issues will be described on the project’s
> > status page."
>
> I think the meaning you guys are after is "The artifact may not be in
> compliance with Apache's policies (CatA/CatB/CatX, etc)", but what you
> actually drafted so far can be read as "We do not promise to you that the
> LICENSE file is complete and accurate", which would be a deal breaker to
> downstreams.
>

s/would/may/

As a hobbyist user, I really don't care what is in LICENSE and NOTICE.
Heck, I don't even care if those files are missing.

Cheers,
-g

Re: New disclaimer text

[Roman Shaposhnik]

On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher  wrote:
>
> Hi -
>
> > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
> >  wrote:
> >
> > Hi,
> >
> > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
> > wrote:
> >> ...I put up suggested text changes for an incubator disclaimer here [1]...
> >
> > Basically just adding this, right?
> >
> >> Some of the project releases may not follow ASF policy or have
> >> incomplete or unknown licensing conditions
> >
> > It works for me but I'd say "incubating project" to be clearer.
>
> How is this?
>
> “Some of the incubating project’s releases may not be fully compliant with 
> ASF policy. For example, releases may have incomplete or unreviewed licensing 
> conditions. Known issues will be described on the project’s status page."

I would suggest we have a policy where known issues are actually
listed in the DISCLAIMER itself. Along the lines of:

"Some of the incubating project’s releases may not be fully compliant
with ASF policy. For example, releases may have incomplete or
unreviewed licensing conditions. What follows is a list of known
issues the project is currently aware of (note that this list, by
definition, is likely to be incomplete):"

I would also suggest we add an explicit note warning our downstream consumers:

"If you are planning to incorporate this work into your
product/project, please be aware that you will need to conduct a
thorough licensing review to determine the overall implications of
including this work"

> >> ...It also been suggested than any known issues be listed in the 
> >> disclaimer...
> >
> > I don't think that works as modifying the disclaimer to list issues
> > will change the digests of the archive that's being voted on - and
> > those shouldn't change IMO.
> >
> > As Paul suggests in a different thread I'd go for easy to find tickets
> > to describe those changes. The disclaimer might point to
> > http://incubator.apache.org/release-issues which in turn points to
> > those tickets, keyed by release name and version number. Or something
> > like that - a permalink that points to the details.
>
> I would suggest that in a revamping of podling status pages that the podling 
> can list current issues with each release.
>
> The link to that page is easy: http://incubator.apache.org/projects/
>
> BTW - I’ve changed my thoughts on a Whimsical version of the status data and 
> am planning to put these in as AsciiDoc pages / YML into the Incubator’s Git.
>
> Regards,
> Dave
>
> >
> > -Bertrand
> >
> > -
> > 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
>

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

Re: New disclaimer text

[Dave Fisher]

> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik  wrote:
> 
> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher  wrote:
>> 
>> Hi -
>> 
>>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
>>> wrote:
 ...I put up suggested text changes for an incubator disclaimer here [1]...
>>> 
>>> Basically just adding this, right?
>>> 
 Some of the project releases may not follow ASF policy or have
 incomplete or unknown licensing conditions
>>> 
>>> It works for me but I'd say "incubating project" to be clearer.
>> 
>> How is this?
>> 
>> “Some of the incubating project’s releases may not be fully compliant with 
>> ASF policy. For example, releases may have incomplete or unreviewed 
>> licensing conditions. Known issues will be described on the project’s status 
>> page."
> 
> I would suggest we have a policy where known issues are actually
> listed in the DISCLAIMER itself. Along the lines of:
> 
> "Some of the incubating project’s releases may not be fully compliant
> with ASF policy. For example, releases may have incomplete or
> unreviewed licensing conditions. What follows is a list of known
> issues the project is currently aware of (note that this list, by
> definition, is likely to be incomplete):”

-1.

This only works for issues known before a release is cut. It does NOT WORK if 
the issue is discovered during the release vote. Why? Because we are trying to 
allow the release to go through without redoing it and this would require 
reworking the release.

I would rather do it outside of the release. Policing the actual DISCLAIMER is 
not easily feasible and decreases the burden.

If this is the decision then it leads to a choice that is worse than the status 
quo.

> 
> I would also suggest we add an explicit note warning our downstream consumers:
> 
> "If you are planning to incorporate this work into your
> product/project, please be aware that you will need to conduct a
> thorough licensing review to determine the overall implications of
> including this work”

This is a reasonable approach for the usual DISCLAIMER but …

Regards,
Dave

> 
 ...It also been suggested than any known issues be listed in the 
 disclaimer...
>>> 
>>> I don't think that works as modifying the disclaimer to list issues
>>> will change the digests of the archive that's being voted on - and
>>> those shouldn't change IMO.
>>> 
>>> As Paul suggests in a different thread I'd go for easy to find tickets
>>> to describe those changes. The disclaimer might point to
>>> http://incubator.apache.org/release-issues which in turn points to
>>> those tickets, keyed by release name and version number. Or something
>>> like that - a permalink that points to the details.
>> 
>> I would suggest that in a revamping of podling status pages that the podling 
>> can list current issues with each release.
>> 
>> The link to that page is easy: http://incubator.apache.org/projects/
>> 
>> BTW - I’ve changed my thoughts on a Whimsical version of the status data and 
>> am planning to put these in as AsciiDoc pages / YML into the Incubator’s Git.
>> 
>> Regards,
>> Dave
>> 
>>> 
>>> -Bertrand
>>> 
>>> -
>>> 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
>> 
> 
> -
> 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

Re: New disclaimer text

[Dave Fisher]

> On Jul 3, 2019, at 12:16 PM, Dave Fisher  wrote:
> 
> 
> 
>> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik  wrote:
>> 
>> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher  wrote:
>>> 
>>> Hi -
>>> 
 On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
  wrote:
 
 Hi,
 
 On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
 wrote:
> ...I put up suggested text changes for an incubator disclaimer here [1]...
 
 Basically just adding this, right?
 
> Some of the project releases may not follow ASF policy or have
> incomplete or unknown licensing conditions
 
 It works for me but I'd say "incubating project" to be clearer.
>>> 
>>> How is this?
>>> 
>>> “Some of the incubating project’s releases may not be fully compliant with 
>>> ASF policy. For example, releases may have incomplete or unreviewed 
>>> licensing conditions. Known issues will be described on the project’s 
>>> status page."
>> 
>> I would suggest we have a policy where known issues are actually
>> listed in the DISCLAIMER itself. Along the lines of:
>> 
>> "Some of the incubating project’s releases may not be fully compliant
>> with ASF policy. For example, releases may have incomplete or
>> unreviewed licensing conditions. What follows is a list of known
>> issues the project is currently aware of (note that this list, by
>> definition, is likely to be incomplete):”
> 
> -1.
> 
> This only works for issues known before a release is cut. It does NOT WORK if 
> the issue is discovered during the release vote. Why? Because we are trying 
> to allow the release to go through without redoing it and this would require 
> reworking the release.
> 
> I would rather do it outside of the release. Policing the actual DISCLAIMER 
> is not easily feasible and decreases the burden.

Sorry I meant to write increases the burden and not lessens it.

> 
> If this is the decision then it leads to a choice that is worse than the 
> status quo.
> 
>> 
>> I would also suggest we add an explicit note warning our downstream 
>> consumers:
>> 
>> "If you are planning to incorporate this work into your
>> product/project, please be aware that you will need to conduct a
>> thorough licensing review to determine the overall implications of
>> including this work”
> 
> This is a reasonable approach for the usual DISCLAIMER but …
> 
> Regards,
> Dave
> 
>> 
> ...It also been suggested than any known issues be listed in the 
> disclaimer...
 
 I don't think that works as modifying the disclaimer to list issues
 will change the digests of the archive that's being voted on - and
 those shouldn't change IMO.
 
 As Paul suggests in a different thread I'd go for easy to find tickets
 to describe those changes. The disclaimer might point to
 http://incubator.apache.org/release-issues which in turn points to
 those tickets, keyed by release name and version number. Or something
 like that - a permalink that points to the details.
>>> 
>>> I would suggest that in a revamping of podling status pages that the 
>>> podling can list current issues with each release.
>>> 
>>> The link to that page is easy: 
>>> http://incubator.apache.org/projects/
>>> 
>>> BTW - I’ve changed my thoughts on a Whimsical version of the status data 
>>> and am planning to put these in as AsciiDoc pages / YML into the 
>>> Incubator’s Git.
>>> 
>>> Regards,
>>> Dave
>>> 
 
 -Bertrand
 
 -
 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
>>> 
>> 
>> -
>> 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
> 


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

Re: New disclaimer text

[Roman Shaposhnik]

On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher  wrote:
> > On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik  wrote:
> >
> > On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher  wrote:
> >>
> >> Hi -
> >>
> >>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
> >>>  wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
> >>> wrote:
>  ...I put up suggested text changes for an incubator disclaimer here 
>  [1]...
> >>>
> >>> Basically just adding this, right?
> >>>
>  Some of the project releases may not follow ASF policy or have
>  incomplete or unknown licensing conditions
> >>>
> >>> It works for me but I'd say "incubating project" to be clearer.
> >>
> >> How is this?
> >>
> >> “Some of the incubating project’s releases may not be fully compliant with 
> >> ASF policy. For example, releases may have incomplete or unreviewed 
> >> licensing conditions. Known issues will be described on the project’s 
> >> status page."
> >
> > I would suggest we have a policy where known issues are actually
> > listed in the DISCLAIMER itself. Along the lines of:
> >
> > "Some of the incubating project’s releases may not be fully compliant
> > with ASF policy. For example, releases may have incomplete or
> > unreviewed licensing conditions. What follows is a list of known
> > issues the project is currently aware of (note that this list, by
> > definition, is likely to be incomplete):”
>
> -1.
>
> This only works for issues known before a release is cut. It does NOT WORK if 
> the issue is discovered during the release vote. Why? Because we are trying 
> to allow the release to go through without redoing it and this would require 
> reworking the release.
>
> I would rather do it outside of the release. Policing the actual DISCLAIMER 
> is not easily feasible and decreases the burden.
>
> If this is the decision then it leads to a choice that is worse than the 
> status quo.

Nobody is suggesting the policing bit. What I'm suggesting is a
central place for that information to be collated. Whether that
becomes a showstopper for a release gets decided by the VOTE. But what
I'm saying is that we shouldn't be in a position where we have to hunt
for *known* and *acknowledged* issues all over the place (JIRA,
mailing lists, wiki, website, etc.). Lets at least make sure we make
our downstream consumer's life a bit easier.

Thanks,
Roman.

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

Re: New disclaimer text

[Dave Fisher]

> On Jul 3, 2019, at 12:24 PM, Roman Shaposhnik  wrote:
> 
> On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher  wrote:
>>> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik  wrote:
>>> 
>>> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher  wrote:
 
 Hi -
 
> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
>  wrote:
> 
> Hi,
> 
> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
> wrote:
>> ...I put up suggested text changes for an incubator disclaimer here 
>> [1]...
> 
> Basically just adding this, right?
> 
>> Some of the project releases may not follow ASF policy or have
>> incomplete or unknown licensing conditions
> 
> It works for me but I'd say "incubating project" to be clearer.
 
 How is this?
 
 “Some of the incubating project’s releases may not be fully compliant with 
 ASF policy. For example, releases may have incomplete or unreviewed 
 licensing conditions. Known issues will be described on the project’s 
 status page."
>>> 
>>> I would suggest we have a policy where known issues are actually
>>> listed in the DISCLAIMER itself. Along the lines of:
>>> 
>>> "Some of the incubating project’s releases may not be fully compliant
>>> with ASF policy. For example, releases may have incomplete or
>>> unreviewed licensing conditions. What follows is a list of known
>>> issues the project is currently aware of (note that this list, by
>>> definition, is likely to be incomplete):”
>> 
>> -1.
>> 
>> This only works for issues known before a release is cut. It does NOT WORK 
>> if the issue is discovered during the release vote. Why? Because we are 
>> trying to allow the release to go through without redoing it and this would 
>> require reworking the release.
>> 
>> I would rather do it outside of the release. Policing the actual DISCLAIMER 
>> is not easily feasible and decreases the burden.
>> 
>> If this is the decision then it leads to a choice that is worse than the 
>> status quo.
> 
> Nobody is suggesting the policing bit. What I'm suggesting is a
> central place for that information to be collated. Whether that
> becomes a showstopper for a release gets decided by the VOTE. But what
> I'm saying is that we shouldn't be in a position where we have to hunt
> for *known* and *acknowledged* issues all over the place (JIRA,
> mailing lists, wiki, website, etc.). Lets at least make sure we make
> our downstream consumer's life a bit easier.

My suggestion is that we put these onto our neglected status pages. I’m also 
willing to work on enhancing the status page and process to make this easy for 
Podlings to do.

Regards,
Dave

> 
> Thanks,
> Roman.
> 
> -
> 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

Re: New disclaimer text

[Roman Shaposhnik]

On Wed, Jul 3, 2019 at 12:29 PM Dave Fisher  wrote:
>
>
>
> > On Jul 3, 2019, at 12:24 PM, Roman Shaposhnik  wrote:
> >
> > On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher  wrote:
> >>> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik  
> >>> wrote:
> >>>
> >>> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher  wrote:
> 
>  Hi -
> 
> > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
> >  wrote:
> >
> > Hi,
> >
> > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean 
> >  wrote:
> >> ...I put up suggested text changes for an incubator disclaimer here 
> >> [1]...
> >
> > Basically just adding this, right?
> >
> >> Some of the project releases may not follow ASF policy or have
> >> incomplete or unknown licensing conditions
> >
> > It works for me but I'd say "incubating project" to be clearer.
> 
>  How is this?
> 
>  “Some of the incubating project’s releases may not be fully compliant 
>  with ASF policy. For example, releases may have incomplete or unreviewed 
>  licensing conditions. Known issues will be described on the project’s 
>  status page."
> >>>
> >>> I would suggest we have a policy where known issues are actually
> >>> listed in the DISCLAIMER itself. Along the lines of:
> >>>
> >>> "Some of the incubating project’s releases may not be fully compliant
> >>> with ASF policy. For example, releases may have incomplete or
> >>> unreviewed licensing conditions. What follows is a list of known
> >>> issues the project is currently aware of (note that this list, by
> >>> definition, is likely to be incomplete):”
> >>
> >> -1.
> >>
> >> This only works for issues known before a release is cut. It does NOT WORK 
> >> if the issue is discovered during the release vote. Why? Because we are 
> >> trying to allow the release to go through without redoing it and this 
> >> would require reworking the release.
> >>
> >> I would rather do it outside of the release. Policing the actual 
> >> DISCLAIMER is not easily feasible and decreases the burden.
> >>
> >> If this is the decision then it leads to a choice that is worse than the 
> >> status quo.
> >
> > Nobody is suggesting the policing bit. What I'm suggesting is a
> > central place for that information to be collated. Whether that
> > becomes a showstopper for a release gets decided by the VOTE. But what
> > I'm saying is that we shouldn't be in a position where we have to hunt
> > for *known* and *acknowledged* issues all over the place (JIRA,
> > mailing lists, wiki, website, etc.). Lets at least make sure we make
> > our downstream consumer's life a bit easier.
>
> My suggestion is that we put these onto our neglected status pages. I’m also 
> willing to work on enhancing the status page and process to make this easy 
> for Podlings to do.

Sure, that's a reasonable place too, but the problem is -- it doesn't
help our downstream consumers.

What I'm trying to say is this, I'd like:
   1. this information to be available in one centralized location (per project)
   2. be easily discoverable by downstream consumers

If we all agree that #1 is desired (and sounds like we are). Then #2
can simply contain a link to #1 -- that'd be fine.

Makes sense?

Thanks,
Roman.

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

Re: New disclaimer text

[Dave Fisher]

> On Jul 3, 2019, at 12:32 PM, Roman Shaposhnik  wrote:
> 
> On Wed, Jul 3, 2019 at 12:29 PM Dave Fisher  wrote:
>> 
>> 
>> 
>>> On Jul 3, 2019, at 12:24 PM, Roman Shaposhnik  wrote:
>>> 
>>> On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher  wrote:
> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik  
> wrote:
> 
> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher  wrote:
>> 
>> Hi -
>> 
>>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean 
>>>  wrote:
 ...I put up suggested text changes for an incubator disclaimer here 
 [1]...
>>> 
>>> Basically just adding this, right?
>>> 
 Some of the project releases may not follow ASF policy or have
 incomplete or unknown licensing conditions
>>> 
>>> It works for me but I'd say "incubating project" to be clearer.
>> 
>> How is this?
>> 
>> “Some of the incubating project’s releases may not be fully compliant 
>> with ASF policy. For example, releases may have incomplete or unreviewed 
>> licensing conditions. Known issues will be described on the project’s 
>> status page."
> 
> I would suggest we have a policy where known issues are actually
> listed in the DISCLAIMER itself. Along the lines of:
> 
> "Some of the incubating project’s releases may not be fully compliant
> with ASF policy. For example, releases may have incomplete or
> unreviewed licensing conditions. What follows is a list of known
> issues the project is currently aware of (note that this list, by
> definition, is likely to be incomplete):”
 
 -1.
 
 This only works for issues known before a release is cut. It does NOT WORK 
 if the issue is discovered during the release vote. Why? Because we are 
 trying to allow the release to go through without redoing it and this 
 would require reworking the release.
 
 I would rather do it outside of the release. Policing the actual 
 DISCLAIMER is not easily feasible and decreases the burden.
 
 If this is the decision then it leads to a choice that is worse than the 
 status quo.
>>> 
>>> Nobody is suggesting the policing bit. What I'm suggesting is a
>>> central place for that information to be collated. Whether that
>>> becomes a showstopper for a release gets decided by the VOTE. But what
>>> I'm saying is that we shouldn't be in a position where we have to hunt
>>> for *known* and *acknowledged* issues all over the place (JIRA,
>>> mailing lists, wiki, website, etc.). Lets at least make sure we make
>>> our downstream consumer's life a bit easier.
>> 
>> My suggestion is that we put these onto our neglected status pages. I’m also 
>> willing to work on enhancing the status page and process to make this easy 
>> for Podlings to do.
> 
> Sure, that's a reasonable place too, but the problem is -- it doesn't
> help our downstream consumers.
> 
> What I'm trying to say is this, I'd like:
>   1. this information to be available in one centralized location (per 
> project)
>   2. be easily discoverable by downstream consumers
> 
> If we all agree that #1 is desired (and sounds like we are). Then #2
> can simply contain a link to #1 -- that'd be fine.
> 
> Makes sense?

Yes. I’ll put some effort into the status page in the next week and come back 
when I have a sample where we can all iterate on the content.

Best Regards,
Dave

> 
> Thanks,
> Roman.
> 
> -
> 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

Re: New disclaimer text

[Daniel Shahaf]

Dave Fisher wrote on Wed, 03 Jul 2019 12:16 -0700:
> This only works for issues known before a release is cut. It does NOT 
> WORK if the issue is discovered during the release vote. Why? Because we 
> are trying to allow the release to go through without redoing it and 
> this would require reworking the release.
> 
> I would rather do it outside of the release. Policing the actual 
> DISCLAIMER is not easily feasible and decreases the burden.

I recommend to put the information in DISCLAIMER.  Yes, that means bugs
in DISCLAIMER require re-rolling, but:

1. Bugs in DISCLAIMER should be found before the first artifact is
   rolled.  It's simply an audit and it can be done directly on the
   source tree in version control.

2. Re-rolling shouldn't be an expensive step that should be avoided. It
   should be "Edit DISCLAIMER, commit, run script to roll" followed by
   everyone diffing the old artifact to the new one and re-casting their
   votes based on the work they already did to review the old artifact.
   (And yes, it's still some effort, about which, see #1.)

3. Artifacts should state their exact license terms — accurately,
   completely, and (de facto standard) in-band.

Daniel

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

Re: New disclaimer text

[Alex Harui]

Suggestion:  The DISCLAIMER references a detached copy of the DISCLAIMER at 
dist.a.o/releases/incubator/project and that detached copy is the one that gets 
updated with late breaking stuff.

Re-rolling required re-GPG-signing, new hashes, etc.

-Alex

On 7/3/19, 2:08 PM, "Daniel Shahaf"  wrote:

Dave Fisher wrote on Wed, 03 Jul 2019 12:16 -0700:
> This only works for issues known before a release is cut. It does NOT 
> WORK if the issue is discovered during the release vote. Why? Because we 
> are trying to allow the release to go through without redoing it and 
> this would require reworking the release.
> 
> I would rather do it outside of the release. Policing the actual 
> DISCLAIMER is not easily feasible and decreases the burden.

I recommend to put the information in DISCLAIMER.  Yes, that means bugs
in DISCLAIMER require re-rolling, but:

1. Bugs in DISCLAIMER should be found before the first artifact is
   rolled.  It's simply an audit and it can be done directly on the
   source tree in version control.

2. Re-rolling shouldn't be an expensive step that should be avoided. It
   should be "Edit DISCLAIMER, commit, run script to roll" followed by
   everyone diffing the old artifact to the new one and re-casting their
   votes based on the work they already did to review the old artifact.
   (And yes, it's still some effort, about which, see #1.)

3. Artifacts should state their exact license terms — accurately,
   completely, and (de facto standard) in-band.

Daniel

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

Re: New disclaimer text

[Greg Stein]

On Wed, Jul 3, 2019 at 4:35 PM Alex Harui  wrote:

> Suggestion:  The DISCLAIMER references a detached copy of the DISCLAIMER
> at dist.a.o/releases/incubator/project and that detached copy is the one
> that gets updated with late breaking stuff.
>
> Re-rolling required re-GPG-signing, new hashes, etc.
>

Which is made worse by the two-step/vote process of podling then IPMC.

Cheers,
-g

Re: New disclaimer text

[Daniel Shahaf]

Alex Harui wrote on Wed, 03 Jul 2019 21:35 +:
> Re-rolling required re-GPG-signing, new hashes, etc.

Yes, I know how re-rolling works.  I've RM'd things before.  I still think 
in-band is better.

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

Re: New disclaimer text

[Roman Shaposhnik]

On Wed, Jul 3, 2019 at 2:52 PM Greg Stein  wrote:
>
> On Wed, Jul 3, 2019 at 4:35 PM Alex Harui  wrote:
>
> > Suggestion:  The DISCLAIMER references a detached copy of the DISCLAIMER
> > at dist.a.o/releases/incubator/project and that detached copy is the one
> > that gets updated with late breaking stuff.
> >
> > Re-rolling required re-GPG-signing, new hashes, etc.
> >
>
> Which is made worse by the two-step/vote process of podling then IPMC.

Perhaps that should be addressed first?

Thanks,
Roman.

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

Re: New disclaimer text

[Dave Fisher]

Sent from my iPhone

> On Jul 3, 2019, at 3:59 PM, Daniel Shahaf  wrote:
> 
> Alex Harui wrote on Wed, 03 Jul 2019 21:35 +:
>> Re-rolling required re-GPG-signing, new hashes, etc.
> 
> Yes, I know how re-rolling works.  I've RM'd things before.  I still think 
> in-band is better.

It really is up to the PPMC Members coming around to how a full PMC and RM 
would act in the Apache Way!

On Day minus obviously not.

On Day one not yet, but ...

On Day halfway, well yes and congratulations!

On Day done, fully yes and congratulations times ten!

Regards,
Dave
> 
> -
> 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

Re: New disclaimer text

[Daniel Shahaf]

Dave Fisher wrote on Wed, 03 Jul 2019 16:06 -0700:
> > On Jul 3, 2019, at 3:59 PM, Daniel Shahaf  wrote:
> > Alex Harui wrote on Wed, 03 Jul 2019 21:35 +:
> It really is up to the PPMC Members coming around to how a full PMC and 
> RM would act in the Apache Way!

No, it isn't.  Getting the LICENSE file correct is like having a warnings-free
build: it's good software development practice that's not specific to
any particular license or governance model.

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

Re: New disclaimer text

[Justin Mclean]

Hi,

The issue with having a detached disclaimer is that it can change and get out 
of sync with what was actually in a released version.

However one possible compromise would be to list known issues in the disclaimer 
and list any other issues found by the IPMC in the release announcements and on 
the release page next to the download links. The DISCLAIMER in version control 
can also be updated and always reflect the current set of released issues are. 
What do other people think about this?

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New disclaimer text

[Matt Sicker]

Since this is sort of a post-release set of info, I think it’d make sense
to have either a page specific to each version, or at least a section per
version all on a single page (similar to a security issues page might be or
a change log in general).

On Tue, Jul 9, 2019 at 21:24, Justin Mclean 
wrote:

> Hi,
>
> The issue with having a detached disclaimer is that it can change and get
> out of sync with what was actually in a released version.
>
> However one possible compromise would be to list known issues in the
> disclaimer and list any other issues found by the IPMC in the release
> announcements and on the release page next to the download links. The
> DISCLAIMER in version control can also be updated and always reflect the
> current set of released issues are. What do other people think about this?
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
> --
Matt Sicker 

Re: New disclaimer text

[Jan Piotrowski]

What is the requirement for this disclaimer text change?
Is this coming from Legal? Or is this Incubator policy?
Has this been decided on already or is this text suggestion to be used
for a decision?

J

Am Mi., 10. Juli 2019 um 15:50 Uhr schrieb Matt Sicker :
>
> Since this is sort of a post-release set of info, I think it’d make sense
> to have either a page specific to each version, or at least a section per
> version all on a single page (similar to a security issues page might be or
> a change log in general).
>
> On Tue, Jul 9, 2019 at 21:24, Justin Mclean 
> wrote:
>
> > Hi,
> >
> > The issue with having a detached disclaimer is that it can change and get
> > out of sync with what was actually in a released version.
> >
> > However one possible compromise would be to list known issues in the
> > disclaimer and list any other issues found by the IPMC in the release
> > announcements and on the release page next to the download links. The
> > DISCLAIMER in version control can also be updated and always reflect the
> > current set of released issues are. What do other people think about this?
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> > --
> Matt Sicker 

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

Re: New disclaimer text

[Gian Merlino]

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. Especially this part:

> If you are planning to incorporate this work into your
> product/project, please be aware that you will need to conduct a
> thorough licensing review to determine the overall implications of
> including this work.

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.

And yeah, as a few others have mentioned, I believe that a more streamlined
voting process would make PPMCs more likely to adopt an attitude of doing
releases as cleanly as possible. I think mentors could play a valuable part
in streamlining the process, since they have binding votes from both the
PPMC and IPMC perspective, and are in theory plugged in to both communities.

On Wed, Jul 10, 2019 at 7:44 AM Jan Piotrowski  wrote:

> What is the requirement for this disclaimer text change?
> Is this coming from Legal? Or is this Incubator policy?
> Has this been decided on already or is this text suggestion to be used
> for a decision?
>
> J
>
> Am Mi., 10. Juli 2019 um 15:50 Uhr schrieb Matt Sicker :
> >
> > Since this is sort of a post-release set of info, I think it’d make sense
> > to have either a page specific to each version, or at least a section per
> > version all on a single page (similar to a security issues page might be
> or
> > a change log in general).
> >
> > On Tue, Jul 9, 2019 at 21:24, Justin Mclean 
> > wrote:
> >
> > > Hi,
> > >
> > > The issue with having a detached disclaimer is that it can change and
> get
> > > out of sync with what was actually in a released version.
> > >
> > > However one possible compromise would be to list known issues in the
> > > disclaimer and list any other issues found by the IPMC in the release
> > > announcements and on the release page next to the download links. The
> > > DISCLAIMER in version control can also be updated and always reflect
> the
> > > current set of released issues are. What do other people think about
> this?
> > >
> > > Thanks,
> > > Justin
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > > --
> > Matt Sicker 
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: New disclaimer text

[Ted Dunning]

My thought is that having a scary incubator warning text is the price to be
paid for having an incubator release process that could allow releases with
problems.

The best solution to that is to graduate and get rid of the warning
entirely.



On Wed, Jul 10, 2019 at 9:50 AM Gian Merlino  wrote:

> 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. Especially this part:
>
> > If you are planning to incorporate this work into your
> > product/project, please be aware that you will need to conduct a
> > thorough licensing review to determine the overall implications of
> > including this work.
>
> 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.
>
> And yeah, as a few others have mentioned, I believe that a more streamlined
> voting process would make PPMCs more likely to adopt an attitude of doing
> releases as cleanly as possible. I think mentors could play a valuable part
> in streamlining the process, since they have binding votes from both the
> PPMC and IPMC perspective, and are in theory plugged in to both
> communities.
>
> On Wed, Jul 10, 2019 at 7:44 AM Jan Piotrowski 
> wrote:
>
> > What is the requirement for this disclaimer text change?
> > Is this coming from Legal? Or is this Incubator policy?
> > Has this been decided on already or is this text suggestion to be used
> > for a decision?
> >
> > J
> >
> > Am Mi., 10. Juli 2019 um 15:50 Uhr schrieb Matt Sicker  >:
> > >
> > > Since this is sort of a post-release set of info, I think it’d make
> sense
> > > to have either a page specific to each version, or at least a section
> per
> > > version all on a single page (similar to a security issues page might
> be
> > or
> > > a change log in general).
> > >
> > > On Tue, Jul 9, 2019 at 21:24, Justin Mclean 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > The issue with having a detached disclaimer is that it can change and
> > get
> > > > out of sync with what was actually in a released version.
> > > >
> > > > However one possible compromise would be to list known issues in the
> > > > disclaimer and list any other issues found by the IPMC in the release
> > > > announcements and on the release page next to the download links. The
> > > > DISCLAIMER in version control can also be updated and always reflect
> > the
> > > > current set of released issues are. What do other people think about
> > this?
> > > >
> > > > Thanks,
> > > > Justin
> > > > -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > > > --
> > > Matt Sicker 
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: New disclaimer text

[Justin Mclean]

Hi,

> What is the requirement for this disclaimer text change?
> Is this coming from Legal? Or is this Incubator policy?

The incubator wold like to make it easies for podlings to make releases, 
allowing realises with issues in them is a way of doing this. The legal 
committee has been involved in the discussions and has had input on the text.

> Has this been decided on already or is this text suggestion to be used
> for a decision?

No it not been decided it , this is what this conversation is aoout.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New disclaimer text

[Justin Mclean]

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

Re: New disclaimer text

[Joshua Poore]

Hi,

I’m also a PPMC member (Apache Flagon). It seems the Incubator is at an 
inflection point—been tracking how different threads on general@ are 
capitulating on issues of identity and process. Gian’s points are SPOT on, but 
so are Justin’s. I have some reconciliatory thoughts and suggestions, which I’m 
embedding in line:

> On Jul 10, 2019, at 5:44 PM, Justin Mclean  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.

+1 on both points. The value we (podlings) take out of the Incubator is 
mentorship and scaffolding in adopting the Apache Way. In doing so, the “Way”, 
its processes, and the policies that shape those processes are meant to improve 
our offerings (code), our adoptability, and grow a sustainable community. 
Adding an additional disclaimer that we may have known issues adds additional 
barriers to adoption and community growth. An Incubator by definition takes on 
risk—infrastructure, time,  and opportunity, sunk, and operational costs—to 
help nurture its participants. That risk is directly yoked to the participants’ 
value gains from participating. Placing additional barriers to growth and 
adoption to eliminate the ASF’s risk breaks the incubator model altogether. 

> 
>> 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.

+1 on both point and counterpoint. This disclaims too much and there needs to 
be compliance to policy. The risk the Incubator needs to take is that 100% 
compliance is an eventual, but measurable goal. Yet, the Incubator needs a 
means to manage risk. A better model than the disclaimer: progressively 
incentivize compliance with metrics. 

Here’s one way for the ASF Incubator: Apache’s key marketing point is the 
Apache Way. Break down critical processes, determine key performance indicators 
against those processes, and centrally track metrics (license compliance, 
community participation, release compliance, notice, keys, whatever, whatever). 
Then build some Apache-branded badges that expose those metrics publicly so 
that all your podlings can stick them on their GitHub READMEs, same way as we 
have for CI, test coverage, etc., etc. Doing something like this, the Incubator 
is using the brand to incentivize organic compliance and manage risk. Implicit 
in this usage of the Apache brand is communication that podling projects are 
not fully endorsed by Apache, but the project being looked after by a trusted 
organization. Podlings have clear metrics that they can communicate and take 
actions to move the needle on. Podlings have a way to discriminate themselves 
from other open-source projects and from other podlings by showing positive 
values on their badges. This whole model provides a discriminator for all 
podlings in that other open-source projects don’t have the infrastructure to 
communicate these metrics; these badges’ existence engenders trust in the ASF & 
Incubator brand(s) and skepticism about non-Apache projects. Podlings who work 
to budge metrics can communicate to consumers and potential community members 
and continually brings them in line with Apache policy—the value they get from 
the incubator is now directly proportional to compliance (Incubator risk 
reduction). The Incubator also gets a better way to track incubation status, 
direct special attention to podlings that are bottoming out (before removal) 
and podlings that are showing progressive improvement. This method (or similar) 
tells the public how much trust Apache has in a particular podling. The 
additional disclaimer communicates that Apache has little trust in its 
podlings, at large.

Maybe this is too much technically (I doubt that), maybe this isn’t the best or 
only way to do this, but the key theme here is: measurable, progressive 
improvement. That should be sufficient to stay in the Incubator and necessary 
to graduate. Importantly, “progressive” means that metrics are updated 
regularly and not just at the time of release... 

> 
>> And yeah, as 

Re: New disclaimer text

[Justin Mclean]

Hi,

> Adding an additional disclaimer that we may have known issues adds additional 
> barriers to adoption and community growth.

I think the question to be asked is does that add barries more than having to 
have 100% compliant releases? I think the answer may depend on the podling. 
Have does that work out for 50 odd podlings?

> Here’s one way for the ASF Incubator: Apache’s key marketing point is the 
> Apache Way. Break down critical processes, determine key performance 
> indicators against those processes, and centrally track metrics (license 
> compliance, community participation, release compliance, notice, keys, 
> whatever, whatever).

I really like the idea, would you be willing to work on it further?

Some things to consider. I don’t know it we have enough volunteer time to 
implement something along those line or if we could come out with clear metrics 
to suit all podlings. However in some ways this work has already been done with 
the maturity model. There are issues this this as well a) not all IPMC members 
or podlings think it should be used so so it's optional. b) we’ve had podlings 
fill it in and ask to graduate that were clearly not ready to graduate.

>  The additional disclaimer communicates that Apache has little trust in its 
> podlings, at large.

About 1 in 5 podling releases put up fro IPMC have serious issues and have 
previously have attracted -1 votes by IPMC members. If we allow those to be 
released then I think we need to add something to the the disclaimer, we just 
need to work out a balance.

> -1. These are connected issues: Mentors are IMPCs "tip of the spear" for 
> managing compliance risk and for adding value to podlings. I have so much 
> respect for Justin and other IPMC regulars who tirelessly volunteer and 
> monitor general@, dig into minor releases to test builds and check 
> compliance. It’s heroic, but heroes are a sign of struggling operations in 
> orgs, and heroes burn out.

I’ve yet to see any proposal that deals with the issue of how it would get 
around that only PMC members votes are binding. I don’t see voting in all PPMC 
member as PMC member working (we get complaints that he IPMC is already too 
large) and I don’t think the board would allow a TLP to ignore that particular 
bylaw. I’m open to suggestions.

> Their valuable time is better spent institutionalizing knowledge and skills: 
> making mentors' jobs easier with templates, documentations, infrastructure 
> projects.

We do quite a bit of that as well.

> IMHO: the thing the needs to be discussed in a different thread is how the 
> Incubator supports and incentivizes engaged mentors. Speaking from 
> experience: engaged mentors are magical gifts from above. Losing mentors 
> during critical junctures is terrifying because there is so much to learn and 
> its hard to find documentation and examples for how to do things right.

If you have engaged mentors then that should be no issue, the last checkbox 
before graduation is that you don’t need mentors anymore and can wrk out things 
for yourself that are in line with how other ASF projects operate and the 
Apache Way. If you feel like that then perhaps your mentors haven’t completed 
their job.

Thanks for your thoughts,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New disclaimer text

[Jan Piotrowski]

> I think the question to be asked is does that add barries more than having to 
> have 100% compliant releases?

Is this a current requirement that is written down somewhere and
generally practiced?

Am Fr., 12. Juli 2019 um 09:49 Uhr schrieb Justin Mclean
:
>
> Hi,
>
> > Adding an additional disclaimer that we may have known issues adds 
> > additional barriers to adoption and community growth.
>
> I think the question to be asked is does that add barries more than having to 
> have 100% compliant releases? I think the answer may depend on the podling. 
> Have does that work out for 50 odd podlings?
>
> > Here’s one way for the ASF Incubator: Apache’s key marketing point is the 
> > Apache Way. Break down critical processes, determine key performance 
> > indicators against those processes, and centrally track metrics (license 
> > compliance, community participation, release compliance, notice, keys, 
> > whatever, whatever).
>
> I really like the idea, would you be willing to work on it further?
>
> Some things to consider. I don’t know it we have enough volunteer time to 
> implement something along those line or if we could come out with clear 
> metrics to suit all podlings. However in some ways this work has already been 
> done with the maturity model. There are issues this this as well a) not all 
> IPMC members or podlings think it should be used so so it's optional. b) 
> we’ve had podlings fill it in and ask to graduate that were clearly not ready 
> to graduate.
>
> >  The additional disclaimer communicates that Apache has little trust in its 
> > podlings, at large.
>
> About 1 in 5 podling releases put up fro IPMC have serious issues and have 
> previously have attracted -1 votes by IPMC members. If we allow those to be 
> released then I think we need to add something to the the disclaimer, we just 
> need to work out a balance.
>
> > -1. These are connected issues: Mentors are IMPCs "tip of the spear" for 
> > managing compliance risk and for adding value to podlings. I have so much 
> > respect for Justin and other IPMC regulars who tirelessly volunteer and 
> > monitor general@, dig into minor releases to test builds and check 
> > compliance. It’s heroic, but heroes are a sign of struggling operations in 
> > orgs, and heroes burn out.
>
> I’ve yet to see any proposal that deals with the issue of how it would get 
> around that only PMC members votes are binding. I don’t see voting in all 
> PPMC member as PMC member working (we get complaints that he IPMC is already 
> too large) and I don’t think the board would allow a TLP to ignore that 
> particular bylaw. I’m open to suggestions.
>
> > Their valuable time is better spent institutionalizing knowledge and 
> > skills: making mentors' jobs easier with templates, documentations, 
> > infrastructure projects.
>
> We do quite a bit of that as well.
>
> > IMHO: the thing the needs to be discussed in a different thread is how the 
> > Incubator supports and incentivizes engaged mentors. Speaking from 
> > experience: engaged mentors are magical gifts from above. Losing mentors 
> > during critical junctures is terrifying because there is so much to learn 
> > and its hard to find documentation and examples for how to do things right.
>
> If you have engaged mentors then that should be no issue, the last checkbox 
> before graduation is that you don’t need mentors anymore and can wrk out 
> things for yourself that are in line with how other ASF projects operate and 
> the Apache Way. If you feel like that then perhaps your mentors haven’t 
> completed their job.
>
> Thanks for your thoughts,
> Justin
> -
> 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

Re: New disclaimer text

[Joshua Poore]

Replies inline:

> On Jul 12, 2019, at 3:49 AM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Adding an additional disclaimer that we may have known issues adds 
>> additional barriers to adoption and community growth.
> 
> I think the question to be asked is does that add barries more than having to 
> have 100% compliant releases? I think the answer may depend on the podling. 
> Have does that work out for 50 odd podlings?

I’m looking at this from a corporate investment perspective, having some 
insights into that process: you’re right, each podling has a different market 
with different community dynamics. I’m not going to speculate as to the 
base-rates. What I can say is that the ASF needs to be (and probably is) 
tracking the growth in the tech start-up, small-business market. The Apache 
license is highly desirable by small business and those working under VC, as is 
the `Apache` brand (even US gov’t agencies are looking at this more closely). 
This is going to be a huge potential drivers for growth in projects and 
communities. Looking at things from this perspective, if there is an additional 
disclaimer that make an Apache Incubator project look riskier to adopt than 
some other junk on GitHub with more than 10 stars, then I see an unnecessary 
barrier in exploiting how the growing tech market can accelerate the growth of 
open-source projects. Open-source no longer just about a bunch of folks who 
love keeping software free and open, or folks to love collaborating, its also 
about driving technology markets in strategic ways. I hold all three of these 
interests.

> 
>> Here’s one way for the ASF Incubator: Apache’s key marketing point is the 
>> Apache Way. Break down critical processes, determine key performance 
>> indicators against those processes, and centrally track metrics (license 
>> compliance, community participation, release compliance, notice, keys, 
>> whatever, whatever).
> 
> I really like the idea, would you be willing to work on it further?

I would, and I will, but I can’t do it all on my own. Some of the back-end 
stuff and navigating the INFRA reqs will be beyond my skills. However, I can 
contribute and at least work on marshaling other volunteer resources, managing 
tickets, requirements generation, and drawing in examples from some of the 
existing badges that are so popular in say, the node.js community. My action to 
start a thread in the near-term on this for discussion, I might need your help 
in directing other podlings PPMCs to the thread so that we get the best range 
of requirements and levels of interest from the podlings. I will also add a 
confluence page on this proposal.

> 
> Some things to consider. I don’t know it we have enough volunteer time to 
> implement something along those line or if we could come out with clear 
> metrics to suit all podlings. However in some ways this work has already been 
> done with the maturity model. There are issues this this as well a) not all 
> IPMC members or podlings think it should be used so so it's optional. b) 
> we’ve had podlings fill it in and ask to graduate that were clearly not ready 
> to graduate.

That’s OK. We’ll run it to ground. At minimum, I think the conversation will be 
a forcing function to really ascertain whether the larger podling community 
cares about the disclaimer as much as a few vocal committers.

> 
>> The additional disclaimer communicates that Apache has little trust in its 
>> podlings, at large.
> 
> About 1 in 5 podling releases put up fro IPMC have serious issues and have 
> previously have attracted -1 votes by IPMC members. If we allow those to be 
> released then I think we need to add something to the the disclaimer, we just 
> need to work out a balance.

Communication of distrust isn’t the same thing as how we trust something right 
now. It's clear that if these compliance issues are really risks from a legal 
perspective then you have very good reason to distrust some podlings. How the 
Incubator communicates that distrust and its implications for giving podlings a 
real shot at success is the crux of the issues. My point is that any Incubation 
model requires some element of risk because those risks are precisely the value 
adds to incubator participants. Beyond a balance in accepting risk, we need to 
help find the Incubator better, more efficient ways of managing risks. I 
suppose that’s the tl;dr version of the manifesto I accidentally wrote the 
other night.

> 
>> -1. These are connected issues: Mentors are IMPCs "tip of the spear" for 
>> managing compliance risk and for adding value to podlings. I have so much 
>> respect for Justin and other IPMC regulars who tirelessly volunteer and 
>> monitor general@, dig into minor releases to test builds and check 
>> compliance. It’s heroic, but heroes are a sign of struggling operations in 
>> orgs, and heroes burn out.
> 
> I’ve yet to see any proposal that deals with the issue of how it would get 
> around that only PMC members vo

Re: New disclaimer text

[Craig Russell]

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  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

Re: New disclaimer text

[Jim Jagielski]

This is a great idea... +1

> On Jul 12, 2019, at 6:31 PM, Craig Russell  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  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

Re: New disclaimer text

[Matt Sicker]

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  wrote:

> This is a great idea... +1
>
> > On Jul 12, 2019, at 6:31 PM, Craig Russell  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 
> 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 

Re: New disclaimer text

[Roman Shaposhnik]

Big +1!

On Fri, Jul 12, 2019 at 4:08 PM Matt Sicker  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  wrote:
>
> > This is a great idea... +1
> >
> > > On Jul 12, 2019, at 6:31 PM, Craig Russell  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 
> > 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 

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

Re: New disclaimer text

[Justin Mclean]

Hi,

+1 Works for me.

It will need to be made very clear to podlings that different rules apply 
depending on what disclaimer they have.

Would this also please to the disclaimer on their web site and in announcement 
emails?

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New disclaimer text

[Sheng Wu]

+1 from me to have two disclaimers, chosen by podings.

Also, +1 from me, the one they chosen should stay in website and
announcement.

Sheng

Justin Mclean 于2019年7月13日 周六上午9:37写道：

> Hi,
>
> +1 Works for me.
>
> It will need to be made very clear to podlings that different rules apply
> depending on what disclaimer they have.
>
> Would this also please to the disclaimer on their web site and in
> announcement emails?
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
> --
Sheng Wu
SkyWalking, Shardingsphere and Zipkin

Re: New disclaimer text

[Dave Fisher]

+1 if as discussed earlier we enhance both disclaimers to include a link to the 
podling status page where the podling will provide the most up to date details.

We can discuss a new Git based status page in a separate thread. I’d like to 
change from the xml/secret yaml files in svn to a straight up markdown file in 
Git.

Regards,
Dave

Sent from my iPhone

> On Jul 12, 2019, at 5:44 PM, Sheng Wu  wrote:
> 
> +1 from me to have two disclaimers, chosen by podings.
> 
> Also, +1 from me, the one they chosen should stay in website and
> announcement.
> 
> Sheng
> 
> Justin Mclean 于2019年7月13日 周六上午9:37写道：
> 
>> Hi,
>> 
>> +1 Works for me.
>> 
>> It will need to be made very clear to podlings that different rules apply
>> depending on what disclaimer they have.
>> 
>> Would this also please to the disclaimer on their web site and in
>> announcement emails?
>> 
>> Thanks,
>> Justin
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> --
> Sheng Wu
> SkyWalking, Shardingsphere and Zipkin


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

Re: New disclaimer text

[Justin Mclean]

HI,

> +1 if as discussed earlier we enhance both disclaimers to include a link to 
> the podling status page where the podling will provide the most up to date 
> details.

I think the text needs to refer to that release, while the latest is also 
useful, it if doesn’t include things that were in that release it could be 
misleading.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New disclaimer text

[Dave Fisher]

Sent from my iPhone

> On Jul 12, 2019, at 7:32 PM, Justin Mclean  wrote:
> 
> HI,
> 
>> +1 if as discussed earlier we enhance both disclaimers to include a link to 
>> the podling status page where the podling will provide the most up to date 
>> details.
> 
> I think the text needs to refer to that release, while the latest is also 
> useful, it if doesn’t include things that were in that release it could be 
> misleading.

The language would be:

“For the current status of this project through the Apache Incubator visit 
http://incubator.apache.org/project/${podling}.html


> 
> Thanks,
> Justin
> -
> 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

Re: New disclaimer text

[Justin Mclean]

Hi,

> The language would be:
> 
> “For the current status of this project through the Apache Incubator visit 
> http://incubator.apache.org/project/${podling}.html

Understand you now I’ve added that to the wiki page.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New disclaimer text

[Craig Russell]

It looks like we are closing on agreement to have (at least) two disclaimers. 
Now we need to discuss naming. [1]

Two big choices here: 

DISCLAIMER.txt for both versions of disclaimer; or

DISCLAIMER.txt for the current standard disclaimer and some other name for the 
new disclaimer.

If we choose another name:

DISCLAIMER2.txt
DISCLAIMER-X.txt
DISCLAIMER-L.txt

The advantage of keeping the same name for old and new disclaimers is there is 
no need to change existing tools. But I'd argue that this violates the 
principle of least surprise. If someone is reviewing a release, possibly with 
the idea of redistributing it, they see DISCLAIMER.txt and think they know what 
it contains, but it does not. Oops.

The advantage of changing the name with changed content is it highlights that 
this is not the same disclaimer we all know and love. Which means the person 
(or AI bot) reviewing the release is going to raise a flag to be looked at in 
more detail. At that point, the reviewer (or human overseer) will notice that 
the content is different and the release needs to have more scrutiny. Of 
course, the disadvantage of this is that tooling will need to change to 
accommodate the new disclosure. 

If we go down the path of changing the file name, I'd probably lean toward 
DISCLAIMER-X.txt which sounds a bit scary until you read the disclaimer which 
is much more scary than the file name.

Regards,

Craig

[1] The two hardest problems in computer science: cache invalidation, naming 
and off-by-one
https://martinfowler.com/bliki/TwoHardThings.html

> On Jul 12, 2019, at 7:04 PM, Dave Fisher  wrote:
> 
> +1 if as discussed earlier we enhance both disclaimers to include a link to 
> the podling status page where the podling will provide the most up to date 
> details.
> 
> We can discuss a new Git based status page in a separate thread. I’d like to 
> change from the xml/secret yaml files in svn to a straight up markdown file 
> in Git.
> 
> Regards,
> Dave
> 
> Sent from my iPhone
> 
>> On Jul 12, 2019, at 5:44 PM, Sheng Wu  wrote:
>> 
>> +1 from me to have two disclaimers, chosen by podings.
>> 
>> Also, +1 from me, the one they chosen should stay in website and
>> announcement.
>> 
>> Sheng
>> 
>> Justin Mclean 于2019年7月13日 周六上午9:37写道：
>> 
>>> Hi,
>>> 
>>> +1 Works for me.
>>> 
>>> It will need to be made very clear to podlings that different rules apply
>>> depending on what disclaimer they have.
>>> 
>>> Would this also please to the disclaimer on their web site and in
>>> announcement emails?
>>> 
>>> Thanks,
>>> Justin
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>>> --
>> Sheng Wu
>> SkyWalking, Shardingsphere and Zipkin
> 
> 
> -
> 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

Re: New disclaimer text

[Sheng Wu]

Not good at naming stuff :) But I support to use different names.

Sheng Wu
Apache Skywalking, ShardingSphere, Zipkin



> 在 2019年7月14日，上午9:49，Craig Russell  写道：
> 
> It looks like we are closing on agreement to have (at least) two disclaimers. 
> Now we need to discuss naming. [1]
> 
> Two big choices here: 
> 
> DISCLAIMER.txt for both versions of disclaimer; or
> 
> DISCLAIMER.txt for the current standard disclaimer and some other name for 
> the new disclaimer.
> 
> If we choose another name:
> 
> DISCLAIMER2.txt
> DISCLAIMER-X.txt
> DISCLAIMER-L.txt
> 
> The advantage of keeping the same name for old and new disclaimers is there 
> is no need to change existing tools. But I'd argue that this violates the 
> principle of least surprise. If someone is reviewing a release, possibly with 
> the idea of redistributing it, they see DISCLAIMER.txt and think they know 
> what it contains, but it does not. Oops.
> 
> The advantage of changing the name with changed content is it highlights that 
> this is not the same disclaimer we all know and love. Which means the person 
> (or AI bot) reviewing the release is going to raise a flag to be looked at in 
> more detail. At that point, the reviewer (or human overseer) will notice that 
> the content is different and the release needs to have more scrutiny. Of 
> course, the disadvantage of this is that tooling will need to change to 
> accommodate the new disclosure. 
> 
> If we go down the path of changing the file name, I'd probably lean toward 
> DISCLAIMER-X.txt which sounds a bit scary until you read the disclaimer which 
> is much more scary than the file name.
> 
> Regards,
> 
> Craig
> 
> [1] The two hardest problems in computer science: cache invalidation, naming 
> and off-by-one
> https://martinfowler.com/bliki/TwoHardThings.html
> 
>> On Jul 12, 2019, at 7:04 PM, Dave Fisher  wrote:
>> 
>> +1 if as discussed earlier we enhance both disclaimers to include a link to 
>> the podling status page where the podling will provide the most up to date 
>> details.
>> 
>> We can discuss a new Git based status page in a separate thread. I’d like to 
>> change from the xml/secret yaml files in svn to a straight up markdown file 
>> in Git.
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>> On Jul 12, 2019, at 5:44 PM, Sheng Wu  wrote:
>>> 
>>> +1 from me to have two disclaimers, chosen by podings.
>>> 
>>> Also, +1 from me, the one they chosen should stay in website and
>>> announcement.
>>> 
>>> Sheng
>>> 
>>> Justin Mclean 于2019年7月13日 周六上午9:37写道：
>>> 
 Hi,
 
 +1 Works for me.
 
 It will need to be made very clear to podlings that different rules apply
 depending on what disclaimer they have.
 
 Would this also please to the disclaimer on their web site and in
 announcement emails?
 
 Thanks,
 Justin
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 --
>>> Sheng Wu
>>> SkyWalking, Shardingsphere and Zipkin
>> 
>> 
>> -
>> 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

Re: New disclaimer text

[Paul King]

+1

On Sat, Jul 13, 2019 at 10:44 AM Sheng Wu  wrote:

> +1 from me to have two disclaimers, chosen by podings.
>
> Also, +1 from me, the one they chosen should stay in website and
> announcement.
>
> Sheng
>
> Justin Mclean 于2019年7月13日 周六上午9:37写道：
>
> > Hi,
> >
> > +1 Works for me.
> >
> > It will need to be made very clear to podlings that different rules apply
> > depending on what disclaimer they have.
> >
> > Would this also please to the disclaimer on their web site and in
> > announcement emails?
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> > --
> Sheng Wu
> SkyWalking, Shardingsphere and Zipkin
>

Re: New disclaimer text

[Jim Jagielski]

> On Jul 13, 2019, at 9:49 PM, Craig Russell  wrote:
> 
> DISCLAIMER.txt for the current standard disclaimer and some other name for 
> the new disclaimer.
> 

This seems less confusing, I think. DISCLAIMERv2.txt for the other?


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

Re: New disclaimer text

[David Jencks]

To me, v2 implies an improvement over its predecessor and an expectation that 
eventually it will universally replace said predecessor.

Perhaps 
DISCLAIMER-b.txt
DISCLAIMER-x.txt
might avoid this implication?

David Jencks 

Sent from my iPhone

> On Jul 15, 2019, at 7:40 AM, Jim Jagielski  wrote:
> 
> 
> 
>> On Jul 13, 2019, at 9:49 PM, Craig Russell  wrote:
>> 
>> DISCLAIMER.txt for the current standard disclaimer and some other name for 
>> the new disclaimer.
>> 
> 
> This seems less confusing, I think. DISCLAIMERv2.txt for the other?
> 
> 
> -
> 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

Re: New disclaimer text

[Jim Jagielski]

Very good point... I'm personally fine w/ anything. Let's avoid bike shedding :)

> On Jul 15, 2019, at 11:07 AM, David Jencks  wrote:
> 
> To me, v2 implies an improvement over its predecessor and an expectation that 
> eventually it will universally replace said predecessor.
> 
> Perhaps 
> DISCLAIMER-b.txt
> DISCLAIMER-x.txt
> might avoid this implication?
> 
> David Jencks 
> 
> Sent from my iPhone
> 
>> On Jul 15, 2019, at 7:40 AM, Jim Jagielski  wrote:
>> 
>> 
>> 
>>> On Jul 13, 2019, at 9:49 PM, Craig Russell  wrote:
>>> 
>>> DISCLAIMER.txt for the current standard disclaimer and some other name for 
>>> the new disclaimer.
>>> 
>> 
>> This seems less confusing, I think. DISCLAIMERv2.txt for the other?
>> 
>> 
>> -
>> 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
> 


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

Re: New disclaimer text

[Justin Mclean]

Hi,

I don’t rally care what they are called but I would suggest that we use
- Keep the existing one called as it is
- Name the new one something like DISCLAIMER-PERMISSIVE, DISCLAIMER-ISSUES, 
DISCLAIMER-INITIAL, or DISCLAIMER-PROGRESS

The name may be a bit long but I think it needs to clearly indicates the intent 
rather than just adding a single letter.

Thanks,
Justin


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

Re: New disclaimer text

[Bertrand Delacretaz]

Hi,

On Wed, Jul 17, 2019 at 8:06 AM Justin Mclean  wrote:
> - Keep the existing one called as it is...

And have it mention the possible additional disclaimers, as DISCLAIMER-* maybe.

>... Name the new one something like DISCLAIMER-PERMISSIVE, DISCLAIMER-ISSUES,
> DISCLAIMER-INITIAL, or DISCLAIMER-PROGRESS...

I suggest DISCLAIMER-WIP as in Work In Progress.

-Bertrand

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

Re: New disclaimer text

[Dave Fisher]

> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz  
> wrote:
> 
> Hi,
> 
>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
>> wrote:
>> ...I put up suggested text changes for an incubator disclaimer here [1]...
> 
> Basically just adding this, right?
> 
>> Some of the project releases may not follow ASF policy or have
>> incomplete or unknown licensing conditions
> 
> It works for me but I'd say "incubating project" to be clearer.
> 
>> ...It also been suggested than any known issues be listed in the 
>> disclaimer...
> 
> I don't think that works as modifying the disclaimer to list issues
> will change the digests of the archive that's being voted on - and
> those shouldn't change IMO.
> 
> As Paul suggests in a different thread I'd go for easy to find tickets
> to describe those changes. The disclaimer might point to
> http://incubator.apache.org/release-issues which in turn points to
> those tickets, keyed by release name and version number. Or something
> like that - a permalink that points to the details.
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

Re: New disclaimer text

[Paul King]

+1 for:
DISCLAIMER-PERMISSIVE or DISCLAIMER-WIP


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Jul 17, 2019 at 5:05 PM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi,
>
> On Wed, Jul 17, 2019 at 8:06 AM Justin Mclean 
> wrote:
> > - Keep the existing one called as it is...
>
> And have it mention the possible additional disclaimers, as DISCLAIMER-*
> maybe.
>
> >... Name the new one something like DISCLAIMER-PERMISSIVE,
> DISCLAIMER-ISSUES,
> > DISCLAIMER-INITIAL, or DISCLAIMER-PROGRESS...
>
> I suggest DISCLAIMER-WIP as in Work In Progress.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: New disclaimer text

[Justin Mclean]

Hi,

Seems a few people like DISCLAIMER-WIP and there no strong objection or 
opinions to other names, so let's go with that.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New disclaimer text

[Craig Russell]

I agree that the DISCLAIMER-WIP should refer to the status page, but the 
current disclaimer 
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Incubator+Disclaimer 
also has a free-form section for a list of known issues. "What follows is a 
list of known
issues the project is currently aware of..."

I think that the free-form section should also be generic, and refer to the 
JIRA or github issues for the podling. Something like 

https://github.com/apache//issues or
https://issues.apache.org/jira/projects//issues

After looking at a couple of podlings, I now understand that it is difficult to 
construct a definitive link since each project has its own way to track issues.

But I also think that editing the DISCLAIMER-WIP file should not be the first 
choice...

Maybe we should require that any podling that has DISCLAIMER-WIP issues must 
also have a page with known issues. This page can itself refer to jira or 
github but it has to be easy to find. How about 
https://.apache.org/issues.html which itself should be linked from 
https://.apache.org. The page should have prominent links "Issues to 
be resolved before the next release" and "Issues to be resolved before 
graduation". If the issues are organized well in the issue tracker, these links 
can be fixed links that don't need to be edited for each release. 
https://issues.apache.org/jira/projects//issues/?filter=graduationblockingissues
 and 
https://issues.apache.org/jira/projects//issues/?filter=releaseblockingissues

I can already hear the voices "the incubator is too heavy handed". But the 
incubator is allowing the podling to release with known issues, so I think it's 
a fair compromise.

Regards,

Craig

> On Jul 12, 2019, at 8:28 PM, Dave Fisher  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jul 12, 2019, at 7:32 PM, Justin Mclean  wrote:
>> 
>> HI,
>> 
>>> +1 if as discussed earlier we enhance both disclaimers to include a link to 
>>> the podling status page where the podling will provide the most up to date 
>>> details.
>> 
>> I think the text needs to refer to that release, while the latest is also 
>> useful, it if doesn’t include things that were in that release it could be 
>> misleading.
> 
> The language would be:
> 
> “For the current status of this project through the Apache Incubator visit 
> http://incubator.apache.org/project/${podling}.html
> 
> 
>> 
>> Thanks,
>> Justin
>> -
>> 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
> 

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

Re: New disclaimer text

[Justin Mclean]

Hi,

> I think that the free-form section should also be generic, and refer to the 
> JIRA or github issues for the podling. Something like 
> 
> https://github.com/apache//issues or
> https://issues.apache.org/jira/projects//issues

There’s an issue with that is you pointing to something that will change over 
time. If someone uses a release that list may not be correct as things are 
fixed over time. Unless that pages list releases one by one and with a list of 
issues for each.

> Maybe we should require that any podling that has DISCLAIMER-WIP issues must 
> also have a page with known issues. This page can itself refer to jira or 
> github but it has to be easy to find.

I think this is a good idea for a podlings to do, but not sure we should make 
it a requirement. Also some podlings are slow in creating their websites.

Thanks,
Justin


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