Hi Niclas, I am glad to hear that the term "Convenience Binaries" is under review.
Few things we were not clear or have some difference of opinion are: 1) Licensing a) Should we check all the binaries used in Dockerfiles for license-compliance? b) For Dockerfiles used in Helm Chart, is checking License for Dockerfiles enough, or should we also check the licenses of the binaries used by the Dockerfiles, how deep should we go? i.e Is checking the license of the Dockerfile enough or not c) If the answer for (b) is Yes, should we also then start thinking about checking license for the dependencies of our python dependencies that we use in our main project or trust the direct dependency? 2) Re-buildability (Sources) a) If a binary used in our Dockerfile or the external Dokcerfile used in our Helm Chart is built of another Open Source project that has their source code open with correct licenses and if instructions to rebuild are provided on their project, is that sufficient? Or do we need to provide helper scripts to our user to rebuild it the dependency of our dependency? Some of the points I mentioned above are still discussed in one of the threads in [email protected] but please let us know if something has already been decided on ASF level or else like Jarek said we would happy to discuss in-depth to sort this out on the org level. Regards, Kaxil On Wed, Sep 9, 2020 at 11:40 AM Ash Berlin-Taylor <[email protected]> wrote: > Jarek, you might want to check out https://reproducible-builds.org/ -- > it's come out of Debian with the aim to try and make binary builds of > .deb/software installed via .deb binary reproducible. > > I think you have less strict goals in mind than bit-for-bit identical > rebuilds of docker images? If so probably worth highlighting that as a > "non-goal" of your propsal (assuming it is a non-goal?) > > -a > > On Sep 9 2020, at 11:35 am, Jarek Potiuk <[email protected]> wrote: > > > Hello Niclas, > > > > Thanks for that. > > > > I feel that this guidance already answers most of my questions. > > > > I volunteered to lead proposal discussion and preparation for the ASF > Board > > on this subject (and I am sure other PMCs from Airflow will also be > engaged > > a lot, so I hope we can work out some reasonable policies on that. I hope > > to have the first draft proposal for discussion this week. I also invited > > Apache Security team members who are already commenting on that > > thread, as > > I think those policies should at least provide guidance on all those > > topics: licensing, security, stability, and "rebuildability" (for the > lack > > of a better term). Those are IMHO super important if we want to > > address the > > needs of corporate users especially (looking at the requirements of the > > corporates we are working with). > > > > J > > > > > > On Wed, Sep 9, 2020 at 8:38 AM Niclas Hedhman <[email protected]> wrote: > > > >> Hi everyone, > >> > >> The report submitted to the September Board meeting is requesting > guidance > >> on binary releases, such as Docker and Helm. I act as the board's > shepherd > >> of Airflow, and here to help if needed. > >> > >> First of all, Apache Software Foundation releases Open SOURCE > >> software, and > >> the source release is always the primary one. There are many reasons for > >> this, such as security (one can know for sure what it contains), > >> jurisprudence (trace origin,++) and usability on platforms that the > >> community may not provide binaries for. > >> > >> Many communities provides additional binary releases, that has been > called > >> "Convenience Binaries", but the term is under review/reconsideration as > >> they are for some communities (say, OpenOffice) the primary > >> artifacts for > >> the majority of users (OpenOffice users are typically not > >> developers). The > >> exact policies around this are being reviewed and worked on at the > moment. > >> Things like credentials to DockerHub or npm are for instance of > >> concern, as > >> well as the long-term stability of some of these distribution systems. > >> > >> That said; in general, as long as the binaries are buildable (with > >> instructions) and the product can be built and used without reliance on > >> such external systems, then it is mostly OK and it is up to each > community > >> to decide if binaries are provided and how. If there are specific > questions > >> on release policy or special requests, then contact the > >> Infrastructure team > >> and ask if it is Ok with them. If there are more general > >> thoughts/feedback/discussion items in this space, ComDev is the place to > >> approach. > >> > >> I will also try to do my best to answer questions here... > >> > >> Niclas Hedhman > >> > > > > > > -- > > > > Jarek Potiuk > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > M: +48 660 796 129 <+48660796129> > > [image: Polidea] <https://www.polidea.com/> > > >
