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
