[m-rev.] for review: fix bug #183

[Peter Wang]

On Thu, 23 May 2013 13:32:13 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
> 
> Hi,
> 
> On Thu, 23 May 2013, Peter Wang wrote:
> 
> > On Wed, 22 May 2013 17:53:24 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
> >>
> >> That's what I've been doing.  In this case, I simply forgot what branch
> >> my workspace was on and neglected to check.
> >
> > I've cherry-picked it onto 13.05.
> 
> Ta!
> 
> >>
> >>> and defer merges so we get fewer of them?
> >>
> >> Given that the rotds are taken off the master branch, aren't you simply
> >> go to defer bug-fixes going into the rotds by doing that?
> >>
> >
> > Yes.  The rotd script can simply merge the 13.05 branch into master
> > first, with a single command.  If the merge fails we simply don't get
> > the release-of-that-day, as for a bootcheck failure.
> 
> Is there are rationale for this other than wanting fewer merges from
> the release branch?   IMO, if fixes are intended for both branches,
> then they should go on both branches (immediately).

Not really.  Maybe less effort, as you're not compelled to merge+push
immediately.

> >> It would be a good idea if the policies
> >> regarding branches and how they are managed were written down somewhere.
> >> Any volunteers?
> >>
> >> On sort of related note, the conversion to git has meant that there
> >> are loads of useless branches and tags in the github project.  Can we
> >> delete these?
> >
> > The unlabeled-* branches and the unstable-* and stable-* tags?
> 
> Yes, yes, and yes -- and probably yes to quite a few of the others there
> too.

"unlabeled" are apparently a result of deleted branches in CVS.
I guess they were earlier versions of the "mode-constraints" branch.

The stable/unstable tags, I guess, were automatically made to indicate
the source files for a binary package.  I see no need to keep them.

Peter