* Re: The 1.6.1 release.
[not found] ` <87r8mxs5t8.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us>
@ 2002-03-31 0:21 ` Thien-Thi Nguyen
[not found] ` <E16rT62-0003Dh-00@giblet>
1 sibling, 0 replies; 6+ messages in thread
From: Thien-Thi Nguyen @ 2002-03-31 0:21 UTC (permalink / raw)
Cc: guile-devel, guile-user
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: The 1.6.1 release.
[not found] ` <E16rT62-0003Dh-00@giblet>
@ 2002-03-31 13:00 ` Mr. Peter Ivanyi
2002-04-03 10:32 ` Thien-Thi Nguyen
2002-03-31 20:41 ` Rob Browning
[not found] ` <87lmc8fp24.fsf@raven.i.defaultvalue.org>
2 siblings, 1 reply; 6+ messages in thread
From: Mr. Peter Ivanyi @ 2002-03-31 13:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: The 1.6.1 release.
[not found] ` <E16rT62-0003Dh-00@giblet>
2002-03-31 13:00 ` Mr. Peter Ivanyi
@ 2002-03-31 20:41 ` Rob Browning
[not found] ` <87lmc8fp24.fsf@raven.i.defaultvalue.org>
2 siblings, 0 replies; 6+ messages in thread
From: Rob Browning @ 2002-03-31 20:41 UTC (permalink / raw)
Cc: evan, guile-devel, guile-user
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: The 1.6.1 release.
[not found] ` <87lmc8fp24.fsf@raven.i.defaultvalue.org>
@ 2002-04-01 14:26 ` Neil Jerram
2002-04-03 10:37 ` Thien-Thi Nguyen
1 sibling, 0 replies; 6+ messages in thread
From: Neil Jerram @ 2002-04-01 14:26 UTC (permalink / raw)
Cc: ttn, evan, guile-devel, guile-user
>>>>> "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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: The 1.6.1 release.
2002-03-31 13:00 ` Mr. Peter Ivanyi
@ 2002-04-03 10:32 ` Thien-Thi Nguyen
0 siblings, 0 replies; 6+ messages in thread
From: Thien-Thi Nguyen @ 2002-04-03 10:32 UTC (permalink / raw)
Cc: guile-user
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: The 1.6.1 release.
[not found] ` <87lmc8fp24.fsf@raven.i.defaultvalue.org>
2002-04-01 14:26 ` Neil Jerram
@ 2002-04-03 10:37 ` Thien-Thi Nguyen
1 sibling, 0 replies; 6+ messages in thread
From: Thien-Thi Nguyen @ 2002-04-03 10:37 UTC (permalink / raw)
Cc: evan, guile-devel, guile-user
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-04-03 10:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <87ofi5qm4a.fsf@raven.i.defaultvalue.org>
[not found] ` <87r8mxs5t8.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us>
2002-03-31 0:21 ` The 1.6.1 release Thien-Thi Nguyen
[not found] ` <E16rT62-0003Dh-00@giblet>
2002-03-31 13:00 ` Mr. Peter Ivanyi
2002-04-03 10:32 ` Thien-Thi Nguyen
2002-03-31 20:41 ` Rob Browning
[not found] ` <87lmc8fp24.fsf@raven.i.defaultvalue.org>
2002-04-01 14:26 ` Neil Jerram
2002-04-03 10:37 ` Thien-Thi Nguyen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).