Thanks Kaxil! I agree adding scripts should not be compulsory - I already changed it to "best practice" wherever I mentioned it. If you think even this is too much - I am happy to discuss :).
I think that really the definition of the packaging that would make it possible to legally comply with the requirements is the most important part of the proposal - all the rest is just clarification of intentions. For the rebuilds - I think the most important is the intention that the user SHOULD be able to rebuild it and should know how to do it. This is the only really important bit. Whether those are scripts or some other ways - it should be up to the project for sure. For many of those scripts or automation might simply be impossible. J. On Sun, Oct 18, 2020 at 6:34 PM Kaxil Naik <kaxiln...@gmail.com> wrote: > I have added comments on the proposed document. I don't think we should > make it compulsory to include scripts to rebuild binaries used in the > projects. It > is a maintenance nightmare. > > I agree though that we need a proper definition for the "convenience > packages" > and some guidelines around Docker Image and Helm Chart. > > Regards, > Kaxil > Apache Airflow PMC > > On Sun, Oct 18, 2020 at 3:14 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > @Matt Sicker <boa...@gmail.com> - absolutely, thanks for mentioning > that. > > My intention is to hash-out as many details as possible and get as much > > input as possible from relevant people to make a strong case to the > board. > > While I am not an ASF member myself, just a PMC, I watched some of the > > Apache Con talks and I understand that board operates in asynchronous > mode > > and that they should get an information that they could digest earlier, > > offline and make decisions quickly, so I want to make everything to make > it > > clear and straightforward and - possibly have a strong case, supported, > or > > at least with very limited number of strong "no" opinions, so I am still > in > > the phase of involving people and gathering feedback. > > > > @Justin - I read it and I think this is all really great. I think it > very > > nicely documents the current policies and beyond, there is only one thing > > in both - current release policies and the incubator distribution > > guidelines that are a bit contradictory and I hope part of my proposal > for > > policy update addresses. And I know it's the toughest one. > > It's about category X software inclusion in binary convenience packages. > As > > I see it is pretty much impossible not to include category X software in > a > > docker image. Since they are Linux-kernel based usually there are always > > some GPL licensed libraries included in those. > > > > While I perfectly understand that "COMPILED PACKAGES" should not contain > > Category X software, I think "Docker images" (and likely other binary > > distribution mechanisms - for example those that package software for > > installation on Windows/Mac workstation) can - and it should be allowed. > > Unfortunately according to the policies "Convenience binaries need to > > follow licensing policy and not include any category X licensed > software." > > > > So the really only thing I am looking for is to introduce a separate > > category for those different "packaging mechanism" and separate them out > > (and explicitly name as category). For now we either release "software" > or > > "convenience binaries". And docker images are neither. > > > > J, > > > > > > > > > > On Sun, Oct 18, 2020 at 3:14 AM Justin Mclean <jus...@classsoftware.com> > > wrote: > > > > > Hi, > > > > > > > I am not even sure myself if I am the only one who feels the > > > disconnection > > > > between reality and the current policies, that's why I started the > > thread > > > > here. > > > > > > You would not be the only person who set this. People and project are > > > making small steps to correct this. Recently Infra’s distribution > policy > > > was updated and the Incubator made these guidelines. [1] Note that > Infra > > do > > > support docker as a platform. > > > > > > Thanks, > > > Justin > > > > > > 1. https://incubator.apache.org/guides/distribution.html > > > --------------------------------------------------------------------- > > > 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
