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-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: The 1.6.1 release.

[Mr. Peter Ivanyi]

Thien-Thi Nguyen wrote:
> 
>    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?

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

<rant>
Personally I "hate" the current situation with 2 development branches and I
would
really hate to have 3 or more development branches.
So far I could not figure out what is the difference between 1.5.x and 1.7.x and
why do 1.7.x exist at all ?
</rant>

Anyway, I would suggest that "bugs", which do not crash guile, should not be 
considered as "show-stoppers". For example, if I understand this bug

1004-socket-accept-blocks-all-threads

just behaves in an unexpected way but guile still runs and maybe certain 
applications will have difficulty to use it, or cannot simply use it. So let
just live with it for the moment.

Secondly, a sort of common decision can be made about the main improvements in
the
next release. For example for 1.8 all gh interface should be transfered to scm. 
This would mean that all related bugs should be fixed, but other
non-crashing bugs can be fixed, but are not going to stop the release.

						Peter Ivanyi

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

Re: The 1.6.1 release.

[Thien-Thi Nguyen]

   From: "Mr. Peter Ivanyi" <peteri@carme.sect.mce.hw.ac.uk>
   Date: Sun, 31 Mar 2002 14:00:56 +0100

   [label bugs]
   [define feature sets per version]

these are good ideas.  probably the first will be put into practice
before the second, but neither will be forgotten.

thi

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

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-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

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-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user