Thanks for your reply, Penghui. I saw your note on that thread but didn't realize it affected 2.8.3.
I absolutely did not mean to imply that you don't want to share here. I appreciate your many contributions to the community and the mailing list, and I look forward to future collaboration. Thanks, Michael On Wed, Feb 16, 2022 at 6:58 PM PengHui Li <peng...@apache.org> wrote: > > > I agree that it can be non-trivial to determine if an issue is an > internal test or an upstream issue. > > My main point is that we should prefer early communication of > potential issues that affect pending releases and accept that the > issue might prove to be nothing more than a short delay in the release > cycle. The alternative is that a release manager completes the build > process, which takes several hours, then discovers a new candidate is > needed. There is still an inherent race condition for release creation > and validation, but early communication (and collaboration) might help > us avoid some of the cases where candidates are rejected immediately. > > I have explained here > https://lists.apache.org/thread/m5so1scfok44hnd74436w100smn2vbh3 > at 11/02/2022 > Have you seen it? As I said before, I forget to update this thread, > I have declared at the first time that I respond to this thread. > it's not that I don't want to share to this thread. > I can't accept dave and you thinking I don't want to share here. > it's completely different > > > For what it's worth, I don't think you need to verify your test > correctness 100% before sharing potential issues that affect pending > releases. A quick note to the dev mailing list indicating that you're > investigating a potential issue would be sufficient and valuable. > > If I can't confirm the issue, what should I share? > Our failed tests happen every day due to different problems, > do I need to share them with the community every day? > > Penghui > > On Thu, Feb 17, 2022 at 3:41 AM Michael Marshall <mmarsh...@apache.org> > wrote: > > > I agree that it can be non-trivial to determine if an issue is an > > internal test or an upstream issue. > > > > My main point is that we should prefer early communication of > > potential issues that affect pending releases and accept that the > > issue might prove to be nothing more than a short delay in the release > > cycle. The alternative is that a release manager completes the build > > process, which takes several hours, then discovers a new candidate is > > needed. There is still an inherent race condition for release creation > > and validation, but early communication (and collaboration) might help > > us avoid some of the cases where candidates are rejected immediately. > > > > For what it's worth, I don't think you need to verify your test > > correctness 100% before sharing potential issues that affect pending > > releases. A quick note to the dev mailing list indicating that you're > > investigating a potential issue would be sufficient and valuable. > > > > Thanks, > > Michael > > > > > > > > > > > > On Tue, Feb 15, 2022 at 6:30 PM PengHui Li <peng...@apache.org> wrote: > > > > > > > Just a friendly reminder that we are an open source project and other > > > community members who may have different internal testing may find better > > > fixes. > > > > > > Sorry, dave. I know we are an open source project. > > > We found a problem in our internal test, we need to confirm it is not > > > the test issue right? > > > > > > Do you suggest that we discuss this in the email when we find our > > internal > > > test errors? > > > The community has no responsibility to deal with our internal testing > > bugs. > > > > > > On Wed, Feb 16, 2022 at 8:04 AM Dave Fisher <w...@apache.org> wrote: > > > > > > > > > > > > > > > > On Feb 15, 2022, at 3:59 PM, PengHui Li <peng...@apache.org> wrote: > > > > > > > > > >> I wonder if we should be more willing to share suspicions on the > > > > > mailing list when releases are actively being prepared. I would > > > > > have appreciated the notice, and I could have possibly helped > > > > > confirm the issue. On the other hand, I respect that it is hard to > > > > > know when to share a theory and when to test it out a bit more. > > > > > > > > > > Yes, It's just that these issues are happening in our internal > > testing > > > > > and we need to 100% confirm the issue and then share it out, > > > > > otherwise, We may confuse the contributors due to internal test > > problems. > > > > > > > > Just a friendly reminder that we are an open source project and other > > > > community members who may have different internal testing may find > > better > > > > fixes. > > > > > > > > > > > > > > This kind of problem is often easy to fix, but difficult to > > troubleshoot. > > > > > So usually when you are 100% confirmed the issue, usually know how > > to fix > > > > > it. > > > > > > > > > >> I think these were not included because they were labeled after I > > > > > cherry picked PRs on Friday. I will take a look and try to cherry > > pick > > > > > all of those before tagging the next release candidate > > > > > > > > > > Oh, I see. Thanks. I have checked > > > > > https://github.com/apache/pulsar/commits/branch-2.8 > > > > > LGTM. > > > > > > > > > > Regards, > > > > > Penghui > > > > > > > > > > On Wed, Feb 16, 2022 at 1:21 AM Michael Marshall < > > mmarsh...@apache.org> > > > > > wrote: > > > > > > > > > >> Closing the vote with one -1 from Penghui. > > > > >> > > > > >>> We just confirmed yesterday that this is a breaking change, > > > > >>> I was just suspicious before, so do not share the information > > > > >>> to avoid confusing reviewers. For now, we confirmed it > > > > >> > > > > >> I wonder if we should be more willing to share suspicions on the > > > > >> mailing list when releases are actively being prepared. I would > > > > >> have appreciated the notice, and I could have possibly helped > > > > >> confirm the issue. On the other hand, I respect that it is hard to > > > > >> know when to share a theory and when to test it out a bit more. > > > > >> > > > > >>> And not all the PRs get cherry-picked to 2.8.3? > > > > >> > > > > >> I think these were not included because they were labeled after I > > > > >> cherry picked PRs on Friday. I will take a look and try to cherry > > pick > > > > >> all of those before tagging the next release candidate. > > > > >> > > > > >> Thanks, > > > > >> Michael > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> On Tue, Feb 15, 2022 at 12:52 AM PengHui Li <peng...@apache.org> > > wrote: > > > > >>> > > > > >>> Sorry Michael > > > > >>> > > > > >>> There is a breaking change introduced in branch-2.8. > > > > >>> Sorry for that I forget to update the 2.8.3 release process, > > > > >>> Only update the context in 2.9.2 and 2.10.0. > > > > >>> > > > > >>> We just confirmed yesterday that this is a breaking change, > > > > >>> I was just suspicious before, so do not share the information > > > > >>> to avoid confusing reviewers. For now, we confirmed it > > > > >>> > > > > >>> The fixed PR is https://github.com/apache/pulsar/pull/14288 > > > > >>> > > > > >>> And not all the PRs get cherry-picked to 2.8.3? > > > > >>> Please check the list > > > > >>> > > > > >> > > > > > > https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.8.3+is%3Aclosed+-label%3Acherry-picked%2Fbranch-2.8+ > > > > >>> If they are not a requirement for 2.8.3, we can move it to the next > > > > >> version. > > > > >>> For https://github.com/apache/pulsar/pull/14246, I can confirm, > > > > without > > > > >>> this fix, we will also introduce breaking change in 2.8.3 > > > > >>> > > > > >>> I have to give my -1 here > > > > >>> > > > > >>> Regards, > > > > >>> Penghui > > > > >>> > > > > >>> > > > > >>> On Tue, Feb 15, 2022 at 12:56 PM Michael Marshall < > > > > mmarsh...@apache.org> > > > > >>> wrote: > > > > >>> > > > > >>>> This is the first release candidate for Apache Pulsar, version > > 2.8.3. > > > > >>>> > > > > >>>> It fixes the following issues: > > > > >>>> > > https://github.com/apache/pulsar/compare/v2.8.2...v2.8.3-candidate-1 > > > > >>>> > > > > >>>> *** Please download, test and vote on this release. This vote will > > > > stay > > > > >>>> open > > > > >>>> for at least 72 hours *** > > > > >>>> > > > > >>>> Note that we are voting upon the source (tag), binaries are > > provided > > > > >> for > > > > >>>> convenience. > > > > >>>> > > > > >>>> Source and binary files: > > > > >>>> > > > > >> > > https://dist.apache.org/repos/dist/dev/pulsar/pulsar-2.8.3-candidate-1/ > > > > >>>> > > > > >>>> SHA-512 checksums: > > > > >>>> > > > > >>>> > > > > >>>> > > > > >> > > > > > > b9d48a92404bacb0505406f57974c9e1ceecfede12cdc286656dbf1ee75c204c0af67540945a5d7b0fb1e295b6f06317444932359fd9af29d4ee8ceefa13f0ee > > > > >>>> apache-pulsar-2.8.3-bin.tar.gz > > > > >>>> > > > > >>>> > > > > >> > > > > > > d31ee747ba2a796230dd052994214028761813057967e92599dcf51e1b64726178b5ba6e3676cc5e947d60ee0411b0f02cb1ffcd91ba8a4138d220bbec7b6731 > > > > >>>> apache-pulsar-2.8.3-src.tar.gz > > > > >>>> > > > > >>>> Unofficial Docker images: > > > > >>>> michaelmarshall/pulsar:2.8.3-rc1 > > > > >>>> michaelmarshall/pulsar-all:2.8.3-rc1 > > > > >>>> michaelmarshall/pulsar-standalone:2.8.3-rc1 > > > > >>>> michaelmarshall/pulsar-grafana:2.8.3-rc1 > > > > >>>> > > > > >>>> Maven staging repo: > > > > >>>> > > > > >> > > > > > > https://repository.apache.org/content/repositories/orgapachepulsar-1139/ > > > > >>>> > > > > >>>> The tag to be voted upon: > > > > >>>> v2.8.3-candidate-1 (f3234374b50ae25d5afc9e882d1e3eb50a79fffd) > > > > >>>> https://github.com/apache/pulsar/releases/tag/v2.8.3-candidate-1 > > > > >>>> > > > > >>>> Pulsar's KEYS file containing PGP keys we use to sign the release: > > > > >>>> https://dist.apache.org/repos/dist/dev/pulsar/KEYS > > > > >>>> > > > > >>>> Please download the source package, and follow the README to build > > > > >>>> and run the Pulsar standalone service. > > > > >>>> > > > > >> > > > > > > > > > >
