Re: Merge stable to master vs cherry-picking
On 6 December 2021 06:07:50 GMT, Harald Sitter wrote: > I'm all for cherry picking. It's both easier and makes sure fixes are > actually available in master. I like cherry picking since it tends to be more straightforward than merging, but there's always the danger that someone might forget to cherry pick a fix. Merging ensures that fixes will always be made available in master, without relying on people always remembering to do the right thing. So as I see it, merging is the only safe way to ensure that fixes are applied to both branches. > On Fri, Dec 3, 2021 at 6:55 PM Kai Uwe Broulik wrote: > > > > Hi everyone, > > > > as part of the GitLab transition in Plasma we changed our commit > > strategy from committing to stable and merging to master to committing > > to master and cherry-picking to stable. Reason being that it's a lot > > more convenient to do from GitLab's UI. I can merge and cherry-pick all > > from the web UI. > > > > However, other projects, such as most of KDE Gear, continues using > > merging, which makes the experience inconsistent and tedious. Fully > > retargeting a branch doesn't seem possible from the UI and not sure if > > you can merge up there either. > > > > What's keeping us from changing the strategy for the rest of KDE, too? > > > > Cheers > > Kai Uwe > -- David Jarvie KAlarm author, KDE developer
Re: Merge stable to master vs cherry-picking
El dilluns, 6 de desembre de 2021, a les 7:07:50 (CET), Harald Sitter va escriure: > I'm all for cherry picking. It's both easier and makes sure fixes are > actually available in master. I don't agree that cherry-picking is easier. Example: I want to fix a bug in kmail. Fixing it in master means i have to build a zillion of repositories before even trying to start fixing the bug, it may also happen that once I built master i can't reproduce the bug because master has been fixed for various reasons (re-architecture, fixed the bug and forgot to cherry-pick, etc) Fixing it in the stable branch is much easier, just build the kmail repo and fix the bug. Cheers, Albert > > HS > > On Fri, Dec 3, 2021 at 6:55 PM Kai Uwe Broulik wrote: > > > > Hi everyone, > > > > as part of the GitLab transition in Plasma we changed our commit > > strategy from committing to stable and merging to master to committing > > to master and cherry-picking to stable. Reason being that it's a lot > > more convenient to do from GitLab's UI. I can merge and cherry-pick all > > from the web UI. > > > > However, other projects, such as most of KDE Gear, continues using > > merging, which makes the experience inconsistent and tedious. Fully > > retargeting a branch doesn't seem possible from the UI and not sure if > > you can merge up there either. > > > > What's keeping us from changing the strategy for the rest of KDE, too? > > > > Cheers > > Kai Uwe >
Reminder - Please do not use noreply domains from Gitlab.com/Github.com
Hi all, A while back Sysadmin encountered a series of issues with the DNS resolvers that support the noreply email addresses offered by one of Github.com/Gitlab.com to their users. These issues led to our hooks refusing to accept the email addresses in commits because the domain does not exist (because their DNS servers are flaky/faulty). As these domains are essentially anonymous and not usable in the long run (and in the case of one of them having faulty DNS servers) the decision was made to blacklist them. Recently however we have had an incident where it appears, either someone has either by accident or otherwise evaded this blacklist by using the domain users.noreply.github.com. That domain has now been added to the blacklist. For those of you using repository forks to prepare your merge requests for plasma/plasma-desktop, if it was created more than 5 days ago i'm afraid your fork is now unable to be rebased and will need to be destroyed and recreated. (as the commit hooks will refuse to admit the commits from the noreply domains - especially now that i've corrected the blacklist omission). My apologies for the inconvenience caused. Regards, Ben Cooksley KDE Sysadmin
