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

Tue Oct 22 13:07:49 BST 2019

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.

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

 - 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/7aad3c0f/attachment.sig>