[Pkg-javascript-devel] Packages ready to review

[Paolo Greppi]

Il 09/05/2018 08:25, Xavier ha scritto:
> Le 08/05/2018 à 10:55, Pirate Praveen a écrit :
>> On തി, മേയ് 7, 2018 at 8:10 വൈകു, Xavier <x.guimard at free.fr> wrote:
>>> Updated list of packages to review: - node-mongodb - node-mongodb-core
> ...
>> Also rebuild browser_build/bson.js using the provided webpack
>> configuration. See
>> https://wiki.debian.org/Javascript/Nodejs#Using_build_tools_like_grunt
> 
> OK, but this need to package babel-polyfill and used only to provide
> browser lib (which is no more provided since renaming). I've so skipped
> this step
> 
>> - node-nodedbi - node-file-cache-simple - node-fs-jetpack -
>>> node-inireader - node-q - node-syslog-client Regards, Xavier
> 
> I packaged also node-modern-syslog
> 
> Regards,
> Xavier

Looking at this thread which involves a dozen ITPs, and at the batch of 118
ITPs to process for the ongoing refresh/review of the already uploaded
packages:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2018-May/026121.html
I realized that it would be easier to track this type of work (that involves
many ITPs) in a gitlab kanban ("issue board"):
https://docs.gitlab.com/ee/user/project/issue_board.html

To test this hypothesis, I have created a pseudo-project in salsa:
js-team/current_itps
In there I have enabled the issues tracker [1], then manually (!) created
issues for all my open ITPs not yet uploaded (4), and also for a random one
picked from the 14 which I have uploaded but are stuck in the NEW queue.

But the idea is NOT to add permanent, important updates to these issues: these
belong to the BTS !

The salsa tracker could be used in a complementary way to the BTS to keep track
of volatile, transient information (that currently flows through the mailing
list, IRC, and the ftp-master NEW queue), and visualize it in the issue board:
https://salsa.debian.org/js-team/current_itps/boards

As a start, I have created three labels (shown in the issue board besides the
default ones "Backlog" and "Done"), which correspond to three different
"stages" an ITP can be at:
- "RFC": Requesting comments from all members of the js-team
  this is intended to be used when packaging work is almost complete and the
  maintainer would like to have the other team members to have a look at it
  (at this point you should add a link to the salsa repo to make this review
  easier)
- "RFS": Request for sponsorship
  moving an ITP into this column could replace the usual RFS:... mail to the
  mailing list
- "NEW": Is stuck in the ftp-master NEW queue
  moving issues TO this column could be made automatic thanks to the
  ftp_master_fancy_new script, requiring no additional action from the sponsor

Feel free to experiment with creating issues for your ITPs in the
js-team/current_itps repo and try out the issue board.

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 ...

At this point I want to disclose my hidden agenda, which has three items:
- I want to exploit the new toy (gitlab)
- I aim to increase collaboration within the js-team
- I would like to make the sponsor process more robust, by involving more
  people besides the uploader and the sponsor (that's the purpose of the RFC
  stage I propose).

All that because I believe the ftp-master team is more likely to address the
node-* backlog if they can trust us to have made every effort that the uploaded
packages are not crap.

What do you think ?

Paolo

[1] By default, the issues tracker is disabled for each new salsa project. To
turn it on, go to project / settings / general:
https://salsa.debian.org/owner/project/edit
then expand Permissions, turn on issues for "Everyone with access", then Save
changes.