Re: R-Survaillance (Was: [med-svn] r3007 - trunk/packages/R/r-cran-surveillance/trunk/debian)
On Mon, 19 Jan 2009, Steffen Moeller wrote:
http://lists.alioth.debian.org/pipermail/pkg-escience-devel/
It is a low traffic list.
No doubt - but even low volume lists should have an archive which
I failed to seek for.
Well, jmol is there since Taverna needs it. It does not comply with the DFSG and I don't
even recall the exact state.
Well, that just happens. I'm just currios why it happens without
any notice of our project. I try to collect all needed information
about interesting programs and I failed to link to the latest effort
to work on this package and just misleaded people to Daniels work.
The pkg-escience wiki page has more details.
Thanks for the hint. I admit I have no idea what Taverna might be
but somehow the packaging stuff seems to rank around this. Moreover
I see this nice table with color codes. Do you think we are missing
something on the Blends tasks pages which could not reimplement a
feature of this "just another manually maintained overview table"
in the Wiki. Please correct me if I'm wrong if I think the information
could be nicely integrated into Debian Med and Debian Science tasks
pages and thus become more visible there.
BioJava however
is a fully functional package that was recently uploaded to the new queue.
That's really great news! Congratulations!
But that was not my point. I have no doubt that you are able to
build functional packages. You have proven this several times.
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.
That's a shame. Why not using the commit mailing lists
debian-med-packaging@lists.alioth.debian.org or
debian-science-maintainers@lists.alioth.debian.org. It is all
about making sure that potential helpers can step in. You
surely remember about some efforts to clean up some systematic
packaging changes over the whole SVN we did in the past. You
will miss those features if you diverge from stronger teams.
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.
Sorry I can not really parse this. Could you please try to
clarify what according your opinion is the most up to date
jmol packaging effort (perhaps we should also follow Daniels
hint to those two people who asked him for the packaging stuff -
but Daniel mentioned no e-mail adresses ...).
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.
This does not answer the question why these people maintain
their stuff in a place where chances are low to get some help.
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.
Yes. What to do now is obvious. What should have been done before
(making sure that people who are interested in icu4j are easily able
to find your work) is the problem.
Google would have helped to spot my previous packaging.
That's a point.
There might even have been a now closed ITP for it.
Yes there is one: #489507. Michael Koch from Java fame and it is
about two years older than your changelog entry and he neither
announced that he has successfully googled your stuff nor you
gave an hint on it. If your stuff would have resided in pkg-java
he probably would have noticed and might have taken it over.
And I have other things to care about, truly.
Yes. That's what I'm talking about. I try to make sure that
single people try to connect to strong teams to make sure that
the time they spended on a project is not wasted and that they
get help from others. The whole point of my mail to save
your (and other peoples) time. For instance Michael Koch
could have saved some time in the example above.
http://svn.debian.org/wsvn/debian-science
Well. It should be named pkg-science.
There was a naming discussion on debian-science list. This time
is over. I admit I'm infavour of projects without the restriction
to packaging issues because building a system is more than adding
single packages and so I'm in favour of debian-science.
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'm unsure what you mean by playground? Are you talking about
"branches" in SVN?
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.
That's perfectly OK and fixing problems at the source is a really
clever solution. But what is the connection to pkg-escience in
contrast to my suggestion to rather go to debian-med, debian-science
or pkg-java?
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 do not know these projects but I can not really believe that they
are so different from what we have that really deserve the extra
effort of a separate project. And I see a clear contradiction to
your intent to safe time.
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.
Similar effort to what?
But then we have non-scientific bits on Debian-science, no?
There is no definition for scientific or non-scientific bits.
I feel that packages should be
close to where someone who cares about them.
You think
http://cdd.alioth.debian.org/science/tasks/statistics.html
is not a proper place for any R related package?
That care may only be motivated by caring for
reverse-dependent packages.
As I said, I would not really like to see so many reverse Depends in
Debian Med. But in science-statistics most of these are well
placed. Some of them should rather go to pkg-grass-devel because
they are GIS related - but that's a complicated different issue
which should not be discussed here. May be
http://cdd.alioth.debian.org/science/tasks/geography.html
is a better place for the moment.
And as you said, bits can move any time.
Yes. So please try to move those bits who are interesting on more
important places out of your hidden playground or alternatively
iron out the position of your playground and clarify the relation
of this to the projects above to make sure it gets the notice it
deserves. The later alternative will cost more time.
Sorry if I sound harsh which is not my intention. It would be
much better to discuss such issues in RL or via phone line. Steffen,
perhaps we should do this.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: