[Maria-developers] 10.3 branches
Hello Serg, all, A few weeks ago I created a new branch "10.3" and pushed essential patches needed for the compatibility project. It worked as follows: - In 10.3: git rebase origin/10.2 git push --force - In bb-10.2-compatibility: git rebase origin/10.3 git push --force Now as other developers start to push into 10.3, this won't work anymore. We briefly discussed with Monty that, as the compatibility project should be as stable as possible and merging all 10.3 patches into bb-10.2-compatibility is not desirable, we could try something like this: Add a new branch (Monty proposed "10.3-base" as the name) and propagate changes as follows: - In 10.3-base: git rebase origin/10.2 git push --force - In bb-10.2-compatibility git rebase origin/10.3-base git push --force - In 10.3: git merge origin/10.3-base git push (no --force) 10.2 ---(rebase)--->10.3-base--(rebase)-->bb-10.2-compatibility | | (merge) (merge) | | V | 10.3<-----------------/ Any objections about this scheme? I'd only propose to use "10.2-ext" instead of "10.3-base", as this intermediate branch is going to be more 10.2 than 10.3. Thanks.
Hi, Alexander! Sure, 10.2-ext or 10.3-base - whatever you prefer. I understand that bb-10.2-compatibility will be eventually pushed into 10.3 too, when it'll be ready. For now, I'd suggest the following: 10.2----------------------->10.3 \ \- 10.2-ext ---> 10.2-compat and eventually 10.2-ext and 10.2-compat are getting merged or rebased into 10.3. Other features that depend on your refactoring and need be in the compat branch, can be pushed directly into 10.2-ext. Are there features that should not be in 10.2-compat but still depend on your refactorings? On Dec 16, Alexander Barkov wrote:
Hello Serg, all,
A few weeks ago I created a new branch "10.3" and pushed essential patches needed for the compatibility project.
It worked as follows: - In 10.3: git rebase origin/10.2 git push --force
- In bb-10.2-compatibility: git rebase origin/10.3 git push --force
Now as other developers start to push into 10.3, this won't work anymore. We briefly discussed with Monty that, as the compatibility project should be as stable as possible and merging all 10.3 patches into bb-10.2-compatibility is not desirable, we could try something like this:
Add a new branch (Monty proposed "10.3-base" as the name) and propagate changes as follows:
- In 10.3-base: git rebase origin/10.2 git push --force
- In bb-10.2-compatibility git rebase origin/10.3-base git push --force
- In 10.3: git merge origin/10.3-base git push (no --force)
10.2 ---(rebase)--->10.3-base--(rebase)-->bb-10.2-compatibility | | (merge) (merge) | | V | 10.3<-----------------/
Any objections about this scheme?
I'd only propose to use "10.2-ext" instead of "10.3-base", as this intermediate branch is going to be more 10.2 than 10.3.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi Sergei, Thanks! Please see my replies inline: On 12/16/2016 05:38 PM, Sergei Golubchik wrote:
Hi, Alexander!
Sure, 10.2-ext or 10.3-base - whatever you prefer. I understand that bb-10.2-compatibility will be eventually pushed into 10.3 too, when it'll be ready.
Correct.
For now, I'd suggest the following:
10.2----------------------->10.3 \ \- 10.2-ext ---> 10.2-compat
and eventually 10.2-ext and 10.2-compat are getting merged or rebased into 10.3.
I created a new branch bb-10.2-ext. So the tentative data flow looks like this: 10.2---------->10.3 <---(once) \ ^ ^ \ | | \- bb-10.2-ext ---> bb-10.2-compatibility - 10.2 will be periodically merged to 10.3. - bb-10.2-ext will be periodically rebased on top of 10.2 - bb-10.2-compatibility will be periodically rebased on top of bb-10.2-ext. - bb-10.2-ext will be periodically merged to 10.3 - bb-10.2-compatibility will once (when it's ready) be merged or rebased to 10.3 Every time I rebase bb-10.2-ext on top of the current 10.2, I can merge bb-10.2-ext to 10.3 immediately, so we don't have to do double work.
Other features that depend on your refactoring and need be in the compat branch, can be pushed directly into 10.2-ext.
Correct. Note, by refactoring I mean two things: - Moving pieces of the code from sql_yacc.yy as methods to LEX, sp_head, THD, etc. This is to avoid duplicate code in sql_yacc_ora.yy. - Some Type_handler related patches.
Are there features that should not be in 10.2-compat but still depend on your refactorings?
Sanja and I are thinking of pushing MDEV-10141 Add support for INTERSECT (and common parts for EXCEPT) into bb-10.2-ext when it's ready. There will be more tasks, I think.
On Dec 16, Alexander Barkov wrote:
Hello Serg, all,
A few weeks ago I created a new branch "10.3" and pushed essential patches needed for the compatibility project.
It worked as follows: - In 10.3: git rebase origin/10.2 git push --force
- In bb-10.2-compatibility: git rebase origin/10.3 git push --force
Now as other developers start to push into 10.3, this won't work anymore. We briefly discussed with Monty that, as the compatibility project should be as stable as possible and merging all 10.3 patches into bb-10.2-compatibility is not desirable, we could try something like this:
Add a new branch (Monty proposed "10.3-base" as the name) and propagate changes as follows:
- In 10.3-base: git rebase origin/10.2 git push --force
- In bb-10.2-compatibility git rebase origin/10.3-base git push --force
- In 10.3: git merge origin/10.3-base git push (no --force)
10.2 ---(rebase)--->10.3-base--(rebase)-->bb-10.2-compatibility | | (merge) (merge) | | V | 10.3<-----------------/
Any objections about this scheme?
I'd only propose to use "10.2-ext" instead of "10.3-base", as this intermediate branch is going to be more 10.2 than 10.3.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
On Mon, Dec 19, 2016 at 10:49:42AM +0400, Alexander Barkov wrote:
Hi Sergei,
Thanks! Please see my replies inline:
On 12/16/2016 05:38 PM, Sergei Golubchik wrote:
Hi, Alexander!
Sure, 10.2-ext or 10.3-base - whatever you prefer. I understand that bb-10.2-compatibility will be eventually pushed into 10.3 too, when it'll be ready.
Correct.
For now, I'd suggest the following:
10.2----------------------->10.3 \ \- 10.2-ext ---> 10.2-compat
and eventually 10.2-ext and 10.2-compat are getting merged or rebased into 10.3.
I created a new branch bb-10.2-ext.
So the tentative data flow looks like this:
10.2---------->10.3 <---(once) \ ^ ^ \ | | \- bb-10.2-ext ---> bb-10.2-compatibility
- 10.2 will be periodically merged to 10.3. - bb-10.2-ext will be periodically rebased on top of 10.2 - bb-10.2-compatibility will be periodically rebased on top of bb-10.2-ext. - bb-10.2-ext will be periodically merged to 10.3 - bb-10.2-compatibility will once (when it's ready) be merged or rebased to 10.3
Every time I rebase bb-10.2-ext on top of the current 10.2, I can merge bb-10.2-ext to 10.3 immediately, so we don't have to do double work.
Maybe I am missing something, but suppose somebodty has pushed the code for MDEV-10141 (for example, I am using this MDEV as it is mentioned below) into bb-10.2-ext. Then, you rebase bb-10.2-ext on top of 10.2. This will cause another commit for MDEV-10141 to be created. Then you merge it to 10.3. This means 10.3 will have two commits for MDEV-10141. If you do the above process N times, 10.3 will have 1..N copies of everything that was pushed into bb-10.2-ext. Is that the intent?
Other features that depend on your refactoring and need be in the compat branch, can be pushed directly into 10.2-ext.
Correct.
Note, by refactoring I mean two things: - Moving pieces of the code from sql_yacc.yy as methods to LEX, sp_head, THD, etc. This is to avoid duplicate code in sql_yacc_ora.yy.
- Some Type_handler related patches.
Are there features that should not be in 10.2-compat but still depend on your refactorings?
Sanja and I are thinking of pushing
MDEV-10141 Add support for INTERSECT (and common parts for EXCEPT)
into bb-10.2-ext when it's ready.
There will be more tasks, I think.
On Dec 16, Alexander Barkov wrote:
Hello Serg, all,
A few weeks ago I created a new branch "10.3" and pushed essential patches needed for the compatibility project.
It worked as follows: - In 10.3: git rebase origin/10.2 git push --force
- In bb-10.2-compatibility: git rebase origin/10.3 git push --force
Now as other developers start to push into 10.3, this won't work anymore. We briefly discussed with Monty that, as the compatibility project should be as stable as possible and merging all 10.3 patches into bb-10.2-compatibility is not desirable, we could try something like this:
Add a new branch (Monty proposed "10.3-base" as the name) and propagate changes as follows:
- In 10.3-base: git rebase origin/10.2 git push --force
- In bb-10.2-compatibility git rebase origin/10.3-base git push --force
- In 10.3: git merge origin/10.3-base git push (no --force)
10.2 ---(rebase)--->10.3-base--(rebase)-->bb-10.2-compatibility | | (merge) (merge) | | V | 10.3<-----------------/
Any objections about this scheme?
I'd only propose to use "10.2-ext" instead of "10.3-base", as this intermediate branch is going to be more 10.2 than 10.3.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog
Hello Sergey, On 12/19/2016 07:26 PM, Sergey Petrunia wrote:
On Mon, Dec 19, 2016 at 10:49:42AM +0400, Alexander Barkov wrote:
Hi Sergei,
Thanks! Please see my replies inline:
On 12/16/2016 05:38 PM, Sergei Golubchik wrote:
Hi, Alexander!
Sure, 10.2-ext or 10.3-base - whatever you prefer. I understand that bb-10.2-compatibility will be eventually pushed into 10.3 too, when it'll be ready.
Correct.
For now, I'd suggest the following:
10.2----------------------->10.3 \ \- 10.2-ext ---> 10.2-compat
and eventually 10.2-ext and 10.2-compat are getting merged or rebased into 10.3.
I created a new branch bb-10.2-ext.
So the tentative data flow looks like this:
10.2---------->10.3 <---(once) \ ^ ^ \ | | \- bb-10.2-ext ---> bb-10.2-compatibility
- 10.2 will be periodically merged to 10.3. - bb-10.2-ext will be periodically rebased on top of 10.2 - bb-10.2-compatibility will be periodically rebased on top of bb-10.2-ext. - bb-10.2-ext will be periodically merged to 10.3 - bb-10.2-compatibility will once (when it's ready) be merged or rebased to 10.3
Every time I rebase bb-10.2-ext on top of the current 10.2, I can merge bb-10.2-ext to 10.3 immediately, so we don't have to do double work.
Maybe I am missing something, but suppose somebodty has pushed the code for MDEV-10141 (for example, I am using this MDEV as it is mentioned below) into bb-10.2-ext.
Then, you rebase bb-10.2-ext on top of 10.2. This will cause another commit for MDEV-10141 to be created.
This is something I didn't know. I thought it will reuse the same commit hash after rebasing.
Then you merge it to 10.3. This means 10.3 will have two commits for MDEV-10141. If you do the above process N times, 10.3 will have 1..N copies of everything that was pushed into bb-10.2-ext. Is that the intent?
No, this is not the intent. So it seems rebase does not work, only merge works. Thanks for bringing this up!
Other features that depend on your refactoring and need be in the compat branch, can be pushed directly into 10.2-ext.
Correct.
Note, by refactoring I mean two things: - Moving pieces of the code from sql_yacc.yy as methods to LEX, sp_head, THD, etc. This is to avoid duplicate code in sql_yacc_ora.yy.
- Some Type_handler related patches.
Are there features that should not be in 10.2-compat but still depend on your refactorings?
Sanja and I are thinking of pushing
MDEV-10141 Add support for INTERSECT (and common parts for EXCEPT)
into bb-10.2-ext when it's ready.
There will be more tasks, I think.
On Dec 16, Alexander Barkov wrote:
Hello Serg, all,
A few weeks ago I created a new branch "10.3" and pushed essential patches needed for the compatibility project.
It worked as follows: - In 10.3: git rebase origin/10.2 git push --force
- In bb-10.2-compatibility: git rebase origin/10.3 git push --force
Now as other developers start to push into 10.3, this won't work anymore. We briefly discussed with Monty that, as the compatibility project should be as stable as possible and merging all 10.3 patches into bb-10.2-compatibility is not desirable, we could try something like this:
Add a new branch (Monty proposed "10.3-base" as the name) and propagate changes as follows:
- In 10.3-base: git rebase origin/10.2 git push --force
- In bb-10.2-compatibility git rebase origin/10.3-base git push --force
- In 10.3: git merge origin/10.3-base git push (no --force)
10.2 ---(rebase)--->10.3-base--(rebase)-->bb-10.2-compatibility | | (merge) (merge) | | V | 10.3<-----------------/
Any objections about this scheme?
I'd only propose to use "10.2-ext" instead of "10.3-base", as this intermediate branch is going to be more 10.2 than 10.3.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Hi, Alexander! On Dec 19, Alexander Barkov wrote:
I created a new branch bb-10.2-ext.
So the tentative data flow looks like this:
10.2---------->10.3 <---(once) \ ^ ^ \ | | \- bb-10.2-ext ---> bb-10.2-compatibility
- 10.2 will be periodically merged to 10.3. - bb-10.2-ext will be periodically rebased on top of 10.2 - bb-10.2-compatibility will be periodically rebased on top of bb-10.2-ext. - bb-10.2-ext will be periodically merged to 10.3
No, please, never do that. You cannot have "bb-10.2-ext will be periodically rebased" and "bb-10.2-ext will be periodically merged to 10.3" both at the same time. If you've merged some commit into 10.3, you cannot rebase it anymore. You can either "periodically rebase bb-10.2-ext on 10.2" or "periodically merge bb-10.2-ext in 10.3" I suggest the former.
- bb-10.2-compatibility will once (when it's ready) be merged or rebased to 10.3
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi Sergei, On 12/19/2016 08:29 PM, Sergei Golubchik wrote:
Hi, Alexander!
On Dec 19, Alexander Barkov wrote:
I created a new branch bb-10.2-ext.
So the tentative data flow looks like this:
10.2---------->10.3 <---(once) \ ^ ^ \ | | \- bb-10.2-ext ---> bb-10.2-compatibility
- 10.2 will be periodically merged to 10.3. - bb-10.2-ext will be periodically rebased on top of 10.2 - bb-10.2-compatibility will be periodically rebased on top of bb-10.2-ext. - bb-10.2-ext will be periodically merged to 10.3
No, please, never do that. You cannot have "bb-10.2-ext will be periodically rebased" and "bb-10.2-ext will be periodically merged to 10.3" both at the same time. If you've merged some commit into 10.3, you cannot rebase it anymore.
You can either "periodically rebase bb-10.2-ext on 10.2" or "periodically merge bb-10.2-ext in 10.3"
I suggest the former.
Right, as Sergey Pertrunya explained, this will generate duplicate commits in 10.3 for everything in bb-10.2-ext. I didn't know about this. So the only way to do it correctly is to merge from 10.2 to bb-10.2-ext. Let's describe it again: 10.2---------->10.3 <---(once) \ ^ ^ \ | | \- bb-10.2-ext ---> bb-10.2-compatibility 1. 10.2 will be periodically merged to 10.3. 2. 10.2 will be periodically merged to bb-10.2-ext 3. bb-10.2-ext will be periodically merged to 10.3 4. bb-10.2-compatibility will be periodically rebased on top of bb-10.2-ext. 5. bb-10.2-compatibility will once merged to 10.3 To save some duplicate merge work: whenever we do #2 we also do #3. Does it sound correct now? Thanks!
- bb-10.2-compatibility will once (when it's ready) be merged or rebased to 10.3
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (3)
-
Alexander Barkov -
Sergei Golubchik -
Sergey Petrunia