Re: advice/help needed for including new software in debian (science)
Hi Felipe,
On Mon, Nov 25, 2013 at 04:38:04PM -0200, Felipe Figueiredo wrote:
> > inside the Debian Med team. I'm not fully sure whether MMRRSim[1] fits
> > that medical scope so well but I'm pretty sure about TRepid[2].
>
> Yes, TRepid is well suited for debian-med. MMRRSim is applicable in
> the ecology field, not necessarilly medical one, which is why I
> submitted the initial request for help to d-science instead of d-med.
> I hope this was ok.
For sure this is OK. Debian Med and Debian Science are not competing
with each other - so you have less chances to do something "wrong".
> > I'd recommend having a look into the Debian Med team policy document [0]
> > because I have the strong feeling that most of your questions are
>
> Thanks for the pointer, it seems to have very much of what I need for
> now. I will take a look at it later this week.
Fine. If you mind joining both alioth projects (Debian Med and Debian
Science) and would feel more home in Debian Science it is fine to put
both packages into this one repository. I'd volunteer to sponsor your
packages in any case. Debian Science policy[1] is not very different
from Debian Med policy. In fact you will probably not do very wrong if
you read the more detailed Debian Med policy and just change the VCS
URL. Specifically the initial tips how to register on alioth migth be
a concern here.
> > answered. Yes, it is correct that you should provide some downloadable
> > versioned tarball of your software and if you do not mind using Git
> > rather than bzr (well, we need to restrict the number of VCS somehow to
> > make sure not every team member needs to become a "various VCS expert")
> > you can commit your debian/ packaging to the Debian Med team Git (or SVN
>
> I expected this might be the case, since bzr does not seem to have a
> major user base, at least compared to git. When I started using it, it
> really seemed to have a softer learning curve, and now I'm very much
> used to it. I don't mind using git, though, especially since AFAIUI it
> should be easy to migrate to/from git/bzr.
OK.
> Just to be sure I'm following you: the packaging will no longer be
> done in the upstream site, but rather debian itself? After I fix the
> packaging as per [0], it will all be migrated to a debian server and
> mantained there? Then, the current packaging branch in LP will be
> abandoned.
This would be my advise since dealing with this in different repositorie
might create more trouble than it is helpful.
> > if you prefer this). Everything is verbosely written down[0] - feel free
> > to contact us on the list in case there might be some open questions
> > remaining.
>
> Great! I do have several questions.
>
> What about bug reporting? I'd prefer to check for users feedback in
> only one place, which I setup upstream in launchpad (as opposed to one
> bug tracker per distro - I also intend to eventually submit to
> Fedora).
Hmmm, that seems to be hard to aproach. We have the Debian BTS and
Ubuntu has Launchpad. According to my experience some bugs in Launchpad
were forwarded by some brave people who care but it is not fully
reliable. I have no idea how bugs are reported in Fedora (BTW, there is
some Fedora Medical SIG and I'm lurking on their list - but they do not
maintain such a large pool on biological software as Debian does.) I do
not have the slightest idea whether there is any "inter-distribution bug
tracking aggregator" ... even if this would be a nice thing to have,
thought.
> Another question is about the user base. I don't expect MMRRSim to
> generate a large user base, as is a somewhat specific case of a more
> broadly used ecological experiment. Although it is possible, I
> currently I have no plans to expand it to a more generic simulation
> environment (as I hope TRepid might be perceived). Does this affect
> its acceptability in Debian?
To answer this question yourself you might like to have a look at the
Debian Med biology task page which also contains Popcon numbers. You
see several packages with popcon < 20. In Debian it is not the number
of users but rather the number of bugs that counts. If your software
is
1. DFSG free
2. Has no release critical bugs
3. Finds an active maintainer (you ;-))
this is OK for Debian.
> Also, as soon as the packaging is corrected, and proof-read by experts
> and machine-reading programs in your pipeline, I think it will be
> fairly easy to package new versions myself, so I don't mind being the
> maintainer (or be a part of a maintainer group, if that is ok with you
> guys).
Yes. That's welcome.
> I expect both MMRRSim and TRepid to stabilize development after
> a while, as seem to be usual in some scientific fields.
+1
Kind regards
Andreas.
> > [0] http://debian-med.alioth.debian.org/docs/policy.html
[1] http://debian-science.alioth.debian.org/debian-science-policy.html
[2] http://debian-med.alioth.debian.org/tasks/bio
--
http://fam-tille.de
Reply to: