Hi all, The PR has merged, and the https://github.com/apache/pulsar/wiki link has been updated. If you have any good ideas to improve the release process and release validation documents. You can push a PR directly.
Best, Penghui On Fri, Aug 19, 2022 at 2:18 PM PengHui Li <peng...@apache.org> wrote: > The PR to move the release-related documentation to the codebase. > https://github.com/apache/pulsar/pull/17176 > > After the PR gets merged, I will update the > https://github.com/apache/pulsar/wiki > to link to the doc in the codebase. > > Thanks, > Penghui > > On Tue, Aug 16, 2022 at 11:42 AM Haiting Jiang <jianghait...@gmail.com> > wrote: > >> Hi Dave, >> >> > Just remove that command. Having two servers should be enough. >> >> Agree, I have removed it. >> >> > Release candidates should not be made by a bot. Releases must be >> verified >> by building them from source. See >> https://www.apache.org/legal/release-policy.html#owned-controlled-hardware >> >> Thanks for the explanation. I get it now. It's mostly because we can only >> sign the artifacts locally. >> Apart from that, I think we can make other procedures more automatic and >> more lightweight. >> For example, currently we upload `pulsar-2.7.5-source-release.zip` [1] >> (the >> size is 6.23 GB) to maven >> repository. I am not sure if it's necessary to upload this artifact. >> >> Anyway, IMO, we need to provide a more clear and convenient way to >> optimize >> the releasing procedure. >> And moving the docs to codebase seems to be a good starting point. >> >> [1] >> >> https://repository.apache.org/service/local/repositories/orgapachepulsar-1171/content/org/apache/pulsar/pulsar/2.7.5/pulsar-2.7.5-source-release.zip >> >> Thanks, >> Haiting >> >> On Mon, Aug 15, 2022 at 10:45 PM Dave Fisher <w...@apache.org> wrote: >> >> > >> > >> > > On Aug 15, 2022, at 3:30 AM, Haiting Jiang <jianghait...@gmail.com> >> > wrote: >> > > >> > >> Maybe we'd better move the release process doc and validation doc >> > >> to the codebase, not the wiki pages. >> > > >> > > IMO, we can move all contributor documentation and committers >> > documentation >> > > to codebase. >> > > One example is that `pool.sks-keyservers.net` in [1] seems not >> available >> > > anymore, but I am not that confident enough to edit it directly. >> > >> > Just remove that command. Having two servers should be enough. >> > >> > > >> > >> And another point is can we have an automatic validation program to >> > reduce >> > >> the burden on validators? >> > > >> > > I am in favour of this idea. At least some of the validations can be >> done >> > > automatically, like checking GPG signatures. >> > > Or we can just run some part of the integration CI process on the >> release >> > > artifacts. >> > >> > The checksum checking burden is an intentional part of the release >> > process. That said I often use a verification shell script. >> > >> > #!/bin/bash >> > >> > export DISTURL='https://dist.apache.org/repos/dist/dev' >> > export PROJECT=${1} >> > export ARTIFACT=${2} >> > export DISTRO=${DISTURL}/${PROJECT}/${ARTIFACT} >> > >> > echo ${DISTRO} >> > >> > export TMPDIR=/tmp/${PROJECT} >> > >> > mkdir -p $TMPDIR >> > cd $TMPDIR >> > pwd >> > >> > curl -f -L ${DISTRO} --output ${ARTIFACT} >> > curl -f -L ${DISTRO}.asc --output ${ARTIFACT}.asc >> > curl -f -L ${DISTRO}.sha256 --output ${ARTIFACT}.sha256 >> > curl -f -L ${DISTRO}.sha512 --output ${ARTIFACT}.sha512 >> > >> > echo 'Check signature' >> > gpg --verify ${ARTIFACT}.asc >> > echo 'Compare checksum to sha256' >> > cat ${ARTIFACT}.sha256 >> > shasum -a 256 ${ARTIFACT} >> > echo 'Compare checksum to sha512' >> > cat ${ARTIFACT}.sha512 >> > shasum -a 512 ${ARTIFACT} >> > echo >> > >> > >> > > >> > > And furthermore, I think we can consider using a BOT (like Github >> Action) >> > > to make the release candidates. >> > > The following release steps require quite a lot of time and a stable >> > > network. >> > > - 3.1 Build RPM and DEB packages >> > >> > These are considered to be convenience binaries. Only the RM is required >> > to build them. It’s extra and appreciated if they are built and >> reviewed by >> > others in the VOTE. Should the project attempt to start producing >> > repeatable builds then we can also verify. >> > >> > > - 4. Sign and stage the artifacts >> > >> > It needs to be a manual script, but that is not too different from a >> > checker script. >> > >> > > - 5. Stage artifacts in maven >> > > I believe once we make the release process easier, our future version >> > > releases will be on time more often. >> > >> > The most important part of the release is the source release and this >> > should be the focus during a VOTE. >> > >> > Perhaps we need a more nuanced VOTE email. Here is an example from >> Apache >> > OpenOffice where there are some 240 artifacts in a release Source + (4 >> > linux builds + 1 macOS build + 1 windows build) * 41 languages. >> > >> > ——— >> > >> > I am calling a VOTE on releasing the source and complimentary community >> > builds of >> > Apache OpenOffice 4.1.13-RC1 as GA. >> > >> > These artifacts can be found at: >> > >> > https://dist.apache.org/repos/dist/dev/openoffice/4.1.13-RC1/ >> > >> > Please cast your vote: >> > >> > The Release Candidate is good for production/GA: >> > >> > [ ] yes / +1 >> > >> > [ ] no / -1 >> > >> > My vote is based on >> > >> > [ ] binding (member of PMC) >> > >> > [ ] I have built and tested the RC from source on platform [ ] >> > >> > [ ] I have tested the binary RC on platform [ ] >> > >> > This vote will be open for 7 days to allow for sufficient time >> > for testing, review, and voting. >> > >> > —— >> > >> > Best Regards, >> > Dave >> > >> > > >> > > [1] >> > > >> > >> https://github.com/apache/pulsar/wiki/Create-GPG-keys-to-sign-release-artifacts >> > > >> > > BR, >> > > Haiting >> > > >> > > On Fri, Aug 12, 2022 at 6:12 PM PengHui Li <peng...@apache.org> >> wrote: >> > > >> > >> Thanks for raising this question. >> > >> >> > >> Maybe we'd better move the release process doc and validation doc >> > >> to the codebase, not the wiki pages. >> > >> >> > >> - Only committers can update the wiki pages >> > >> - The changes without review >> > >> >> > >> After moving to the pulsar codebase >> > >> >> > >> - Everyone can contribute to the validation doc >> > >> - The release process doc update can get reviewers to review >> > >> >> > >> I think there are multiple issues that need to be resolved for the >> > release >> > >> process >> > >> >> > >> - Have the Python client(Linux, osx) at the RC stage, I think >> currently >> > we >> > >> only have the C++ client for RC, but push to pypi after the RC gets >> > passed >> > >> - Add validation process for the Python and C++ client >> > >> - Add the Go function and Python function validation process >> > >> - Add a script for building images for RC >> > >> - Add images validation process >> > >> >> > >> And another point is can we have an automatic validation program to >> > reduce >> > >> the burden on validators? >> > >> I'm not sure if it is acceptable. >> > >> >> > >> Thanks, >> > >> Penghui >> > >> >> > >> On Fri, Aug 12, 2022 at 4:50 PM Haiting Jiang < >> jianghait...@gmail.com> >> > >> wrote: >> > >> >> > >>>> the 7th step is "Write release notes", should we execute this >> > >>>> step later? >> > >>> >> > >>> From what I see, the release note can be postponed after the voting >> > >>> process. >> > >>> And it's not part of the voting content and does not affect whether >> we >> > >>> should cut a new release candidate. >> > >>> >> > >>>> In addition, I found the previous candidate [2] includes the docker >> > >>>> images, which is not included in the template of the 8th step "Run >> the >> > >>>> vote". It seems to be the 10th step "Publish Docker Images". >> > >>> >> > >>> Confused +1, If we do add docker image as part of release vote, we >> > should >> > >>> also add validation method in [1] >> > >>> >> > >>> [1] >> https://github.com/apache/pulsar/wiki/Release-Candidate-Validation >> > >>> >> > >>> Thanks, >> > >>> Haiting >> > >>> >> > >>> On Thu, Aug 11, 2022 at 9:49 PM Yunze Xu >> <y...@streamnative.io.invalid >> > > >> > >>> wrote: >> > >>> >> > >>>> Hi all, >> > >>>> >> > >>>> Recently I'm working on the release of 2.8.4 and it's near the >> vote of >> > >>>> the 1st candidate but I have some questions. >> > >>>> >> > >>>> From the tutorial [1] we can see, the 8th step is "Run the vote". >> > >>>> However, the 7th step is "Write release notes", should we execute >> this >> > >>>> step later? I see the 16th step is also "Write release notes" but >> the >> > >>>> 16th step at the beginning of "Release workflow" section is "Update >> > >>>> the site". >> > >>>> >> > >>>> In addition, I found the previous candidate [2] includes the docker >> > >>>> images, which is not included in the template of the 8th step "Run >> the >> > >>>> vote". It seems to be the 10th step "Publish Docker Images". >> > >>>> >> > >>>> It seems that the documents are not maintained well, which really >> > >>>> makes me confused. Therefore, before voting for the 1st candidate, >> I >> > >>>> want to get some clarifications from the mail list. >> > >>>> >> > >>>> [1] https://github.com/apache/pulsar/wiki/Release-process >> > >>>> [2] >> https://lists.apache.org/thread/q0g5ko617rb77b1wqpxy94ks5mq48d88 >> > >>>> >> > >>>> >> > >>>> Thanks, >> > >>>> Yunze >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>>> >> > >>> >> > >> >> > >> > >> >
