[Pkg-javascript-devel] Packages ready to review

[Paolo Greppi]

Il 09/05/2018 10:30, Paolo Greppi ha scritto:
> ...
> Of course before we make it part of our workflow, the manual bits have to be
> streamlined.
> 
> There are some python scripts that you can use to sync the BTS bugs to gitlab
> issues:
> https://lists.debian.org/debian-devel/2018/03/threads.html#00318
> 
> They could help us automatically move out of the way the issues linked to ITPs
> that have been closed.
> To automatize the creation of issues from ITPs is trickier.
> I cannot think of a feasible criterion to filter the wnpp bugs in the BTS to
> import only those "belonging" to pkg-javascript-devel.
> Perhaps we could attach some tag / label in the BTS ...
> ...

We should automate the syncing with the BTS, but the best way to understand if
this kanban thing can be useful to the team is to populate it and play with it.

So I looked in the BTS which ITPs we are working on.

I found 268 pending ITPs related to node or JavaScript based on the title
alone:
  ssh git.debian.org
  psql -U guest -h udd.debian.org -p 5452 udd
  SELECT count(*)
  FROM all_bugs
  WHERE
    package='wnpp'
    AND (title LIKE 'ITP: libjs-%' OR title LIKE 'ITP: node-%')
    AND status = 'pending' ;

Then I fetch the ITPs that would be closed by uploads that are sitting in the
NEW queue:
```
wget http://212.237.56.209/new.json
cat new.json | jq '.[] | {status: .status, source: .source, itp: .changes.closes}'
```

I used a spreadsheet to join these lists, and found out that of the 268 pending
ITPs, 160 are in NEW.
So we're left with 108 ITP; now how to find out which ones are meant to be
maintained in the js-team ?

As a first approx, if a repo is present in salsa.debian.org/js-team or on
alioth /git/pkg-javascript with the name of the ITP source package, we can
assume that the ITP owner intends to maintain it in the js-team.

Turns out of the 108 pending ITPs not yet in NEW there were 13 with a salsa
repo and 14 with an alioth one, so I created them manually (migrating the 14
repos from alioth to salsa in the process), and assigned them to the ITP owner
(if I could find a matching salsa user).

In doing this I realized that the current ITP workflow should take into account
that:

1. there may be several duplicate ITP bugs in the BTS associated to a new
   package

2. there may be non-ITP bugs such as O: or RFP: where someone is working at,
   but did not yet change the title to ITP

3. DMs will need RFS also for updates (possibly without an associated bug in
   the BTS)

4. DDs won't need sponsorship obviously but may benefit from the RFC step as well.

Paolo