* Tool version in HACKING
@ 2002-04-09 17:12 Marius Vollmer
2002-04-09 19:28 ` Gary Houston
[not found] ` <200204091928.MAA18084@onyx.he.net>
0 siblings, 2 replies; 7+ messages in thread
From: Marius Vollmer @ 2002-04-09 17:12 UTC (permalink / raw)
Cc: guile-devel
Hi,
on 2001-11-22, you have removed the required tool version numbers from
the HACKING file (see ChangeLog entry below). Why did you do this?
I think they are an important bit of information since Guile will
indeed not work with all old versions.
2001-11-22 Gary Houston <ghouston@arglist.com>
* HACKING: Modified the Hacking It Yourself section.
Removed the version numbers from the tools.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Tool version in HACKING 2002-04-09 17:12 Tool version in HACKING Marius Vollmer @ 2002-04-09 19:28 ` Gary Houston 2002-04-10 6:29 ` Thien-Thi Nguyen [not found] ` <200204091928.MAA18084@onyx.he.net> 1 sibling, 1 reply; 7+ messages in thread From: Gary Houston @ 2002-04-09 19:28 UTC (permalink / raw) Cc: guile-devel > Hi, > > on 2001-11-22, you have removed the required tool version numbers from > the HACKING file (see ChangeLog entry below). Why did you do this? > > I think they are an important bit of information since Guile will > indeed not work with all old versions. > > 2001-11-22 Gary Houston <ghouston@arglist.com> > > * HACKING: Modified the Hacking It Yourself section. > Removed the version numbers from the tools. The versions seemed a bit out of date, and the last policy I remember is that the latest released versions are always used. Since it's easy to find out what the versions are, it doesn't seem necessary to list them in the file and saves the confusion when the released versions differ from the file versions (is the file correct or did somebody just forget to update it?) _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Tool version in HACKING 2002-04-09 19:28 ` Gary Houston @ 2002-04-10 6:29 ` Thien-Thi Nguyen 2002-04-10 15:07 ` Rob Browning 2002-04-22 16:59 ` Thien-Thi Nguyen 0 siblings, 2 replies; 7+ messages in thread From: Thien-Thi Nguyen @ 2002-04-10 6:29 UTC (permalink / raw) Cc: mvo, guile-devel From: Gary Houston <ghouston@arglist.com> Date: 9 Apr 2002 20:28:25 +0100 The versions seemed a bit out of date, and the last policy I remember is that the latest released versions are always used. Since it's easy to find out what the versions are, it doesn't seem necessary to list them in the file and saves the confusion when the released versions differ from the file versions (is the file correct or did somebody just forget to update it?) for the most part the HACKING tools are stable; we've run accross weirdness (recently and also going back, considering some of the comments in the input files), but over time the tools live up to their documentation. to be precise and do minimal work, we need to record version numbers only for problematic cases. this means every time there's a tool bug discovered, HACKING needs to be updated, otherwise the default stance (which we need to state explicitly) of "latest is greatest" holds. we need to also remind people to check their tool distributor's policy and practice. btw, in fixing this bug we come to the process question of: how do bugs fit into the TODO list? one obvious answer is "don't use TODO list, bug fixing (for those deemed needing it) is best managed separately". this is a not wholistic view however; bug fixing takes time which directly affects what can be done on TODO. fundamentally, bug fixing is a (we hope) non-repetitive action, something to do when the time is right. (and if the particular fix is congruent w/ long term design, the fix could be called one-shot.) so i think it would be useful to consider ways to include bugs in the TODO list. what does everyone think about this protocol: - discuss bug - someone proposes fix - agree on fix - add to TODO "NAME: FIX-ACTION" (or just "NAME" and use another level to enumerate fix-action subtasks) under "Fix Bugs" (a new top-level) - if a bug moves for whatever reason (for example under "Guile 1.6"), it needs to be put under another "Fix Bugs" parent ? the basic characteristic here is that only bugs whose fixes are known are added to TODO, and bug fix parent task is always easy to identify. this helps keep TODO focus probably and definitely makes downstream tools happy. thi _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Tool version in HACKING 2002-04-10 6:29 ` Thien-Thi Nguyen @ 2002-04-10 15:07 ` Rob Browning 2002-04-10 18:42 ` Thien-Thi Nguyen 2002-04-22 16:59 ` Thien-Thi Nguyen 1 sibling, 1 reply; 7+ messages in thread From: Rob Browning @ 2002-04-10 15:07 UTC (permalink / raw) Cc: ghouston, mvo, guile-devel Thien-Thi Nguyen <ttn@giblet.glug.org> writes: > btw, in fixing this bug we come to the process question of: how do bugs > fit into the TODO list? one obvious answer is "don't use TODO list, bug > fixing (for those deemed needing it) is best managed separately". this > is a not wholistic view however; bug fixing takes time which directly > affects what can be done on TODO. fundamentally, bug fixing is a (we > hope) non-repetitive action, something to do when the time is right. > (and if the particular fix is congruent w/ long term design, the fix > could be called one-shot.) > > so i think it would be useful to consider ways to include bugs in the > TODO list. what does everyone think about this protocol: I'm not sure I follow. I can see why we might want to have references to bugs from the TODO list; are you arguing for more than that? (I don't think I adequately grokked your suggestion). Thanks -- 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] 7+ messages in thread
* Re: Tool version in HACKING 2002-04-10 15:07 ` Rob Browning @ 2002-04-10 18:42 ` Thien-Thi Nguyen 0 siblings, 0 replies; 7+ messages in thread From: Thien-Thi Nguyen @ 2002-04-10 18:42 UTC (permalink / raw) Cc: ghouston, mvo, guile-devel From: Rob Browning <rlb@defaultvalue.org> Date: Wed, 10 Apr 2002 10:07:42 -0500 I'm not sure I follow. I can see why we might want to have references to bugs from the TODO list; are you arguing for more than that? (I don't think I adequately grokked your suggestion). yes, more than that. a reference to a bug is not as accurate (wrt a todo list) as a reference to a bug *fix*, which is more specific. the proposal would conventionalize this, so that we can have some greater confidence that TODO list items (relating to bugs) are actually specific things to do. the more specific a TODO list, the easier it is to follow. other concurrent processes are bugs prioritization and bugfix execution, to name the two that are relevant. often it is one person that takes care of notation, prioritization, and execution, and probably the result is most coherent if this is the case, but it's a good idea to recognize the separate processes anyway, so that the thinking that goes behind these processes can be exposed and refined, and the parallizable parts exploited. bottom line: if the release manager wants to have a say in bugs prioritization, it is helpful to see what the impact of the bug fix is in terms of the other tasks (IMHO). btw, what are your thoughts on the duties of a release manager? this question is related to the roles that people play, overall. thi _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Tool version in HACKING 2002-04-10 6:29 ` Thien-Thi Nguyen 2002-04-10 15:07 ` Rob Browning @ 2002-04-22 16:59 ` Thien-Thi Nguyen 1 sibling, 0 replies; 7+ messages in thread From: Thien-Thi Nguyen @ 2002-04-22 16:59 UTC (permalink / raw) From: Thien-Thi Nguyen <ttn@giblet.glug.org> CC: mvo@zagadka.ping.de, guile-devel@gnu.org to be precise and do minimal work, we need to record version numbers only for problematic cases. HACKING now has a (currently 1-element) list of known-bad tools versions. thi _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <200204091928.MAA18084@onyx.he.net>]
* Re: Tool version in HACKING [not found] ` <200204091928.MAA18084@onyx.he.net> @ 2002-04-15 13:59 ` Marius Vollmer 0 siblings, 0 replies; 7+ messages in thread From: Marius Vollmer @ 2002-04-15 13:59 UTC (permalink / raw) Cc: guile-devel Gary Houston <ghouston@arglist.com> writes: > > on 2001-11-22, you have removed the required tool version numbers from > > the HACKING file (see ChangeLog entry below). Why did you do this? > > > > I think they are an important bit of information since Guile will > > indeed not work with all old versions. > > > > 2001-11-22 Gary Houston <ghouston@arglist.com> > > > > * HACKING: Modified the Hacking It Yourself section. > > Removed the version numbers from the tools. > > The versions seemed a bit out of date, and the last policy I remember > is that the latest released versions are always used. Ahh, I see. I didn't know about the "latest released versions" rule. > Since it's easy to find out what the versions are, it doesn't seem > necessary to list them in the file and saves the confusion when the > released versions differ from the file versions (is the file correct > or did somebody just forget to update it?) Yes, that makes sense to me. Since we can now request specific automake and autoconf versions from Makefile.am and configure.in directly, we should just do this. I.e., we now have AC_PREREQ(2.53) in configure.in which will fail for autoconf versions less than 2.53. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-04-22 16:59 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-04-09 17:12 Tool version in HACKING Marius Vollmer
2002-04-09 19:28 ` Gary Houston
2002-04-10 6:29 ` Thien-Thi Nguyen
2002-04-10 15:07 ` Rob Browning
2002-04-10 18:42 ` Thien-Thi Nguyen
2002-04-22 16:59 ` Thien-Thi Nguyen
[not found] ` <200204091928.MAA18084@onyx.he.net>
2002-04-15 13:59 ` Marius Vollmer
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).