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