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