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 [email protected] > _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
