Re: RFS: r-cran-scatterplot3d
On Sun, Jan 24, 2010 at 08:07:57PM +0100, Philip Rinn wrote:
> > Yet I am not convinced that is what we want to sponsor more as some folks who
> > have sponsored / packaged / uploaded are not keeping up with the new versions
> > at CRAN (I think that holds for matchit, pscl, sp, vgam, zelig per [1] and
> > other pages). I try to keep up with mine, and it really is not a large
> > effort. Yet someone has to make it for the sponsored / team-managed packages
> > too.
>
> I'm not sure if I got your point. Should I just have filed an RFP bug because
> maintaining CRAN packages is so easy and it's not worth getting new people
> involved?
I do not think that this was intended.
> Or do you think we shouldn't have random CRAN packages in Debian?
IMHO Dirk's point is that some R packages have quite frequently new
upstream versions and it is hard to keep all Debian packages in sync.
It is mostly not much work but a pile of small extra jobs every week
just sums up even if they are easy to do.
> > Are you aware of http://debian.cran.r-project.org which gets you 2000+ CRAN
> > packages as deb files for testing on i386 and amd64 ? That is an automated
> > process not suitable for injection into Debian proper, but one that could be
> > extended to other arches etc given suitable hardware donations.
The alternative Dirk wanted to promote here is an effort which
autobuilds Debian packages to avoid the extra work mentioned
above.
The question we should answer is: Do we really need an extra R package
in Debian which might be less up to date than the one in cran2deb. IMHO
the answer just depends from the package. If we want to build any
package which depends from the R package we simply need to build an
official Debian package. If not we should find other reasons why the
official Debian package might make sense (and express this in the ITP).
Morover I think we should discuss whether we really need the latest
update of any R package if there are quite frequent upstream releases.
I'm not really convinced that we allways need every upstream release
packaged. I do not want to give an excuse for lazy maintainers but IMHO
we should handle this issue with a grain of salt. If there is a "New
version available bug" it becomes obvious that a user has an interest
for a more recent version and we should handle this quickly. We should
also not lag behind upstream for a time span larger than say 3 monthes.
I would also suggest to check upstream a reasonable timespan - say 3-4
weeks before the freeze to enable the latest upstream before freeze into
the upcomming distribution. But I fail to see a reason for a blind
upgrade to any latest upstream version specifically if we talk about a
stable scientific workbench. Any opinions?
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: