> 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 <w...@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 <wander4...@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 <y...@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 <peng...@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 <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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>> >>> >
