Branch management for OE-Core release

Branch management for OE-Core release

[Otavio Salvador]

Hello,

I noticed the 2011-1 branch today and it seems it is not fully merged
into master; this is a mistake since it will create an upgrade path
problem for users of it.

How this is going to be managed?

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Branch management for OE-Core release

[Richard Purdie]

On Thu, 2011-09-22 at 09:49 -0300, Otavio Salvador wrote:
> I noticed the 2011-1 branch today and it seems it is not fully merged
> into master; this is a mistake since it will create an upgrade path
> problem for users of it.

Its a branch, master continues on, that branch just gets fixes suitable
for a stable/release branch. I appreciate people have different
definitions of stable and we need to do a better job of documenting what
those criteria are. As a quick attempt:

I've always said with "stable" branches, its up to the person
maintaining it to define what it means. Right now, I'm trying to get a
branch where all the Yocto QA tests pass so it has some base
functionality across all the different architectures, image targets,
SDKs and so forth.

Longer term I'm initially proposing it will take the same kinds of
changes as we'd take for point releases in Yocto. These are high impact
bug fixes, build system OS fixes as new distros appear and security
issues that we're aware of. What is out of scope are new features and
significant version changes. The QT version increment is marginal in
that regard. If after release when we have more time to test it works
out ok it might be considered being just a point release and not a major
version change.

Cheers,

Richard

Re: Branch management for OE-Core release

[Otavio Salvador]

On Thu, Sep 22, 2011 at 20:33, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2011-09-22 at 09:49 -0300, Otavio Salvador wrote:
>> I noticed the 2011-1 branch today and it seems it is not fully merged
>> into master; this is a mistake since it will create an upgrade path
>> problem for users of it.
>
> Its a branch, master continues on, that branch just gets fixes suitable
> for a stable/release branch. I appreciate people have different
> definitions of stable and we need to do a better job of documenting what
> those criteria are. As a quick attempt:

The point here is not about what is allowed to get into it or not but
how it is going to work related to master.

The point is that if we keep it as a branch and doesn't merge it into master.

If we merge the stable branch into master, from time to time, users
that want to go to move to master can merge master into their branch
as it has a common parent and the conflicts fixed. If it is done too
late, it becomes a nightmare.

This is something I'd like to discuss and see how people think about
the process and what way we ought to use.
-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Branch management for OE-Core release

[Richard Purdie]

On Fri, 2011-09-23 at 13:41 -0300, Otavio Salvador wrote:
> On Thu, Sep 22, 2011 at 20:33, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Thu, 2011-09-22 at 09:49 -0300, Otavio Salvador wrote:
> >> I noticed the 2011-1 branch today and it seems it is not fully merged
> >> into master; this is a mistake since it will create an upgrade path
> >> problem for users of it.
> >
> > Its a branch, master continues on, that branch just gets fixes suitable
> > for a stable/release branch. I appreciate people have different
> > definitions of stable and we need to do a better job of documenting what
> > those criteria are. As a quick attempt:
> 
> The point here is not about what is allowed to get into it or not but
> how it is going to work related to master.
> 
> The point is that if we keep it as a branch and doesn't merge it into master.
> 
> If we merge the stable branch into master, from time to time, users
> that want to go to move to master can merge master into their branch
> as it has a common parent and the conflicts fixed. If it is done too
> late, it becomes a nightmare.
> 
> This is something I'd like to discuss and see how people think about
> the process and what way we ought to use.

I don't really see the point of this. Basically you're asking that every
time there is a commit to the branch there is also a merge commit. You
can just as easily either force a checkout of master, or merge against
master with a one sided merge. Git doesn't have the confidence to do
that automatically but I'm pretty sure there is a simple way to tell git
to do a one sided merge...

Cheers,

Richard

Re: Branch management for OE-Core release

[Otavio Salvador]

On Fri, Sep 23, 2011 at 14:30, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
...
> I don't really see the point of this. Basically you're asking that every
> time there is a commit to the branch there is also a merge commit. You
> can just as easily either force a checkout of master, or merge against
> master with a one sided merge. Git doesn't have the confidence to do
> that automatically but I'm pretty sure there is a simple way to tell git
> to do a one sided merge...

Not every time but at every release and point release.

one sided merge make you lose all local changes you did. Doesn't seems
a valid upgrade path but a "replace path".

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Branch management for OE-Core release

[Chris Larson]

On Fri, Sep 23, 2011 at 11:12 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Fri, Sep 23, 2011 at 14:30, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> ...
>> I don't really see the point of this. Basically you're asking that every
>> time there is a commit to the branch there is also a merge commit. You
>> can just as easily either force a checkout of master, or merge against
>> master with a one sided merge. Git doesn't have the confidence to do
>> that automatically but I'm pretty sure there is a simple way to tell git
>> to do a one sided merge...
>
> Not every time but at every release and point release.
>
> one sided merge make you lose all local changes you did. Doesn't seems
> a valid upgrade path but a "replace path".

I agree that we should do this, personally. I think there's almost
always value in merging things back to master on occasion, whether a
release branch or a stable branch or anything of the sort.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Branch management for OE-Core release

[Richard Purdie]

On Fri, 2011-09-23 at 15:12 -0300, Otavio Salvador wrote:
> On Fri, Sep 23, 2011 at 14:30, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> ...
> > I don't really see the point of this. Basically you're asking that every
> > time there is a commit to the branch there is also a merge commit. You
> > can just as easily either force a checkout of master, or merge against
> > master with a one sided merge. Git doesn't have the confidence to do
> > that automatically but I'm pretty sure there is a simple way to tell git
> > to do a one sided merge...
> 
> Not every time but at every release and point release.
> 
> one sided merge make you lose all local changes you did. Doesn't seems
> a valid upgrade path but a "replace path".

Equally, merging against master would make things much more difficult
for anyone wanting to cherry-pick patches over which we've not picked in
the main release branch. Since creating "enhanced" rellease branches is
something we want to support/encourage, I'm still not convinced a load
of merge commits are a good idea.

FWIW, something like git cherry can identify your local changes so you
could apply them on top of master so there are other ways to make your
usecase work...

Cheers,

Richard

Re: Branch management for OE-Core release

[Otavio Salvador]

On Mon, Sep 26, 2011 at 06:23, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
...
> FWIW, something like git cherry can identify your local changes so you
> could apply them on top of master so there are other ways to make your
> usecase work...

This breaks the value of using a SCM since you won't have a common parent.

As Chris, I'd prefer to have it merged.

The only way it can complicate issue is if fixes are cherry-picked
into the stable branch. If they're are done into the stable and merged
into master this works wonderfully.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Branch management for OE-Core release

[Richard Purdie]

On Mon, 2011-09-26 at 09:27 -0300, Otavio Salvador wrote:
> On Mon, Sep 26, 2011 at 06:23, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> ...
> > FWIW, something like git cherry can identify your local changes so you
> > could apply them on top of master so there are other ways to make your
> > usecase work...
> 
> This breaks the value of using a SCM since you won't have a common parent.
> 
> As Chris, I'd prefer to have it merged.
> 
> The only way it can complicate issue is if fixes are cherry-picked
> into the stable branch. If they're are done into the stable and merged
> into master this works wonderfully.

No, this just just plain wrong. Changes go into master which is where
development happens. They can then filter into other branches (there may
be more than one) as needed.

To illustate the problem, if a change is needed in two different release
branches you'd commit to both and then cherry-pick both into master?

Cheers,

Richard

Re: Branch management for OE-Core release

[Otavio Salvador]

On Mon, Sep 26, 2011 at 09:47, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
...
> To illustate the problem, if a change is needed in two different release
> branches you'd commit to both and then cherry-pick both into master?

No, I'd merge it into master.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: Branch management for OE-Core release

[Chris Larson]

On Mon, Sep 26, 2011 at 5:47 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Mon, 2011-09-26 at 09:27 -0300, Otavio Salvador wrote:
>> On Mon, Sep 26, 2011 at 06:23, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>> ...
>> > FWIW, something like git cherry can identify your local changes so you
>> > could apply them on top of master so there are other ways to make your
>> > usecase work...
>>
>> This breaks the value of using a SCM since you won't have a common parent.
>>
>> As Chris, I'd prefer to have it merged.
>>
>> The only way it can complicate issue is if fixes are cherry-picked
>> into the stable branch. If they're are done into the stable and merged
>> into master this works wonderfully.
>
> No, this just just plain wrong. Changes go into master which is where
> development happens. They can then filter into other branches (there may
> be more than one) as needed.

Agreed. No unique changes should generally go into a release or stable
branch first. Master is where future development happens by
definition. The only time a bugfix should go into the stable/release
branch directly is if master has deviated sufficiently such that
fixing it there + cherry picking no longer makes sense.

I do still think there's a certain amount of value in a periodic merge
back, however. Primarily because this encodes knowledge into the
repository about the fact that yes, every single fix in the
release/stable branch is in fact also in master. Someone looking at
the repository, lacking knowledge about our particular branching
policies, will be able to see this by use of rev-list/log.

Just the other day I was doing a conversion from svn to git for a
project and ran into a related issue. There was no merge metadata in
svn from the release branches back to master, so now I have to
painstakingly step through and make absolutely certain all the fixes
went into both. For old releases, this is particularly difficult (and
I think is part of otavio's concern), as you can no longer just merge
from release/stable to master sanely, due to refactoring, renames, etc
on the master branch.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: Branch management for OE-Core release

[Otavio Salvador]

On Mon, Sep 26, 2011 at 11:38, Chris Larson <clarson@kergoth.com> wrote:
...
> Just the other day I was doing a conversion from svn to git for a
> project and ran into a related issue. There was no merge metadata in
> svn from the release branches back to master, so now I have to
> painstakingly step through and make absolutely certain all the fixes
> went into both. For old releases, this is particularly difficult (and
> I think is part of otavio's concern), as you can no longer just merge
> from release/stable to master sanely, due to refactoring, renames, etc
> on the master branch.

I ended up abbandoning our current OE-classic tree due this. I had a
tree that was forked in 2009 and it turned to be impossible to merge
it into master since it has conflicts everywhere. The problem is that
the amount of changes we did is quite small but the lack of knowledge
of SCM regarding what changes made it the fact eaiser to start over
again.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br