Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Matthias Seidel]

Really, I don't even know what they are talking about...
Has anyone been informed about what they are trying to achieve?

What "significant push back from Legal and the Board" should we expect?

Regards,

   Matthias

Am 16.10.20 um 20:59 schrieb Joan Touzet:
> Hi Jarek,
>
> On 16/10/2020 05:45, Jarek Potiuk wrote:
>
>> Joan - I hope you are back and we can continue the discussion. 
> Sorry, I just don't have the time or the energy to carry this further.
>
> I only brought up OO because it was one of the outliers, and the first
> "user application" that came to mind when considering Apache projects
> that deliver actual end user software vs. e.g. Java libraries. All
> deference to Dave Fisher and the OO PMC; they have many concerns that
> extend far beyond the terms of this policy. Apologies for pulling that
> community into this thread.
>
> I'm glad my comments have given you some food for thought. I would
> expect significant push back from Legal and the Board. That said, good
> luck with your efforts.
>
> Please drop me from this thread.
>
> -Joan
>
>> I'd love
>> to come up with the proposal that will include the specifics of OOffice
>> releases. The proposal is here -
>> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
>> .
>> Happy to hear some responses on my comments/proposal
>> Also anyone who is interested - I invite you to comment on the proposal.
>>
>> My plan is to - possibly - come up with a proposal that we all
>> people here will be ok with (hopefully next week) and submit it to the
>> legal team of ASF for review/opinions.
>>
>> J.
>>
>>
>> On Tue, Sep 15, 2020 at 2:06 PM Jarek Potiuk > > wrote:
>>
>> Cool. Thanks Bertrand - I am aware of some of those, but this list
>> will be helpful so I can make some of the references to those in my
>> proposal (and I encourage everyone else to do so). I am super-happy
>> to merge yours with mine. I believe the "spirit" of those is rather
>> similar. I am fully aware legal review should be done - I want now
>> to get some initial feedback and see what controversies the proposal
>> raises and polish it a bit, but I 100% understand the policies are
>> binding for the ASF and the risk and legal side of it should be very
>> carefully considered.
>>
>> Note - I just run through a few of the comments we have there and
>> just for the sake of keeping people informed on what has changed so
>> far here are some "gists" of my changes comparing to the first draft:
>>
>> * there is an open question about the viability of putting all the
>> instructions or scripts to build the binary dependencies into 
>> released sources. Giving the example of OpenOffice, CouchDB and
>> Erlang which makes it next to impossible to do. So I proposed to
>> explicitly say that any form of the instructions: scripts, manual
>> instruction or POINTERS to the right instructions is fine. Simple
>> HTTP link where you can find how to build an external OSS library
>> should be perfectly fine. My ultimate goal is that whatever whenever
>> the source .tar.gz package is created - the goal is that the user
>> can get the sources and following the instructions (including the
>> links to instructions) can - potentially rebuild the software
>> legally. It might be a complex and recursive process (build a
>> library to build a library) and at times those instructions might
>> not work (as it is with all the instructions) but at least an
>> attempt should be made to make it possible.
>>
>> * The "official" 3rd-party binary package is not a good name - I
>> replaced it for now with the "maintained OSS" binary package. The
>> idea behind it is that shortly - it should be open-source and it
>> should be maintained. So while the name does not reflect all the
>> subtleties of "maintained" and "OSS" but it reflects the spirit. I
>> tried to make the "recursive" definition as much relaxed as possible
>> (in terms of SHOULD vs. MUST except with the Licencing which is a MUST) 
>>
>> * In pretty much all cases where I write about "best practices",
>> they are not absolute requirements - so whenever possible they are
>> SHOULD instead of MUST. I am very far from imposing all the best
>> practices on all ASF projects - that will be impractical and stupid
>> thing to do. I really treat those "best practices" as "beacons" -
>> targets that we can have in mind but might never fully achieve them.
>> And as long as we have good reason, not to follow those practices -
>> by all means we do not have to. But if easy and possible, I see the
>> best practices as a powerful message that improves the "Brand" of
>> ASF in general from the user perspective. There are no "bonus
>>

Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Joan Touzet]

Hi Jarek,

On 16/10/2020 05:45, Jarek Potiuk wrote:

> Joan - I hope you are back and we can continue the discussion. 

Sorry, I just don't have the time or the energy to carry this further.

I only brought up OO because it was one of the outliers, and the first
"user application" that came to mind when considering Apache projects
that deliver actual end user software vs. e.g. Java libraries. All
deference to Dave Fisher and the OO PMC; they have many concerns that
extend far beyond the terms of this policy. Apologies for pulling that
community into this thread.

I'm glad my comments have given you some food for thought. I would
expect significant push back from Legal and the Board. That said, good
luck with your efforts.

Please drop me from this thread.

-Joan

> I'd love
> to come up with the proposal that will include the specifics of OOffice
> releases. The proposal is here -
> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
> .
> Happy to hear some responses on my comments/proposal
> Also anyone who is interested - I invite you to comment on the proposal.
> 
> My plan is to - possibly - come up with a proposal that we all
> people here will be ok with (hopefully next week) and submit it to the
> legal team of ASF for review/opinions.
> 
> J.
> 
> 
> On Tue, Sep 15, 2020 at 2:06 PM Jarek Potiuk  > wrote:
> 
> Cool. Thanks Bertrand - I am aware of some of those, but this list
> will be helpful so I can make some of the references to those in my
> proposal (and I encourage everyone else to do so). I am super-happy
> to merge yours with mine. I believe the "spirit" of those is rather
> similar. I am fully aware legal review should be done - I want now
> to get some initial feedback and see what controversies the proposal
> raises and polish it a bit, but I 100% understand the policies are
> binding for the ASF and the risk and legal side of it should be very
> carefully considered.
> 
> Note - I just run through a few of the comments we have there and
> just for the sake of keeping people informed on what has changed so
> far here are some "gists" of my changes comparing to the first draft:
> 
> * there is an open question about the viability of putting all the
> instructions or scripts to build the binary dependencies into 
> released sources. Giving the example of OpenOffice, CouchDB and
> Erlang which makes it next to impossible to do. So I proposed to
> explicitly say that any form of the instructions: scripts, manual
> instruction or POINTERS to the right instructions is fine. Simple
> HTTP link where you can find how to build an external OSS library
> should be perfectly fine. My ultimate goal is that whatever whenever
> the source .tar.gz package is created - the goal is that the user
> can get the sources and following the instructions (including the
> links to instructions) can - potentially rebuild the software
> legally. It might be a complex and recursive process (build a
> library to build a library) and at times those instructions might
> not work (as it is with all the instructions) but at least an
> attempt should be made to make it possible.
> 
> * The "official" 3rd-party binary package is not a good name - I
> replaced it for now with the "maintained OSS" binary package. The
> idea behind it is that shortly - it should be open-source and it
> should be maintained. So while the name does not reflect all the
> subtleties of "maintained" and "OSS" but it reflects the spirit. I
> tried to make the "recursive" definition as much relaxed as possible
> (in terms of SHOULD vs. MUST except with the Licencing which is a MUST) 
> 
> * In pretty much all cases where I write about "best practices",
> they are not absolute requirements - so whenever possible they are
> SHOULD instead of MUST. I am very far from imposing all the best
> practices on all ASF projects - that will be impractical and stupid
> thing to do. I really treat those "best practices" as "beacons" -
> targets that we can have in mind but might never fully achieve them.
> And as long as we have good reason, not to follow those practices -
> by all means we do not have to. But if easy and possible, I see the
> best practices as a powerful message that improves the "Brand" of
> ASF in general from the user perspective. There are no "bonus
> points" for projects that follow it vs. those which decided not to
> in particular cases. But having those as "targets" for ASF projects
> is an important message.
> 
> J,
> 
> 
> 
> On Tue, Sep 15, 2020 at 12:25 PM Bertrand Delacretaz
> mailto:bdelacre...@apache.org>> wrote:
> 
> Hi,
> 
> On Mon, Sep 7, 2020 a

Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Dave Fisher]

Let’s keep this simple.

Focus on your needs for clarification for Helm Charts.

I really don’t have the time or inclination to parse out what troubles there 
are for OpenOffice in your plan. I already have a long list with unexpected 
issues and mandates.

The Foundation exists for its Project Communities. The Board will need to 
decide if it will mandate any changes to PMCs.

VP, Legal Affairs has been delegated the responsibility for Release Policies.

Mandating changes to volunteers is like pushing a string and herding cats.

I don’t mean to be harsh and do want your effort to be successful. Don’t let 
perfection be your enemy.

Best Regards,
Dave

Sent from my iPhone

> On Oct 16, 2020, at 7:58 AM, Jarek Potiuk  wrote:
> 
> I do not want to make any assumptions on Windows/MacOS etc - for me this is
> really just proposal to clarify the ASF policies which (as far as at
> least I understand) are not up-to-date with some distribution mechanisms
> for convenience packages that have become popular way that our users can
> conveniently use to install our software.
> 
> The OpenOffice came because Joan stepped up and raised the point that
> current proposal is not ok for OOofice so I tried to come up with ideas how
> to make it works also for OOffice. I hope discussing it here at the devcom
> is the right place to do.
> 
> Would you be the right person to comment on the proposal Dave from the Open
> Office team? I see you are on the PMC list of Open Office? Would you be
> happy with the proposal? Or maybe you think it is not needed ?
> 
> Just to clarify my intentions (for the whole proposal):
> 
> I just want to make sure that those who are interested in clarifying the
> policy in the way that will make it easier for PMCs to follow the policies
> and make sure that those convenience packages are prepared accordingly,
> including the indemnification promise that ASF gives to the PMCs.
> According the the PMC gude: http://www.apache.org/dev/pmc.html it's the
> PMCs responsibility to follow the policies:
> 
> COMPLY WITH LEGAL AFFAIRS POLICIES¶
> PMCs SHALL ensure that the work on their project and the code that they
> produce comply with relevant Legal Affairs Committee policies, including
> appropriately using the Apache License, handling IP and copyrights
> correctly, handling cryptography, and producing official software releases
> of their products.
> 
> As a PMC of Apache Airflow I simply find it difficult to follow when it
> comes to helm charts/docker images, that's why I came forward with the
> proposal how to modify those policies to adapt to those distribution
> mechanisms - and my intention is to address any concerns other PMC might
> have here. I hope we can collaborate on that.
> 
> J.
> 
> 
>> On Fri, Oct 16, 2020 at 3:05 PM Dave Fisher  wrote:
>> 
>> Questions related to OpenOffice must be discussed with the OpenOffice PMC.
>> Joan is an observer and I don’t recall her asking the PMC.
>> 
>> Please don’t make any assumptions about builds for Windows, macOS (we
>> support 10.7 and newer) and Linux. Community members on their own build
>> OS/2 and FreeBSD versions.
>> 
>> OpenOffice is completely volunteer driven.
>> 
>> Many in the community are not native English speakers.
>> 
>> Tread carefully.
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
 On Oct 16, 2020, at 2:46 AM, Jarek Potiuk  wrote:
>>> 
>>> Hello everyone,
>>> 
>>> As Apache Airflow 2.0 alpha is out, I have some time to come back to the
>>> discussion. I also add Joan who was discussing the policy in a
>>> separate thread in the builds@ devlist:
>>> 
>> https://lists.apache.org/thread.html/r18e21d4719755f83fc67a81c842f7a59a7aa76cd1f621b1362cdd6ae%40%3Cbuilds.apache.org%3E
>>> 
>>> Joan - I hope you are back and we can continue the discussion. I'd love
>> to
>>> come up with the proposal that will include the specifics of OOffice
>>> releases. The proposal is here -
>>> 
>> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
>> .
>>> Happy to hear some responses on my comments/proposal
>>> Also anyone who is interested - I invite you to comment on the proposal.
>>> 
>>> My plan is to - possibly - come up with a proposal that we all people
>> here
>>> will be ok with (hopefully next week) and submit it to the legal team of
>>> ASF for review/opinions.
>>> 
>>> J.
>>> 
>>> 
 On Tue, Sep 15, 2020 at 2:06 PM Jarek Potiuk  wrote:
 
 Cool. Thanks Bertrand - I am aware of some of those, but this list will
>> be
 helpful so I can make some of the references to those in my proposal
>> (and I
 encourage everyone else to do so). I am super-happy to merge yours with
 mine. I believe the "spirit" of those is rather similar. I am fully
>> aware
 legal review should be done - I want now to get some initial feedback
>> and
 see what controversies the proposal raises and polish it a bit, but I
>> 100%
 understand the policies are binding for the ASF and t

Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Jarek Potiuk]

I do not want to make any assumptions on Windows/MacOS etc - for me this is
really just proposal to clarify the ASF policies which (as far as at
least I understand) are not up-to-date with some distribution mechanisms
for convenience packages that have become popular way that our users can
conveniently use to install our software.

The OpenOffice came because Joan stepped up and raised the point that
current proposal is not ok for OOofice so I tried to come up with ideas how
to make it works also for OOffice. I hope discussing it here at the devcom
is the right place to do.

Would you be the right person to comment on the proposal Dave from the Open
Office team? I see you are on the PMC list of Open Office? Would you be
happy with the proposal? Or maybe you think it is not needed ?

Just to clarify my intentions (for the whole proposal):

I just want to make sure that those who are interested in clarifying the
policy in the way that will make it easier for PMCs to follow the policies
and make sure that those convenience packages are prepared accordingly,
including the indemnification promise that ASF gives to the PMCs.
According the the PMC gude: http://www.apache.org/dev/pmc.html it's the
PMCs responsibility to follow the policies:

COMPLY WITH LEGAL AFFAIRS POLICIES¶
PMCs SHALL ensure that the work on their project and the code that they
produce comply with relevant Legal Affairs Committee policies, including
appropriately using the Apache License, handling IP and copyrights
correctly, handling cryptography, and producing official software releases
of their products.

As a PMC of Apache Airflow I simply find it difficult to follow when it
comes to helm charts/docker images, that's why I came forward with the
proposal how to modify those policies to adapt to those distribution
mechanisms - and my intention is to address any concerns other PMC might
have here. I hope we can collaborate on that.

J.


On Fri, Oct 16, 2020 at 3:05 PM Dave Fisher  wrote:

> Questions related to OpenOffice must be discussed with the OpenOffice PMC.
> Joan is an observer and I don’t recall her asking the PMC.
>
> Please don’t make any assumptions about builds for Windows, macOS (we
> support 10.7 and newer) and Linux. Community members on their own build
> OS/2 and FreeBSD versions.
>
> OpenOffice is completely volunteer driven.
>
> Many in the community are not native English speakers.
>
> Tread carefully.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Oct 16, 2020, at 2:46 AM, Jarek Potiuk  wrote:
> >
> > Hello everyone,
> >
> > As Apache Airflow 2.0 alpha is out, I have some time to come back to the
> > discussion. I also add Joan who was discussing the policy in a
> > separate thread in the builds@ devlist:
> >
> https://lists.apache.org/thread.html/r18e21d4719755f83fc67a81c842f7a59a7aa76cd1f621b1362cdd6ae%40%3Cbuilds.apache.org%3E
> >
> > Joan - I hope you are back and we can continue the discussion. I'd love
> to
> > come up with the proposal that will include the specifics of OOffice
> > releases. The proposal is here -
> >
> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
> .
> > Happy to hear some responses on my comments/proposal
> > Also anyone who is interested - I invite you to comment on the proposal.
> >
> > My plan is to - possibly - come up with a proposal that we all people
> here
> > will be ok with (hopefully next week) and submit it to the legal team of
> > ASF for review/opinions.
> >
> > J.
> >
> >
> >> On Tue, Sep 15, 2020 at 2:06 PM Jarek Potiuk  wrote:
> >>
> >> Cool. Thanks Bertrand - I am aware of some of those, but this list will
> be
> >> helpful so I can make some of the references to those in my proposal
> (and I
> >> encourage everyone else to do so). I am super-happy to merge yours with
> >> mine. I believe the "spirit" of those is rather similar. I am fully
> aware
> >> legal review should be done - I want now to get some initial feedback
> and
> >> see what controversies the proposal raises and polish it a bit, but I
> 100%
> >> understand the policies are binding for the ASF and the risk and legal
> side
> >> of it should be very carefully considered.
> >>
> >> Note - I just run through a few of the comments we have there and just
> for
> >> the sake of keeping people informed on what has changed so far here are
> >> some "gists" of my changes comparing to the first draft:
> >>
> >> * there is an open question about the viability of putting all the
> >> instructions or scripts to build the binary dependencies into  released
> >> sources. Giving the example of OpenOffice, CouchDB and Erlang which
> makes
> >> it next to impossible to do. So I proposed to explicitly say that any
> form
> >> of the instructions: scripts, manual instruction or POINTERS to the
> right
> >> instructions is fine. Simple HTTP link where you can find how to build
> an
> >> external OSS library should be perfectly fine. My ultimate goal is that
> >> whatever w

Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Dave Fisher]

Questions related to OpenOffice must be discussed with the OpenOffice PMC. Joan 
is an observer and I don’t recall her asking the PMC.

Please don’t make any assumptions about builds for Windows, macOS (we support 
10.7 and newer) and Linux. Community members on their own build OS/2 and 
FreeBSD versions.

OpenOffice is completely volunteer driven. 

Many in the community are not native English speakers.

Tread carefully.

Regards,
Dave

Sent from my iPhone

> On Oct 16, 2020, at 2:46 AM, Jarek Potiuk  wrote:
> 
> Hello everyone,
> 
> As Apache Airflow 2.0 alpha is out, I have some time to come back to the
> discussion. I also add Joan who was discussing the policy in a
> separate thread in the builds@ devlist:
> https://lists.apache.org/thread.html/r18e21d4719755f83fc67a81c842f7a59a7aa76cd1f621b1362cdd6ae%40%3Cbuilds.apache.org%3E
> 
> Joan - I hope you are back and we can continue the discussion. I'd love to
> come up with the proposal that will include the specifics of OOffice
> releases. The proposal is here -
> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages.
> Happy to hear some responses on my comments/proposal
> Also anyone who is interested - I invite you to comment on the proposal.
> 
> My plan is to - possibly - come up with a proposal that we all people here
> will be ok with (hopefully next week) and submit it to the legal team of
> ASF for review/opinions.
> 
> J.
> 
> 
>> On Tue, Sep 15, 2020 at 2:06 PM Jarek Potiuk  wrote:
>> 
>> Cool. Thanks Bertrand - I am aware of some of those, but this list will be
>> helpful so I can make some of the references to those in my proposal (and I
>> encourage everyone else to do so). I am super-happy to merge yours with
>> mine. I believe the "spirit" of those is rather similar. I am fully aware
>> legal review should be done - I want now to get some initial feedback and
>> see what controversies the proposal raises and polish it a bit, but I 100%
>> understand the policies are binding for the ASF and the risk and legal side
>> of it should be very carefully considered.
>> 
>> Note - I just run through a few of the comments we have there and just for
>> the sake of keeping people informed on what has changed so far here are
>> some "gists" of my changes comparing to the first draft:
>> 
>> * there is an open question about the viability of putting all the
>> instructions or scripts to build the binary dependencies into  released
>> sources. Giving the example of OpenOffice, CouchDB and Erlang which makes
>> it next to impossible to do. So I proposed to explicitly say that any form
>> of the instructions: scripts, manual instruction or POINTERS to the right
>> instructions is fine. Simple HTTP link where you can find how to build an
>> external OSS library should be perfectly fine. My ultimate goal is that
>> whatever whenever the source .tar.gz package is created - the goal is that
>> the user can get the sources and following the instructions (including the
>> links to instructions) can - potentially rebuild the software legally. It
>> might be a complex and recursive process (build a library to build a
>> library) and at times those instructions might not work (as it is with all
>> the instructions) but at least an attempt should be made to make it
>> possible.
>> 
>> * The "official" 3rd-party binary package is not a good name - I replaced
>> it for now with the "maintained OSS" binary package. The idea behind it is
>> that shortly - it should be open-source and it should be maintained. So
>> while the name does not reflect all the subtleties of "maintained" and
>> "OSS" but it reflects the spirit. I tried to make the "recursive"
>> definition as much relaxed as possible (in terms of SHOULD vs. MUST except
>> with the Licencing which is a MUST)
>> 
>> * In pretty much all cases where I write about "best practices", they are
>> not absolute requirements - so whenever possible they are SHOULD instead of
>> MUST. I am very far from imposing all the best practices on all ASF
>> projects - that will be impractical and stupid thing to do. I really treat
>> those "best practices" as "beacons" - targets that we can have in mind but
>> might never fully achieve them. And as long as we have good reason, not to
>> follow those practices - by all means we do not have to. But if easy and
>> possible, I see the best practices as a powerful message that improves the
>> "Brand" of ASF in general from the user perspective. There are no "bonus
>> points" for projects that follow it vs. those which decided not to in
>> particular cases. But having those as "targets" for ASF projects is an
>> important message.
>> 
>> J,
>> 
>> 
>> 
>> On Tue, Sep 15, 2020 at 12:25 PM Bertrand Delacretaz <
>> bdelacre...@apache.org> wrote:
>> 
>>> Hi,
>>> 
>>> On Mon, Sep 7, 2020 at 10:24 AM Bertrand Delacretaz
>>>  wrote:
>>> ...
 ...* https://issues.apache.org/jira/browse/ASFP-23 (accessible to ASF
 Members) has links to relate

Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Jarek Potiuk]

Hello everyone,

As Apache Airflow 2.0 alpha is out, I have some time to come back to the
discussion. I also add Joan who was discussing the policy in a
separate thread in the builds@ devlist:
https://lists.apache.org/thread.html/r18e21d4719755f83fc67a81c842f7a59a7aa76cd1f621b1362cdd6ae%40%3Cbuilds.apache.org%3E

Joan - I hope you are back and we can continue the discussion. I'd love to
come up with the proposal that will include the specifics of OOffice
releases. The proposal is here -
https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages.
Happy to hear some responses on my comments/proposal
Also anyone who is interested - I invite you to comment on the proposal.

My plan is to - possibly - come up with a proposal that we all people here
will be ok with (hopefully next week) and submit it to the legal team of
ASF for review/opinions.

J.


On Tue, Sep 15, 2020 at 2:06 PM Jarek Potiuk  wrote:

> Cool. Thanks Bertrand - I am aware of some of those, but this list will be
> helpful so I can make some of the references to those in my proposal (and I
> encourage everyone else to do so). I am super-happy to merge yours with
> mine. I believe the "spirit" of those is rather similar. I am fully aware
> legal review should be done - I want now to get some initial feedback and
> see what controversies the proposal raises and polish it a bit, but I 100%
> understand the policies are binding for the ASF and the risk and legal side
> of it should be very carefully considered.
>
> Note - I just run through a few of the comments we have there and just for
> the sake of keeping people informed on what has changed so far here are
> some "gists" of my changes comparing to the first draft:
>
> * there is an open question about the viability of putting all the
> instructions or scripts to build the binary dependencies into  released
> sources. Giving the example of OpenOffice, CouchDB and Erlang which makes
> it next to impossible to do. So I proposed to explicitly say that any form
> of the instructions: scripts, manual instruction or POINTERS to the right
> instructions is fine. Simple HTTP link where you can find how to build an
> external OSS library should be perfectly fine. My ultimate goal is that
> whatever whenever the source .tar.gz package is created - the goal is that
> the user can get the sources and following the instructions (including the
> links to instructions) can - potentially rebuild the software legally. It
> might be a complex and recursive process (build a library to build a
> library) and at times those instructions might not work (as it is with all
> the instructions) but at least an attempt should be made to make it
> possible.
>
> * The "official" 3rd-party binary package is not a good name - I replaced
> it for now with the "maintained OSS" binary package. The idea behind it is
> that shortly - it should be open-source and it should be maintained. So
> while the name does not reflect all the subtleties of "maintained" and
> "OSS" but it reflects the spirit. I tried to make the "recursive"
> definition as much relaxed as possible (in terms of SHOULD vs. MUST except
> with the Licencing which is a MUST)
>
> * In pretty much all cases where I write about "best practices", they are
> not absolute requirements - so whenever possible they are SHOULD instead of
> MUST. I am very far from imposing all the best practices on all ASF
> projects - that will be impractical and stupid thing to do. I really treat
> those "best practices" as "beacons" - targets that we can have in mind but
> might never fully achieve them. And as long as we have good reason, not to
> follow those practices - by all means we do not have to. But if easy and
> possible, I see the best practices as a powerful message that improves the
> "Brand" of ASF in general from the user perspective. There are no "bonus
> points" for projects that follow it vs. those which decided not to in
> particular cases. But having those as "targets" for ASF projects is an
> important message.
>
> J,
>
>
>
> On Tue, Sep 15, 2020 at 12:25 PM Bertrand Delacretaz <
> bdelacre...@apache.org> wrote:
>
>> Hi,
>>
>> On Mon, Sep 7, 2020 at 10:24 AM Bertrand Delacretaz
>>  wrote:
>> ...
>> > ...* https://issues.apache.org/jira/browse/ASFP-23 (accessible to ASF
>> > Members) has links to related discussions...
>>
>> For the benefit of people who don't have access to that ticket, here's
>> a list of links that are public and can help inform this discussion.
>>
>> -
>> https://cwiki.apache.org/confluence/display/INCUBATOR/Distribution+Guidelines
>> mentions Maven, GitHub, Docker and other similar distribution
>> channels. The topic was discussed several times in the Incubator,
>> including
>>
>> https://lists.apache.org/thread.html/f614a20f82b010d152ce3871165841810c0db6c4de9d8a27e78b71d6@%3Clegal-discuss.apache.org%3E
>>
>> - LEGAL- tickets, https://issues.apache.org/jira/browse/LEGAL-270 ,
>> https://issues.apache.org/ji