Re: Maintaining non-med packages in the team only to satisfy dependencies
Hi Andreas, Le 30/05/2020 à 07:51, Andreas Tille a écrit : > Hi Pierre, > > On Fri, May 29, 2020 at 11:48:39PM +0200, Pierre Gruet wrote: >> >> Lastly I have begun packaging Java software needed as dependencies of >> snpeff, that we would need in Debian Med as it is related to genes and >> proteins. > > At first I'd like to say thanks a lot for this. > You are welcome! :) > > > For picking a team there is no real right or wrong. As I recently wrote > here[1] we should assemble all biology / medicine related software no > matter what language it is written in, here. But also to this rule > exceptions exist. > > We have a very "bad" example for generic software in Debian Med team > which is libzstd which is now even on boot disks. I'd love to get rid > of this here - but there is no other place and it was initially > maintained by a Debian Med member. > > I think the decision where to maintain involves also some gut feeling. > I usually decide based on the chances I see to get the best maintenance. > Its better to get mails about RC bugs via the channels you usually read > instead of just getting information that your final target package will > be removed from testing due to RC bugs somewhere else. > Thanks a lot for giving your opinion in details, this helps! > >> Of course we in Debian Med will do the maintenance effort as we need >> those software (e.g. for snpeff, which we want to have in Debian), but >> don't you think that other teams could blame us for working on packages >> that would logically be maintained by them? > > There is no "blame" about this. Teams like Debian Med and Debian > Science are working closely together. There is no real competition > about who maintaines what. > I perfectly understand. I was not suggesting competition, but trying to infer some rules in the mechanisms that lead one package to be maintained in one team or another. Besides, I am very much aware of one of the main reasons, which is the needs and time of the members of the teams. > >> I imagine you already have an opinion on that, and I would be interested >> in the rationale. > > For you as a newcomer I'd recommend to stay in a team where you are > comfortable with. Finally packages can be moved between teams if > needed. I'm personally reading Debian Science list but not with the > same frequence as the Debian Med list. So if you want a quick response > from me, just maintain it here. If you rather want to meet people in > Debian Science which can be interesting, just do it there (and may be > CC me in mails to be save to get quick response). Both is fine. > Thanks again. I am indeed very comfortable in Debian Med; my only concern was to do things correctly in my Debian work :-) I will thus go on doing the packaging efforts toward SnpEff in Debian Med. > >> Thanks for reading, and have a very nice week-end, > > Same to you > > Andreas. > Kind regards, Pierre
Re: Tandem Repeats Finder License Terms
Hi again Gary, I do not want to sound impatient. I'm just drafting my talk for MiniDebConf online which I will hold tomorrow. I would like to report about success of our sprint. I would love to point to a repository with freely licensed Tandem Repeats Finder if it exists. So just not missing some important outcome of our sprint. So is there any progress from your side or should we keep on waiting patiently? Kind regards Andreas. On Sun, May 10, 2020 at 01:26:08PM +0200, Étienne Mollier wrote: > Dear Gary, > > This is amazing! Thank you so much for your decision! > Yes please, let us know once the source code is available, so > the packaging of Tandem Repeats Finder can start. > > Kind Regards, > Étienne Mollier > for the Debian Med Team > > Gary Benson, on 2020-05-09 16:32:03 -0400: > > Dear Étienne, > > > > I'm making TRF open source with an AGPL license. Hopefully this > > will be completed in a week or two. > > > > I'll send a link to the github repository when it's ready. > > > > Sincerely, > > Gary Benson > > > > On 5/8/20 1:18 PM, Étienne Mollier wrote: > > > Greetings Mr. Gary Benson and Yözen Hernández, > > > > > > I'm in the process of giving a hand to the Debian Med Team with > > > maintaining several applications for the Debian project. In the > > > context of the Covid-19 pandemic, the need for easing access to > > > applications related to the medical field, notably virology, has > > > become dire, and there is a list of projects that has been > > > established by the Debian Med Team which is considered a > > > priority work, see: > > > > > > > > > https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/COVID-19-Hackathon-packages-needing-work > > > > > > So in this context, I've begun packaging VirusSeeker, initially > > > written in the Washington University in St. Louis, and this > > > program makes use of RepeatMasker for one of its processing > > > steps. This program, in turn, depends on Tandem Repeats Finder. > > > However, the current licensing terms are making TRF incompatible > > > with integration into the main Debian repository, thus render > > > RepeatMasker and VirusSeeker both ineligible to it as well. > > > > > > I was wondering if it were possible to open the source code of > > > TRF, and choose licensing terms that would be compatible with an > > > integration into Debian main repository, for instance by using > > > the GPL-3 or the MIT license, or whichever terms suits your > > > taste among the ones considered DFSG compatible: > > > > > > https://wiki.debian.org/DFSGLicenses#DFSG-compatible_Licenses > > > > > > In hope your licensing change will help us all moving forward, > > > Kind Regards, -- http://fam-tille.de
