Re: R-Survaillance (Was: [med-svn] r3007 - trunk/packages/R/r-cran-surveillance/trunk/debian)
Hi Andreas,
Andreas Tille wrote:
> 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.
That was meant ironic, your observation that the mailing list is not used, is correct.
>> 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.
I did this looonng before the nice new alioth portal popped up. And I did it only for me.
Good to hear that you like it.
> 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.
It cannot since the packages are non-functional. It would be missleading to indicate that
Debian would have packages ready, DFSG-compliant or not, that could be used for Taverna or
the jars it depends on - with a few exceptions.
And this was (and is) my main motivcation behind pkg-escience. I can dump skeletons of
packages without disturbing others or without imposing any levels of quality be their
availability in a particular repository.
>> 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.
Well, right. But I don't even want to distract the force of the team for non-functional
packages. There will be a time when I will finish yet another package. And then I go for a
completion.
>>> 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 ...).
I am probably one of them.
>> 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.
It is a regular alioth project. Chances are not low.
>> 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.
Michael knows about pkg-escience. I had forgotten about that package myself and it was
outdated anyway.
>>> 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.
pkg-escience can disappear once the infrastructure for Taverna is available. Maybe I
should have called it pkg-taverna.
>> 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?
It is more of a publicly inspectable packaging with no time pressure to arrive at DFSG
compliant solutions.
>> 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?
I don't disturb. And I have everything together.
>> 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.
We can move them later. At the moment, there just is not overly much to move, really.
>> 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?
Similar to pkg-escience. The packages in pkg-escience are in there for ...1 to 2 years I'd
say. debian-science has come along in the meantime. Why should I become active in moving
anything?
>> 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?
Hm. No, you are right, all the debian-med R bits could move right there.
>> 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.
I am maintaining or comaintaining packages in all the alioth projects that have been
mentioned in this email, I think. I just chose the project I feel to be right, which is a
very spontaneous decision and may depend on the directory my shell just happens to be in.
It is a non-issue. Someone wasting an hour here or there on something that has already
been done is not too bad. Probably more ideas arise when comparing the efforts for a later
merger.
> 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.
I am very emotionless in this issue. My reply got long for my deep respect for you and
your work, not for fighting over anything. Should I sound "short" in my answers, then
because I don't know what to say, really. pkg-escience exists for not-disturbing, not for
disturbing, but somehow it seems to do the opposite. I will not jump into special action
because of some other alioth project opening its doors, which is certainly understandable.
Best,
Steffen
Reply to: