Personally I don't think having the two entries, one on Github and one in the Apache official link, will confuse the users, since the binaries are the same.
IMO, it's not a problem and it's allowed. +1 for having the github release page with the official link Il giorno ven 17 mag 2019 alle ore 02:44 Willem Jiang < [email protected]> ha scritto: > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > > > 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 <[email protected]> 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 <[email protected]> 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 < > [email protected]> > > > > > 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 <[email protected]> > 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 > > > > > > > > > > > > > > > > > > > > > > >
