You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Yunze Xu <yz...@streamnative.io.INVALID> on 2022/08/11 13:48:49 UTC
Questions about the release process
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
Re: Questions about the release process
Posted by Yunze Xu <yz...@streamnative.io.INVALID>.
I'm going to push the Docker images for the 1st candidate soon.
Unfortunately, when I followed the 10th step "Publish Docker Images",
I found the tag doesn't have the "-rc" suffix.
```bash
cd docker
./build.sh
DOCKER_USER=bewaremypower DOCKER_PASSWORD="<my-password>" DOCKER_ORG=bewaremypower ./publish.sh
```
I didn't have a deep look into the `build.sh` and `publish.sh`. But I
think we need to make it clear for release manager in the documents.
I'm strongly against asking many questions directly to previous
release managers. Unfortunately, I did in the passed few days. The
documents could, and should be better.
Anyway, I will open a VOTE soon.
Thanks,
Yunze
> 2022年8月11日 21:48，Yunze Xu <yz...@streamnative.io> 写道：
>
> 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
>
>
>
>
Re: Questions about the release process
Posted by Dave Fisher <wa...@apache.org>.
> On Aug 15, 2022, at 4:09 AM, Yunze Xu <yz...@streamnative.io.INVALID> wrote:
>
>> 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.
>
> Yeah. It’s not available in my env as well. I made some changes recently,
> but I’m also not sure about this point.
I think that key server has gone away. We will need to document alternatives.
>
>> I think we can consider using a BOT (like Github Action)
> to make the release candidates.
>
> +1. But maybe it’s not an easy job.
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
Best Regards,
Dave
>
> Thanks,
> Yunze
>
>
>
>
>> 2022年8月15日 18:30，Haiting Jiang <ji...@gmail.com> 写道：
>>
>> 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.
>
Re: Questions about the release process
Posted by Yunze Xu <yz...@streamnative.io.INVALID>.
> 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.
Yeah. It’s not available in my env as well. I made some changes recently,
but I’m also not sure about this point.
> I think we can consider using a BOT (like Github Action)
to make the release candidates.
+1. But maybe it’s not an easy job.
Thanks,
Yunze
> 2022年8月15日 18:30，Haiting Jiang <ji...@gmail.com> 写道：
>
> 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.
Re: Questions about the release process
Posted by PengHui Li <pe...@apache.org>.
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 <pe...@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 <ji...@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 <wa...@apache.org> wrote:
>>
>> >
>> >
>> > > On Aug 15, 2022, at 3:30 AM, Haiting Jiang <ji...@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 <pe...@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 <
>> jianghaiting@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
>> <yzxu@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
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>
>> > >>
>> >
>> >
>>
>
Re: Questions about the release process
Posted by PengHui Li <pe...@apache.org>.
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 <ji...@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 <wa...@apache.org> wrote:
>
> >
> >
> > > On Aug 15, 2022, at 3:30 AM, Haiting Jiang <ji...@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 <pe...@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 <jianghaiting@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
> <yzxu@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
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Questions about the release process
Posted by Haiting Jiang <ji...@gmail.com>.
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 <wa...@apache.org> wrote:
>
>
> > On Aug 15, 2022, at 3:30 AM, Haiting Jiang <ji...@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 <pe...@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 <ji...@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 <yzxu@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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
>
>
Re: Questions about the release process
Posted by Dave Fisher <wa...@apache.org>.
> On Aug 15, 2022, at 3:30 AM, Haiting Jiang <ji...@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 <pe...@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 <ji...@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 <yz...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
Re: Questions about the release process
Posted by Haiting Jiang <ji...@gmail.com>.
> 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.
> 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.
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
- 4. Sign and stage the artifacts
- 5. Stage artifacts in maven
I believe once we make the release process easier, our future version
releases will be on time more often.
[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 <pe...@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 <ji...@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 <yz...@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
> > >
> > >
> > >
> > >
> > >
> >
>
Re: Questions about the release process
Posted by Dave Fisher <wa...@comcast.net>.
Sent from my iPhone
> On Aug 13, 2022, at 9:35 PM, Michael Marshall <mm...@apache.org> wrote:
>
> Thanks for raising this Yunze. The docker image was added to the VOTE
> threads as a convenience for voters/testers. I don't believe we
> established a formal requirement for it, which might explain why it is
> not in the wiki. It should, however, be listed as an optional step if
> we want it to be one.
>
> I agree with putting the release process in the apache/pulsar git repo.
>
>> we do need to assure that the PMC fully reviews changes
>
> Currently, any committer has access to modify the release docs, so
> this introduces a new requirement. One way to enforce who reviews a PR
> is with a CODEOWNERS file. We could create a GitHub group with PMC
> members and then require that any PR that touches the release process
> documentation file is approved by a PMC member. I am not sure that
> this is the "right" direction though.
There is already a Pulsar PMC / private group in GitHub that is maintained by ASF infra. We would need to briefly discuss with them if we choose this approach
>
>> Do not make the release docs part of versioned docs.
>
> I agree.
>
> Thanks,
> Michael
>
>
>> On Fri, Aug 12, 2022 at 10:32 PM Yunze Xu <yz...@streamnative.io.invalid> wrote:
>>
>>> The RM should ask a PMC member to help them add their KEY.
>>> Do not make the release docs part of versioned docs.
>> I agree.
>>
>> Thanks,
>> Yunze
>>
>>
>>
>>
>>> 2022年8月12日 23:10，Dave Fisher <wa...@apache.org> 写道：
>>>
>>> Hi -
>>>
>>> One change that needs to be made is regarding the KEYS file.
>>>
>>> We should drop the use of https://dist.apache.org/repos/dist/dev/pulsar/KEYS instead we should carefully update https://dist.apache.org/repos/dist/release/pulsar/KEYS
>>>
>>> The two KEYS files are currently out of sync. The release file had to be hand reconstructed at the beginning of the year and I’ve had to deal with new Release Manager KEYS that were not copied during the Release Process. (Recently Apache Infra has been scanning release and is informing PMCs when their releases are broken.)
>>>
>>> The RM should ask a PMC member to help them add their KEY. I’m willing to do it and I’m certain other PMC members would do the same.
>>>
>>> The VOTE threads can then always refer to a proper KEYS file that will always be correct. RMs should also make sure that their KEY does not expire while the release is active which could be for several years. If your KEY is revoked at some point then please let the PMC know.
>>>
>>> I like moving the Release Docs to the codebase, but we do need to assure that the PMC fully reviews changes. The reviews that count before squash and merge must be from PMC members. The reason is that the Pulsar PMC is responsible for assuring that Pulsar releases comply with Apache Release Policies.
>>>
>>> Do not make the release docs part of versioned docs. There should be only the current policy. If other products of the Pulsar project require different release docs it is fine to have separate docs.
>>>
>>> All The Best,
>>> Dave
>>>
>>>> On Aug 12, 2022, at 7:41 AM, tison <wa...@gmail.com> wrote:
>>>>
>>>> Hi Penghui & Yunze,
>>>>
>>>> I ever wrote developer guides for TiDB[1] and Apache Kvrocks (Incubating),
>>>> including the release guide for the latter[2].
>>>>
>>>> Just for your information, I'm preparing the proposal to bring a developer
>>>> guide page (series docs). Perhaps start in the next month.
>>>>
>>>> Although, it cannot help the current status, and I don't want to discuss
>>>> details on this topic here. Again, just for your information :)
>>>>
>>>> Best,
>>>> tison.
>>>>
>>>> [1] https://pingcap.github.io/tidb-dev-guide/
>>>> [2] https://kvrocks.apache.org/community/how-to-release
>>>>
>>>>
>>>> Yunze Xu <yz...@streamnative.io.invalid> 于2022年8月12日周五 21:57写道：
>>>>
>>>>> Yeah, I agree. It’s better to move the release process to the codebase.
>>>>>
>>>>> Regarding the automatic validation program, we can have that for some
>>>>> common verifications like the GPG verification, which only requires a
>>>>> simple
>>>>> command if you have downloaded the binary.
>>>>>
>>>>> Thanks,
>>>>> Yunze
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 2022年8月12日 18:12，PengHui Li <pe...@apache.org> 写道：
>>>>>>
>>>>>> 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 <ji...@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 <yz...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>
Re: Questions about the release process
Posted by Michael Marshall <mm...@apache.org>.
Thanks for raising this Yunze. The docker image was added to the VOTE
threads as a convenience for voters/testers. I don't believe we
established a formal requirement for it, which might explain why it is
not in the wiki. It should, however, be listed as an optional step if
we want it to be one.
I agree with putting the release process in the apache/pulsar git repo.
> we do need to assure that the PMC fully reviews changes
Currently, any committer has access to modify the release docs, so
this introduces a new requirement. One way to enforce who reviews a PR
is with a CODEOWNERS file. We could create a GitHub group with PMC
members and then require that any PR that touches the release process
documentation file is approved by a PMC member. I am not sure that
this is the "right" direction though.
> Do not make the release docs part of versioned docs.
I agree.
Thanks,
Michael
On Fri, Aug 12, 2022 at 10:32 PM Yunze Xu <yz...@streamnative.io.invalid> wrote:
>
> > The RM should ask a PMC member to help them add their KEY.
> > Do not make the release docs part of versioned docs.
> I agree.
>
> Thanks,
> Yunze
>
>
>
>
> > 2022年8月12日 23:10，Dave Fisher <wa...@apache.org> 写道：
> >
> > Hi -
> >
> > One change that needs to be made is regarding the KEYS file.
> >
> > We should drop the use of https://dist.apache.org/repos/dist/dev/pulsar/KEYS instead we should carefully update https://dist.apache.org/repos/dist/release/pulsar/KEYS
> >
> > The two KEYS files are currently out of sync. The release file had to be hand reconstructed at the beginning of the year and I’ve had to deal with new Release Manager KEYS that were not copied during the Release Process. (Recently Apache Infra has been scanning release and is informing PMCs when their releases are broken.)
> >
> > The RM should ask a PMC member to help them add their KEY. I’m willing to do it and I’m certain other PMC members would do the same.
> >
> > The VOTE threads can then always refer to a proper KEYS file that will always be correct. RMs should also make sure that their KEY does not expire while the release is active which could be for several years. If your KEY is revoked at some point then please let the PMC know.
> >
> > I like moving the Release Docs to the codebase, but we do need to assure that the PMC fully reviews changes. The reviews that count before squash and merge must be from PMC members. The reason is that the Pulsar PMC is responsible for assuring that Pulsar releases comply with Apache Release Policies.
> >
> > Do not make the release docs part of versioned docs. There should be only the current policy. If other products of the Pulsar project require different release docs it is fine to have separate docs.
> >
> > All The Best,
> > Dave
> >
> >> On Aug 12, 2022, at 7:41 AM, tison <wa...@gmail.com> wrote:
> >>
> >> Hi Penghui & Yunze,
> >>
> >> I ever wrote developer guides for TiDB[1] and Apache Kvrocks (Incubating),
> >> including the release guide for the latter[2].
> >>
> >> Just for your information, I'm preparing the proposal to bring a developer
> >> guide page (series docs). Perhaps start in the next month.
> >>
> >> Although, it cannot help the current status, and I don't want to discuss
> >> details on this topic here. Again, just for your information :)
> >>
> >> Best,
> >> tison.
> >>
> >> [1] https://pingcap.github.io/tidb-dev-guide/
> >> [2] https://kvrocks.apache.org/community/how-to-release
> >>
> >>
> >> Yunze Xu <yz...@streamnative.io.invalid> 于2022年8月12日周五 21:57写道：
> >>
> >>> Yeah, I agree. It’s better to move the release process to the codebase.
> >>>
> >>> Regarding the automatic validation program, we can have that for some
> >>> common verifications like the GPG verification, which only requires a
> >>> simple
> >>> command if you have downloaded the binary.
> >>>
> >>> Thanks,
> >>> Yunze
> >>>
> >>>
> >>>
> >>>
> >>>> 2022年8月12日 18:12，PengHui Li <pe...@apache.org> 写道：
> >>>>
> >>>> 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 <ji...@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 <yz...@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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >
>
Re: Questions about the release process
Posted by Yunze Xu <yz...@streamnative.io.INVALID>.
> The RM should ask a PMC member to help them add their KEY.
> Do not make the release docs part of versioned docs.
I agree.
Thanks,
Yunze
> 2022年8月12日 23:10，Dave Fisher <wa...@apache.org> 写道：
>
> Hi -
>
> One change that needs to be made is regarding the KEYS file.
>
> We should drop the use of https://dist.apache.org/repos/dist/dev/pulsar/KEYS instead we should carefully update https://dist.apache.org/repos/dist/release/pulsar/KEYS
>
> The two KEYS files are currently out of sync. The release file had to be hand reconstructed at the beginning of the year and I’ve had to deal with new Release Manager KEYS that were not copied during the Release Process. (Recently Apache Infra has been scanning release and is informing PMCs when their releases are broken.)
>
> The RM should ask a PMC member to help them add their KEY. I’m willing to do it and I’m certain other PMC members would do the same.
>
> The VOTE threads can then always refer to a proper KEYS file that will always be correct. RMs should also make sure that their KEY does not expire while the release is active which could be for several years. If your KEY is revoked at some point then please let the PMC know.
>
> I like moving the Release Docs to the codebase, but we do need to assure that the PMC fully reviews changes. The reviews that count before squash and merge must be from PMC members. The reason is that the Pulsar PMC is responsible for assuring that Pulsar releases comply with Apache Release Policies.
>
> Do not make the release docs part of versioned docs. There should be only the current policy. If other products of the Pulsar project require different release docs it is fine to have separate docs.
>
> All The Best,
> Dave
>
>> On Aug 12, 2022, at 7:41 AM, tison <wa...@gmail.com> wrote:
>>
>> Hi Penghui & Yunze,
>>
>> I ever wrote developer guides for TiDB[1] and Apache Kvrocks (Incubating),
>> including the release guide for the latter[2].
>>
>> Just for your information, I'm preparing the proposal to bring a developer
>> guide page (series docs). Perhaps start in the next month.
>>
>> Although, it cannot help the current status, and I don't want to discuss
>> details on this topic here. Again, just for your information :)
>>
>> Best,
>> tison.
>>
>> [1] https://pingcap.github.io/tidb-dev-guide/
>> [2] https://kvrocks.apache.org/community/how-to-release
>>
>>
>> Yunze Xu <yz...@streamnative.io.invalid> 于2022年8月12日周五 21:57写道：
>>
>>> Yeah, I agree. It’s better to move the release process to the codebase.
>>>
>>> Regarding the automatic validation program, we can have that for some
>>> common verifications like the GPG verification, which only requires a
>>> simple
>>> command if you have downloaded the binary.
>>>
>>> Thanks,
>>> Yunze
>>>
>>>
>>>
>>>
>>>> 2022年8月12日 18:12，PengHui Li <pe...@apache.org> 写道：
>>>>
>>>> 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 <ji...@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 <yz...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
Re: Questions about the release process
Posted by Dave Fisher <wa...@apache.org>.
Hi -
One change that needs to be made is regarding the KEYS file.
We should drop the use of https://dist.apache.org/repos/dist/dev/pulsar/KEYS instead we should carefully update https://dist.apache.org/repos/dist/release/pulsar/KEYS
The two KEYS files are currently out of sync. The release file had to be hand reconstructed at the beginning of the year and I’ve had to deal with new Release Manager KEYS that were not copied during the Release Process. (Recently Apache Infra has been scanning release and is informing PMCs when their releases are broken.)
The RM should ask a PMC member to help them add their KEY. I’m willing to do it and I’m certain other PMC members would do the same.
The VOTE threads can then always refer to a proper KEYS file that will always be correct. RMs should also make sure that their KEY does not expire while the release is active which could be for several years. If your KEY is revoked at some point then please let the PMC know.
I like moving the Release Docs to the codebase, but we do need to assure that the PMC fully reviews changes. The reviews that count before squash and merge must be from PMC members. The reason is that the Pulsar PMC is responsible for assuring that Pulsar releases comply with Apache Release Policies.
Do not make the release docs part of versioned docs. There should be only the current policy. If other products of the Pulsar project require different release docs it is fine to have separate docs.
All The Best,
Dave
> On Aug 12, 2022, at 7:41 AM, tison <wa...@gmail.com> wrote:
>
> Hi Penghui & Yunze,
>
> I ever wrote developer guides for TiDB[1] and Apache Kvrocks (Incubating),
> including the release guide for the latter[2].
>
> Just for your information, I'm preparing the proposal to bring a developer
> guide page (series docs). Perhaps start in the next month.
>
> Although, it cannot help the current status, and I don't want to discuss
> details on this topic here. Again, just for your information :)
>
> Best,
> tison.
>
> [1] https://pingcap.github.io/tidb-dev-guide/
> [2] https://kvrocks.apache.org/community/how-to-release
>
>
> Yunze Xu <yz...@streamnative.io.invalid> 于2022年8月12日周五 21:57写道：
>
>> Yeah, I agree. It’s better to move the release process to the codebase.
>>
>> Regarding the automatic validation program, we can have that for some
>> common verifications like the GPG verification, which only requires a
>> simple
>> command if you have downloaded the binary.
>>
>> Thanks,
>> Yunze
>>
>>
>>
>>
>>> 2022年8月12日 18:12，PengHui Li <pe...@apache.org> 写道：
>>>
>>> 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 <ji...@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 <yz...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
Re: Questions about the release process
Posted by tison <wa...@gmail.com>.
Hi Penghui & Yunze,
I ever wrote developer guides for TiDB[1] and Apache Kvrocks (Incubating),
including the release guide for the latter[2].
Just for your information, I'm preparing the proposal to bring a developer
guide page (series docs). Perhaps start in the next month.
Although, it cannot help the current status, and I don't want to discuss
details on this topic here. Again, just for your information :)
Best,
tison.
[1] https://pingcap.github.io/tidb-dev-guide/
[2] https://kvrocks.apache.org/community/how-to-release
Yunze Xu <yz...@streamnative.io.invalid> 于2022年8月12日周五 21:57写道：
> Yeah, I agree. It’s better to move the release process to the codebase.
>
> Regarding the automatic validation program, we can have that for some
> common verifications like the GPG verification, which only requires a
> simple
> command if you have downloaded the binary.
>
> Thanks,
> Yunze
>
>
>
>
> > 2022年8月12日 18:12，PengHui Li <pe...@apache.org> 写道：
> >
> > 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 <ji...@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 <yz...@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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
>
>
Re: Questions about the release process
Posted by Yunze Xu <yz...@streamnative.io.INVALID>.
Yeah, I agree. It’s better to move the release process to the codebase.
Regarding the automatic validation program, we can have that for some
common verifications like the GPG verification, which only requires a simple
command if you have downloaded the binary.
Thanks,
Yunze
> 2022年8月12日 18:12，PengHui Li <pe...@apache.org> 写道：
>
> 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 <ji...@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 <yz...@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
>>>
>>>
>>>
>>>
>>>
>>
Re: Questions about the release process
Posted by PengHui Li <pe...@apache.org>.
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 <ji...@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 <yz...@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
> >
> >
> >
> >
> >
>
Re: Questions about the release process
Posted by Haiting Jiang <ji...@gmail.com>.
> 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 <yz...@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
>
>
>
>
>