[Rd] Wish list

[Fernando Henrique Ferraz]

Frank E Harrell Jr writes:
> Let me add to the wish list the creation of some mechanism to better track
> improvements and bug fixes in packages, such as a change log link by each
> package's area in CRAN, or easy access to CVS information from there. 
> When I report bugs (e.g., in read.xport in foreign [due somewhat to
> problems inherent with SAS's format] or ace or avas in acepack) it would
> be nice to see some announcement when the bugs are resolved, or to easily
> track this.  Even a checkbox that the package maintainer has seen the bug
> report even if she/he currently does not have time to work on it would be
> very helpful, as would a notation that the bug report was found to be
> "buggy".
> 

	I highly agree with you on this. It would be very nice having a fully
featured bug reporting system, where you could upload patches, discuss
improvements on existing packages or on the R-core itself, request for
features and so on. I think that Bugzilla (www.bugzilla.org) would suit
these expectations very well. It is the bug tracking system used by huge
projects like Mozilla (bugzilla.mozilla.org), Gentoo (bugs.gentoo.org),
and  Redhat (bugzilla.redhat.com), and based on my own experience I'd say
it addresses most of the things you pointed out.

	It works (at least in Gentoo, which is the one I'm more used to
working with) like this: someone files in a bug report. In the bug report
itself one informs the type of the bug report (a bug, a feature improvement, a
request to the developer), the severity, and any other relevant information. It
is also possible to upload attachments (like proposed patches) or additional
information on the report.

	The bug report then is assigned to a given group or, in the case of
packages to the person who is in charge for mantaining it. Anyone then can read
the bug report and make suggestions or propose fixes (see for example:
http://bugs.gentoo.org/show_bug.cgi?id=30784 ). [As opposed to the current
system, where the bug report can't even be linked to a website, and all the
discussion should be done via the mailing lists]. The maintainer or any
other other authorized developer can then accept or reject the proposed
suggestions, close the bug as duplicate, as invalid or at least inform that
he is aware of the problem and will work on it some time later.

	Just my two cents,

--
[]'s
Fernando Henrique Ferraz P. da Rosa