Re: "Entry: NA" in debian/upstream/metadata

[Andrius Merkys]

Hi Steffen,

On 2021-03-04 23:12, Steffen Möller wrote:
> This reminds me of the early days of my computer science education with
> the question if {} and {{}} are the same thing. They are not. My first
> idea was that the parser is to blame, but the example at
> https://yaml.org/type/null.html makes the same
> what-I-consider-to-be-a-mistake. I am a fan to use the ~ as a proper NA
> substitute but there is little point if we cannot distinguish it from
> nothing when parsing it.

If the DEP 12 was designed just now, I would vote for ""/~ pair, because
these two are clearly separable via parsers. Moreover, I am positive
that empty string ("") would not clash with any identifier in any
registry. However, consensus seems have been reached here that
Debian-wide replacement s/NA/""/g is not worth the hassle, as we should
not worry about an identifier equal to "NA". And I see the point.

> Somewhere else was the suggestion made to also add a time stamp. This
> makes perfect sense for the NA/~ and in that case, if that date was
> specified, we know that unknown is a confirmed unknown. For entries that
> are found, we should possibly just rely on git blame in salsa.

Exactly. This was my point. Because if someone stumbles upon a timestamp
from 3+ years ago, one may check the registry to see if the entry is
still not there. If the entry is still missing, one would update the
timestamp to let everyone else know "hey, I have checked it, and it is
not there". Otherwise one's effort will be lost, and the next one who
sees a missing entry may repeatedly drain one's time looking.

Best,
Andrius

Re: Outreachy project: complete workflows of tools

[Tassia Camoes Araujo]

Hi all,

>> On 04/03/2021 16:54, Andreas Tille wrote:
>>> [...]
>>> If I understood you correctly your question to Tony was whether he might
>>> like to volunteer to support drafting an Outreachy proposal.  Guessing
>>> from Tony's response to your mail this was not totally clear to him.
>>
Thanks, Andreas!

> Am 04.03.21 um 22:09 schrieb Tony Travis:
>> I'm planning to re-write the tutorial, which includes QIIME, for my
>> Debian-Med version of Bio-Linux, but it would be really helpful if
>> someone is interested in doing that as part of an 'Outreachy' project.
>>
Seems like a plan!

On 2021-03-04 16:19, Steffen Möller wrote: 
> I am very confident that Tony would be a wonderful mentor. I happily
> help by co- or co-co-mentoring - we had discussed Qiime at the very last
> minutes of our Sprint if I recall correctly.
> 
I'm checking if 3 mentors are possible, and I could help you with all
the
bureaucracy with Outreachy. If not, I think it would make more sense to
have
the two of you as mentors. In any case, I'll be following the process
and
helping informally.

> So, with Tony having gone the conda route a while back when our recent
> Debian packages have not yet been existing, I see this as particularly
> valuable for Tássia to both experience and compare.
>
That's all great!

Now we need to submit an intern project proposal, and deadline is March
11th
(next Thursday). First we need to define the following:

- Project title & description
- How can applicants make a contribution (starter tasks)
- Applicant skills (description, impact on intern selection, experience
Level)
- Intern tasks

Since deadline is approaching quickly, I suggest we move this off-list
and start
writing in a wiki or pad. We could also schedule a meeting to write this
together, if you prefer.

Please take a look at Pre-application Process [1] and mentor
requirements [2],
just to confirm we are all on the same track ;-)

Thanks!

Tassia.
--

[1] https://www.outreachy.org/mentor/mentor-faq/#define-a-project
[2] https://www.outreachy.org/mentor/#mentor

Re: Outreachy project: complete workflows of tools

[Nilesh Patra]

Hi,

On Fri, 5 Mar, 2021, 9:40 pm Tassia Camoes Araujo, 
wrote:

> Hi all,
>
> On 2021-03-04 16:19, Steffen Möller wrote:
> > I am very confident that Tony would be a wonderful mentor. I happily
> > help by co- or co-co-mentoring - we had discussed Qiime at the very last
> > minutes of our Sprint if I recall correctly.
> >
> I'm checking if 3 mentors are possible, and I could help you with all
> the
> bureaucracy with Outreachy. If not, I think it would make more sense to
> have
> the two of you as mentors. In any case, I'll be following the process
> and
> helping informally.
>

Having 3 mentors is entirely possible out of which one would be primary
mentor, and the other would co-mentors(having seen it)

However, to my understanding, the powers of mentors and co-mentors are the
same as far as reviews+coordinating with outreachy+filling evaluations goes.
In fact, in the winter outreachy round in 2020, we had "5" mentors for one
of the projects
We didn't get any interns finally though, but well that's a different story


> > So, with Tony having gone the conda route a while back when our recent
> > Debian packages have not yet been existing, I see this as particularly
> > valuable for Tássia to both experience and compare.
> >
> That's all great!


> Now we need to submit an intern project proposal, and deadline is March
> 11th
> (next Thursday).


I'd really want to thank you for putting these efforts! :-)

Nilesh

Re: guix-based installation of pigx-rnaseq - works

[Steffen Möller]

Am 05.03.21 um 01:10 schrieb zimoun:
> Hi,
>
> On Wed, 03 Mar 2021 at 20:45, Steffen Möller  wrote:
>
>>> What would be nice for Debian instead of
>>> ?
>> The updates of Debian's packages and those of guix are not synchronized.
>> And once something is in a regular Debian release, the Debian package
>> likely points to an older version of the same in guix. It would hence be
>> preferable to have an unversioned page to point to - which then lists
>> all the versions available for that package.
> Something like that:
>
> 1: 
> 
>
> ?
>
https://data.guix.gnu.org/repository/1/branch/master/package/vim/

Seems just fine.

>>> And where could I find a an example on how the others do?
>> https://tracker.debian.org/pkg/vim
> Something equivalent is the Guix Data Service, as mentioned in [1].

I'll add some refs in d/u/metadata over the upcoming weeks to get this
forward - if you feel like adding some yourself for the med packages,
just ping me with your salsa account, please.

Best,

Steffen

Re: Outreachy project: complete workflows of tools

[Andreas Tille]

Hi all,

On Fri, Mar 05, 2021 at 08:09:44AM -0800, Tassia Camoes Araujo wrote:
> 
> Now we need to submit an intern project proposal, and deadline is March
> 11th
> (next Thursday). First we need to define the following:

Short notice from my side:  Starting from the next hour until Sunday
14.3. I'm rarely online due to real live preferences.  So please do
not trust on me in the initial project definition phase (even if I
might have a look from time to time.
 
Kind regards

  Andreas. 

-- 
http://fam-tille.de

Re: guix-based installation of pigx-rnaseq - works

[Steffen Möller]

Am 05.03.21 um 18:10 schrieb Steffen Möller:
> Am 05.03.21 um 01:10 schrieb zimoun:
>> Hi,
>>
>> On Wed, 03 Mar 2021 at 20:45, Steffen Möller  wrote:
>>
 What would be nice for Debian instead of
 ?
>>> The updates of Debian's packages and those of guix are not synchronized.
>>> And once something is in a regular Debian release, the Debian package
>>> likely points to an older version of the same in guix. It would hence be
>>> preferable to have an unversioned page to point to - which then lists
>>> all the versions available for that package.
>> Something like that:
>>
>> 1: 
>> 
>>
>> ?
>>
> https://data.guix.gnu.org/repository/1/branch/master/package/vim/
>
> Seems just fine.
>
 And where could I find a an example on how the others do?
>>> https://tracker.debian.org/pkg/vim
>> Something equivalent is the Guix Data Service, as mentioned in [1].
> I'll add some refs in d/u/metadata over the upcoming weeks to get this
> forward - if you feel like adding some yourself for the med packages,
> just ping me with your salsa account, please.

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

Registry:
- Name: OMICtools
Entry: OMICS_33677
- Name: conda:bioconda
Entry: NA
- Name: guix
Entry: pigx-rnaseq

Andreas already kindly offered to do the downstream adjustments from here.

Cheers,
Steffen

What date format for d/u/metadata ? Re: "Entry: NA" in debian/upstream/metadata

[Steffen Möller]

Hi Andrius,

Am 05.03.21 um 16:13 schrieb Andrius Merkys:
> Hi Steffen,
>
> On 2021-03-04 23:12, Steffen Möller wrote:
>> This reminds me of the early days of my computer science education with
>> the question if {} and {{}} are the same thing. They are not. My first
>> idea was that the parser is to blame, but the example at
>> https://yaml.org/type/null.html makes the same
>> what-I-consider-to-be-a-mistake. I am a fan to use the ~ as a proper NA
>> substitute but there is little point if we cannot distinguish it from
>> nothing when parsing it.
> If the DEP 12 was designed just now, I would vote for ""/~ pair, because
> these two are clearly separable via parsers. Moreover, I am positive
> that empty string ("") would not clash with any identifier in any
> registry. However, consensus seems have been reached here that
> Debian-wide replacement s/NA/""/g is not worth the hassle, as we should
> not worry about an identifier equal to "NA". And I see the point.
>
>> Somewhere else was the suggestion made to also add a time stamp. This
>> makes perfect sense for the NA/~ and in that case, if that date was
>> specified, we know that unknown is a confirmed unknown. For entries that
>> are found, we should possibly just rely on git blame in salsa.
> Exactly. This was my point. Because if someone stumbles upon a timestamp
> from 3+ years ago, one may check the registry to see if the entry is
> still not there. If the entry is still missing, one would update the
> timestamp to let everyone else know "hey, I have checked it, and it is
> not there". Otherwise one's effort will be lost, and the next one who
> sees a missing entry may repeatedly drain one's time looking.

Since I was just active on pigx-rnaseq for the thread on guix, I came up
with

Registry:
 - Name: OMICtools
   Entry: OMICS_33677
 - Name: conda:bioconda
   Entry: NA
   Checked: Fri, 05 Mar 2021 20:06:08 +0100
 - Name: guix
   Entry: pigx-rnaseq
 - Name: bio.tools
   Entry: NA
   Checked: Fri, 05 Mar 2021 20:07:04 +0100

But, donno, this RFC 5322 is barely parseable by eye, even though this
is how we typically put dates in Debian (you get this via 'date -R').
Much more readable though would be `date --rfc-3339=date`

Registry:
 - Name: OMICtools
   Entry: OMICS_33677
 - Name: conda:bioconda
   Entry: NA
   Checked: 2021-03-05
 - Name: guix
   Entry: pigx-rnaseq
 - Name: bio.tools
   Entry: NA
   Checked: 2021-03-05

but do our American friends understand that this is not May? And we do
not need the time, as in

2021-03-05 20:14:12+01:00

I would start without the time and then add it if needed - but as I
said, the art is to eliminate the NAs in the respective
registry/repository and for that, the time of the day does not really
matter, I tend to think.

A pending question is if we need a "" as in "This entry is not
going to be added to that repository". I personally do think so and
consider this information more important than the NA since a repeated
request likely annoys someone on the other end.

Thanks!

Steffen