* 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 2002-03-31 20:41 ` Rob Browning 0 siblings, 1 reply; 4+ 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-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: The 1.6.1 release. 2002-03-31 0:21 ` The 1.6.1 release Thien-Thi Nguyen @ 2002-03-31 20:41 ` Rob Browning 2002-04-01 14:26 ` Neil Jerram 2002-04-03 10:37 ` Thien-Thi Nguyen 0 siblings, 2 replies; 4+ 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-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: The 1.6.1 release. 2002-03-31 20:41 ` Rob Browning @ 2002-04-01 14:26 ` Neil Jerram 2002-04-03 10:37 ` Thien-Thi Nguyen 1 sibling, 0 replies; 4+ 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-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: The 1.6.1 release. 2002-03-31 20:41 ` Rob Browning 2002-04-01 14:26 ` Neil Jerram @ 2002-04-03 10:37 ` Thien-Thi Nguyen 1 sibling, 0 replies; 4+ 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-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-04-03 10:37 UTC | newest] Thread overview: 4+ 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 2002-03-31 20:41 ` Rob Browning 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).