Suggestion: use 'main' as the development branch instead of an ever changing 11.x
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
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 < developers@lists.mariadb.org> 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 -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
-- Yours truly, Nikita Malyavin
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, < developers@lists.mariadb.org> 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 < developers@lists.mariadb.org> 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 -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
-- Yours truly, Nikita Malyavin _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
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 < developers@lists.mariadb.org> 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, < developers@lists.mariadb.org> 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 < developers@lists.mariadb.org> 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 -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
-- Yours truly, Nikita Malyavin _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
_______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
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 <developers@lists.mariadb.org> 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 <developers@lists.mariadb.org> 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, <developers@lists.mariadb.org> 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 <developers@lists.mariadb.org> 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 -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
-- Yours truly, Nikita Malyavin _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
_______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
_______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
Changing the branch naming rule won't require more work for those who makes the release: Now we: 1. add a tag with released version 2. create a branch for next version 3. mark it as main on github With this change we would: 1. add a tag with released version 2. create a branch for *released* version no 3, since next is always just 'main' 👍 On Sun, 30 Jun 2024 at 20:37, Trevor Gross via developers < developers@lists.mariadb.org> wrote:
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 <developers@lists.mariadb.org> 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 <
developers@lists.mariadb.org> 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, <
developers@lists.mariadb.org> 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 <
developers@lists.mariadb.org> 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 -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
-- Yours truly, Nikita Malyavin _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
_______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
_______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
-- Yours truly, Nikita Malyavin
Hi, Otto, Thanks. I was thinking about something like that too. But I have mixed feelings about it. (+) it could be more familiar to new contributors, who, supposedly aren't familiar with the workflow where a newest version branch is the development branch (-) but it's exactly what Drupal is using, so MariaDB is not the only open source project that does that (+) I won't need to change the default branch in the github project config every three months (-) contributors will still need to rebase, from main to main, same branch name but otherwise exactly as many new commits (-) we'll need to adjust our tools, like buildbot, but I expect it'll only need minor changes, it shouldn't be a problem So, as you can see, I'm kind of on the fence. We can make either way work. Monty had an interesting argument thought. Say, he wants to fix a bug in 11.6. Pulls the latest 'main' branch, fixes the bug, buildbot, weekend. Then he pushes, but by that time I've already branched 11.6 off and the 'main' branch is now 11.7. Thus the bug fix ends in the wrong branch. I'd count it as a (-) of the 'main' model. What are the benefits (or drawbacks) that I've missed? Eric wrote he was advocating for this in the past, what were the arguments there? Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org On Jun 27, Otto Kekäläinen via developers 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
Hi! Thanks for listing the pros/cons from your point of view and it is interesting to learn that Drupal has the same model. However not all of the listed pros and cons are of equal importance. Avoiding having MariaDB admins change the default branch every 3 months and avoiding having contributors to change the PR target branch every 3 months is a *very* important benefit that should outweigh most other arguments. Sure, rebases might be needed occasionally even if a PR targets branch 'main' and does not need branch updates. However, simple rebases can be done by the person doing the merge using the GitHub UI. Target branch changes can't be done by anyone else than the submitter. Consider e.g. https://github.com/MariaDB/server/pull/3175. It will be rebased *and* have the target branch updated to 11.6 this week. However based on MDEV-33834 it should target 11.7, which does not exist yet, and since the submitter is about to change teams we know he will never change the target branch to a future 11.7, and thus that MR will never be merged. If MariaDB had branch 'main' as the general development target, this problem would not exist. Drupal also uses a versioned trunk branch (11.x currently at https://git.drupalcode.org/project/drupal), but they change it only every 2 years, so they don't suffer from the constant need to update target branches in submissions. In MariaDB the new quarterly releases has made this aspect painful. - Otto PS. This phenomenon is also an example of something where the problem and the solution would be obvious to core MariaDB developers, if they just used Pull Requests themselves to have first hand experience of how it currently works (or does not work).
Following on from the discussion here and a conversation on a call yesterday, I have created a poll to help decide which direction to go based on contributor feedback: https://mariadb.org/mariadb-server-github-branches-have-your-say/ I hope this helps. Kind Regards Andrew On 03/07/2024 03:46, Otto Kekäläinen wrote:
Hi!
Thanks for listing the pros/cons from your point of view and it is interesting to learn that Drupal has the same model. However not all of the listed pros and cons are of equal importance.
Avoiding having MariaDB admins change the default branch every 3 months and avoiding having contributors to change the PR target branch every 3 months is a *very* important benefit that should outweigh most other arguments.
Sure, rebases might be needed occasionally even if a PR targets branch 'main' and does not need branch updates. However, simple rebases can be done by the person doing the merge using the GitHub UI. Target branch changes can't be done by anyone else than the submitter. Consider e.g. https://github.com/MariaDB/server/pull/3175. It will be rebased *and* have the target branch updated to 11.6 this week. However based on MDEV-33834 it should target 11.7, which does not exist yet, and since the submitter is about to change teams we know he will never change the target branch to a future 11.7, and thus that MR will never be merged. If MariaDB had branch 'main' as the general development target, this problem would not exist.
Drupal also uses a versioned trunk branch (11.x currently at https://git.drupalcode.org/project/drupal), but they change it only every 2 years, so they don't suffer from the constant need to update target branches in submissions. In MariaDB the new quarterly releases has made this aspect painful.
- Otto
PS. This phenomenon is also an example of something where the problem and the solution would be obvious to core MariaDB developers, if they just used Pull Requests themselves to have first hand experience of how it currently works (or does not work).
-- Andrew (LinuxJedi) Hutchings Chief Contributions Officer MariaDB Foundation
Thanks Andrew for setting up a vote. Seems like a good way to engage the developer community. May I suggest the wording to be updated to this? * Versioned branch, e.g. ’11.6’, changes every 3 months (current method) * Static brach 'main', does not change (proposed method) By default git has 'main' since a couple years back, so I would propose only it (not 'trunk').
Hi! The results are out now: https://mariadb.org/mariadb-server-github-branches-moving-to-main/ Nice to see Andrew coordinate a vote and announce the result this clearly, thanks! Hopefully implementation goes well and everyone is happy, and perhaps we will see more votes on other topics as well..
Hi, Otto, This is done now. https://github.com/MariaDB/server/tree/main/ I pessimistically expect the first few days (or weeks) to be a bit rough while all tools are being adjusted. But hopefully I'll be wrong about it and everything might just work. On Jul 18, Otto Kekäläinen wrote:
Hi!
The results are out now: https://mariadb.org/mariadb-server-github-branches-moving-to-main/
Nice to see Andrew coordinate a vote and announce the result this clearly, thanks! Hopefully implementation goes well and everyone is happy, and perhaps we will see more votes on other topics as well..
Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org
participants (7)
-
Andrew Hutchings -
Eric Herman -
Nikita Malyavin -
Otto Kekäläinen -
Sergei Golubchik -
Trevor Gross -
Vicențiu Ciorbaru