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
