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

[Martin Grabmueller]

> From: Rob Browning <address@hidden>
> Date: 18 Jul 2001 10:48:46 -0500
> 
> Thien-Thi Nguyen <address@hidden> writes:
> 
> > 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.

Personally, I have tried to keep the branches in sync when committing
changes.  Up to now, this has been easy, because it's only a `diff'
followed by a `patch'.  But this will change, of course, as people
start hacking on the HEAD branch again.  Merging in big chunks is fine
with me too.  It's just that I (personally) prefer to merge more
often, because it's easier for me to keep track of what I have done,
and what still needs to be done.  And then, I have been doing
seld-contained local patches, which were easy to merge.

> > 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.

There is a true point here, but as you have said, it seems so annoying
because there has been no independent work on the unstable branch.  As
soon as all obvious bugs and buglets have been fixed, there won't be
much work on the stable branch anyway, and it will only be for
bugfixing.

> 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.

I support the idea of having a branch for bugfix releases.  As an
example: It would have been very nice in the past if we had the
possibility to release bugfix releases for 1.4 more easily (1.4.1 with
a fix for the `duplicate definition of inet_aton' for example ;-) And
I think maintaining such releases is more easy with dedicated branches
for a release series.

> 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.

I vote for keeping it.  But I also vote for kicking out 1.6 faster.
At least a 1.6-pre1 or something to get people started on testing a
tarball release.

This said: What is the status of the stuff in TODO?  At least this can
be marked with a `+' I think:

  - [ttn] write "make check" tests for subdir `examples'

Is someone working on the rest?  I think most of the listed items is
`Maintainer's work' (after all, they are responsible for the release),
but if they don't mind, I can look into that too.

We shouldn't be over-careful with the release.  Guile 1.6 will be cool
enough wrt 1.4 to excuse some inaccuracies in doc files.

Regards,
  'martin