[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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



Reply to: