You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Niclas Hedhman <ni...@apache.org> on 2020/09/09 06:38:24 UTC
Docker/Helm releases
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
Re: Docker/Helm releases
Posted by Jarek Potiuk <Ja...@polidea.com>.
Thanks! A really useful one.
It's definitely not about bit-by-bit reproducibility. That also came
in our discussion about images with the Apache Security team. I am
much more advocate of what we currently have in our Production images
- they are designed in the way that you should be able to have the
"buildable" at any time and you should get the results that you want
but they might be rather different depending on when you are running
them (but they should be pretty much guaranteed to work whether you
run them now or in 4 months). But if you build it 4 months from now,
the result should include all (or rather all possible) security fixes
that were released between now and then.
Our image building process works exactly this way. It took quite some
time and effort (especially because of our dependency management "we
are both application and library"). But those properties below always
were - my goal from the beginning of designing the process. And quite
recently we finally got where I wanted it to be.
For example, the current image when you build it using 1.10.12 tag
and Breeze - following the instructions from IMAGES.rst), it will
(automatically):
* take as a base latest released debian-buster-pyhon image (LTS
support - will be supported till 2022 or even 2024).
* install latest versions of all apt dependencies that are available
for that release
* install latest versions of PIP packages that we tested
(automatically) in 1.10.10 branch (we automatically bump up
constraints in our repo when all the tests pass after pushing to
v1-10-stable branch)
All this is automatically tested - so latest base image + latest apt
deps + latest PIP packages are automatically tested and are only
"blessed" once all tests pass for them. Thanks to that we know, that
when user tries to build the same image at any time (following the
--constraint mechanism) - it will work. And we give instructions to
the user how to do it.
This is what I mean by "rebuildability".
J.
On Wed, Sep 9, 2020 at 12:40 PM Ash Berlin-Taylor <as...@apache.org> 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 <Ja...@polidea.com> 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 <ni...@apache.org> 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/>
> >
--
Jarek Potiuk
Polidea | Principal Software Engineer
M: +48 660 796 129
Re: Docker/Helm releases
Posted by Kaxil Naik <ka...@gmail.com>.
Thanks for your thoughtful reply. It clarifies few things but we will also
definitely wait until the lines/rules are more clearer and we (Airflow PMC)
would be very happy to help shape the rules if needed.
On Wed, Sep 9, 2020, 13:26 Niclas Hedhman <ni...@apache.org> wrote:
> No changes have been decided on recently.
>
> If you have external dependencies that can be viewed as System
> Requirements, then you don't need to provide your own build instructions.
> Think; "Windows is a (optional) System Requirement" and what is reasonable
> in that case.
>
> So Docker itself could be a System Requirement for some deployment
> scenarios, but it is not unreasonable to say that some other external
> system is required to be present. I am ignorant of what Helm is and can't
> provide a definite answer.
>
> The licensing issue itself; for projects that are well established, you
> can assume that they have their licensing in order. So if they say "MIT"
> you should assume that their project complies and doesn't have GPL as a
> dependency. For "private persons" the situation is quite often very
> different. Most people don't care, and mix-n-match in incompatible ways. So
> some extra digging should be done when depending on such projects.
>
> You should check sources, provide links to how those are built to binaries
> and then assume the built binaries (docker images) correspond to the
> sources.
>
> Not answers on specific questions, because I don't have enough insight in
> details.
>
> HTH
> Niclas
>
> On Wed, Sep 9, 2020, 12:57 Kaxil Naik <ka...@gmail.com> wrote:
>
>> 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 dev@community.apache.org 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 <as...@apache.org> 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 <Ja...@polidea.com>
>>> 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 <ni...@apache.org>
>>> 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/>
>>> >
>>>
>>
Re: Docker/Helm releases
Posted by Niclas Hedhman <ni...@apache.org>.
No changes have been decided on recently.
If you have external dependencies that can be viewed as System
Requirements, then you don't need to provide your own build instructions.
Think; "Windows is a (optional) System Requirement" and what is reasonable
in that case.
So Docker itself could be a System Requirement for some deployment
scenarios, but it is not unreasonable to say that some other external
system is required to be present. I am ignorant of what Helm is and can't
provide a definite answer.
The licensing issue itself; for projects that are well established, you can
assume that they have their licensing in order. So if they say "MIT" you
should assume that their project complies and doesn't have GPL as a
dependency. For "private persons" the situation is quite often very
different. Most people don't care, and mix-n-match in incompatible ways. So
some extra digging should be done when depending on such projects.
You should check sources, provide links to how those are built to binaries
and then assume the built binaries (docker images) correspond to the
sources.
Not answers on specific questions, because I don't have enough insight in
details.
HTH
Niclas
On Wed, Sep 9, 2020, 12:57 Kaxil Naik <ka...@gmail.com> wrote:
> 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 dev@community.apache.org 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 <as...@apache.org> 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 <Ja...@polidea.com>
>> 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 <ni...@apache.org>
>> 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/>
>> >
>>
>
Re: Docker/Helm releases
Posted by Kaxil Naik <ka...@gmail.com>.
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 dev@community.apache.org 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 <as...@apache.org> 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 <Ja...@polidea.com> 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 <ni...@apache.org> 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/>
> >
>
Re: Docker/Helm releases
Posted by Ash Berlin-Taylor <as...@apache.org>.
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 <Ja...@polidea.com> 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 <ni...@apache.org> 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/>
>
Re: Docker/Helm releases
Posted by Kaxil Naik <ka...@gmail.com>.
Thanks, will check it out this week.
On Wed, Sep 16, 2020, 14:11 Jarek Potiuk <Ja...@polidea.com> wrote:
> My proposal
>
> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
> have
> gone through the first round of comments and updates. I invite more voices
> to the discussion:
>
> https://lists.apache.org/thread.html/rcb608739206d788785081073a0deb417ffa9981634975fc5525dc769%40%3Cdev.community.apache.org%3E
>
> J.
>
> On Sun, Sep 13, 2020 at 3:46 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > Hello Everyone,
> >
> > As promised, I prepared a draft of the proposal of changes that I would
> > love if a number of interested people discuss it, comment, criticise,
> agree
> > on eventually, and submit to the ASF Board for Approval.
> >
> > I tried to capture all the context, but also I marked clearly all the
> > proposals that I think should be included in the ASF policies and clearly
> > marked changes that should be applied. I also tried to write it in the
> > "future-proof" way - I tried to make statements that do not refer to the
> > Images or Helm Charts, but describe general practices of "packaged"
> > software as opposed to "compiled" software that seems to be the origin of
> > the current policies. So my approach was really to try to describe and
> set
> > policies around "software packaging" in general, rather than "Images/Helm
> > Charts" in particular. However I believe it is much more to take the
> > proposed policies and apply them directly to the Images and Helm Charts
> > rather than the original policies.
> >
> > As promised I also commented (with inline comments), the places where I
> > know there are some controversies - at least those that came up in our
> > original discussions in Airflow - and I explained how I understand the
> > controversies that are around that.
> >
> > I would really love to get a lot of comments and discussion around the
> > proposal, before we submit the proposal - I am looking forward to your
> > comments!
> >
> > The proposal is here:
> >
> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
> >
> >
> > BTW. I really encourage everyone to use the "Inline comments" of CWiki
> > rather than commenting at the bottom (select paragraph, wait have a
> second
> > and click the resulting "comment" bubble). This makes it so much easier
> to
> > organise a discussion around certain part of the document.
> >
> > J,
> >
> >
> > On Thu, Sep 10, 2020 at 5:19 AM Daniel Imberman <
> daniel.imberman@gmail.com>
> > wrote:
> >
> >> Thank you Niclas, this will help us a lot in figuring out our helm
> >> situation
> >>
> >> via Newton Mail
> >> <
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.50&pv=10.15.6&source=email_footer_2
> >
> >>
> >> On Wed, Sep 9, 2020 at 5:36 AM, Kaxil Naik <ka...@gmail.com> wrote:
> >>
> >> Credits to Jarek on that one, he is the one who is actually drafting the
> >> proposal.
> >>
> >> On Wed, Sep 9, 2020, 13:31 Niclas Hedhman <ni...@apache.org> wrote:
> >>
> >> > Corporate requirements are typically that they can build everything
> from
> >> > sources and have clear instructions (preferably scriptable) on how to
> do
> >> > that.
> >> >
> >> > Good to hear that ComDev is in the loop and you are together working
> on
> >> > draft proposals. It will be greatly appreciated.
> >> >
> >> >
> >> > Niclas
> >> >
> >> >
> >> >
> >> > On Wed, Sep 9, 2020, 13:00 Jarek Potiuk <Ja...@polidea.com>
> >> wrote:
> >> >
> >> > > Added Niclas to my response :). Responding to devlist when someone
> >> from
> >> > > outside of it sends a message is tricky :)
> >> > >
> >> > > On Wed, Sep 9, 2020 at 12:35 PM Jarek Potiuk <
> >> Jarek.Potiuk@polidea.com>
> >> > > 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 <ni...@apache.org>
> >> > 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/>
> >> > >>
> >> > >>
> >> > >
> >> > > --
> >> > >
> >> > > Jarek Potiuk
> >> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >> > >
> >> > > M: +48 660 796 129 <+48660796129>
> >> > > [image: Polidea] <https://www.polidea.com/>
> >> > >
> >> > >
> >> >
> >>
> >>
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
> >
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>
Re: Docker/Helm releases
Posted by Jarek Potiuk <Ja...@polidea.com>.
My proposal
https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
have
gone through the first round of comments and updates. I invite more voices
to the discussion:
https://lists.apache.org/thread.html/rcb608739206d788785081073a0deb417ffa9981634975fc5525dc769%40%3Cdev.community.apache.org%3E
J.
On Sun, Sep 13, 2020 at 3:46 PM Jarek Potiuk <Ja...@polidea.com>
wrote:
> Hello Everyone,
>
> As promised, I prepared a draft of the proposal of changes that I would
> love if a number of interested people discuss it, comment, criticise, agree
> on eventually, and submit to the ASF Board for Approval.
>
> I tried to capture all the context, but also I marked clearly all the
> proposals that I think should be included in the ASF policies and clearly
> marked changes that should be applied. I also tried to write it in the
> "future-proof" way - I tried to make statements that do not refer to the
> Images or Helm Charts, but describe general practices of "packaged"
> software as opposed to "compiled" software that seems to be the origin of
> the current policies. So my approach was really to try to describe and set
> policies around "software packaging" in general, rather than "Images/Helm
> Charts" in particular. However I believe it is much more to take the
> proposed policies and apply them directly to the Images and Helm Charts
> rather than the original policies.
>
> As promised I also commented (with inline comments), the places where I
> know there are some controversies - at least those that came up in our
> original discussions in Airflow - and I explained how I understand the
> controversies that are around that.
>
> I would really love to get a lot of comments and discussion around the
> proposal, before we submit the proposal - I am looking forward to your
> comments!
>
> The proposal is here:
> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
>
>
> BTW. I really encourage everyone to use the "Inline comments" of CWiki
> rather than commenting at the bottom (select paragraph, wait have a second
> and click the resulting "comment" bubble). This makes it so much easier to
> organise a discussion around certain part of the document.
>
> J,
>
>
> On Thu, Sep 10, 2020 at 5:19 AM Daniel Imberman <da...@gmail.com>
> wrote:
>
>> Thank you Niclas, this will help us a lot in figuring out our helm
>> situation
>>
>> via Newton Mail
>> <https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.50&pv=10.15.6&source=email_footer_2>
>>
>> On Wed, Sep 9, 2020 at 5:36 AM, Kaxil Naik <ka...@gmail.com> wrote:
>>
>> Credits to Jarek on that one, he is the one who is actually drafting the
>> proposal.
>>
>> On Wed, Sep 9, 2020, 13:31 Niclas Hedhman <ni...@apache.org> wrote:
>>
>> > Corporate requirements are typically that they can build everything from
>> > sources and have clear instructions (preferably scriptable) on how to do
>> > that.
>> >
>> > Good to hear that ComDev is in the loop and you are together working on
>> > draft proposals. It will be greatly appreciated.
>> >
>> >
>> > Niclas
>> >
>> >
>> >
>> > On Wed, Sep 9, 2020, 13:00 Jarek Potiuk <Ja...@polidea.com>
>> wrote:
>> >
>> > > Added Niclas to my response :). Responding to devlist when someone
>> from
>> > > outside of it sends a message is tricky :)
>> > >
>> > > On Wed, Sep 9, 2020 at 12:35 PM Jarek Potiuk <
>> Jarek.Potiuk@polidea.com>
>> > > 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 <ni...@apache.org>
>> > 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/>
>> > >>
>> > >>
>> > >
>> > > --
>> > >
>> > > Jarek Potiuk
>> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
>> > >
>> > > M: +48 660 796 129 <+48660796129>
>> > > [image: Polidea] <https://www.polidea.com/>
>> > >
>> > >
>> >
>>
>>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>
>
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
Re: Docker/Helm releases
Posted by Jarek Potiuk <Ja...@polidea.com>.
Hello Everyone,
As promised, I prepared a draft of the proposal of changes that I would
love if a number of interested people discuss it, comment, criticise, agree
on eventually, and submit to the ASF Board for Approval.
I tried to capture all the context, but also I marked clearly all the
proposals that I think should be included in the ASF policies and clearly
marked changes that should be applied. I also tried to write it in the
"future-proof" way - I tried to make statements that do not refer to the
Images or Helm Charts, but describe general practices of "packaged"
software as opposed to "compiled" software that seems to be the origin of
the current policies. So my approach was really to try to describe and set
policies around "software packaging" in general, rather than "Images/Helm
Charts" in particular. However I believe it is much more to take the
proposed policies and apply them directly to the Images and Helm Charts
rather than the original policies.
As promised I also commented (with inline comments), the places where I
know there are some controversies - at least those that came up in our
original discussions in Airflow - and I explained how I understand the
controversies that are around that.
I would really love to get a lot of comments and discussion around the
proposal, before we submit the proposal - I am looking forward to your
comments!
The proposal is here:
https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
BTW. I really encourage everyone to use the "Inline comments" of CWiki
rather than commenting at the bottom (select paragraph, wait have a second
and click the resulting "comment" bubble). This makes it so much easier to
organise a discussion around certain part of the document.
J,
On Thu, Sep 10, 2020 at 5:19 AM Daniel Imberman <da...@gmail.com>
wrote:
> Thank you Niclas, this will help us a lot in figuring out our helm
> situation
>
> via Newton Mail
> <https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.50&pv=10.15.6&source=email_footer_2>
>
> On Wed, Sep 9, 2020 at 5:36 AM, Kaxil Naik <ka...@gmail.com> wrote:
>
> Credits to Jarek on that one, he is the one who is actually drafting the
> proposal.
>
> On Wed, Sep 9, 2020, 13:31 Niclas Hedhman <ni...@apache.org> wrote:
>
> > Corporate requirements are typically that they can build everything from
> > sources and have clear instructions (preferably scriptable) on how to do
> > that.
> >
> > Good to hear that ComDev is in the loop and you are together working on
> > draft proposals. It will be greatly appreciated.
> >
> >
> > Niclas
> >
> >
> >
> > On Wed, Sep 9, 2020, 13:00 Jarek Potiuk <Ja...@polidea.com>
> wrote:
> >
> > > Added Niclas to my response :). Responding to devlist when someone from
> > > outside of it sends a message is tricky :)
> > >
> > > On Wed, Sep 9, 2020 at 12:35 PM Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> > > 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 <ni...@apache.org>
> > 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/>
> > >>
> > >>
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48660796129>
> > > [image: Polidea] <https://www.polidea.com/>
> > >
> > >
> >
>
>
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
Re: Docker/Helm releases
Posted by Daniel Imberman <da...@gmail.com>.
Thank you Niclas, this will help us a lot in figuring out our helm
situation
via Newton Mail
[https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.50&pv=10.15.6&source=email_footer_2]
On Wed, Sep 9, 2020 at 5:36 AM, Kaxil Naik <ka...@gmail.com> wrote:
Credits to Jarek on that one, he is the one who is actually drafting the
proposal.
On Wed, Sep 9, 2020, 13:31 Niclas Hedhman <ni...@apache.org> wrote:
> Corporate requirements are typically that they can build everything from
> sources and have clear instructions (preferably scriptable) on how to do
> that.
>
> Good to hear that ComDev is in the loop and you are together working on
> draft proposals. It will be greatly appreciated.
>
>
> Niclas
>
>
>
> On Wed, Sep 9, 2020, 13:00 Jarek Potiuk <Ja...@polidea.com>
wrote:
>
> > Added Niclas to my response :). Responding to devlist when someone
from
> > outside of it sends a message is tricky :)
> >
> > On Wed, Sep 9, 2020 at 12:35 PM Jarek Potiuk
<Ja...@polidea.com>
> > 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 <ni...@apache.org>
> 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/>
> >>
> >>
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
> >
>
Re: Docker/Helm releases
Posted by Kaxil Naik <ka...@gmail.com>.
Credits to Jarek on that one, he is the one who is actually drafting the
proposal.
On Wed, Sep 9, 2020, 13:31 Niclas Hedhman <ni...@apache.org> wrote:
> Corporate requirements are typically that they can build everything from
> sources and have clear instructions (preferably scriptable) on how to do
> that.
>
> Good to hear that ComDev is in the loop and you are together working on
> draft proposals. It will be greatly appreciated.
>
>
> Niclas
>
>
>
> On Wed, Sep 9, 2020, 13:00 Jarek Potiuk <Ja...@polidea.com> wrote:
>
> > Added Niclas to my response :). Responding to devlist when someone from
> > outside of it sends a message is tricky :)
> >
> > On Wed, Sep 9, 2020 at 12:35 PM Jarek Potiuk <Ja...@polidea.com>
> > 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 <ni...@apache.org>
> 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/>
> >>
> >>
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
> >
>
Re: Docker/Helm releases
Posted by Niclas Hedhman <ni...@apache.org>.
Corporate requirements are typically that they can build everything from
sources and have clear instructions (preferably scriptable) on how to do
that.
Good to hear that ComDev is in the loop and you are together working on
draft proposals. It will be greatly appreciated.
Niclas
On Wed, Sep 9, 2020, 13:00 Jarek Potiuk <Ja...@polidea.com> wrote:
> Added Niclas to my response :). Responding to devlist when someone from
> outside of it sends a message is tricky :)
>
> On Wed, Sep 9, 2020 at 12:35 PM Jarek Potiuk <Ja...@polidea.com>
> 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 <ni...@apache.org> 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/>
>>
>>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>
>
Re: Docker/Helm releases
Posted by Jarek Potiuk <Ja...@polidea.com>.
Added Niclas to my response :). Responding to devlist when someone from
outside of it sends a message is tricky :)
On Wed, Sep 9, 2020 at 12:35 PM Jarek Potiuk <Ja...@polidea.com>
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 <ni...@apache.org> 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/>
>
>
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
Re: Docker/Helm releases
Posted by Jarek Potiuk <Ja...@polidea.com>.
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 <ni...@apache.org> 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/>