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, like
science-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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
