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