On Tue, 20 Jan 2009, Steffen Moeller wrote:
we have it this way for biojava. as a compromise from my side: we do it conversely? If I don't need to do it myself, please feel free to move (or have moved) the packages currently residing in pkg-escience to anywhere in debian-science, pkg-scicomp, debian-med or pkg-java. A note on the Wiki page indicating where a package has ended up would be fine.
I'm hesitant to move anything anybody has put somewhere else on purpose but I will inspect in detail every part and will inform you about my intent.
Those listed on the Debian-Med project page should be listed in "red", not in "yellow". The latter would indicate that the package is current and functional. The packages _may_ be functional, but they certainly are outdated (except for a few).
For all yellow listed packages we do NOT guarantee that packages or the stuff which is linked to is working. That's what unofficial means: Somebody else gave it a try and your milleage may vary. Yellow says: well, some work has started. So if you want to distinguish the yellow parts regarding some criterions please make a suggestion. The information which is given in the yellow section is basically: Just consider having a look into what exists before you start from scratch. Chances for getting a "green" package *might* be better than for the yellows than for the red ones because there is obviosely somebody who took some time to work on this. IMHO this perfectly fits for your work. If there were known problems with some package I used to express this verbally in the end of the long description to give no false hope. Se for instance my remark at http://debian-med.alioth.debian.org/tasks/imaging.html#micromanager This is more valuable information than simply moving it to the red section: 1. There is something the user might try on his own risk. 2. The reasons why it is not "green" are expressed. Please send me reasonable text for your packages - or just put it into the control files in your packaging stuff so that I might be able to copy your text.
So I'll go on moving my R stuff to debian-science ...
^^
Save your time, I'd say. The debian/control file indicates where to find the source. And at least r-cran-qtl is not too wrongly found under the hood of Debian-Med.
I will move *my* stuff, not yours. I just commited some preconditions for r-survaillance in which are not Med related. I will not touch stuff who whas previousely there for a reason!
We had a case _within_ Debian-Med when Charles did not find libbioperl-runtime and started an effort on his own for bioperl-runtime. You cannot avoid such things. And it has little to do with the Blend or Alioth project one is in.
I admit that this always might happen. I just want to reduce the probability. The fact that it happens even in our own repository makes my arguing even stronger, IMHO.
You have some good points in what you are saying. The integration of pkg-escience with some blend certainly helps visibility, particularly since debian-med.alioth.debian.org is up. However, the current situation lets single developers join many alioth projects, and the contributor to a single package has the rights to edit many. I don't like that since changes (intentionally or not) may not be noticed.
I see your point. The chances to not note something are reduced by using the commit mailing list but anyway it might happen. On the other hand I never observed a harmful unwanted change on any of my packages in practice.
pkg-scicomp and pkg-java are basically too large to check out as a whole.
Valid point. I hope the the mr tool might be of some help here. I personally check out only parts of the repository.
And Debian-Med develops towards such a complexity, too.
Also a valid point (see above).
An "all in one" or "poly in oligo" will not scale for long, at least not if we are successful. We should start thinking about what is coming next.
I fully agree here. I'm not sure whether a restructuring of our repository might make sense. 1. starting the whole tree with trunk just makes no sense so we might community and packages to the root 2. Perhaps we should think about categorising our packages somehow. The first idea which comes to mind is using the tasks we just have. Most people feel obliged to a certain task and it sounds reasonable to assume that checking out the "interesting" task for a developer helps to reduce the download. On the other hand the bio task would be quite filled anyway. What do you think? Better suggestions. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org