Re: Cherry-picking policy
On 11/21/22 01:28, David Redondo wrote: Nate brought up label + milestone. Please correct me but you can only have one milestone I think. I guess it would need to work something like, - if has "Cherry-pick" label and milestone LTS -> pick to LTS and stable - if has "Cherry-pick" label and milestone stabel -> pick to stable Yep, I think that would make sense. Do we have situations where we pick to more than stable and latest LTS? The only thing that would come to my mind are security fixes after the normal support period. Indeed, and I think those should be done manually anyway. Nate
Re: Cherry-picking policy
Am Samstag, 19. November 2022, 05:06:11 CET schrieb Ben Cooksley: > Not sure how much of this is on our radar at the moment, but I do know that > we were playing with a bot to do tagging of MRs at one point in time. > > In terms of how this bot operates, how are people thinking it should work? I quite like the way Qt does it, in the commit message footer you add for example "Pick to: 6.4 6.2" and after the your change is merged to dev the bot creates MR for the relevant branches. Nate brought up label + milestone. Please correct me but you can only have one milestone I think. I guess it would need to work something like, - if has "Cherry-pick" label and milestone LTS -> pick to LTS and stable - if has "Cherry-pick" label and milestone stabel -> pick to stable Do we have situations where we pick to more than stable and latest LTS? The only thing that would come to my mind are security fixes after the normal support period. David
Re: Cherry-picking policy
On Thu, Nov 17, 2022 at 3:03 AM Aleix Pol wrote: > +1, thanks for bringing this up, this is also something I'd pondered at > times. > > Adding sysadmin on CC as automating this has been brought up and > AFAIR this was something they'd been working on before. > Hey Aleix, Not sure how much of this is on our radar at the moment, but I do know that we were playing with a bot to do tagging of MRs at one point in time. In terms of how this bot operates, how are people thinking it should work? Cheers, Ben > Aleix > > On Wed, Nov 16, 2022 at 11:12 AM Vlad Zahorodnii > wrote: > > > > Hi, > > > > At the moment, we have the following bugfixing workflow in plasma: > > > > * fix a bug in master > > * cherry pick the fix to stable branch(es) > > > > The last step is usually done without creating a MR. If there is a merge > > conflict, some people do create a MR though. > > > > I propose to make creating MRs for bugfix backports mandatory: > > > > - this helps us to ensure that CI is happy > > - increases the visibility of what happens in stable branches. For > > example some people help with backporting bugfixes, but they can forget > > to include a commit if the original MR included multiple commits. > > Hopefully, this can help us to catch these cases > > > > Ideally this should be automated, but we have no tooling to do that. > > > > Thoughts? > > > > Regards, > > Vlad >
Re: Cherry-picking policy
No objections, seems like a really good idea. I am *highly* in favor of a bot to do this automatically in response to the presence of the "cherry-pick" label and appropriate milestone to cherry-pick to being defined, which would also help with people remembering to do those things. Nate On 11/16/22 03:11, Vlad Zahorodnii wrote: Hi, At the moment, we have the following bugfixing workflow in plasma: * fix a bug in master * cherry pick the fix to stable branch(es) The last step is usually done without creating a MR. If there is a merge conflict, some people do create a MR though. I propose to make creating MRs for bugfix backports mandatory: - this helps us to ensure that CI is happy - increases the visibility of what happens in stable branches. For example some people help with backporting bugfixes, but they can forget to include a commit if the original MR included multiple commits. Hopefully, this can help us to catch these cases Ideally this should be automated, but we have no tooling to do that. Thoughts? Regards, Vlad
Re: Cherry-picking policy
+1, thanks for bringing this up, this is also something I'd pondered at times. Adding sysadmin on CC as automating this has been brought up and AFAIR this was something they'd been working on before. Aleix On Wed, Nov 16, 2022 at 11:12 AM Vlad Zahorodnii wrote: > > Hi, > > At the moment, we have the following bugfixing workflow in plasma: > > * fix a bug in master > * cherry pick the fix to stable branch(es) > > The last step is usually done without creating a MR. If there is a merge > conflict, some people do create a MR though. > > I propose to make creating MRs for bugfix backports mandatory: > > - this helps us to ensure that CI is happy > - increases the visibility of what happens in stable branches. For > example some people help with backporting bugfixes, but they can forget > to include a commit if the original MR included multiple commits. > Hopefully, this can help us to catch these cases > > Ideally this should be automated, but we have no tooling to do that. > > Thoughts? > > Regards, > Vlad
Re: Cherry-picking policy
Hi, > I propose to make creating MRs for bugfix backports mandatory: Agreed. I have also been guilty of cherry-picking changes on a whim from my phone before going to bed, which is not something we want for the stable branch. Back when we were still forward-merging I was at least compiling them locally and giving them a quick test run. Cheers Kai Uwe
