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 <wilfr...@apache.org>, 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 <w...@apache.org> 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.* > >
