Thanks Weiwei and Wilfred. +0 on this approach. I am overall feeling fine with the approach suggested. However I may have personally prefer to do this in a create-release.sh and Dockerfile like hadoop model.
As Weiwei pointed out, its used in Opwnwhisk pjct as well, may be we can try this out and find the positiveness. I think, we should make the scripts or configs in this repo more dynamic in nature agnostic to any release version. RM can supply this version etc as a run time param to these scripts. Thanks Sunil On Tue, Apr 14, 2020 at 12:26 PM Weiwei Yang <[email protected]> wrote: > Hi Wilfred > > Thanks for the feedback. > > The reason to introduce a new repo is to have some tools/docs easier for > release managers. I found this is a good practice when you have multiple > repos. Please see Apache OpenWhisk as an example. > > If you look at the config file I shared, that helps to track source code > revision of different repos, which is easy to assemble a release. > > I propose to do unified release, which means we alway release all repos > together. This is simpler to manage. > > If you look at the archive file, I should have put a script and a README > about how to build docker images. Can you please take a look at that? If > that is not there, pls see the script on github. > > Thanks for verifying the content. Could you please let me know what files > are wrong? > > > > -- > Weiwei > On Apr 13, 2020, 11:30 PM -0700, Wilfred Spiegelenburg < > [email protected]>, wrote: > > Hi Weiwei, > > > > Do we really need another repo for three files? > > We should sleep track of this in the core repo not in another repo which > we > > need to release manage again. I think managing the release from the core > > repo will make it easier later on if we need to or want to change the > build > > process further. Now we need need to manage and track soo many repos that > > it becomes more and more difficult. > > We also need to keep in mind that version information is in the module > > files. There might thus be more that needs to change for a release. The > > other thing is that we might not want to release a new version of one of > > the components while updating another component. That would means that we > > need to release manage 5 repositories for one release, including all the > > overhead. > > > > Apache releases are source releases. We still need to provide some kind > of > > make etc over the source code also. I agree with the fact that we need to > > provide one source archive that is signed. However with the current build > > process just the k8shim code is enough to build the docker image. The > other > > code repos will be pulled in from github. The mod file point there for > all > > go dependencies including the core and SI. It does not provide any detail > > on the how and what for any of the repos. We need to provide some build > > instructions in the root of the source archive. I would not know how to > > build from the source package if we just add the checked out code into > it. > > We need to provide some steps even if they are just pointers to existing > > docs. > > I also don't think we have the correct files in the archive with the > > current generated archive. > > > > Wilfred > > > > > > > On Mon, 13 Apr 2020 at 14:01, Weiwei Yang <[email protected]> wrote: > > > > > For 0.8 release, I did some work and I wanted to share the latest > status. I > > > think we should target for *docker-image-based* release mode. I > propose to > > > release a unified open-source tarball, we don't release a binary > tarball > > > (not a must [1]). Things have been *DONE*: > > > > > > 1. I have created a repo for release mgmt: > > > https://github.com/yangwwei/yunikorn-release, I think we need to move > > > this to apache repo too. > > > > > 2. This repo has the instructions and tools for a release. The tool > > > loads configs from > > > > > > > https://github.com/yangwwei/yunikorn-release/blob/master/tools/release-configs.json > > > and > > > downloads source code from certain repo/branch/hash to assemble the > > > release > > > artifacts > > > > 3. This repo contains a *build-docker-image.sh* to build yunikorn docker > > > images (scheduler, admission-controller, and web) > > > 4. I have created *branch-0.8* for all 4 repos > > > 5. The generated tarball will also have the helm chart for user to > > > install and run yunikorn on an existing K8s cluster > > > 6. I tried to generate PGP key and sign the tarball > > > > > > Things *TODO* > > > > > > 1. Create a repo for yunikorn-release under ASF > > > 2. IIUC, https://issues.apache.org/jira/browse/YUNIKORN-79 is a > blocker > > > for 0.8. Can we get this fixed ASAP? > > > 3. Once #2 is done, create a tag for 0.8-rc1 and start the voting > thread > > > > > > Thanks! > > > > > > [1] https://infra.apache.org/release-publishing.html *The Apache > Software > > > Foundation exists to create open source software, so the fundamental > > > requirement for a release is that it has the necessary source code to > build > > > the project. A project may provide compiled binaries of each release > for > > > the convenience of users.* > > > >
