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