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