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

[Xavier]

Le Mardi, Octobre 22, 2019 14:07 CEST, Jonas Smedegaard <jonas at jones.dk> a écrit: 
> Quoting Xavier (2019-10-22 13:23:28)
> > Le Mardi, Octobre 22, 2019 12:03 CEST, Jonas Smedegaard <jonas at jones.dk> a écrit: 
> > > Quoting Xavier (2019-10-22 11:32:19)
> > > > Le Mardi, Octobre 22, 2019 11:15 CEST, Jonas Smedegaard <jonas at jones.dk> a écrit: 
> > > > > Quoting Xavier (2019-10-22 10:01:11)
> > > > > > Le Mardi, Octobre 22, 2019 09:10 CEST, Julien Puydt <julien.puydt at laposte.net> a écrit: 
> > > > > > > If you want to have ts-node, why not package it properly, 
> > > > > > > with a RFP or ITP?
> > > > > > > 
> > > > > > > I don't see the point into packaging those together...
> > > > > > 
> > > > > > It was an attempt to avoid waiting 6 or 7 months in the NEW 
> > > > > > queue with a 50% chance of getting an acceptance or never 
> > > > > > getting an answer (which seems to be considered as a 
> > > > > > rejection, see node-mimelib for example).
> > > > > > In node-sinon packaging, we decide to embed @sinon ecosystem 
> > > > > > to avoid this. I thought we could consider ts-node as part of 
> > > > > > the typescript ecosystem.
> > > > > > 
> > > > > > Then OK, I'll ITP and continue to embed ts-node in some 
> > > > > > packages...
> > > > > 
> > > > > Please do *not* hide code from ftpmasters by embedding it in 
> > > > > other packages - that is foul play, and you risk getting banned 
> > > > > from Debian!
> > > > 
> > > > Remember that embedding is a requirement from ftpmaster. I don't 
> > > > hide anything in my package and I follow all the rules I know.
> > > 
> > > Great!
> > > 
> > > 
> > > > But if you think my work is bad, please denounce me and ask for my 
> > > > immediate expel !
> > > 
> > > What I try to communicate above is that it seems you are missing a 
> > > rule when you describe avoiding NEW queue as a reason for embedding.
> > > 
> > > (sure there are _other_ reasons for _sometimes_ embedding)
> > 
> > Like tsc, ts-node is used during build or test. I already pushed 
> > packages in new queue with build or test components embedded and 
> > ftpmaster accepted them (I always put test component in 
> > debian/tests/test_modules), same during Buster freeze: I fixed some 
> > problem and enabled test using embedded components : it has been 
> > reviewed and accepted by release team.
> 
> Great!
> 
> 
> > Many packages are missing to enable upstream tests in our packages.
> 
> Yes, and that is horrible - we should certainly improve on that!
> 
> Let's make sure to flag all superficial autopkgtests as such, to more 
> clearly get an indication of what is weakly tested.
> 
> And let's package more test helpers like sinon and eslint (to mention 
> one you are working on and one that I am working on).
> 
> 
> > If this group decide to ban embedding test and/or build modules, 
> > [snip]
> 
> Noone is talking about banning embedding modules here!
> 
> Embedding makes sense for tiny projects where the benefit (reducing 
> metadata in our packaging system) outweigh the drawbacks (complicated 
> packaging, weaker upstream change tracking).
> 
> My point above is that _abusing_ embedding to avoid ftpmaster review is 
> wrong and bad and if done may in worst case lead to expulsion.
> 
> Oh, and let me write it explicitly to avoid doubt: I am *NOT* implying 
> that you should be expelled now, nor that I dislike you or your work.
> 
> I am reacting to things you write here being a reason for embedding, not 
> reacting to things you have done in any packages.
> 
> 
> > 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)...
Then when/if psl.js is accepted, I'll update node-tough-cookie and package that depends on it will be able to upgrade. 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...
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.

Embedding was a way to try to deliver some package with better quality, 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,...).

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.

> > The trouble came when ftpmaster asked us to stop packaging separately 
> > and group package. Initially for "little" components, but some 
> > not-so-little where also rejected. I worked on uscan and pkg-js-tools 
> > to propose some workaround to this new requirement.
> 
> I also found it super frustrating that ftpmaster "hit the break" on our 
> previous packaging style and demanded that we re-evaluate and do better. 
> But at the same time I understand why they did it (and no, not only 
> JavaScript packages was affected by that).
> 
> I also (still!) find it super frustrating that rulings by and/or 
> dialogues with ftpmaster is sometimes not very sensible to me.
> 
> I disagree with describing it as "trouble" - it was a frustrating but 
> needed change.  And it is an ongoing change - tools like uscan need 
> adaptation to deal with versioning schemes for bundling, and we need to 
> learn more about which scheme is most sensible to bridge the different 
> thresholds for metadata between upstream and Debian.
> 
> 
> > The idea here was to group ecosystems to follow ftpmaster new 
> > requirement.
> 
> Great.  Then I totally misunderstood you, because you initially talked 
> about embedding as a means to avoid long waiting time in NEW queue.