Brainstorming about Debian Med paper, motivated by Nat Rev Gen paper "Crowdsourcing biomedical research" citing our Sprint paper
Hello,
https://www.researchgate.net/publication/305342071_Crowdsourcing_biomedical_research_Leveraging_communities_as_innovation_engines
cites our "Community-driven development for computational biology at
Sprints, Hackathons and Codefests" paper
https://www.researchgate.net/publication/268977937_Community-driven_development_for_computational_biology_at_Sprints_Hackathons_and_Codefests
Now, being cited in a Nature Reviews Genetics paper is something that I
presume we all appreciate. This other gang of four (the one first
pointing me to the first gang of four I refer to gets another glas of
water at our next sprint), and senior author Gustavo in particular, are
known for the DREAM challenges (http://dreamchallenges.org/people/). I
attended their preconference meeting at the ISMB in Dublin.
I am bit shocked that our Sprints paper is already from 2014. But sure,
it was right after the Berlin Codefest that synced with the 2014 ISMB.
Debian Med has changed quite a bit since its last Debian Med centric
publication. I am not sure about what what exactly should go into any
upcoming description of ours, but I presume we all agree there should be
an upgrade and we should aim at some higher impact factor than we
modestly did in the past. We have:
* exchange and integration with bio.tools - this we need to complete
and give examples on how it is used
* common-workflow-language - a description on how Debian Med adds value
would be nice
* minimal redundancy between software installations and community as a
distinctive effort over linuxbrew
* community communication with upstream developers, here we can cite
above Sprints paper again :o)
* continuous integration checks that ensure nothing goes wrong when
removing the redundancy
* the statistics of Andreas and popcon.debian.org that formally
describe our development
* scientific reproducibility with snapshot.debian.org
* commerical HPC support via Roland
* ?
Also, I felt that we should think about describing how having software
with Debian+Ubuntu+mint helps with using cloud services. I do not only
mean the IaaS providers like Amazon+friends. There are also tantalising
environments like Cloud9 (https://c9.io) that allow you to apt-get
install stuff and I have not yet figured out what this means to us.
Something that is intrinsically difficult to address is the different
expectation for scientific and system software for when this should be
updated. I only run testing or unstable, never stable, except for mere
file servers, possibly. So, for all virtualised efforts (remotely on
clouds or local with Docker or VirtualBox) I presume we all agree that
testing (i.e. post CI) or unstable (you do the CI effectively yourself)
is just fine. I hence want to motivate that we find a way to get Debian
Med auto-transformed to one of the upcoming flat/snappy user-installable
package formats. This way we'd be basically distribution-version-less
happy and it would successfuly fight me personally from contributing
more to linuxbrew. Chroot environments are a near miss.
What we should also think more about are ways to invite non-maintainers
to contribute. With Linuxbrew it is so easy and inviting to come up with
new versions of whatever is missing, it almost hurts to see how we are
doing it. I know, we are talking about any github-clone featuring our
package instructions for ages, but even when we change things in our
package repository, the next invocation of apt-get install still does
not have any newer version, which it would with linuxbrew because we
would have worked on a local clone of the packaging instructions and
those are executed directly, not from any abstract source/binary
package. So, we have some room for improvements, still, but nonetheless,
we make the world a better place and should tell the same about it in an
updated paper. I'll be at the ECCB in September - is anybody else on
this list going?
Best,
Steffen
Reply to: