Consider sticking to one active branch in tarantool fork
Currently we use two branches. x.y.z-picodata and picodata-submodule. First one represents our patches on top of upstream x.y.z tag. picodata-submodule carries some additional patches on top of x.y.z-picodata.
The point is that two branches pose aditional maintenance overhead. These branches should be kept in sync in order to avoid situations when patch is merged only into one branch but is needed in the other one too.
For example consider this MR: !105 (merged) It was merged into main 2.11.0-picodata branch, but not into picodata-submodule branch. So one needs to spend time to figure out what is the problem, whether it was already fixed in another branch, cherry-pick/merge it into another branch, etc.
Also there is always a question which branch to make patch against.
Suggested solution is to keep only one branch - versioned x.y.z-picodata. As @gmoshkin said there are only a couple of changes that exist only in picodata-submodule. In general we agreed that having only one branch would be simpler but we need to make sure this wont brake anything with these changes. to include them in versioned version of the product (though we agreed that we should double check).
List of changes:
- Ability to call statically compiled stored procedures with
.foo - Rpc call handler sets current fiber name to the name of current stored procedure. While adding some overhead its expected to be negligible.
Another point for this approach is that we'd do this eventually anyway because there should
be single picodata distribution and not separate picodata-tarantool pointing to x.y.z-picodata
and picodata itself using picodata-submodule
This also simplifies release process.