Re: HEADS UP: pending guile-gnome changes require HEAD G-Wrap

[Greg Troxel]

  * Changes made (merged into) the master archive must not introduce
    dependencies on unreleased tool versions. 

    In this concrete case, this would have meant I would have tested the
    changes in my private archive, released a new G-Wrap version and
    after that pushed changes into the master archive, along with a
    HEADS-UP message. Sounds OK?

Yes, that sounds fine.

There's a larger issue lurking which is how stable the underlying
tools are, but in this case g-wrap and guile-gnome are coevolving and
that seems fine and too hard to avoid.

  >   All releases from official repositories - not from private ones.
  >
  I already pestered Wingo about this. He was opposed to doing that
  since he can't "lock" the master archive during release as opposed to
  his private one. IIRC, he said the two possibilities would be either
  using release branches on the master archive, or using his private
  archive. I don't think either is inherently superior, since his
  archive is public, and I think using a private archive is more
  convinient than dealing with the (many) release branches in the master
  archive. 

<flamebait>This sounds like arch is inadequate, then.</>

The fact that his archive is public is helpful, but that's really not
the point.  The project has an official archive, and all releases
should correspond exactly to some tag in that archive.

If the real archive is the one he uses, then perhaps we should just
give up on the fiction that the currently-declared-official one
matters, repoint the 'official archive' at Wingo's, and let him merge
things from others and be the only one with write privs.

Is the issue that we are trying to have releases be (cvs speak) point
tags on the head, and that someone else might commit a changeset to
head around release time?  I can think of two easy ways around this:

a) Create a branch for each release.  If no recent/problematic commits
happen, this won't have any changes.  Label the branch with a point
tag to correspond to the release.

b) When ready for release, declare code freeze on the list, check it,
and tag it.  Release announcement lifts freeze.

It seems really large projects (e.g. NetBSD) do (a) and then stabilize
the branch.  This project is way too small for this, so (b) sounds
fine.

  We agreed, however, that the person doing the release would push all
  changes made to the release branches (in this case in his private
  archive) back to the master immediatly after doing the actual release.

I would suggest that the desired property is that it should be
possible to generate, with little to no human work, the exact release
contents (modulo autotools version fuzz, which is a separate issue) by
checking out a particular tag from the project's archive.  If
locking/synchronization is the problem, I don't see how merging
changesets from a private archive after a release is going to provide
this property.  And, since that has to be dealt with, it might as well
be done before release, avoiding the
release-not-from-project's-official-archive bug.

Surely other projects using arch can deal with this issue.  I'm not an
arch weenie yet, so I can't help here with the details - but I suspect
using outside-arch locking (i.e. email) would suffice.

  >   Clarity about this in NEWS, README, download pages etc.
  >

  Could you elaborate a bit what information specifically you want to
  have in these places?

Perhaps this is ok now; I've pointed out a number of things in the
past.  When you push a changeset to guile-gnome that changes the rules
about which g-wrap is needed, that needs a change in README that says
what the prereqs are, on the web page, and a note to the list.  (The
web page seems to have moved to www.gnu.org, but the archive is still
at gna?  There is no news entry about the web page moving back.
http://home.gna.org/guile-gnome/ redirects to
http://www.gnu.org/software/guile-gnome/, currently.)

I'll send specific issues to the list.

Thanks for listening.


-- 
        Greg Troxel <address@hidden>