It may not always make sense for things to stay in debian-med's tasks, even if that's where they've traditionally lived. It may make more sense for them to migrate to other task sets / packages, and for debian-med's tasks to inherit wholesale from those tasks. Or it may not :)Well, the good thing about Debian-Med is that it exists. ;-) I explained several times that I do not want to have a "hard grip" on the biological part if someone else (someone in the sense of a project I'd happily join) would start a working system. The problem is that up to today there was no such project focussing on a collection of biological software that is needed (amongst others) in medical research. On the other hand there is no problem in making an imaginary science-bio meta package dependant from med-bio or even making med-bio dependant from science-bio if this would exist at some point in time.I sense some potential concerns about debian-med's thunder being stolen by a set of upstart science tasks;Well, there is nothing to steal - cooperation would make thunder for both (at least I would hope this).
Thunder for both would be great :) :) :)
I'm looking at something like debian-science-sociology as a potential sibling to debian-med; the community there is not nearly as advanced w.r.t. adoption of open source tools, barring a few areas, and some advocacy is probably needed.Well, advocacy is one *very* important point (if not even the main point) in the Debian to outsider relation for any Custom Debian Distribution.
Yes.
I think that "thinking big" is a good thing, here -- just imagine if even 1/3 of the disciplines listed by participants in this conversation had some degree of debian-med's success: Debian would quickly become known as *THE* platform for doing science in those areas... not a bad thing at all.That's the idea. Debian has become the reference platform in several medical projects even if they are not yet included into Debian.
:)
Yep. The experimentalists in this camp are reasonably heavy statistics users; they tend to like things like R. Plus all of the packages in the archives that are related somehow to UI development or UI testing.... there are quite a number, from RAD toolkits all the way up to unit testing widgets for graphical apps (e.g. GUnit).Well, this is fine but as I explained in one of my previous mails I would vote for some field related meta packages, likescience-astronomy science-biology science-chemestry ... and some generic meta packages that contain tools for any science science-imaging science-plotting science-statistics ...
To some degree, it may be better for folks working in various subdisciplines to decide and select packages that are actually maximally useful to them and to their students / co-workers.
--e