Tool version in HACKING

Tool version in HACKING

[Marius Vollmer]

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

Re: Tool version in HACKING

[Gary Houston]

> 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

Re: Tool version in HACKING

[Thien-Thi Nguyen]

   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

Re: Tool version in HACKING

[Rob Browning]

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

Re: Tool version in HACKING

[Thien-Thi Nguyen]

   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

Re: Tool version in HACKING

[Marius Vollmer]

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

Re: Tool version in HACKING

[Thien-Thi Nguyen]

   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