[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: node-tty-browserify_0.0.0-1_amd64.changes REJECTED

Pirate Praveen writes ("Re: node-tty-browserify_0.0.0-1_amd64.changes REJECTED"):
> Thorsten Alteholz <ftpmaster@ftp-master.debian.org> wrote:
> > I am sorry, but I don't understand why you module makes sense.
> > Please add a more detailed description to your debian/control.
> This is seriously becoming too much. "This module is a dependency
> for browserify." is already present in the description. And short
> description says "tty module from node core for browsers".
> We are not expecting anyone to install this module directly. You
> can't apply the same standard of a full featured application to a
> small module. The whole node eco system is different from what we
> are used to before or after.

I don't see the original package.  When you escalate things like this
to -devel, can you please provide a link to the whole package which
was rejected ?

Descriptions are not only used by users to decide whether to install a
package; they are also used by system administrators deciding whether
to install a security update, Debian QA and release teams deciding
where to focus their effort, RC bug squashers trying to figure out how
to test a package, and so on.

The whole point of a Description is to be meaningful to people who are
not already familiar with the context.  As someone not familiar with
Javascript or Node.js, I'm afraid I have no idea what "tty module from
node core" is.

> You can't ask to do two mutually exclusive things at the same
> time. You have to either grant an exception to browserified
> javascript or accept small modules. You can't have it both ways.
> How do you expect we package browserify if you reject its
> dependencies like tty-browserify?

Of course many of us would like to see better Javascript support in
Debian.  But that does not necessarily mean that ftpmaster *must*
accept anything in particular.  (For example, ftpmaster might want you
to package these tiny modules in aggregate packages.  Apparently it
has been decided not to require that.  But that doesn't mean that
we are necessarily going to relax other requirements.

> I'm not super thrilled to package so many small dependencies, but
> I'm forced to package them because ruby-handlebars-assets won't
> be accepted without browserify. I'd happily stop packaging all
> these small modules if you grant an exception for
> ruby-handlebars-assets.

Is it very hard to write a better description ?

For modules which are "foo from node.js core for browsers" is there a
systematic way to find a description of node.js core's "foo" ?


Reply to: