Re: ruby-bio RRIDs not shown but fine with yamllint

2019-02-19 Thread Andreas Tille
Hi Steffen,
[moving from PM to Debian Med list]

On Tue, Feb 19, 2019 at 03:24:40PM +0100, Steffen Möller wrote:
> Hi Andreas,
> 
> On 19.02.19 14:13, Andreas Tille wrote:
> > Hi Steffen,
> > 
> > On Tue, Feb 19, 2019 at 12:43:17PM +0100, Steffen Möller wrote:
> > > Dear Andreas,
> > > 
> > > the RRIDs of
> > > 
> > > https://salsa.debian.org/ruby-team/ruby-bio/tree/master/debian/upstream
> > > 
> > > is not showing up on https://blends.debian.org/med/tasks/bio-dev . It is
> > > yamllint clean.
> > Hmmm, the parser does not (yet) include Ruby team.  Perhaps I should 
> > consider
> > this.  Or we should get back the package in Debian Med team since I had the
> > feeling it was not properly maintained there anyway.
> 
> Thank you for having checked!

You are welcome.
 
> The package is up to date. And I feel we don't grow if we don't invite more
> contributing hands.  So, leave it there, I suggest.

I do not think that we get more helping hands just because the package
is sitting in some other teams (in this case Ruby team) Git repository.
Similarly we could give commit permissions to those who contributed and
there are also pull requests.

> It seems like a good idea to also have the parse iterate through the Ruby
> team packages. I personally think that a co-maintenance of two teams makes
> decent sense - like I tried with milib. But then again ... if having the
> Ruby team's packages also parsed would help our situtation then - go for it,
> please.

Will you volunteer to answer quite harsh mails from Salsa admins because
of stress testing Salsa continuously by fetching >100 packages just to
get metadata of a single one?  I had some heavy discussions about this
and the box I was running the gathering was even in the black list of
Salsa for some time.  So if it is only a single package we are
interested in (and I'm not aware of more) it is not worth to simply burn
computing cycles.

I also was not happy about finding that you are spreading clearly
biology related packages (like milib) over some other language teams.
By doing so these packages are effectively escaping all QA tools I've
written to make sure all our packages will be in good shape.  Please do
not do this without **really** good reason (and if you think you have a
really good reason please discuss it here anyway).  I'd say the only
exception for having a biology centric package maintained by a language
team is for R packages.  The reason is that we have at least 30% of the
R packages originally maintained by Debian Med and these packages are
included into the QA tools.

As a rule of thumb:
  1. If you have a citation in a biological or medical paper maintain
 the package in Debian Med Git.
  2. If the software is mentioned in one of the biological registries
 maintain the package in Debian Med Git.
  3. If you really want to derive from 1. or 2. discuss it here first

Any volunteer to put this into our team policy?

Kind regards

   Andreas.

-- 
http://fam-tille.de



Re: Metadata for parts of the sources

2019-02-19 Thread Aaron M. Ucko
Andreas Tille  writes:

>> Sidenote: Should cn3d be a separate binary package? I am a fan.
>
> That's a different question - I have put Aaron in CC.

Sure, I can split it out if that would be helpful; thanks for calling
the suggestion to my attention.  I'm inclined to call the binary package
ncbi-cn3d for consistency with other NCBI package names.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



Re: Metadata for parts of the sources

2019-02-19 Thread Steffen Möller



On 18.02.19 16:39, Aaron M. Ucko wrote:

Andreas Tille  writes:


Sidenote: Should cn3d be a separate binary package? I am a fan.

That's a different question - I have put Aaron in CC.

Sure, I can split it out if that would be helpful; thanks for calling
the suggestion to my attention.  I'm inclined to call the binary package
ncbi-cn3d for consistency with other NCBI package names.


Hi Aaron,

ncbi-cn3d would do, but cn3d is pretty unique such that IMHO it could also
stand alone. You may decide to have ncbi-tools-x11 depend or at least
recommend on it.

Best,

Steffen



Re: Metadata for parts of the sources

2019-02-19 Thread Steffen Möller



On 19.02.19 17:39, Steffen Möller wrote:


On 18.02.19 16:39, Aaron M. Ucko wrote:

Andreas Tille  writes:


Sidenote: Should cn3d be a separate binary package? I am a fan.

That's a different question - I have put Aaron in CC.

Sure, I can split it out if that would be helpful; thanks for calling
the suggestion to my attention.  I'm inclined to call the binary package
ncbi-cn3d for consistency with other NCBI package names.


Hi Aaron,

ncbi-cn3d would do, but cn3d is pretty unique such that IMHO it could 
also

stand alone. You may decide to have ncbi-tools-x11 depend or at least
recommend on it.

Best,

Steffen


Uh - I wanted to have started and ended with some big thanks for your
work on all these NCBI tools. Messed that one up.

So, now: Many thanks for all these efforts. Much appreciated!

Steffen