Hi Nicola, +1 to cut the camel-k release once to simplify the release process. I think we could create an internal account in the docker hub for the staging release and publish the snapshot version for internal validation. Once we have the official source release, we could push the voted staging image into Apache docker repo as the final release process.
For the Github release page, it could be better to have one entry (Apache official link) for the user to download. In this way the user could not be confused to find out which binary is the best one. Regards, Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, May 17, 2019 at 6:55 AM Nicola Ferraro <ni.ferr...@gmail.com> wrote: > > Thanks Willem for taking time for looking into this issue. > > For staging the binary files, I think it's ok to follow the ServiceComb > approach (I assume that the /dev path is for dev builds only and cannot be > mistaken for the official release path). > Also point 3 can be addressed. I hope we can do it with the new website, > that I'd like to see online soon. > > But I think we have a problem with docker images. In other projects, docker > images are a different way of packaging the binaries, but camel k is a > cloud platform and cannot be run without the docker images. > This means that if we don't publish the docker images, we're not able to > test the software before the vote. > > So we are asked to release docker images after voting, but cannot vote > without them. It's a kind of chicken and eggs problem. > > On the other side. For camel k, users are not expected to look into docker > hub to find the software, i.e. we're not using docker hub as a portal to > distribute the software to our users. The primary way to install the > software is through the 'kamel' CLI, that pulls the docker image on the > cloud system, under the hood. So there's no way a user can mistakenly take > a docker image for an official release and use it (that was the main > concern of the legal discussion you've linked). Same holds also for > snapshots. > > For us, Docker Hub is not a distribution channel, it's a delivery network > used internally by the software. > If you agree on this, we have good chances to convince the legal team. > > Continuing this thread, I'd like to simplify a bit the release process, to > avoid having two votes for runtime and go binaries, because Camel k is a > single project, even if split into two repos. > I think it makes sense NOT to vote for camel-k-runtime. If we need to > release a new camel-k-runtime version, we can do it when we're ready to cut > a full camel-k release. In this case we stage the camel-k-runtime plus the > go binaries and docker images (...) and ask for a combined vote. > There can be cases where we won't need to release a new runtime but only a > new version of the binaries and related docker images. In such cases, we'll > vote only for the camel-k go stuff. > > As last step, I'd like to keep the release page on GitHub as additional > downstream convenience distribution channel. It seems allowed by legal, as > long as it's used as additional distribution channel and does not replace > the main one. > > What do you think? > > Nicola > > > Il gio 16 mag 2019, 02:14 Willem Jiang <willem.ji...@gmail.com> ha scritto: > > > For the go artifacts(source and binary) we can put them into [1]. > > Current ServiceComb service-center is using [2] as the staging repo. > > I found camel-k already use publish the dock image here[3], but > > according to [4], we cannot use this repo to distribute SNAPSHOT > > version. > > > > So I think the missing parts of current camel-k release are > > 1. We need to stage go artifacts and vote of them. > > 2. Publish the artifacts if the vote is passed. > > 3. Updating the Apache Camel website for the downloading of the artifacts. > > 4. Push the convicen binary docker image which is based on the > > official release. > > > > FYI, there are some discussion[5] in the Zipkin about the release > > which we take as a reference. > > > > [1]https://dist.apache.org/repos/dist/dev/camel/camel-k > > [2] > > https://dist.apache.org/repos/dist/dev/servicecomb/servicecomb-service-center/ > > [3]https://hub.docker.com/r/apache/camel-k > > [4]https://issues.apache.org/jira/browse/INFRA-12659 > > [5]https://github.com/apache/incubator-zipkin/issues/2597 > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Sat, May 4, 2019 at 3:46 PM Nicola Ferraro <ni.ferr...@gmail.com> > > wrote: > > > > > > Yes, released go binaries are still unofficial dev builds. We should > > find a > > > way to complete the release process. > > > There are many points that we need to cover, including signing and > > > distributing binaries but also the docker images. Iirc docker hub is not > > an > > > officially recognized system for distributing resources. > > > > > > But I agree we should standardize the process, otherwise we cannot even > > do > > > official announcements and people won't know about them. > > > > > > Nicola > > > > > > > > > > > > Il sab 4 mag 2019, 09:07 Andrea Cosentino <anco...@gmail.com> ha > > scritto: > > > > > > > Ok. Lets synch with others and we can write up a release process for > > that > > > > > > > > Il sab 4 mag 2019, 08:56 Willem Jiang <willem.ji...@gmail.com> ha > > scritto: > > > > > > > > > We could use the https://dist.apache.org/repos/dist/dev as a > > staging > > > > > repo to host the artifacts which need to be voted. > > > > > > > > > > Willem Jiang > > > > > > > > > > Twitter: willemjiang > > > > > Weibo: 姜宁willem > > > > > > > > > > On Sat, May 4, 2019 at 2:11 PM Andrea Cosentino <anco...@gmail.com> > > > > wrote: > > > > > > > > > > > > We can add a goal to push the binary generated on dist. But all the > > > > stuff > > > > > > generated is just go binaries and docker images. It's not like a > > normal > > > > > > Java project. > > > > > > > > > > > > Lets wait for Nicola and Luca about this. > > > > > > > > > > > > Il sab 4 mag 2019, 03:41 Willem Jiang <willem.ji...@gmail.com> ha > > > > > scritto: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I just found there are release in the github of camel-k 0.3.3 > > > > > > > recently. I can only find the vote of camel-k runtime 0.3.3. > > From my > > > > > > > understanding camel-k is dependent on camel-k runtime, but they > > are > > > > > > > two different projects. As the official Apache release, we need > > the > > > > > > > vote of PMC[1] > > > > > > > According to the release distribution guild of ASF[2]. > > > > > > > "The Apache infrastructure must be the primary source for all > > > > > > > artifacts officially released by the ASF." We need to put the > > > > > > > artifacts of camel-k into the > > https://dist.apache.org/repos/dist/. > > > > > > > > > > > > > > Please let me know if I missed something. > > > > > > > > > > > > > > [1]http://www.apache.org/dev/release-publishing.html#goal > > > > > > > [2] > > http://www.apache.org/dev/release-publishing.html#distribution > > > > > > > > > > > > > > Willem Jiang > > > > > > > > > > > > > > Twitter: willemjiang > > > > > > > Weibo: 姜宁willem > > > > > > > > > > > > > > > > > >
