openerp-community team mailing list archive
Mailing list archive
Re: Work in progress: OCB 7.0 on github
Lionel Sausin <ls@xxxxxxxxxxxxxxxx>
Thu, 12 Jun 2014 17:39:02 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
If OCB is not supposed to be a fork, then act like you are not the
"upstream", just a branch like the others.
Make sure it merges cleanly into official, and make the history clean
you can. If rebase does that then I'd say go ahead.
From my point of view it's OK and cleaner to rebase OCB, because I for
one won't mirror OCB on the production server.
I'll simply fork the official branches and then merge OCB just like my
other feature/bugfix branches, and re-merge from time to time.
The big bonus of this approach is that you get a very clear upgrade log
of the production server which is always handy to track regressions.
Le 12/06/2014 16:26, Raphael Valyi a écrit :
I know that last Friday the two topics were running in parallel:
1) the replay of OCB
2) and systematic rebase at OCB update
In fact we started investigating more deeply the concrete consequences
of a systematic rebase of OCB in French with Alexandre en Sandy.
So in case you missed it, by rebasing OCB systematically at every
update from upstream odoo:
clean history with explicit patches that can easily be shared
between OCB 7.0, 8.0 or official branches. That's kind of giving a
chance for OCB not being a fork ;-p
despite OCB will be the final branch for may be 80% of the use case,
in may be 20% of the use case, people will still need to add extra
patches on it, mostly if a patch has not been accepted in upstream OCB
or if it's an assumed quick and dirty patch with no universality
pretension as it does happen sometimes.
In that case, when updating from upstream OCB, people might get a
"detached branch" with their old sha1 that they had deployed
previously. Then they may need to tag that sha1 to avoid it to be
garbage collected automatically... In the case they want to replicate
an install with the former sha1 they used in production (say for
hunting a regression), then they may need to push that detached sha1
somewhere because it would have no meaning on a fresh checkout of OCB...
I mean that's really a lot of plumbing to assume...
I will gladly listen to git experts, but my preference today is to go
merge instead of rebase, despite the mess. If we go for rebase, well
then that plumping should be assumed, specially in tools like Anybox
recipe against many of us are now converging.
Founder and consultant
+55 21 3942-2434
On Thu, Jun 12, 2014 at 10:38 AM, Stefan <stefan@xxxxxxxx
thanks for taking a look!
On 12-06-14 15:02, Raphael Valyi wrote:
I have no doubt that it's better to manage the final patches
of a branch with Github rebase interactive. Now I'm not 100%
convinced yet it's the best for OCB given OCB may still
receive additional local patches for production (were no
agreement exists yet or because it's a qucik and dirty
production hotfix without hope to merge it upstream).
Because one should remember that derivating from a branch that
is rebased constantly is possible but not easy.
You could be right about that. I'll do some tests myself, and
maybe some of the other more git-knowledgeable people can chip in.
Therp - Maatwerk in open ontwikkeling
Stefan Rijnhart - Ontwerp en implementatie
mail: stefan@xxxxxxxx <mailto:stefan@xxxxxxxx>
tel: +31 (0) 614478606 <tel:%2B31%20%280%29%20614478606>
Mailing list: https://launchpad.net/~openerp-community
Post to : openerp-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp