Re: The 1.6.1 release.

Re: The 1.6.1 release.

[Thien-Thi Nguyen]

   From: Evan Prodromou <evan@glug.org>
   Date: Wed, 06 Mar 2002 16:13:39 -0600

   So, for my own clarification, once 1.5.x becomes "blessed" into 1.6.x,
   what happens in CVS? Will there still be 2 branches, one stable and
   one unstable? Or will a third branch, 1.9.x, start happening at that
   point? Or later, when 1.7.x is starting to look like 1.8.x?

good question.

IMO, the more branches there are the more PITA it is to maintain them.
this suggests that to cut ourselves slack we should delay branching
until things are *determined* to be stable (as opposed being *declared*
to be stable).

to do a good determination means we need to define what are the criteria
for stability so that we can measure the living tree against it.  there
is now workbook/build/stability.text (currently empty) -- everyone
please feel free to suggest items to add to that file.  [cc guile-user]

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The 1.6.1 release.

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> good question.
>
> IMO, the more branches there are the more PITA it is to maintain them.
> this suggests that to cut ourselves slack we should delay branching
> until things are *determined* to be stable (as opposed being *declared*
> to be stable).

I have no problem with this.  This is what I'd intended for the next
release.

> to do a good determination means we need to define what are the
> criteria for stability so that we can measure the living tree
> against it.  there is now workbook/build/stability.text (currently
> empty) -- everyone please feel free to suggest items to add to that
> file.

As a practical definition, I'd love to see it move to the point where
being ready for release was more just a matter of making sure all the
release-critical TODO items had been done (which would include
references into the bug tree), and that "make check" would complete
without error on the "primary platforms".  In particular, I'd like to
see items added to "make check" whenever we have important problems
that need fixing -- *before* we fix them.  This wouldn't be
appropriate for all problems, but for many I suspect it would.

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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The 1.6.1 release.

[Neil Jerram]

>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:

    Rob> Thien-Thi Nguyen <ttn@giblet.glug.org> writes:
    >> good question.
    >> 
    >> IMO, the more branches there are the more PITA it is to maintain them.
    >> this suggests that to cut ourselves slack we should delay branching
    >> until things are *determined* to be stable (as opposed being *declared*
    >> to be stable).

    Rob> I have no problem with this.  This is what I'd intended for the next
    Rob> release.

Although I'm probably a prime culprit (because of the elisp work in
unstable), I also agree with this.  It's a major pain having to work
with multiple branches over an extended period.

(Especially when that period includes deciding to merge all the
documentation directories and then separate them out again - d'oh!)

        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The 1.6.1 release.

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Sun, 31 Mar 2002 14:41:07 -0600

   As a practical definition, I'd love to see it move to the point where
   being ready for release was more just a matter of making sure all the
   release-critical TODO items had been done (which would include
   references into the bug tree), and that "make check" would complete
   without error on the "primary platforms".  In particular, I'd like to
   see items added to "make check" whenever we have important problems
   that need fixing -- *before* we fix them.  This wouldn't be
   appropriate for all problems, but for many I suspect it would.

why don't you add this to build/release.text and fill it out w/ related
process?  i think it's safe to say that whoever writes release.text has
the most say in the release process.  since you're doing the release it
makes more sense for you to do it than for me.  (i'm a lazy bastard,
too. ;-)

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel