If we are concerned about correctly ensuring only bug fixes go to
release branches, I think we ought to discuss using a merge git
strategy instead of a cherry pick git strategy. This change was
discussed briefly on this mailing list at the end of 2021 [0]. I will
make a brief argument for making th
>Maybe it is better to start a discussion on the mailing list when you want
to
>cherry-pick something and wait for some time.
>If nobody objects then it is good to go
Because there are a large number of PRs that need to be cherry-picked,
some PRs may not strictly abide by this agreement when cherr
Il giorno mar 28 feb 2023 alle ore 12:11 PengHui Li
ha scritto:
>
> > By the way the main point in this email thread is that we should
> totally stop to do cherry-picks of stuff that it is
> not strictly needed
>
> Yes, the main issue we need to resolve is how we can define if
> the stuff strictl
> By the way the main point in this email thread is that we should
totally stop to do cherry-picks of stuff that it is
not strictly needed
Yes, the main issue we need to resolve is how we can define if
the stuff strictly needed to cherry-pick. Do you think the author
to provide the cherry-pick in
Il giorno mar 28 feb 2023 alle ore 11:19 Yubiao Feng
ha scritto:
>
> Append asuggestion:
> - After a PR revert, we need to remove the label named "release-xxx", which
> can alleviate the release manager's work
I think that it is up to the committer who merges the patch to
cherry-pick immediately
Append asuggestion:
- After a PR revert, we need to remove the label named "release-xxx", which
can alleviate the release manager's work
Thanks
Yubiao Feng
On Mon, Feb 27, 2023 at 11:27 PM Enrico Olivelli
wrote:
> Hello Committers,
> I believe that we should stop cherry-picking breaking changes
> If the author haven't provided the context, any committer who want to add
the release/* label should left a comment about why the PR should be
cherry-pick.
Totally agree. The committer needs to add at least one comment for the
reason if he wants to add the release labels.
I think we could add
I found another example https://github.com/apache/pulsar/pull/19425
Which has cherry-picked and then reverted
If the PR's author knows the PR should be cherry-pick to some branches,
it's better to contains this part in the PR description and explain why the
fix
should be cherry-picked. The reviewe
Enrico,
I find it interesting that the main reaction is to focus on the symptom,
rather than the disease.
From my experience, the open source project should drop the support of
multiple release branches (especially since they are claimed to be
backward compatible), only have one released ve
Sent from my iPhone
> On Feb 27, 2023, at 9:28 PM, tison wrote:
>
>
>>
>> Yes, but..
>
> For this case, I agree that the RM trust Jason who tagged the PR needs to
> be picked to 2.10. In this case Jason was supposed to do the check.
>
>> guidance for release managers to evaluate PR cherr
> Yes, but..
For this case, I agree that the RM trust Jason who tagged the PR needs to
be picked to 2.10. In this case Jason was supposed to do the check.
> guidance for release managers to evaluate PR cherry-pick labels carefully
For the current workflow, the RM can trust the labels since only
> For the issued PR, Hang commented at
https://github.com/apache/pulsar/pull/15914#issuecomment-1146942281 that it
changes the default behavior.
Yes, but it looks like it has been ignored by the reviewers and the author.
The PR still gets merged, finally. We should give a `Change Request` if the
P
Sent from my iPhone
> On Feb 27, 2023, at 9:08 PM, tison wrote:
>
>
>>
>> The release manager is unable to review all PRs before releasing it.
>
> At least the RM is responsible for PRs cherry-picked he/she made. As we
> take compatibility in a high priority, if it's unclear a fix (patch)
> At least the RM is responsible for PRs cherry-picked he/she made. As we
take compatibility in a high priority, if it's unclear a fix (patch)
without breaking changes, the RM can ask for confirmation.
Yes, but it's not easy without going through all the comments,
review the PR changes. If we don'
I agree that the `release/*` tags are misleading hints. Remove all the tags
for the issued PR.
Best,
tison.
tison 于2023年2月28日周二 13:13写道：
> For "what is breaking changes", at least the PULL_REQUEST_TEMPLATE gives
> some hints:
> https://github.com/apache/pulsar/blob/bbb543d8ed2b03361807c852da1a
For "what is breaking changes", at least the PULL_REQUEST_TEMPLATE gives
some hints:
https://github.com/apache/pulsar/blob/bbb543d8ed2b03361807c852da1a31cfb92939f3/.github/PULL_REQUEST_TEMPLATE.md?plain=1#L56-L72
For the issued PR, Hang commented at
https://github.com/apache/pulsar/pull/15914#issu
> The release manager is unable to review all PRs before releasing it.
At least the RM is responsible for PRs cherry-picked he/she made. As we
take compatibility in a high priority, if it's unclear a fix (patch)
without breaking changes, the RM can ask for confirmation.
Best,
tison.
PengHui Li
Hi enrico,
+1 for your point.
Do you know the details of the breaking change?
I can't find any discussions under the mailing list about the breaking
change.
I have added the `release/important-notice ` label to the PR, and we should
also discuss first, better to have a proposal if we are making
Hi Enrico Olivelli,
Totally agree, we should be careful when cherry-picking PRs. And we can't
trust our own judgment too much. For an uncertain PR, we must submit a PR
and wait for everyone to review it together.
For example, for the PR [1] mentioned above, the measure I took was to push
a PR to c
Hi Enrico Olivelli
Thank you for helping me correct my mistake
Yubiao Feng
On Mon, Feb 27, 2023 at 11:27 PM Enrico Olivelli
wrote:
> Hello Committers,
> I believe that we should stop cherry-picking breaking changes like [1]
> to released branches.
> Really, this is something that we cannot do
Linus Thorvalds has spoken about this more than once, and his position
is that the ultimate failure of a project is to worsen the user
experience, and changing behavior is "worse experience". He claim to go
as far as revert bug fixes if there are people depending on the buggy
behavior and ca
+1000,
We should pay attention on two places:
1. Why add release/xxx label to the breaking change PR ?
2. We should recheck the context when committer cherry-pick PRs.
Best,
Mattison
On Feb 27, 2023, 23:27 +0800, Enrico Olivelli , wrote:
> Hello Committers,
> I believe that we should stop cherr
Hello Committers,
I believe that we should stop cherry-picking breaking changes like [1]
to released branches.
Really, this is something that we cannot do.
When you decide to cherry-pick a commit to a "stable branch",
currently branch-2.8, branch-2.9, branch-2.10 and branch-2.11 you
always have to
23 matches
Mail list logo
