Le dimanche 07 septembre 2014 à 10:44 +0200, Jonas Smedegaard a écrit :
> Quoting Leo Iannacone (2014-09-07 10:21:24)
> > On 6 September 2014 14:30, Jonas Smedegaard <d...@jones.dk> wrote:
> > And... should we have a "max-lines-of-code" number under of that the
> > module should go in a multi-module package ?
> I am sceptical to such quantitative measure. But then again, I am
> sceptical to the whole approach so should probably step back and let
> those exploring the approach discuss here :-)
> My point was not that recent activities on bundling tiny Node packages
> has failed, but that a) I most likely won't participate in that and b) I
> recommend to beware if really needed (do the critical voices in Debian
> indicate real trouble e.g. with Policy or just a loud minority opinion).
While i think a package manager is supposed to manage packages, not
force upon us arbitrary constraints, i must admit i'm not so happy with
many small modules doing the same thing, like the multiplication of
async helpers, or ansi tools, or stream tools (which is caused by the
absence of a standard library for Node.js).
Eventually, in a given category, many modules are going to be removed in
favor of one (most popular / technically sound).
Instead of waiting for the natural selection to happen, there are
several things we could do to fasten the process:
* bundle similar modules in the same category
* propose a good representant, popular module of that category and
progressively patch away all others in the same category
* add some "compatibility helpers" to a representant module to ease
replacement of other modules
In the end, i'm not sure any of this work will be really useful, since
the time spent doing that is time not spent on the quality of existing
packages, and i don't think it would be a vast improvement to do that.