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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
