Version management and branches (again ... sorry)

RTT's master and toolchain-2.1 have diverged. Do did typelib's
earlier, and my guess is that all packages are in this state at one
point or the other.

So, I'm asking myself (again), why ...

In my mind, everything was clear: toolchain-* are used by users to avoid
being broken by a mistake in one commit. All development goes into master.

Was I mistaken ?

Version management and branches (again ... sorry)

On Wednesday 03 November 2010 14:44:44 Sylvain Joyeux wrote:
> RTT's master and toolchain-2.1 have diverged. Do did typelib's
> earlier, and my guess is that all packages are in this state at one
> point or the other.
>
> So, I'm asking myself (again), why ...
>
> In my mind, everything was clear: toolchain-* are used by users to avoid
> being broken by a mistake in one commit. All development goes into master.
>
> Was I mistaken ?

Not that I see. What is the exact problem ? Bugfixes go directly into
toolchain-2.1 and are merged 'upstream' to master, while new branches/features
branch from master and merge to master.

Peter

Version management and branches (again ... sorry)

On 11/03/2010 03:00 PM, Peter Soetens wrote:
> On Wednesday 03 November 2010 14:44:44 Sylvain Joyeux wrote:
>> RTT's master and toolchain-2.1 have diverged. Do did typelib's
>> earlier, and my guess is that all packages are in this state at one
>> point or the other.
>>
>> So, I'm asking myself (again), why ...
>>
>> In my mind, everything was clear: toolchain-* are used by users to avoid
>> being broken by a mistake in one commit. All development goes into master.
>>
>> Was I mistaken ?
> Not that I see. What is the exact problem ? Bugfixes go directly into
> toolchain-2.1 and are merged 'upstream' to master
So, yes I was mistaken. In my mind *no* development happens on the
toolchain- branches because the "merged back to master" step is mostly
forgotten. And therefore -- if I work on master -- I don't work on the
latest code.

In my mind, there was *no* direct development on the toolchain branches
because it would lead to the aforementioned problem I see right now.
Namely, people develop on two different branches all the time.

I saw it as "we develop on master and release whenever it sees fit". If
some critical changes are needed on the toolchain-XX branches, then
cherry-pick them.

Version management and branches (again ... sorry)

On Wednesday 03 November 2010 15:06:49 Sylvain Joyeux wrote:
> On 11/03/2010 03:00 PM, Peter Soetens wrote:
> > On Wednesday 03 November 2010 14:44:44 Sylvain Joyeux wrote:
> >> RTT's master and toolchain-2.1 have diverged. Do did typelib's
> >>
> >> earlier, and my guess is that all packages are in this state at one
> >> point or the other.
> >>
> >> So, I'm asking myself (again), why ...
> >>
> >> In my mind, everything was clear: toolchain-* are used by users to avoid
> >> being broken by a mistake in one commit. All development goes into
> >> master.
> >>
> >> Was I mistaken ?
> >
> > Not that I see. What is the exact problem ? Bugfixes go directly into
> > toolchain-2.1 and are merged 'upstream' to master
>
> So, yes I was mistaken. In my mind *no* development happens on the
> toolchain- branches because the "merged back to master" step is mostly
> forgotten. And therefore -- if I work on master -- I don't work on the
> latest code.

Ack.

>
> In my mind, there was *no* direct development on the toolchain branches
> because it would lead to the aforementioned problem I see right now.
> Namely, people develop on two different branches all the time.

I have no other option because I need to make bugfix releases, that can't
branch of master, but must branch of the toolchain-x.y branches.

>
> I saw it as "we develop on master and release whenever it sees fit". If
> some critical changes are needed on the toolchain-XX branches, then
> cherry-pick them.

That's harder to maintain (for me), given the number of bugfixes we apply
weekly. I'd like to merge all fixes to master, then I'm sure master has all of
them.

The good side is that you can always merge toolchain to master yourself
locally, this will always work, but may require a rebase or a merge lateron to
get in sync with the 'official' master.

Peter

Version management and branches (again ... sorry)

On Nov 4, 2010, at 09:05 , Peter Soetens wrote:

> On Wednesday 03 November 2010 15:06:49 Sylvain Joyeux wrote:
>> On 11/03/2010 03:00 PM, Peter Soetens wrote:
>>> On Wednesday 03 November 2010 14:44:44 Sylvain Joyeux wrote:
>>>> RTT's master and toolchain-2.1 have diverged. Do did typelib's
>>>>
>>>> earlier, and my guess is that all packages are in this state at one
>>>> point or the other.
>>>>
>>>> So, I'm asking myself (again), why ...
>>>>
>>>> In my mind, everything was clear: toolchain-* are used by users to avoid
>>>> being broken by a mistake in one commit. All development goes into
>>>> master.
>>>>
>>>> Was I mistaken ?
>>>
>>> Not that I see. What is the exact problem ? Bugfixes go directly into
>>> toolchain-2.1 and are merged 'upstream' to master
>>
>> So, yes I was mistaken. In my mind *no* development happens on the
>> toolchain- branches because the "merged back to master" step is mostly
>> forgotten. And therefore -- if I work on master -- I don't work on the
>> latest code.
>
> Ack.
>
>>
>> In my mind, there was *no* direct development on the toolchain branches
>> because it would lead to the aforementioned problem I see right now.
>> Namely, people develop on two different branches all the time.
>
> I have no other option because I need to make bugfix releases, that can't
> branch of master, but must branch of the toolchain-x.y branches.
>
>>
>> I saw it as "we develop on master and release whenever it sees fit". If
>> some critical changes are needed on the toolchain-XX branches, then
>> cherry-pick them.
>
> That's harder to maintain (for me), given the number of bugfixes we apply
> weekly. I'd like to merge all fixes to master, then I'm sure master has all of
> them.
>
> The good side is that you can always merge toolchain to master yourself
> locally, this will always work, but may require a rebase or a merge lateron to
> get in sync with the 'official' master.

Which master is the _actual_ master? There is a master branch in both Peter's github repo and also in the "official" repo on gitorious. And they don't seem to sync up, based on my updates from both today. Which is the canonical, official repository? I understand that v1.x branches are only in Peter's github, but what of master, stable, and the toolchain branches?

Given repositories ...

gito-official git [..] ...:orocos-toolchain/rtt.git (fetch)
official git://github.com/psoetens/orocos-rtt.git (fetch)

Why don't master's nor the toolchain branches match on both?

REPO/BRANCH Date of tip commit SHA
gito-official/toolchain-2.1 2010-11-30
gito-official/stable 2010-12-13
gito-official/master 2010-12-24 25431fb2df47563881b926685d5358bfae4df0df
gito-official/toolchain-2.2 2011-01-21

official/stable N/A
official/toolchain-2.1 2010-10-13
official/master 2010-12-24 a3e95424fa376a1c65f727b5b5add76c2b50a7c8
official/toolchain-2.2 2010-12-23

When and under what conditions do stable and master get updated? (which ever master is the official one)

Just trying to understand so that I know what to branch off for patches, to make everyone else's life easier. Once we have a consensus here, or simply a better explanation, I'll add a "Developers" wiki page and put this stuff there (unless this already exists, and I just haven't found it?). Including a description of what branch is what ... referencing Peter's September email ...

> I'm using these 'new' names for my branches on git*.com:
>
> - master : main development line, latest features. Replaces rtt-2.0-mainline
> - toolchain-2.0 : stable release branch for the 2.0 release series.
> - rtt-1.0-svn-patches: remains for svn bridge of 1.x release series
> - ocl-1.0-svn : remains for svn bridge of 1.x release series

Thanks
Stephen

Version management and branches (again ... sorry)

On Saturday 22 January 2011 20:11:47 S Roderick wrote:
> On Nov 4, 2010, at 09:05 , Peter Soetens wrote:
> > On Wednesday 03 November 2010 15:06:49 Sylvain Joyeux wrote:
> >> On 11/03/2010 03:00 PM, Peter Soetens wrote:
> >>> On Wednesday 03 November 2010 14:44:44 Sylvain Joyeux wrote:
> >>>> RTT's master and toolchain-2.1 have diverged. Do did typelib's
> >>>>
> >>>> earlier, and my guess is that all packages are in this state at one
> >>>> point or the other.
> >>>>
> >>>> So, I'm asking myself (again), why ...
> >>>>
> >>>> In my mind, everything was clear: toolchain-* are used by users to
> >>>> avoid being broken by a mistake in one commit. All development goes
> >>>> into master.
> >>>>
> >>>> Was I mistaken ?
> >>>
> >>> Not that I see. What is the exact problem ? Bugfixes go directly into
> >>> toolchain-2.1 and are merged 'upstream' to master
> >>
> >> So, yes I was mistaken. In my mind *no* development happens on the
> >> toolchain- branches because the "merged back to master" step is mostly
> >> forgotten. And therefore -- if I work on master -- I don't work on the
> >> latest code.
> >
> > Ack.
> >
> >> In my mind, there was *no* direct development on the toolchain branches
> >> because it would lead to the aforementioned problem I see right now.
> >> Namely, people develop on two different branches all the time.
> >
> > I have no other option because I need to make bugfix releases, that can't
> > branch of master, but must branch of the toolchain-x.y branches.
> >
> >> I saw it as "we develop on master and release whenever it sees fit". If
> >> some critical changes are needed on the toolchain-XX branches, then
> >> cherry-pick them.
> >
> > That's harder to maintain (for me), given the number of bugfixes we apply
> > weekly. I'd like to merge all fixes to master, then I'm sure master has
> > all of them.
> >
> > The good side is that you can always merge toolchain to master yourself
> > locally, this will always work, but may require a rebase or a merge
> > lateron to get in sync with the 'official' master.
>
> Which master is the _actual_ master? There is a master branch in both
> Peter's github repo and also in the "official" repo on gitorious. And they
> don't seem to sync up, based on my updates from both today. Which is the
> canonical, official repository? I understand that v1.x branches are only
> in Peter's github, but what of master, stable, and the toolchain branches?
>
> Given repositories ...
>
> gito-official git [..] ...:orocos-toolchain/rtt.git (fetch)
> official git://github.com/psoetens/orocos-rtt.git (fetch)
>
> Why don't master's nor the toolchain branches match on both?

Because I'm lazy. I only push to github when my personal workflow requires it,
I push to gitorious whenever new bugfixes are ready.

>
> REPO/BRANCH Date of tip commit SHA
> gito-official/toolchain-2.1 2010-11-30
> gito-official/stable 2010-12-13
> gito-official/master 2010-12-24 25431fb2df47563881b926685d5358bfae4df0df
> gito-official/toolchain-2.2 2011-01-21
>
> official/stable N/A
> official/toolchain-2.1 2010-10-13
> official/master 2010-12-24
a3e95424fa376a1c65f727b5b5add76c2b50a7c8
> official/toolchain-2.2 2010-12-23
>
> When and under what conditions do stable and master get updated? (which
> ever master is the official one)

master gets updated when new branches are merged into it by its maintainer.
This can be a merge from the bugfix branches (ie merge from toolchain-2.x) or a
merge from a development branch.

stable should always point to the latest toolchain-2.x tip. Since I don't yet
have a way to automate this, it's lagging. Probably something for a hudson job
or a git commit hook.

>
> Just trying to understand so that I know what to branch off for patches, to
> make everyone else's life easier. Once we have a consensus here, or simply
> a better explanation, I'll add a "Developers" wiki page and put this stuff
> there (unless this already exists, and I just haven't found it?).
> Including a description of what branch is what ... referencing Peter's
> September email ...

I think this branch info is indeed lacking in the wiki.

>
> > I'm using these 'new' names for my branches on git*.com:
> >
> > - master : main development line, latest features. Replaces
> > rtt-2.0-mainline - toolchain-2.0 : stable release branch for the 2.0
> > release series. - rtt-1.0-svn-patches: remains for svn bridge of 1.x
> > release series - ocl-1.0-svn : remains for svn bridge of 1.x release
> > series
>
> Thanks
> Stephen

Peter