R-alpha: lbeta, .. etc

Kurt Hornik Kurt.Hornik@ci.tuwien.ac.at
Fri, 27 Jun 1997 08:33:35 +0200


>>>>> Ross & writes:

> Kurt Hornik writes:
>> Actually, I must have missed that patch, too.  I'll rebuild my Debian
>> packages right away ...
>> 
>> Re official versus non-official patches.  What I could do is put all
>> patches that were posted on r-devel and look reasonable into CRAN (e.g.,
>> src/patches).  However, R&R will probably not be too happy about the
>> existence of unofficial patches ...

> [ With great effort, raises self from death-bed ... ]

> I have a heap of stuff "ready to go".  It has been for several weeks,
> but various disasters have intervened.  I hope to have a new version
> out on monday.  

Oh boy, do I wish it was Monday already ...

> Luke Tierney is visiting for a bit after that and so there will be
> other priorities ...

(Or try to get Luke involved in the R development ...)

> I would like to start a discussion on widening the group of people who
> can commit changes to R and create new releases (although maybe new
> releases are a one-man job).  At present, the "core group" (those who
> can commit changes to the CVS tree) consists of Robert, Martin
> Maechler and Myself.  I think it would be feasible to enlarge this
> group to perhaps 6 or 7.

(I also treat all patches sent by R&R and Martin as `official', and
apply them asap.)

> At the same time we could open up the update process so that any can
> choose to be on the "bleeding edge".  This is the mechanism which is
> used in FreeBSD development, and I think it has proved a good model.
> The necessary software (cvsup) is also pretty readily available.

> For those who want stability, there is a twice yearly "stable"
> release, and for those who want to suffer, they can have it as
> "up-to-date" as they can stand by grabbing the current cvs archive.

> Any thoughts?

For e.g. Linux, libc, Octave, ... there are two versions, the ones with
even minors are stable releases changed only for bug fixes, the ones
with odd minors are `unstable' development versions which may change
very often.  So e.g., we could start with

	R-0.6		next stable release
	R-0.7		new development tree

I have no experience with situtations where several people can manage
the source tree.  It is perhaps easier to have one person in charge of
that.  On the other hand, obvious cleanups in the interpreted code or in
the documentation do not really require a central authority ...

-k
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-