Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
Pirate Praveen writes ("Re: [Pkg-javascript-devel]
three.js_80+dfsg2-2_amd64.changes REJECTED"):
> On വ്യാഴം 01 മാർച്ച് 2018 05:45 വൈകു, Ian Jackson wrote:
> > For the avoidance of doubt, I don't have a problem with the specific
> > decision of ftpmaster here.
>
> Coming back to this specific rejection (I have already started a
> discussion on policy question in d-policy), do you agree node-backbone
> (and all other packages currently in archive and match the criteria of
> rejection used for node-three, ie, a binary package with just symlinks
> and a package.json) should be removed from the archive? If that is the
> general agreement, I will file serious bugs against these packages
> (already in the archive for years).
Firstly, I don't think this follows. It is right that the criteria
for accepting a new package are stricter than the criteria for
removing an existing one.
Secondly, the actual question of what should be in these packages is
precisely a policy question. We should decide what our policy is and
then apply it. (Of course examples can illuminate the policy.) So I
don't think your queston can be answered until we know what the policy
should be.
By "don't disagree" I don't mean "agree". I mean that the rejection
seems plausible and I haven't seen enough arguments to have a firm
opinion.
If the policy we decide on is that the packages with just symlinks
should be folded into the packages they provide links to, then yes
those packages should be fixed but it is IMO unlikely to be sensibly
considered an RC bug.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On വ്യാഴം 01 മാർച്ച് 2018 05:45 വൈകു, Ian Jackson wrote: > For the avoidance of doubt, I don't have a problem with the specific > decision of ftpmaster here. Coming back to this specific rejection (I have already started a discussion on policy question in d-policy), do you agree node-backbone (and all other packages currently in archive and match the criteria of rejection used for node-three, ie, a binary package with just symlinks and a package.json) should be removed from the archive? If that is the general agreement, I will file serious bugs against these packages (already in the archive for years). signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On വെള്ളി 02 മാർച്ച് 2018 04:38 വൈകു, Ian Jackson wrote: > This is the first I'd heard of this being a policy question. How > about you discuss the team policy and the reasons behind it on > d-policy CC the javascript list. If you wish to retain the policy, > but ftpmaster disagree with it, you can escalate the policy question > to the TC. > > The TC are empowered to "Decide on any matter of technical policy". > If the TC endorse your policy then I don't doubt that ftpmaster will > stop rejecting packages for complying with it. > > Ian. > Thanks for the suggestion, I have started a thread in d-policy. signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On വെള്ളി 02 മാർച്ച് 2018 02:00 വൈകു, Joerg Jaspert wrote: > But if you continously "run into the same wall", then it does not do any > good to assume its that one person hating you and that, if you happen to > get to another team member, they will like you. It's the wrong mindset. This is based on my past experience with multiple packages where same criteria was interpreted differently by different ftp masters (At least 3 cases I can quote 1. node-babel-preset-env was rejected but node-rollup was accepted, both can't be bootstrapped without a binary upload first. 2. I was asked to make a single handlebars package, by waldi, but it was accepted by Chris 3. There was long discussion on node-babel but it was easily resolved when another ftp master was involved). > Also, possibly we should adjust our communications here, at least get > others to respond/jump in (earlier). Not sure we need it so much formal > as Ian wrote down, but get someone else in early shouldn't hurt. > Thanks. signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
Pirate Praveen writes ("Re: [Pkg-javascript-devel]
three.js_80+dfsg2-2_amd64.changes REJECTED"):
> So in this specific case, I will add these files to libjs-three. I think
> ftp masters don't want to distinguish between browser environment and
> node environment, but just have one package. See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837467#22 for a
> previous instance of this demand. I think arbitrarily reducing the
> number of binary packages is more important than following JavaScript
> team policy https://wiki.debian.org/Javascript/Policy which says "should
> generate a node-foo binary package if the script is usable also for Nodejs".
>
> I also propose we abandon the current Javascript team policy because it
> is not supposed to be followed. Just have one binary package for every
> source package irrespective of it is useful for node or browser.
This is the first I'd heard of this being a policy question. How
about you discuss the team policy and the reasons behind it on
d-policy CC the javascript list. If you wish to retain the policy,
but ftpmaster disagree with it, you can escalate the policy question
to the TC.
The TC are empowered to "Decide on any matter of technical policy".
If the TC endorse your policy then I don't doubt that ftpmaster will
stop rejecting packages for complying with it.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On 14963 March 1977, Pirate Praveen wrote: >> I wonder why you think "a single ftpmaster". We are a team. We closely >> coordinate what we do and how we do it. When one of us rejects, the team >> rejects - it just happens to be a random one of us doing it. Others do >> not need to get involved and review everything. Or we wouldn't ever be >> able to get anything done if each of us always has to weight in on any >> single issue. > Thanks for the clarification. I was thinking about it more like how the > courts work in India (possibly in other countries too). When a single > judge decides on a case, there is always an option to appeal to larger > bench (more number of judges). Right. > The team as a whole has to weigh in only when the decision of a single > team member is challenged and such a review is requested. > I don't think it is healthy to not have an option of reviewing > individual members decisions. > > That leaves me only GR as a possible escalation route. I will think > about it. And no, I didnt say one can not ever challenge a reject, although one can put that meaning in my words, sorry for that. Quite the contrary, despite other rumours, we are all just humans, and humans make mistakes. And we are open to be told about such and do admit them, and yes, that does happen. But if you continously "run into the same wall", then it does not do any good to assume its that one person hating you and that, if you happen to get to another team member, they will like you. It's the wrong mindset. Also, possibly we should adjust our communications here, at least get others to respond/jump in (earlier). Not sure we need it so much formal as Ian wrote down, but get someone else in early shouldn't hurt. -- bye, Joerg -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On വ്യാഴം 01 മാർച്ച് 2018 10:47 വൈകു, Gunnar Wolf wrote: > We should not wait for dissent just forever. The issue you mention was > rejected by ftp-masters, then brought to the TC, then dismissed by the > TC as not-our-role-to-overrule-delegates, and some more days > passed. Do you really think there's a brewing dissent within the > ftp-masters team that has not yet bubbled to become public? My point was: either dissent or agreement, another member should respond to indicate it is a team decision rather than waiting for random number of days in case a decision was challenged (I did not imply there was a dissent). But Joerg already clarified that decisions are coordinated. So the only realistic options are, 1. Just do what they say irrespective of its technical merit or following team standards 2. Get it overruled by a GR which is really unlikely to succeed. So in this specific case, I will add these files to libjs-three. I think ftp masters don't want to distinguish between browser environment and node environment, but just have one package. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837467#22 for a previous instance of this demand. I think arbitrarily reducing the number of binary packages is more important than following JavaScript team policy https://wiki.debian.org/Javascript/Policy which says "should generate a node-foo binary package if the script is usable also for Nodejs". I also propose we abandon the current Javascript team policy because it is not supposed to be followed. Just have one binary package for every source package irrespective of it is useful for node or browser. signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
Pirate Praveen dijo [Thu, Mar 01, 2018 at 03:15:42PM +0530]: > >> 1. If a single ftp master is in disagreement, there should be a team > >> decision (in previous cases of disagreement also, other team members did > >> not get involved). > > > > I'm lost already, sorry. As I understand the case of three.js's recent > > rejection, no other ftp-master said anything and thus there cannot be > > any dissention. > > I think it would be better if that is made explicit else how many days > should someone wait to see no response and assume no dissent? or is to > be always assumed there won't be any dissent? We should not wait for dissent just forever. The issue you mention was rejected by ftp-masters, then brought to the TC, then dismissed by the TC as not-our-role-to-overrule-delegates, and some more days passed. Do you really think there's a brewing dissent within the ftp-masters team that has not yet bubbled to become public? signature.asc Description: PGP signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
Pirate Praveen writes ("Re: [Pkg-javascript-devel]
three.js_80+dfsg2-2_amd64.changes REJECTED"):
> On വ്യാഴം 01 മാർച്ച് 2018 03:48 വൈകു, Joerg Jaspert wrote:
> > I wonder why you think "a single ftpmaster". We are a team. We closely
> > coordinate what we do and how we do it. When one of us rejects, the team
> > rejects - it just happens to be a random one of us doing it. Others do
> > not need to get involved and review everything. Or we wouldn't ever be
> > able to get anything done if each of us always has to weight in on any
> > single issue.
>
> Thanks for the clarification. I was thinking about it more like how the
> courts work in India (possibly in other countries too). When a single
> judge decides on a case, there is always an option to appeal to larger
> bench (more number of judges).
For the avoidance of doubt, I don't have a problem with the specific
decision of ftpmaster here. But I do think that better communication
is essential.
I hope that most REJECTs are accepted by the package's submitters as
being correct, and the problems are fixed. REJECT messages are
necessarily short.
But when a submitter disagrees with a REJECT, and asks for a review,
IMO submitter is entitled to a longer explanation, and there should
explicitly be an opportunity for other ftpmasters to agree or dissent.
I think this could be easily implemented as follows:
When decision of ftpmaster is challenged by the submitter, or
clarification is requested, the original decisionmaker should write a
draft response and circulate it amongst the ftpmaster colleagues.
After a week or two, if no-one on the team has disagreed, that
response should be sent to the submitter.
The ftpmaster team should explicitly state in its public web pages how
long a submitter should have to wait for such an
explanation/confirmation. Also they should explicitly state what the
submitter should do if a response is not received.
Finally, final ftpmaster responses should explicitly state what the
correct escalation path is if the submitter still disagrees.
I don't think any of this would be very onerous for the ftpmaster team
to do. Ultimately in these cases ftpmasters end up having to write
messages like Joerg's. It would be better to have clearer
communication on a technical level, earlier.
If a particular submitter is causing a disproportionate amount of
work, the situation should probably be discussed with the DPL.
Ian.
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On വ്യാഴം 01 മാർച്ച് 2018 03:48 വൈകു, Joerg Jaspert wrote: > On 14963 March 1977, Pirate Praveen wrote: > >> 1. If a single ftp master is in disagreement, there should be a team >> decision (in previous cases of disagreement also, other team members did >> not get involved). > > I wonder why you think "a single ftpmaster". We are a team. We closely > coordinate what we do and how we do it. When one of us rejects, the team > rejects - it just happens to be a random one of us doing it. Others do > not need to get involved and review everything. Or we wouldn't ever be > able to get anything done if each of us always has to weight in on any > single issue. > Thanks for the clarification. I was thinking about it more like how the courts work in India (possibly in other countries too). When a single judge decides on a case, there is always an option to appeal to larger bench (more number of judges). The team as a whole has to weigh in only when the decision of a single team member is challenged and such a review is requested. There are also cases the same criteria was applied differently by two different ftp masters. node-babel-preset-env was rejected for depending on itself, but node-rollup was accepted even though it depended on rollup (a binary package created by node-rollup). I don't think it is healthy to not have an option of reviewing individual members decisions. That leaves me only GR as a possible escalation route. I will think about it. signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On 14963 March 1977, Pirate Praveen wrote: > 1. If a single ftp master is in disagreement, there should be a team > decision (in previous cases of disagreement also, other team members did > not get involved). I wonder why you think "a single ftpmaster". We are a team. We closely coordinate what we do and how we do it. When one of us rejects, the team rejects - it just happens to be a random one of us doing it. Others do not need to get involved and review everything. Or we wouldn't ever be able to get anything done if each of us always has to weight in on any single issue. -- bye, Joerg -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On വ്യാഴം 01 മാർച്ച് 2018 03:24 വൈകു, Chris Lamb wrote: > Apologies, but this reads like another non-sequitur to me. Why would deciding > on a number of days before one can assume _no_ dissent make any difference at > all to the case of three.js given that you are claiming there _is_ dissent? I only said other team members did not respond even when I asked if this is the team decision. I think it would be better if some one respond even if they agree with other team member in case a response from the team is requested. signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
Pirate Praveen wrote: > > I'm lost already, sorry. As I understand the case of three.js's recent > > rejection, no other ftp-master said anything and thus there cannot be > > any dissention. > > I think it would be better if that is made explicit else how many days > should someone wait to see no response and assume no dissent? or is to > be always assumed there won't be any dissent? Apologies, but this reads like another non-sequitur to me. Why would deciding on a number of days before one can assume _no_ dissent make any difference at all to the case of three.js given that you are claiming there _is_ dissent? Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On വ്യാഴം 01 മാർച്ച് 2018 02:28 വൈകു, Chris Lamb wrote: > Pirate, > >> 1. If a single ftp master is in disagreement, there should be a team >> decision (in previous cases of disagreement also, other team members did >> not get involved). > > I'm lost already, sorry. As I understand the case of three.js's recent > rejection, no other ftp-master said anything and thus there cannot be > any dissention. I think it would be better if that is made explicit else how many days should someone wait to see no response and assume no dissent? or is to be always assumed there won't be any dissent? signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
Pirate, > 1. If a single ftp master is in disagreement, there should be a team > decision (in previous cases of disagreement also, other team members did > not get involved). I'm lost already, sorry. As I understand the case of three.js's recent rejection, no other ftp-master said anything and thus there cannot be any dissention. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
[adding -devel] On ഞായര് 25 ഫെബ്രുവരി 2018 03:01 വൈകു, Pirate Praveen wrote: > Does other ftp masters agree with this assessment of considering the > size of the package as the only criteria to accept or reject a package? > I don't agree with forcing other contributors to do extra, non standard, > hacks instead of following the standards were applicable. > > node-three is the standard way for every node tools including webpack to > find this package. Having to replicate this structure for every > depending package is not acceptable. > > I have not objected to every rejection, where it made sense I have > already embedded some modules (is-svg, unique-slug for example, and > switching to a embed first and package on second dependency approach in > general), but I don't agree with this case. It seems ftp masters are literally the masters with only a GR powerful enough to over turn their decisions. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881339#55 I do not think this is really in sync with the rest of debian philosophy. I think the following steps would improve the situation. 1. If a single ftp master is in disagreement, there should be a team decision (in previous cases of disagreement also, other team members did not get involved). 2. CTTE should be able to overrule a delegate when there is a conflict just like conflict between two debian developers. signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On ഞായര് 25 ഫെബ്രുവരി 2018 02:46 വൈകു, Bastian Blank wrote: > Hi > > On Sun, Feb 25, 2018 at 02:00:37PM +0530, Pirate Praveen wrote: >> On ശനി 24 ഫെബ്രുവരി 2018 08:43 വൈകു, Pirate Praveen wrote: >>> On ശനി 24 ഫെബ്രുവരി 2018 04:30 വൈകു, Chris Lamb wrote: Author: Bastian Blank Version: 80+dfsg2-2 Timestamp: 2017-12-15 15:15:24.424738+00:00 REJECT no need to have with one just two symlinks in the node.js path >>> But we need package.json installed in default nodejs path >>> (/usr/lib/nodejs) for node tools like webpack to find these files. It >>> just adds extra custom code to make these files visible to webpack which >>> I'd really like to avoid. Nodejs modules follow a common standard and >>> having to add custom code to other packages is not good in my opinion. >>> I'd like to hear from other javascript team members on this. > If you have one user installing 10MB of code, you maybe waste this 10MB. > If you have 1M users download packages files with this 1k entry, you > waste 1GB every time. > > Bastian > Does other ftp masters agree with this assessment of considering the size of the package as the only criteria to accept or reject a package? I don't agree with forcing other contributors to do extra, non standard, hacks instead of following the standards were applicable. node-three is the standard way for every node tools including webpack to find this package. Having to replicate this structure for every depending package is not acceptable. I have not objected to every rejection, where it made sense I have already embedded some modules (is-svg, unique-slug for example, and switching to a embed first and package on second dependency approach in general), but I don't agree with this case. signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
Hi On Sun, Feb 25, 2018 at 02:00:37PM +0530, Pirate Praveen wrote: > On ശനി 24 ഫെബ്രുവരി 2018 08:43 വൈകു, Pirate Praveen wrote: > > On ശനി 24 ഫെബ്രുവരി 2018 04:30 വൈകു, Chris Lamb wrote: > >> Author: Bastian Blank > >> Version: 80+dfsg2-2 > >> Timestamp: 2017-12-15 15:15:24.424738+00:00 > >> > >> REJECT no need to have with one just two symlinks in the node.js path > >> > > But we need package.json installed in default nodejs path > > (/usr/lib/nodejs) for node tools like webpack to find these files. It > > just adds extra custom code to make these files visible to webpack which > > I'd really like to avoid. Nodejs modules follow a common standard and > > having to add custom code to other packages is not good in my opinion. > > I'd like to hear from other javascript team members on this. If you have one user installing 10MB of code, you maybe waste this 10MB. If you have 1M users download packages files with this 1k entry, you waste 1GB every time. Bastian -- Captain's Log, star date 21:34.5... -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
[Copying Bastian] On ശനി 24 ഫെബ്രുവരി 2018 08:43 വൈകു, Pirate Praveen wrote: > On ശനി 24 ഫെബ്രുവരി 2018 04:30 വൈകു, Chris Lamb wrote: >> Author: Bastian Blank >> Version: 80+dfsg2-2 >> Timestamp: 2017-12-15 15:15:24.424738+00:00 >> >> REJECT no need to have with one just two symlinks in the node.js path >> > But we need package.json installed in default nodejs path > (/usr/lib/nodejs) for node tools like webpack to find these files. It > just adds extra custom code to make these files visible to webpack which > I'd really like to avoid. Nodejs modules follow a common standard and > having to add custom code to other packages is not good in my opinion. > I'd like to hear from other javascript team members on this. >> >> === >> >> Please feel free to respond to this email if you don't understand why >> your files were rejected, or if you upload new files which address our >> concerns. >> > > signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
On ശനി 24 ഫെബ്രുവരി 2018 04:30 വൈകു, Chris Lamb wrote: > Author: Bastian Blank > Version: 80+dfsg2-2 > Timestamp: 2017-12-15 15:15:24.424738+00:00 > > REJECT no need to have with one just two symlinks in the node.js path > But we need package.json installed in default nodejs path (/usr/lib/nodejs) for node tools like webpack to find these files. It just adds extra custom code to make these files visible to webpack which I'd really like to avoid. Nodejs modules follow a common standard and having to add custom code to other packages is not good in my opinion. I'd like to hear from other javascript team members on this. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > signature.asc Description: OpenPGP digital signature -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
