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 <ja...@potiuk.com> 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 <w...@apache.org> 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 <ja...@potiuk.com> 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 <ja...@potiuk.com> 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 >>>>> <bdelacre...@apache.org> 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/jira/browse/LEGAL-427 , >>>>> https://issues.apache.org/jira/browse/LEGAL-323 (linked to a number of >>>>> others), more? >>>>> >>>>> - Reproducible builds (https://reproducible-builds.org/ , >>>>> http://maven.apache.org/guides/mini/guide-reproducible-builds.html ) >>>>> are also a way to improve trust in binaries. >>>>> >>>>> I also made a proposal a while ago about how we might handle these >> things: >>>>> >>>>> *** DRAFT TENTATIVE PROPOSAL ON HOW WE MIGHT EXPLAIN DISTRIBUTIONS **** >>>>> -ASF Releases consist of source code only >>>>> >>>>> -As a convenience, our PMCs often distribute binary packages along >>>>> with these releases, as attachments which are not considered part of >>>>> the release >>>>> >>>>> -We recommend that people build their own binaries from released code, >>>>> but it's a reality that many of them use the binaries that we >>>>> distribute >>>>> >>>>> -The only things we state about these binaries are that the PMC which >>>>> creates them believes they are the correct ones (with no guarantees) >>>>> and that the digests that we distribute are correct >>>>> >>>>> -Those digests are mentioned in the PMC approval votes for these >>>>> binaries, to allow people to look them up if desired >>>>> >>>>> -We strongly encourage our PMCs to produce reproducible builds as per >>>>> https://reproducible-builds.org/ >>>>> *** DRAFT TENTATIVE PROPOSAL ON HOW WE MIGHT EXPLAIN DISTRIBUTIONS **** >>>>> >>>>> I haven't found time to pursue it so far, and it might not be >>>>> implementable as is but hopefully it helps this discussion. >>>>> >>>>> If a draft policy is created based on that and/or Jarek's current >>>>> proposal, legal review will be needed before the ASF can activate it. >>>>> >>>>> -Bertrand >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >>>>> For additional commands, e-mail: dev-h...@community.apache.org >>>>> >>>>> >>>> >>>> -- >>>> +48 660 796 129 >>>> >>> >>> >>> -- >>> +48 660 796 129 >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >> For additional commands, e-mail: dev-h...@community.apache.org >> >> > > -- > +48 660 796 129 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
