Re: R-Survaillance (Was: [med-svn] r3007 - trunk/packages/R/r-cran-surveillance/trunk/debian)
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. ;-)
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/
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.
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. 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
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.
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. 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
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.
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.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: