Re: GOP-PROP 12: keep master in ready-to-release state (probable decision)

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Fri, Sep 23, 2011 at 03:03:46PM +0200, David Kastrup wrote:
>> But we still need to find a solution where I have a chance of getting
>> work done.
>
> dev/staging
>
> I just realized that I forgot to add this to the proposal.  I'll
> do that later tonight and send an updated version.
>
> Or better yet -- dev/lexer-fixes.  Suppose that (almost) all your
> work for the past 2 weeks went onto that branch.  You think you're
> done, so ask if it's ok to merge with master.  James tests it,
> sends you the output of "make doc" failing; you work a bit more,
> maybe revert something, then announce that you think it's working
> now.  James tests again -- and since this is a major merge, he
> tests a completely blank build dir, doing a full make doc, etc --
> and this time it passes.  Merge happens, git master doens't break,
> much celebrations by everybody.

Well, git master breaks with Python errors right now (when just doing
make all, while trying to generate man pages as far as I can tell).  The
merge would have been fine before that, short of the preexisting bug in
the documentation I fixed and committed this morning.

Whatever.

By the way: reverting a merge commit (like I did) is not a really good
idea.  In the history, this revert looks like an ordinary commit.  If
you now remerge the branch at a later point of time, all old commits in
this branch have already been merged according to git, and are not
merged again.  And go missing.  So you need to revert the revert first.
Ugh.

That's really a big wart on the do-as-single-merge-commit approach.

-- 
David Kastrup