Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

2018-03-11 Thread Bastien ROUCARIES
On Sun, Mar 11, 2018 at 9:15 PM, Bill Allombert wrote: > On Sun, Mar 11, 2018 at 02:48:40PM +0530, Pirate Praveen wrote: >> > * Some Javascript modules are very small, resulting in lots of small >> > packages >> >> I think we need to balance the small packages concern with number of >> times suc

Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]

2018-03-11 Thread Bill Allombert
On Sun, Mar 11, 2018 at 02:48:40PM +0530, Pirate Praveen wrote: > > * Some Javascript modules are very small, resulting in lots of small > > packages > > I think we need to balance the small packages concern with number of > times such small packages are used. > > node-has was rejected recently

Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]

2018-03-11 Thread Pirate Praveen
On ഞായര്‍ 11 മാർച്ച് 2018 04:59 വൈകു, Simon McVittie wrote: > The reason I suggested that restriction was to avoid having contradictory > requirements: if node-foo is the naming convention for the module > that lets nodejs users require('foo'), and node-foo is also the naming > convention for a nod

Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]

2018-03-11 Thread Simon McVittie
On Sun, 11 Mar 2018 at 14:48:40 +0530, Pirate Praveen wrote: > On വെള്ളി 09 മാർച്ച് 2018 08:39 വൈകു, Simon McVittie wrote: > > And for executables, perhaps something like this: ... > > * should not be named node-* without a suffix like -bin or -tools (?) > > I don't think there is any particular b

Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]

2018-03-11 Thread Pirate Praveen
On വെള്ളി 09 മാർച്ച് 2018 08:39 വൈകു, Simon McVittie wrote: > I think saying "script" is perhaps unhelpful here, because outside > Javascript, that usually refers to something executable with #! at the > beginning. > > It might be clearer to think about this in terms of libraries and > executables