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-packag...@lists.alioth.debian.org or > debian-science-maintain...@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 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org