R devel - Oct 2005 - Rgnome depends on obsolete components libglade/libxml (PR#8249)

On Mon, 2005-10-24 at 19:15 +0100, Hin-Tak Leung wrote:
> Marc Schwartz (via MN) wrote:
> > On Mon, 2005-10-24 at 17:14 +0100, Hin-Tak Leung wrote:
> > 
> >>Peter Dalgaard wrote:
> <snipped>
> >>>You mean get it upgraded to xml2 and glade2? Patches would
likely be
> >>>accepted... 
> <snipped>
> > 
> > According to the R Admin manual (2.2.0) on page 34:
> > 
> > "This interface is experimental and incomplete. The console
offers a
> > basic command line editing and history mechanism, along with tool and
> > button bars that give a point-and-click console to some R commands.
Many
> > of the features of the console are currently stubs, and the console is
> > **no longer under development**: it has been kept available as an
> > example of adding a front-end to R."
> > 
> > 
> > This language (my emphasis added) would suggest that a TODO list does
> > not (or should not) exist...so Peter's suggestion would seem spot
on.
> 
> Peter's suggestion is spot on ("patches would likely be
accepted"),
> yours suggestion, on the other hand...
> 
> You do understand that, as an *example*, studying it and/or trying
> to learn to modify it is useful for future R improvements in
> similiar areas, and you have just managed to discourage a few 
> individuals from studying a complete if out-dated example.
> (yes, I have spent a few hours modifying the code for glade2).
Respectfully, I would disagree with your characterization of my reply. 

I simply pointed out (as it states in the manual) that there should be
no expectation of further development from R Core and as a result no
expectation of an _officially_ maintained, much less reviewed, TODO list
for the package.

It plainly indicates that it has been left as an example for others,
with no implication that one should be dissuaded from using it as such.
It was done (as others have characterized in prior threads) as a "proof
of concept", not as a fully functioning GUI.

Your reporting a RFE to the R Bug Tracking System would imply an
expectation that the request be officially tracked by R Core in some
fashion (even if just to close out the report) and/or perhaps be acted
upon at some future date by _somebody other than yourself_.

Peter's words were direct in that patches would _likely_ be accepted,
but at the same time are not being actively solicited. A substantive
difference, given that a patch made available for an official R package,
would still take some effort on the part of R Core to implement and
test.

It seems to me that yet another option here would be for you to offer to
take over as the package maintainer and bring it up to date to Gtk2, if
you are so inclined. The package has been made available under the GPL,
thus there is nothing precluding you from doing so and even creating a
new CRAN package based upon it.

The same approach is available for the orphaned packages on CRAN, so
this is nothing new.

This brings us full circle to the whole GUI discussion taking place and
so I'll leave it for that thread.
> A TODO list doesn't mean that it has to be done by the R foundation
> - if you can identify small bug do-able areas that needs improvement,
> some individual might come along just for the fun/fame, and in the
> end, the R foundation gains an outsider who is knowledgeable about
> embedding R. e.g. some college professor might assign that as a
> final year computer programming project, or some student might pick
> it as one. Is it such a bad thing to have a list of "inadequacies
> but nowhere important enough to get fixed any time soon" issues?
I think that the question is more, what TODO list, where and maintained
by whom?

In this case, with a package that is no longer being actively maintained
by R Core, it may very well be appropriate to have a separate TODO list
or even Wiki someplace to address issues where participation by useRs is
being actively solicited. The R-sig-* mailing lists would certainly be
one place for such focused activities.
> The possible gain - somebody decides to take it up, and move forward,
> and in so doing, learns some R internals - is it such a bad thing?
Not bad at all. It is more a question of what is the appropriate
mechanism to facilitate such activity, in a fashion that does not have
an impact on R Core, unless it is truly required.

Best regards,

Marc