[Pkg-javascript-devel] Bug#942809: Why embed ts-node in node-typescript?

Tue Oct 22 15:46:41 BST 2019

Quoting Xavier (2019-10-22 14:45:50)
> Le Mardi, Octobre 22, 2019 14:07 CEST, Jonas Smedegaard <jonas at jones.dk> a écrit: 
> > Quoting Xavier (2019-10-22 13:23:28)
> > > Personnaly I think that we should enable test anywhere it is 
> > > possible to provide quality packages. That's why I prefer 
> > > embedding than pushing package without test.
> > 
> > I agree we should test instead of not test.
> > 
> > I agree we should package testing tools to improve ability to test.
> > 
> > I agree we should embed when embed tiny projects into other 
> > packages.
> > 
> > I disagree that testing inherently requires embedding.
> 
> Inherently not, ... but... Concrete example: node-though-cookie is 
> outdated. Upgrade needs node-psl. psl is a real package, widely used, 
> then I decided to package it separately... 4 months ago (package is 
> clean, no lintian warnings, no ftpmaster question, just too many 
> time)...

Sounds reasonable to introduce psl as new _binary_ package (not embed in 
_binary_ package node-though-cookie and add "Provides: node-psl" hint): 
Upstream project has many seemingly unrelated reverse dependencies which 
are probably not all also depending on node-though-cookie, so it would 
be annoying to have those needlessly pull in node-though-cookie.

Sounds reasonable to instroduce psl as new _source_ package (not embed 
in src:node-though-cookie): It isn't tiny.

NEW entry: https://ftp-master.debian.org/new/psl.js_1.2.0+ds-1.html

No lintian warnings is a good _baseline_ - i.e. avoids speedy 
_rejection_ but not a reason for speedy _acceptance_ by ftpmasters.

My understanding is that NEW queue is not processed as a FIFO, but 
ftpmasters work on packages as they have time, as the volunteers they 
are - just like you and me.  As I understand it, silence generally means 
no ftpmaster has gotten around to look at the package yet.  Why might 
that be?  Could be the very fact it is JavaScript with its reputation of 
commonly having problems and rejections commonly being discussed, so not 
really fun for ftpmasters to touch. Could be that it is related to 
Public Suffix List yet it does not depend or build-depend on 
publicsuffix, indicating high risk of problems concretely.

> Then when/if psl.js is accepted, I'll update node-tough-cookie and 
> package that depends on it will be able to upgrade.

Every new project we introduce into Debian need ftpmaster inspection. 
That's tied to our core values of Free Software.

Embedding that new upstream project into an already inspected package 
means that new codebase is missed a crucial inspection.  That'd be bad!

It is painful when inspection is slow.  But blaming ftpmasters is not 
helping.  Upstream spawns new projects at a higher rate than we can 
package in Debian (read: we need more people in the JavaScript team), 
and upstream care less about freedom than Debian (read: we do need 
ftpmaster processing!).  And JavaScript team introduces upstream projects to Debian at a higher rate 
than ftpmasters can process (read: We need more ftpmasters).

Sounds to me like Debian need more people volunteering for ftpmaster 
tasks - more people who understand and care for JavaScript, so that they 
might prioritize processing those packages in the NEW queue over other 
tasks in the ftpmaster team.

...but beware: I am _not_ suggesting anyone to volunteer for ftpmaster 
tasks by the expectation that they can get packages approved that others 
in the ftpmaster team would reject.  So I am _not_ suggesting that 
volunteering for ftpmaster tasks in any way _replaces_ doing proper 
Debian packaging.  I only suggest that more worker bees reduce time.

> But if one upgrade needs a new package, then a new 4-6 months is 
> needed. In this delay, node-tough-cookie will probably need a new 
> dependency...

Each time a _new_ project needs to get introduced to Debian, there is a 
wait, which _may_ be months but can be weeks or days or hours.

There is no need to wait until the package is processed: You can queue 
up additional revisions of an unapproved package, and the ftpmasters 
will (in my experience) process them together.

Upstream projects crucially needing _new_ dependencies every 3-4 months 
sounds like projects unsuitable for long-term maintenance - i.e. unfit 
for Debian.

> Following our udd.debian.org page, most of our package are strongly 
> outdated (I upgraded this morning node-superagent from 0.2.x to 5.x
> !!!). That's a big problem IMO, Debian Buster proposes a lot of
> totally outdated/unusable node package.

Agreed, that's a big problem. For our team, not for NEW queue.

> Embedding was a way to try to deliver some package with better 
> quality,

Wrong.  Embedding just avoids metadata.

Embedding which implies a speedup - because it is seen as a way to 
introduce new upstream code projects without needing to pass through NEW 
queue - then embedding is being _abused_ for the wrong reason.

> but if it can't be used in this way (and since nothing will 
> change in new queue), we should limit strictly the number of package 
> provided by this group: a good node.js, node-gyp and npm/yarn, and 
> then only dependencies of other project (jquery, bootstrap, 
> react,...).

Regardless of the speed of NEW queue, and regardless of embedding, we 
should tighten our responsibility for the packages we maintain.

As a start, let's do as the Multimedia team: Use Uploaders field to 
indicate who is actively caring for each package, and require that 
packages must list at least 2 Uploaders to belong in the team.

Packages with fewer active uploaders is then an indication that more 
people in the team need to step up and care more for a package, or the 
package should either be moved outside the team (maintained by a single 
maintainer independently, or flagged as orphaned so that everyone in 
Debian can see how "rotten" it becomes, or dropped from Debian.

But let's start with making it possible to identify what we care for - 
as independent measure from how up-to-date it is or how long ago it was 
touched.  Let's treat "Uploaders" as "caretakers"!

> Like you, I'm also member of Perl Team, and I never see a Perl package 
> staying more than 3-4 weeks in NEW queue.

Pers modules are generally far easier to process, both by maintainers 
and (in my experience, implied by processing time) by ftpmasters.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20191022/fcaf7fc2/attachment.sig>