maria-developers team mailing list archive

[Alexander Barkov <bar@xxxxxxxxxxx>]

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@xxxxxxxxxxx
>