You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Bertrand Delacretaz <bd...@codeconsult.ch> on 2019/07/01 08:30:32 UTC
Re: New disclaimer text
Hi,
On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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.
> ...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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jul 2, 2019 at 1:55 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Dave Fisher wrote on Tue, 02 Jul 2019 10:28 -0700:
> > > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <
> bdelacretaz@codeconsult.ch> wrote:
> > >
> > > Hi,
> > >
> > > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <
> justin@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
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Dave Fisher wrote on Tue, 02 Jul 2019 10:28 -0700:
> > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
> >
> > Hi,
> >
> > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Dave Fisher <da...@comcast.net>.
> On Jul 3, 2019, at 12:16 PM, Dave Fisher <da...@comcast.net> wrote:
>
>
>
>> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>
>> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher <da...@comcast.net> wrote:
>>>
>>> Hi -
>>>
>>>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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 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/<podling>
>>>
>>> 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-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Dave Fisher wrote on Wed, 03 Jul 2019 16:06 -0700:
> > On Jul 3, 2019, at 3:59 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Alex Harui wrote on Wed, 03 Jul 2019 21:35 +0000:
> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Dave Fisher <da...@comcast.net>.
Sent from my iPhone
> On Jul 3, 2019, at 3:59 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Alex Harui wrote on Wed, 03 Jul 2019 21:35 +0000:
>> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Alex Harui wrote on Wed, 03 Jul 2019 21:35 +0000:
> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Ted Dunning <te...@gmail.com>.
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 <gi...@apache.org> 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 <pi...@gmail.com>
> 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 <boards@gmail.com
> >:
> > >
> > > 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 <ju...@classsoftware.com>
> > > 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-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > > --
> > > Matt Sicker <bo...@gmail.com>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
Re: New disclaimer text
Posted by Justin Mclean <ju...@me.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Paul King <pa...@asert.com.au>.
+1 for:
DISCLAIMER-PERMISSIVE or DISCLAIMER-WIP
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Wed, Jul 17, 2019 at 5:05 PM Bertrand Delacretaz <
bdelacretaz@codeconsult.ch> wrote:
> Hi,
>
> On Wed, Jul 17, 2019 at 8:06 AM Justin Mclean <ju...@classsoftware.com>
> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: New disclaimer text
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Hi,
On Wed, Jul 17, 2019 at 8:06 AM Justin Mclean <ju...@classsoftware.com> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Justin Mclean <ju...@classsoftware.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Jim Jagielski <ji...@jaguNET.com>.
Very good point... I'm personally fine w/ anything. Let's avoid bike shedding :)
> On Jul 15, 2019, at 11:07 AM, David Jencks <da...@gmail.com> 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 <ji...@jagunet.com> wrote:
>>
>>
>>
>>> On Jul 13, 2019, at 9:49 PM, Craig Russell <ap...@gmail.com> 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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by David Jencks <da...@gmail.com>.
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 <ji...@jagunet.com> wrote:
>
>
>
>> On Jul 13, 2019, at 9:49 PM, Craig Russell <ap...@gmail.com> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jul 13, 2019, at 9:49 PM, Craig Russell <ap...@gmail.com> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Sheng Wu <wu...@gmail.com>.
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 <ap...@gmail.com> 写道：
>
> 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 <wa...@comcast.net> 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 <wu...@gmail.com> 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 <ju...@classsoftware.com>于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-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>> --
>>> Sheng Wu
>>> SkyWalking, Shardingsphere and Zipkin
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig L Russell
> clr@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Craig Russell <ap...@gmail.com>.
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 <wa...@comcast.net> 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 <wu...@gmail.com> 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 <ju...@classsoftware.com>于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-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>> --
>> Sheng Wu
>> SkyWalking, Shardingsphere and Zipkin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
clr@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Justin Mclean <ju...@classsoftware.com>.
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/<podling>/issues or
> https://issues.apache.org/jira/projects/<podling>/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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Craig Russell <ap...@gmail.com>.
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/<podling>/issues or
https://issues.apache.org/jira/projects/<podling>/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://<podling>.apache.org/issues.html which itself should be linked from https://<podling>.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/<podling>/issues/?filter=graduationblockingissues and
https://issues.apache.org/jira/projects/<podling>/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 <wa...@comcast.net> wrote:
>
>
>
> Sent from my iPhone
>
>> On Jul 12, 2019, at 7:32 PM, Justin Mclean <ju...@classsoftware.com> 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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
clr@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Justin Mclean <ju...@me.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Dave Fisher <wa...@comcast.net>.
Sent from my iPhone
> On Jul 12, 2019, at 7:32 PM, Justin Mclean <ju...@classsoftware.com> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Justin Mclean <ju...@classsoftware.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Dave Fisher <wa...@comcast.net>.
+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 <wu...@gmail.com> 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 <ju...@classsoftware.com>于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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>> --
> Sheng Wu
> SkyWalking, Shardingsphere and Zipkin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Paul King <pa...@asert.com.au>.
+1
On Sat, Jul 13, 2019 at 10:44 AM Sheng Wu <wu...@gmail.com> 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 <ju...@classsoftware.com>于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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> > --
> Sheng Wu
> SkyWalking, Shardingsphere and Zipkin
>
Re: New disclaimer text
Posted by Sheng Wu <wu...@gmail.com>.
+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 <ju...@classsoftware.com>于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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
> --
Sheng Wu
SkyWalking, Shardingsphere and Zipkin
Re: New disclaimer text
Posted by Justin Mclean <ju...@classsoftware.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
Big +1!
On Fri, Jul 12, 2019 at 4:08 PM Matt Sicker <bo...@gmail.com> wrote:
>
> Agreed, this sounds like a great way to do this. As IPMC members reviewing
> releases, you now have better guidelines on how to go about reviewing a
> podling release.
>
> On Fri, Jul 12, 2019 at 17:59, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > This is a great idea... +1
> >
> > > On Jul 12, 2019, at 6:31 PM, Craig Russell <ap...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I understand I'm a bit late to this particular discussion, but perhaps
> > we can consider two different disclaimers that podlings can choose:
> > >
> > > The standard disclaimer that does not disclaim licensing issues; or,
> > >
> > > The proposed new disclaimer to be used by podlings' first releases until
> > they sort their licensing issues
> > >
> > > This "split roll" allows "mature" podlings the ability to assuage their
> > downstream that they have their licensing issues in hand.
> > >
> > > Use of the current disclaimer means that any licensing issues found
> > during release voting would cancel the release and require a respin.
> > >
> > > Use of the proposed new disclaimer would allow new-ish podlings to get
> > on with releasing while they sort any licensing issues.
> > >
> > > And we can add to the Maturity Model a section that discusses that the
> > podling has had at least one release with the standard disclaimer.
> > >
> > > Regards,
> > >
> > > Craig
> > >
> > >> On Jul 10, 2019, at 2:44 PM, Justin Mclean <ju...@classsoftware.com>
> > wrote:
> > >>
> > >> Hi,
> > >>
> > >>> Speaking as a member of a currently-incubating project (Apache Druid)
> > where
> > >>> we have always strived to do releases with no known licensing issues,
> > the
> > >>> text sounds needlessly scary to downstream consumers.
> > >>
> > >> And that may be the problem with a one solution fits all process. It
> > has been suggested before we let podlings choose which release process they
> > want. However that may get too complex and make voting on releases
> > inconsistent.
> > >>
> > >>> IMO this disclaims too much, and would chill adoption of incubating
> > >>> software by people that care about having clean licensing. PPMCs
> > should be
> > >>> able to say "we believe this release is clean and have vetted it using
> > a
> > >>> normal Apache vetting process" or maybe even "we have vetted this
> > release
> > >>> and it is clean other than the following list of known issues". If they
> > >>> can't say one of those two statements, then maybe it's not time to do
> > their
> > >>> first release yet.
> > >>
> > >> The idea is to allow podlings to make releases that may not comply with
> > policy. Have a hard switch from your releases doesn’t comply to everything
> > must comply is too difficult for some podlings.
> > >>
> > >>> And yeah, as a few others have mentioned, I believe that a more
> > streamlined
> > >>> voting process
> > >>
> > >> That I think is a different issue, ands may be best to start another
> > thread on that. The main issue here is that IPMC members votes are binding,
> > and not all mentors (who are IPMC members) vote on releases, so podlings
> > need votes from the wider IPMC members to make releases (in about 90%+ of
> > cases). There been a few ideas on how to improve this, including one
> > approved method (but no podlings have take that up yet).
> > >>
> > >> Thanks,
> > >> Justin
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >> For additional commands, e-mail: general-help@incubator.apache.org
> > >>
> > >
> > > Craig L Russell
> > > clr@apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> > --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Matt Sicker <bo...@gmail.com>.
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 <ji...@jagunet.com> wrote:
> This is a great idea... +1
>
> > On Jul 12, 2019, at 6:31 PM, Craig Russell <ap...@gmail.com> wrote:
> >
> > Hi,
> >
> > I understand I'm a bit late to this particular discussion, but perhaps
> we can consider two different disclaimers that podlings can choose:
> >
> > The standard disclaimer that does not disclaim licensing issues; or,
> >
> > The proposed new disclaimer to be used by podlings' first releases until
> they sort their licensing issues
> >
> > This "split roll" allows "mature" podlings the ability to assuage their
> downstream that they have their licensing issues in hand.
> >
> > Use of the current disclaimer means that any licensing issues found
> during release voting would cancel the release and require a respin.
> >
> > Use of the proposed new disclaimer would allow new-ish podlings to get
> on with releasing while they sort any licensing issues.
> >
> > And we can add to the Maturity Model a section that discusses that the
> podling has had at least one release with the standard disclaimer.
> >
> > Regards,
> >
> > Craig
> >
> >> On Jul 10, 2019, at 2:44 PM, Justin Mclean <ju...@classsoftware.com>
> wrote:
> >>
> >> Hi,
> >>
> >>> Speaking as a member of a currently-incubating project (Apache Druid)
> where
> >>> we have always strived to do releases with no known licensing issues,
> the
> >>> text sounds needlessly scary to downstream consumers.
> >>
> >> And that may be the problem with a one solution fits all process. It
> has been suggested before we let podlings choose which release process they
> want. However that may get too complex and make voting on releases
> inconsistent.
> >>
> >>> IMO this disclaims too much, and would chill adoption of incubating
> >>> software by people that care about having clean licensing. PPMCs
> should be
> >>> able to say "we believe this release is clean and have vetted it using
> a
> >>> normal Apache vetting process" or maybe even "we have vetted this
> release
> >>> and it is clean other than the following list of known issues". If they
> >>> can't say one of those two statements, then maybe it's not time to do
> their
> >>> first release yet.
> >>
> >> The idea is to allow podlings to make releases that may not comply with
> policy. Have a hard switch from your releases doesn’t comply to everything
> must comply is too difficult for some podlings.
> >>
> >>> And yeah, as a few others have mentioned, I believe that a more
> streamlined
> >>> voting process
> >>
> >> That I think is a different issue, ands may be best to start another
> thread on that. The main issue here is that IPMC members votes are binding,
> and not all mentors (who are IPMC members) vote on releases, so podlings
> need votes from the wider IPMC members to make releases (in about 90%+ of
> cases). There been a few ideas on how to improve this, including one
> approved method (but no podlings have take that up yet).
> >>
> >> Thanks,
> >> Justin
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
> > Craig L Russell
> > clr@apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
> --
Matt Sicker <bo...@gmail.com>
Re: New disclaimer text
Posted by Jim Jagielski <ji...@jaguNET.com>.
This is a great idea... +1
> On Jul 12, 2019, at 6:31 PM, Craig Russell <ap...@gmail.com> wrote:
>
> Hi,
>
> I understand I'm a bit late to this particular discussion, but perhaps we can consider two different disclaimers that podlings can choose:
>
> The standard disclaimer that does not disclaim licensing issues; or,
>
> The proposed new disclaimer to be used by podlings' first releases until they sort their licensing issues
>
> This "split roll" allows "mature" podlings the ability to assuage their downstream that they have their licensing issues in hand.
>
> Use of the current disclaimer means that any licensing issues found during release voting would cancel the release and require a respin.
>
> Use of the proposed new disclaimer would allow new-ish podlings to get on with releasing while they sort any licensing issues.
>
> And we can add to the Maturity Model a section that discusses that the podling has had at least one release with the standard disclaimer.
>
> Regards,
>
> Craig
>
>> On Jul 10, 2019, at 2:44 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>>
>> Hi,
>>
>>> Speaking as a member of a currently-incubating project (Apache Druid) where
>>> we have always strived to do releases with no known licensing issues, the
>>> text sounds needlessly scary to downstream consumers.
>>
>> And that may be the problem with a one solution fits all process. It has been suggested before we let podlings choose which release process they want. However that may get too complex and make voting on releases inconsistent.
>>
>>> IMO this disclaims too much, and would chill adoption of incubating
>>> software by people that care about having clean licensing. PPMCs should be
>>> able to say "we believe this release is clean and have vetted it using a
>>> normal Apache vetting process" or maybe even "we have vetted this release
>>> and it is clean other than the following list of known issues". If they
>>> can't say one of those two statements, then maybe it's not time to do their
>>> first release yet.
>>
>> The idea is to allow podlings to make releases that may not comply with policy. Have a hard switch from your releases doesn’t comply to everything must comply is too difficult for some podlings.
>>
>>> And yeah, as a few others have mentioned, I believe that a more streamlined
>>> voting process
>>
>> That I think is a different issue, ands may be best to start another thread on that. The main issue here is that IPMC members votes are binding, and not all mentors (who are IPMC members) vote on releases, so podlings need votes from the wider IPMC members to make releases (in about 90%+ of cases). There been a few ideas on how to improve this, including one approved method (but no podlings have take that up yet).
>>
>> Thanks,
>> Justin
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> Craig L Russell
> clr@apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Craig Russell <ap...@gmail.com>.
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 <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> Speaking as a member of a currently-incubating project (Apache Druid) where
>> we have always strived to do releases with no known licensing issues, the
>> text sounds needlessly scary to downstream consumers.
>
> And that may be the problem with a one solution fits all process. It has been suggested before we let podlings choose which release process they want. However that may get too complex and make voting on releases inconsistent.
>
>> IMO this disclaims too much, and would chill adoption of incubating
>> software by people that care about having clean licensing. PPMCs should be
>> able to say "we believe this release is clean and have vetted it using a
>> normal Apache vetting process" or maybe even "we have vetted this release
>> and it is clean other than the following list of known issues". If they
>> can't say one of those two statements, then maybe it's not time to do their
>> first release yet.
>
> The idea is to allow podlings to make releases that may not comply with policy. Have a hard switch from your releases doesn’t comply to everything must comply is too difficult for some podlings.
>
>> And yeah, as a few others have mentioned, I believe that a more streamlined
>> voting process
>
> That I think is a different issue, ands may be best to start another thread on that. The main issue here is that IPMC members votes are binding, and not all mentors (who are IPMC members) vote on releases, so podlings need votes from the wider IPMC members to make releases (in about 90%+ of cases). There been a few ideas on how to improve this, including one approved method (but no podlings have take that up yet).
>
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig L Russell
clr@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Joshua Poore <po...@me.com.INVALID>.
Replies inline:
> On Jul 12, 2019, at 3:49 AM, Justin Mclean <ju...@classsoftware.com> 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 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.
My point is only that mentors will help manage risks, and there is a known issue right now for getting binding votes from PPMC. Like you, I’m not sure that the answer is to change voting policies. I actually love submitting our work to objective scrutiny. It makes me feel better about releases. However, if IPMC members who sit on PPMC aren’t VOTING or signing REPORTs, then its a volunteer incentive problem too. I don’t know a silver bullet method for how to incentivize mentors in a not-for-profit, strict volunteer organization. But, it's a thing that should be raised as discussion. I’ll contribute to that discussion and share any suggestions that pop up.
>
>> 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.
As I said, you’re heroes and inspiring at that. As a committer, I’m not worried about what you’re doing, or how you’re doing it. I’m worried about how much time you spend on stuff you want to do and things you think you should be doing, not just what you need to be doing. When heroes don’t get to do what challenges them, grow them, and fulfills them, they start disappearing. That’s what I worry about because I see the strain that disappearing binding votes and eyes on licenses and notice files is adding to general@, and I worry about the heroes disappearing for burn out.
>
>> 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.
I think you made my point better than I did. I would add that it’s clear that a number of mentors (across the Incubator) just aren’t showing up, which means that they’re not doing their job. That puts burden on PPMC and IPMC processes (releases, reports), shifts the workshare up to IPMC to make sure things are compliant. Now, I fully respect that my subjective experience probably doesn’t cover all others, but I can’t image that some other committers/PPMC aren’t feeling some of the same things. When committers and PPMC have questions they don’t know the answers to, can’t find the right documentation, or can’t deduce the right thing to do because documentation describes process and policy, but doesn’t give context as to why it exists, then any reasonable human can feel an unfamiliar paralysis or irreducible uncertainty that slows growth. We learn without guidance, and sometimes painfully through trial and error, which can be painful in public both in front of general and our own communities for many of the same reasons we worry overhe disclaimer. This is where this thread unravels and needs to be picked up elsewhere. However, the relevant point is that when mentors don’t show up or don’t themselves know the right processes, that contributes to your 1:5 compliance problem. A disclaimer doesn’t fix that, IMO. It's the nuclear option that wipes the map clean of compliance risk and doesn’t address the problems and strains that prevent compliance from improving at the PPMC level before it becomes IPMCs problem.
>
> Thanks for your thoughts,
Thanks for listening. I wouldn’t contribute to this thread if I didn’t care about the incubator, and I do. It's a great organization with great people, and I’m happy to help nurture it in the same way that it is nurturing Flagon.
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Jan Piotrowski <pi...@gmail.com>.
> 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
<ju...@classsoftware.com>:
>
> 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Justin Mclean <ju...@classsoftware.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Joshua Poore <po...@apache.org>.
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 <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> Speaking as a member of a currently-incubating project (Apache Druid) where
>> we have always strived to do releases with no known licensing issues, the
>> text sounds needlessly scary to downstream consumers.
> And that may be the problem with a one solution fits all process. It has been suggested before we let podlings choose which release process they want. However that may get too complex and make voting on releases inconsistent.
+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 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).
>
-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. Their valuable time is better spent institutionalizing knowledge and skills: making mentors' jobs easier with templates, documentations, infrastructure projects. In doing so, the Incubator empowers PPMCs, engenders self-sufficiency and gives mentors bandwidth to progressively track compliance at regular intervals, VOTE on releases (with expediency), swoop in to help with the tactical issues that come up, and actually mentor podlings on how to steadily grow with wisdom and experience.
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. Its hard to know what you have permission to do and taking a risks to do certain things without mentors can result in shame and worry that you’ll look like you're struggling if feel they're done wrong. These issues are inexorably intertwined because mentors are at the heart of managing Incubator risk/compliance and value to podlings.
Ever chasing the Apache Way,
-J
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: New disclaimer text
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Speaking as a member of a currently-incubating project (Apache Druid) where
> we have always strived to do releases with no known licensing issues, the
> text sounds needlessly scary to downstream consumers.
And that may be the problem with a one solution fits all process. It has been suggested before we let podlings choose which release process they want. However that may get too complex and make voting on releases inconsistent.
> IMO this disclaims too much, and would chill adoption of incubating
> software by people that care about having clean licensing. PPMCs should be
> able to say "we believe this release is clean and have vetted it using a
> normal Apache vetting process" or maybe even "we have vetted this release
> and it is clean other than the following list of known issues". If they
> can't say one of those two statements, then maybe it's not time to do their
> first release yet.
The idea is to allow podlings to make releases that may not comply with policy. Have a hard switch from your releases doesn’t comply to everything must comply is too difficult for some podlings.
> And yeah, as a few others have mentioned, I believe that a more streamlined
> voting process
That I think is a different issue, ands may be best to start another thread on that. The main issue here is that IPMC members votes are binding, and not all mentors (who are IPMC members) vote on releases, so podlings need votes from the wider IPMC members to make releases (in about 90%+ of cases). There been a few ideas on how to improve this, including one approved method (but no podlings have take that up yet).
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Gian Merlino <gi...@apache.org>.
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 <pi...@gmail.com> 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 <bo...@gmail.com>:
> >
> > 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 <ju...@classsoftware.com>
> > 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-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > > --
> > Matt Sicker <bo...@gmail.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: New disclaimer text
Posted by Justin Mclean <ju...@classsoftware.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Jan Piotrowski <pi...@gmail.com>.
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 <bo...@gmail.com>:
>
> 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 <ju...@classsoftware.com>
> 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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> > --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Matt Sicker <bo...@gmail.com>.
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 <ju...@classsoftware.com>
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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
> --
Matt Sicker <bo...@gmail.com>
Re: New disclaimer text
Posted by Justin Mclean <ju...@classsoftware.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Jul 3, 2019 at 2:52 PM Greg Stein <gs...@gmail.com> wrote:
>
> On Wed, Jul 3, 2019 at 4:35 PM Alex Harui <ah...@adobe.com.invalid> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jul 3, 2019 at 4:35 PM Alex Harui <ah...@adobe.com.invalid> 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
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <d....@daniel.shahaf.name> 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Dave Fisher <da...@comcast.net>.
> On Jul 3, 2019, at 12:32 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Wed, Jul 3, 2019 at 12:29 PM Dave Fisher <da...@comcast.net> wrote:
>>
>>
>>
>>> On Jul 3, 2019, at 12:24 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>>
>>> On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher <da...@comcast.net> wrote:
>>>>> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>>>>
>>>>> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher <da...@comcast.net> wrote:
>>>>>>
>>>>>> Hi -
>>>>>>
>>>>>>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Jul 3, 2019 at 12:29 PM Dave Fisher <da...@comcast.net> wrote:
>
>
>
> > On Jul 3, 2019, at 12:24 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >
> > On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher <da...@comcast.net> wrote:
> >>> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >>>
> >>> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher <da...@comcast.net> wrote:
> >>>>
> >>>> Hi -
> >>>>
> >>>>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Dave Fisher <da...@comcast.net>.
> On Jul 3, 2019, at 12:24 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher <da...@comcast.net> wrote:
>>> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>>
>>> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher <da...@comcast.net> wrote:
>>>>
>>>> Hi -
>>>>
>>>>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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 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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Jul 3, 2019 at 12:17 PM Dave Fisher <da...@comcast.net> wrote:
> > On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >
> > On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher <da...@comcast.net> wrote:
> >>
> >> Hi -
> >>
> >>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Dave Fisher <da...@comcast.net>.
> On Jul 3, 2019, at 11:50 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher <da...@comcast.net> wrote:
>>
>> Hi -
>>
>>> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>>>
>>> Hi,
>>>
>>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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 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/<podling>
>>
>> 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-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Jul 2, 2019 at 10:28 AM Dave Fisher <da...@comcast.net> wrote:
>
> Hi -
>
> > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
> >
> > Hi,
> >
> > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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 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/<podling>
>
> 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-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Dave Fisher <da...@comcast.net>.
Hi -
> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>
> Hi,
>
> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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."
>
>> ...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/<podling>
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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Dave Fisher <da...@comcast.net>.
> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <bd...@codeconsult.ch> wrote:
>
> Hi,
>
>> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <ju...@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.
>
>> ...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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
Re: New disclaimer text
Posted by Justin Mclean <ju...@me.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org