Re: cvs diffs wrong + doc merge proposal + branching gripe

[Rob Browning]

Thien-Thi Nguyen <address@hidden> writes:

> probably i'm not the first to notice this, but has anyone got a clue
> on how to make correct the cvs diffs sent to guile-cvs mailing list?
> it seems the branching has confused some script mightily.

What's the command the script is running?

> in other news, i've started to make small changes in the doc subdir
> for 1.6 branch.  rather than laboriously trying to sync every change
> w/ the main branch, i'm in favor of one big merge at the end (at
> least for docs), around release time.  any objections?  i suppose
> this approach can be used generally, not just for docs (e.g., the
> examples/ "make check" support).

FWIW, thats fine with me.

> i think branching has been more trouble than its worth,
> unfortunately.  it seems there hasn't been enough parallel
> development on the main branch to warrant branching in the first
> place.  maybe next time we can keep it simple and avoid branching
> altogether?  the cost, requiring a delay in "main branch" checkins,
> is not so great if those checkins are low volume as we are seeing
> here.

Well, we can try to get by without branching, but I suspect that might
become more difficult as we get bigger and have more developers
(presuming we do).  Branching does require a little bit more attention
from the developers, but it seems to me to be a fairly good (though
not ideal) solution to the problem of getting a stable release out and
then maintaining that release in the (so far fairly long) interim
between stable releases.

It's worked fairly well in at least one other large project I've been
involved in, but by all means, if it's causing people too much
trouble, better we drop it.

That said, are there specific issues that you think could be
addressed?  And for the issues, what would be the non-branched
alternate approach?  (Whatever we do, I do think we need to be careful
to consider the various approaches in their totality so we don't end
up playing "aggravating issue whack-a-mole".)

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD