maria-developers team mailing list archive

[Sergey Petrunia <sergey@xxxxxxxxxxx>]

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@xxxxxxxxxxx
> > 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-developers
> Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
> 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