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 > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > >
