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

Re: RRID update on salsa on packages starting with A+B




On 4/3/18 10:30 AM, Andreas Tille wrote:
On Tue, Apr 03, 2018 at 12:14:57AM +0200, Steffen Möller wrote:
Registry:
   - Name: OMICtools
     Entry: NA
   - Name: RRID
     Entry: NA
   - Name: bio.tools
     Entry: NA
That is an interesting one. Please kindly check

https://salsa.debian.org/med-team/autodocksuite/blob/master/debian/upstream/metadata

which on my side shows

Registry:
  - Name: OMICtools
    Entry: OMICS_19997
  - Name: SciCrunch
    Entry: SCR_012746
  - Name: bio.tools
    Entry: AutoDock
May be you forgot to push.  I now received

commit e5292af2136df30df8ea2a0da0dbeba6b82b027b (HEAD -> master, origin/master)
Author: Steffen Möller <moeller@debian.org>
Date:   Mon Mar 26 16:05:33 2018 +0000

     Added RRID to metadata

which has the values you are mentioning.  This was not available in the public
repository (at least until 1st of April).
Hm. No. Have not touched it again. May be some delay-thingy somewhere.
I remember it was not your prefered solution but for the moment 'NA'
values are not stored. [...]
How would you like <strike>Name</strike> and no fancy colouring?

The idea was to inform the world (and ourselves) that we have checked.
I admit I do not like this.  The thing is that the maintainers of the
repository could have updated their data.  Recent development shows that
this is a very probable action these days.  I do not think that the fact
that we have checked is no information which is valuable for a random
visitor of the tasks page and it might be simply wrong since the data
were updated.  So I keep on thinking that 'NA' is not anything
interesting for the page.  For us as developers we can easily do

     grep -w 'NA' */debian/upstream/metadata

if we want to find the information.

Right. If we developers have the whole of Debian Med checked out. I don't.
It is a side-issue. Don't worry.

The
problem is that we are unlikely to be informed about an entry being added to
the registry, so we would look bad. But since the advent of salsa.d.o I am
tempted to risk that.
Sorry, I do not understand this.

We have that mistake only for a few days upon notification.


bio-express (https://salsa.debian.org/med-team/express)
It is rather berkeley-express.  This works now[1].  The reason for the
problem was that the repository name is different from the source
package name.  The importer was simply wrong for these cases.  This is
fixed now (hopefully!) but we should definitely avoid this kind of
divergence and I'm tempted to adapt the repository name to the source
package name once we migrate anonscm.d.o to salsa.d.o (I've lost hope
for some sensible solution to keep anonscm working :-((().
Aaah. Yes. This sounds like a reasonable addition to the Debian Med policy.
We are intuitively doing it in close to all of our packages but
specifying it explicitly in policy makes sense, definitely.

gromacs
No Registry entries in d/upstream/metadata - so nothing to display here.
:o/ Because that is debichem and looked at my not-yet-merged own branch.
Why not asking for membership in Debichem and commit directly?

I was with debichem on alioth and eventually will ask for membership again.
However, I would loose the external view on how we present ourselves. And I
am much after attracting casual contributors to our cause, e.g. to improve
the description of our packages or ... registry entries in d/u/metadata. So,
debichem is a test-case to teach me how this feels on the other side.



This document is prepared every 24 hours for Debian packages selected in the
<a href="https://salsa.debian.org/blends-team/med/blob/master/tasks/bio";>Med
Bio Task Description</a> withinformation in the Ultimate Debian Database (<a
href="https://udd.debian.org";>UDD</a>).
The bottom line has a creation date of the web page.  Currently it says:

      Last update: Mon, 02 Apr 2018 19:21:37 -0000
Excellent. I have missed that one.
It was last updated at [Date+Time].
This information is not available, sorry.
I am uncertain about what "this" refers to, but maybe you have some idea
about who the page can explain itself to the ones who want to contribute
code or content.
There is a daily cron job parsing Salsa directories.
Fine. Somewhere there is (or should be :o) ) a documentation how this page
is crafted. On our Wiki? Let us then have a link to that page. Casual contributors, that is what I am primarily after. For everything else I happily ask you or Ole.
I do not keep
track on the information when this job is finished.  The UDD importer is
reading the result of this job later and I also do not keep track when
this job ends.  So we have two uncertain times - the only time that can
be safely displayed is when the web pages are displayed which is done on
the bottom line.  I admit that I'm not very motivated to make some
effort to keep track of the other times compared to other tasks on my
desk.

That is fine.

There could be a line like "Please allow 48 hours for your change to the
package selection or the package description to have an effect on this page."
There is no difference between pushing from remote repository and a web
interface edit.
Good.

Curious about this autodock/autodocksuite thingy and maybe there is some
chance to have this self-explaining bit at the end.
I have no idea how this can happen.  I do not use the web interface for
editing package data.

And I am after the casual contributions. salsa is everything to me these days.

Could branches for your cron job's autodock checkout differ? The page was updated this morning but yet not references. Or is there a second directory "autodock" when the source package name is "autodocksuite" (because of the joint autogrid tool)?

I have added registry links to about all green entries in bio now. Let us
review those over the next weeks a bit and then think about an announcing it
with the Debian News or whatever the list finds appropriate.
I'd love if we could find some default channel for Debian Med news (and
a person who feels dedicated to feed this channel regularly).

This is a bit of a side-track from the core of this thread. Maybe we would have Tony describing our achievements one they are manifesting in Bio-Linux. And if we have a look at https://salsa.debian.org/dashboard/milestones ? Maybe we can use those as an anchor for achievements from which news could be generated in an easier way, not necessarily by us.

Once we have workflows more prominently working with Debian Med, I am confident that mainstream media will find us. We eventually need to discuss this more openly: What workflows would be ok for us to redistribute if this enables everyone with sufficient technical skills to install Linux to test their 23andme/..yonameitservicetosequenceyourgenome... data for disease-associated SNPs and (not unlikely) its distribution in the family?

Best,

Steffen





Reply to: