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 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel