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@xxxxxxxxxxxxxxxxxxxxx> 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
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
> How do you expect we package browserify if you reject its
> dependencies like tty-browserify?
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
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" ?