Re: R-Survaillance (Was: [med-svn] r3007 - trunk/packages/R/r-cran-surveillance/trunk/debian)
http://www.grid.tsl.uu.se/repos/globus/info/Andreas Tille wrote:
> On Sun, 18 Jan 2009, Steffen Moeller wrote:
>
>> the pkg-bioc project has managed to build what is buildable
>> automatically, but we never
>> got around towards offering it as a service. Dirk maintains the
>> CDBS for the R packaging and I agree - he made it very easy, indeed.
>
> I remember that you once talked about automatic building and
> my impression is that it is perfectly doable (IMHO the perl team
> does it as well). On the other hand for my goal to get r-survaillance
> packaged *now* it is not helpful to wait until it happens and I'm
> currently not able to help on this front. Considering that Dirk
> has done a really great job with CDBS it is so easy that there
> is not enough pressure to do more. ;-)
I tend to agree, particularly not since I became a DD in the meantime
and can upload the packages I am interested in myself :)
>>> hand I'm not really sure whether all these dependencies of
>>> r-survaillance really belong into our SVN.
>>
>> Probably not :)
>
> I agree. However I moved the stuff I needed to your R subfolder
>
> http://svn.debian.org/wsvn/debian-med/trunk/packages/R/?rev=0&sc=0
>
> if any better suggestion comes up, I'd perfectly happy to move it.
>>> I just followed
>>> Steffens scheme in the R subdirectory but I wonder whether
>>> there are more reasonable places than to "hide" for instance
>>> GIS stuff under the topic medicine.
>>> I would like to clarify this before issuing the according
>>> ITPs. Any better suggestions?
>>
>> No, not really. My answer back then was to have pkg-escience as a
>> separate alioth project.
>
> I wanted to have a look into the mailing list archive, but it is
> empty:
>
> http://lists.alioth.debian.org/pipermail/pkg-escience-devel/
It is a low traffic list.
> I notice that some people of Debian Med are listed on this team
> on alioth and I also have seen that for instance jmol and biojava
> reside there.
Well, jmol is there since Taverna needs it. It does not comply with the DFSG and I don't
even recall the exact state. The pkg-escience wiki page has more details. BioJava however
is a fully functional package that was recently uploaded to the new queue.
> The problem I have with pkg-escience is that it seems to be pure
> packaging related and just a SVN to commit some stuff. Don't get
> me wrong: This is the *impression* I have.
It is more or less right. There are a few exceptions, though. The Torque
packaging for instance is alive. Communication does not happen via the list but via direct
email correspondence.
> There is no communication
> to the outer world for instance that nobody for instance stepped
> up here on this list to announce that some work on jmol is in
It is just a place holder. That other project of jmol was far ahead
of mine.
> progress at this (should I say hidden) place. Similar with
> biojava: IMHO two very important qualifications are needed to
> tackle this package: Competence in the field of Biology (which
> is here) and competence in Java programming (which is probably
> not so good here but on pkg-java). The natural thing to do would
> be to connect to one group with competence. Choosing pkg-escience
> is IMHO hiding the project from they eyes of both teams with
> competence.
Depends how you see it. BioJava and Taverna are prepared by
individuals who if they don't work with each other at least know each
other well. There is some side towards keeping Biojava and Taverna on
the same alioth project that is less obvious, it just reflects the
BOSC community to some degree.
> To continue: On pkg-java which has a corresponding mailinglist
> debian-java for jeneral discussion is currently an effort to build
> eclipse packages and as a precondition icu4j. I helped out and
> sponsored icu4j which on its natural place (IMHO) under
>
> http://svn.debian.org/wsvn/pkg-java/trunk/icu4j/?rev=0&sc=0
>
> and it finally got a finished package uploaded. Sorry Steffen
> but the changelog at
>
>
> http://svn.debian.org/wsvn/pkg-escience/icu4j/trunk/debian/changelog?op=file&rev=0&sc=0
>
>
> is not really impressive. This is not against you. You might
> have perfectly valid reasons to stop working on it. The problem
> is that nobody was aware of your work and was able to base up
> to date stuff on it because pkg-escience is some kind of a hidden
> place.
Yip, I was reminded about my past efforts on icu4j. No problem, though. All I need to do
is to remove that package from the repository. Google would have helped to spot my
previous packaging. There might even have been a now closed ITP for it. And I have other
things to care about, truly.
> I just want to try to find out the real sense of pkg-escience.
> We had some discussion on Debian Science about this repository and
> perhaps it might have been inspiring to use this SVN for packaging
> work instead of having a somehow competing
>
> http://svn.debian.org/wsvn/debian-science
Well. It should be named pkg-science.
> My suggestion would be to find a reasonable home for the packages
> in pkg-escience in other repositories which are better known amongst
> Debian people (packages with Java competence to the Java team,
> biology related packages might go into our repository and the remaining
> stuff to debian-science which seems to be a growing and vital group).
> There is no sense in splitting things up and I admit I do care less
> about the "historical fact" that pkg-escience existed before
> debian-science. There was a longish discussion on the Debian Science
> list about what repository to use and if I remember right there
> were not that much people rising their voice for pkg-escience.
> In short: Pkg-escience was a very good idea once it was created.
> People in this project just failed to publish it properly in the
> Debian Science community.
I anticipated pkg-escience as a playground from day one. Anybody willing
to join in for playing is invited to do so any time. I lowered my interest once that I
figured out that the packages I was interested in are incompatible with current versions
of the jars they are redistributing with no knowledge whatsoever about what version they
are actually using themselves. So I decided to move bottom up and this way help upstream
to incrementally locate incompatibility issues themselves.
Biojava and bytecode are leaves of the dependency tree. So they were started with. BioDas,
EnsJ and MartJ are probably next. From my perception, these packages are very much off the
major concerns of pkg-java and probably also of debian-science or debian-med. I don't
care much about pkg-escience now being superfluous by now or not. And certainly I am only
happy when other groups with similar interests to mine start similar efforts.
> Back to the topic (what I wrote above should probably go also to
> debian-science list):
>
>> But, it is less fun, I think. And not too much is gained. I could
>> imagine that having a
>> subfolder or r-surveillance could make sense in which you keep those
>> extra dependencies,
>> but this very much depends on the package. If they are just other
>> regular R packages, then
>> I would not (and have not) distinguish(ed) about primary and secondary
>> packages at all.
>
> They are just other regular R packages. Following my arguing above
> we should put them in maintenance of a group with maximum R
> competence. I do not know about a R maintenance team and I
> seem to remember that Dirk is not really a fan of team maintenance.
> He once issued some valif reasons to me. Even if I disagree and
> think that there are more pros than cons nobody can force the
> main R maintainer to form a team and use a VCS. The next competence
> group would be IMHO a scientific group. So I would ask on
> Debian Science whether a package might be apropriate there.
> I just decided to put r-cran-plotrix there (see #512069 and
>
> http://svn.debian.org/wsvn/debian-med/packages/plotrix/trunk/?rev=0&sc=0 ).
>
> I do not really like to keep that much non-biology related stuff
> in our repository and if you do not see a better chance I will
> move my last commits to debian-science.
But then we have non-scientific bits on Debian-science, no? I feel that packages should be
close to where someone who cares about them. That care may only be motivated by caring for
reverse-dependent packages. And as you said, bits can move any time.
Many greetings,
Steffen
Reply to: