LLVM has a pretty good workflow for managing release branches with a bot. PRs go to main by default, then a maintainer can `/cherry-pick sha-or-range` with a sha from that merge (e.g. [1]) to have the bot open a PR against the stable branch (e.g. [2]). This can then be tested, approved and merged without anyone needing to do the work locally.
Something like this might be useful for MariaDB if a target branch or branch range could be specified to get a PR against each branch: `/cherry-pick 11.6 024a3122..4373c179` or `/cherry-pick lts..beta 1f884c16’. Not to add any specific opinion here since adjusting release workflow would be a huge change, but some automation would probably help smooth things out if branches are ever refactored. - Trevor [1]: https://github.com/llvm/llvm-project/pull/91776#issuecomment-2106751053 [2]: https://github.com/llvm/llvm-project/pull/91917 On Fri, Jun 28, 2024 at 6:40 PM Eric Herman via developers <[email protected]> wrote: > > I am glad to see this getting another look, as I've advocated for this in the > past. > > A cost to be considered is the change in workflow for those whom are > responsible for merging bug-fixes from the earliest branch up through all of > the still-supported releases and eventually on to trunk. > > While this cost of this change seems small to me, I'm not the one who does > this work; let's make sure that the maintainers who do this work are > well-supported as changes are made. > > Cheers, > -Eric > > > > On Fri, 28 Jun 2024 at 22:23, Vicențiu Ciorbaru via developers > <[email protected]> wrote: >> >> I echo Nikita's position here. With our new model, a change that happened >> once every year now must happen once every quarter. >> >> It would also map to our rolling release model too I believe. >> >> This was discussed in the past and we decided against it then, but now times >> have changed where I believe it warrants a second look. >> >> Vicențiu >> >> On Fri, 28 Jun 2024, 16:58 Nikita Malyavin via developers, >> <[email protected]> wrote: >>> >>> Hello Otto, >>> >>> I think it's a good idea, which improves the quality of life. >>> >>> The rebases will still have to take place, but at least the contributors >>> won't have to update the branch names in the PR! >>> >>> Regards, >>> Nikita >>> >>> On Fri, 28 Jun 2024 at 05:55, Otto Kekäläinen via developers >>> <[email protected]> wrote: >>>> >>>> Hi! >>>> >>>> Has the core developers had discussions about using branch name 'main' >>>> for development instead of switching to a new branch every 3 months? >>>> >>>> If all new features and other additions would always target the branch >>>> 'main' it would lower the barrier of entry for new contributors, and >>>> decrease the number of unnecessary rebases done by contributors. >>>> >>>> If the permanent development target was 'main', you would need to >>>> create new 11.x branches only at "freeze" when a new major version >>>> branch is cut for release. >>>> >>>> MariaDB is currently the only open source project I know that does >>>> *not* have a main/master/trunk branch and instead does these constant >>>> new branch names. I imagine this is not only annoying for >>>> contributors, but also the core developers who waste time asking >>>> contributors to rebase PRs every 3 months (see >>>> https://github.com/MariaDB/server/pull/2556 and >>>> https://github.com/MariaDB/server/pull/2671 as examples). >>>> >>>> - Otto >>>> _______________________________________________ >>>> developers mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>> >>> >>> >>> -- >>> Yours truly, >>> Nikita Malyavin >>> _______________________________________________ >>> developers mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> developers mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > developers mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ developers mailing list -- [email protected] To unsubscribe send an email to [email protected]
