Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]
Pirate Praveen writes ("Re: Javascript team policy and rejection of node-three
binary package"):
> On ചൊവ്വ 06 മാർച്ച് 2018 07:42 വൈകു, Ian Jackson wrote:
> > This could be solved by dropping the nodejs dependency from all the
> > nodejs module packages and requiring top-level applications to depend
> > on nodejs.
>
> I see two problems with that approach. 1. It makes these modules
> installable but unuseable in architectures where nodejs itself is not
> available.
I don't think 1 is a problem.
But:
> 2. We won't be able to specify a minimum version of nodejs for these
> modules. For example, node-regexpu-core required nodejs >= 6 and
> this prevented its testing migration for a long time because testing
> only had nodejs 4 for a long time.
That is a problem, indeed. Is this common ?
Another possibility, though would be to use Breaks. Eg
Package: node-regexpu-core
Breaks: nodejs (<< 6~)
> I think separate binary should be allowed at least in the second case.
For me it's not a question of it being *allowed*. I appreciate that a
lot of what is going on here must seem to you very much a question of
the Debian establishment wielding power. But I would prefer to think
about what would be best. If it is best to use another package then
it should not just be "allowed", but indeed encouraged, recommended or
mandated.
But I don't think we have quite explored all the issues yet.
> > Does handlebars contain anything that is useful to run directly ?
>
> handlebars is templating system widely used, not only in nodejs. It has
> binding for different languages (like ruby-handlebars-assets) and also a
> command line interface. The command line can be used for compiling
> handlebars templates.
Right, so you said in the other branch of the thread.
Pirate Praveen writes ("Re: [Pkg-javascript-devel] Javascript team policy and
rejection of node-three binary package"):
> On ചൊവ്വ 06 മാർച്ച് 2018 07:57 വൈകു, Ian Jackson wrote:
> > Is this going to be common ? The Javascript ecosystem has large
> > numbers of small packages - but do they mostly contain just JS
> > libraries or do they generally all contain command line utilities
> > too ?
>
> Libraries are majority, but there are many command line utilities too
> (mocha, uglifyjs, handlebars etc).
Right.
> > If only a much smaller number of upstream packages have command line
> > utilities, then we could have the number of JS .deb packages that need
> > to be maintained by putting the node and browser files into the same
> > package.
>
> I think the following change to point 5 of javascript policy [1] has
> consensus now.
Woah, steady on there. You only just posted this proposal. It can't
possibly have consensus yet! Furthermore, I was mostly asking
questions and exploring possibilities.
I appreciate that you are keen to move forward, but to that end I
would encourage you to engage quickly in this discussion, rather than
waiting a while and then providing a bunch of answers combined with
jumping straight to a policy change.
> Change,
>
> 5. should generate a node-foo binary package if the script is usable
> also for Nodejs
>
> to
>
> 5. should provide node-foo and install package.json in
> /usr/lib/nodejs/foo if the script is usable also for Nodejs. If script
> includes a command line tool, it should generate foo (node-foo in case
> of a name conflict) binary package and declare dependency on nodejs. A
> separate binary package should be generated if the script requires a
> newer version of nodejs than available in testing to facilitate proper
> testing migration.
This would seem to suggest *three* packages in some cases ? I'm not
sure I understand the intent.
Also your comments about namespace make me wonder: do many of these
node scripts have poorly chosen command names ? Can I get a list of
them easily somehow ?
I don't think renaming the package only when there is a conflict is a
good rule of thumb. Instead, the package should be renamed when
conflict is likely, even if it hasn't yet occurred. The same goes for
command names.
I think "handlebars" and "uglify" are OK for this, but I don't know
what the whole ecosystem is like. The controversy about the name
"node" itself, and upstream's handling of that, don't give me
confidence that the node.js upstream community have fully realised
that the command namespace is a global resource, which they should be
using with respect for others.
In practice, as an easier guideline, maybe it would be better to say
that the command and package should *usually* be renamed, unless the
script is high propfile and has a good name which is unlikely to
conflict.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are m
Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package
Pirate Praveen writes ("Re: [Pkg-javascript-devel] Javascript team policy and
rejection of node-three binary package"):
> On March 4, 2018 3:15:24 AM GMT+05:30, Simon McVittie <s...@debian.org> wrote:
> >For instance, src:tap.py builds python3-tap (the Python 3 library for
> >"import tap"), python-tap (the Python 2 library for "import tap") and
> >tappy (the tappy(1) command). If you did similar things for JavaScript,
> >you could have a handlebars package that depends on libjs-handlebars
> >and nodejs?
>
> Yes, that is what I did.
Simon is asking the same questions as I was earlier. Sorry for
posting before reading the whole thread.
Is this going to be common ? The Javascript ecosystem has large
numbers of small packages - but do they mostly contain just JS
libraries or do they generally all contain command line utilities
too ?
If only a much smaller number of upstream packages have command line
utilities, then we could have the number of JS .deb packages that need
to be maintained by putting the node and browser files into the same
package.
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] Javascript team policy and rejection of node-three binary package
Pirate Praveen writes ("Javascript team policy and rejection of node-three
binary package"):
> 1. Node.js has standard locations for discovering installed packages
> which is different from browser targeted javascript libraries.
>
> Node.js expects pure js modules to be installed at /usr/lib/nodejs but
> javascript libraries are installed at /usr/share/javascript
This is not an argument in favour of separate packages AFAICT ?
> 2. Dependency on nodejs is required only during build or when other
> Node.js modules depend on it. a browser targeted library does not need
> to depend on nodejs package.
This could be solved by dropping the nodejs dependency from all the
nodejs module packages and requiring top-level applications to depend
on nodejs.
> If you take example of node-handlebars source package, libjs-handlebars
> is targeted at browsers and does not need to declare a dependency on
> nodejs. But handlebars package need nodejs to run. If there is only a
> single binary package, nodejs will get installed unnecessarily.
Does handlebars contain anything that is useful to run directly ?
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] Javascript team policy and rejection of node-three binary package
Sean Whitton writes ("Re: Javascript team policy and rejection of node-three
binary package"):
> On Fri, Mar 02 2018, Pirate Praveen wrote:
> > I think the policy is good and request debian policy team to endorse
> > it.
Thanks for bringing this up, here. FAOD, my primary intent in
suggesting you do so was to get technicaly input from the denizens of
d-policy, who have a lot of useful expertise.
> The way forward is to add the JavaScript policy to the debian-policy
> package. It would not be wise to add a single requirement to our
> document, with the rest of the JavaScript policy maintained elsewhere.
I agree that importing a single rule from the Javascript policy into
the debian-policy package is not sensible. But there are is a lot of
precedent for policy documents being maintained outside debian-policy.
For example, the DEP-8 spec for debian/tests/control is in the
autopkgtest package.
Many language-specific packaging teams have language-specific
policies. These are usually shipped in some core dev support package
for the policy in question. So far it has not been necessary to
formally reference the Perl policy (say) from the debian-policy
package. But I don't see any reason why debian-policy could not
formally refer to the Javascript policy.
I do think that the Javascript policy has to be not in a wiki page.
We can't have normative references from debian-policy to wiki pages.
Pirate, is there some Debian-specific Javascript dev infrastructure
package that could host this document ?
> If you want to go ahead and do this, please file a bug against
> debian-policy, with a patch that adds the JavaScript policy to our repo.
> (There wouldn't be much point in filing such a bug without a patch.)
Moving the Javascript policy to the debian-policy package might be
nice, but I don't think it needs to be on the critical path for
finalising and formally blessing the policy.
There are also reasons why it might not be a good idea. Other
programming languages find it easier to maintain their
language-specific policies outside both the debian-policy package and
the policy mailing list.
On the third had, Javascript seems to face unusual challenges and may
need more support and intervention from our core policy team.
Thanks,
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
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
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
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
[Pkg-javascript-devel] Bug#877212: Bug#877212: node-d3-color: B-D npm not available in testing
Pirate Praveen writes ("Re: [Pkg-javascript-devel] Bug#877212: node-d3-color:
B-D npm not available in testing"):
> Lets take the two issues separately.
>
> 1. Whether they are suitable for contrib
I don't think that this is what contrib is for. Contrib exists as
part of our commitment (documented in the Social Contract) to help
users who for one reason or another end up using non-free software or
documentation.
So contrib is for things where there are licensing reasons, why not
all of the dependencies (whether declared formally in the packaging or
not) can be built from source in main.
The most usual cases are (i) something involved has a
noncommercial-use-only licence, or (ii) the thing is a
nonredistributable and what is provided is a package for downloading
it at install-time.
It is true that there are a few other cases which don't fit into the
DFSG category, but they are truly exceptional:
For example, I'm sure we have some packages there containing firmware
whose source code is available, and where in principle Free Software
compilers are available, but where the firmware's cpu architecture is
not a Debian release architecture and not supported even as a build
option by the compilers we are shipping (or perhaps the versions we
are shipping would not work because they are far too new).
That seems superficially similar, but there are some important
differences.
It is one thing to have a few firmware binaries in contrib, when
fixing each individual firmware binary would involve packaging a whole
crossbuilding toolchain. It is very questionable whether it would be
a desirable tradeoff for Debian to maintain, as first-class packages,
a cross toolchain whose only real function is to build some obscure
firmware (and which is hard to use for other purposes).
But in the case of the Javascript ecosystem, it is clearly desirable
that the popular toolchains from the Javascript world should be
available in Debian. Each such Javascript tool enables many dependent
packages, and they also have uses by thdmselves.
And there is a big difference in scale. In the case of the Javascript
tools we are not talking about a handful of obscure exceptions.
And of course the exceptional firmware files I am talking about do
not run on the user's main cpu (by definition). They run in separate
hardware devices, usually with a much stronger security boundary
between them and the user's primary environment.
Often these firmwares are even provided simply as a convenience and
are not even always necessary for the program's operation.
Finally, the firmware files I am talking about are rarely modified
and rebuilt by anyone. Mostly they are handed down as heirlooms.
That's quite unlike the situation with these Javascript packages
and their compilers/transpilers/whatever.
Overall, it seems to me that you are using contrib as a way to get
around what is ultimately simply an engineering or quality problem.
The problem with these packages is not that they have licensing
problems; nor is it that there are other serious fundamental reasons
why distributing their source code, and rebuilding them, is hard.
It's just that the packaging is a lot of work. But skipping on
packaging the build dependencies properly produces packages which
don't meet Debian's minimum quality standards.
So at the very least, I think these problems are RC bugs.
One approach would be to have uploaded the packages to experimental
instead of unstable. I think it's OK to have junk of all sorts of
kinds in experimental.
That does assume, of course, that your plan is for this to be a
temporary situation, and you just want to have somewhere to
share your work while you collaborate in improving this whole area.
If you intend for this situation to persist in the medium term - for
example, if you wanted it to be released alongside buster - then of
course that wouldn't work. But for the reasons I have explained I
don't think that's acceptable.
I'm sorry to be so negative. I appreciate that dealing with all of
this stuff is very hard work and I applaud your determination. But in
this case the resistance you are encountering is justified.
Regards,
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
[Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
Jérémy Lal writes ("Re: Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1)
experimental; urgency=medium"):
> So, a short NEWS entry explaining /usr/bin/node is now available by default,
> and that /usr/bin/nodejs will stay available indefinitely ?
> Or even nothing and just a changelog entry ?
I would go for the latter, personally.
My philosophy is that a NEWS entry is something you use when people
have to change something. The best packages do not need NEWS entries
because they simply keep working. Starting to provide /usr/bin/node
and keeping /usr/bin/nodejs means that no-one has to change anything,
which is perfect - and therefore we don't need to bother users.
It's true that NEWS might be used when a new opportunity arises that
means many users might want to change something, even though they
don't have to. I would reserve that for situations where the user's
existing setup is (likely to be) hazardous or seriously suboptimal,
especially in a non-obvious way.
Existing scripts that use /usr/bin/nodejs are not as portable to other
OSes as they could be, but of course the script's author will probably
be aware of that already. It doesn't seem to me to be the kind of
opportunity for remedying a significant defect that would warrant a
NEWS entry.
However:
One thing you I would consider is that it would be nice if scripts in
Debian packages were made more portable to other distros. So Debian
packages should gradually change to use /usr/bin/node. I am very
conservative about these things because I like to keep backporting
(within Debian) as easy as possible. So if I were the maintainer of a
node.js package which had scripts mentioning /usr/bin/nodejs, I would
probably make that change in buster+1 rather than in buster.
In buster+1 you should probably consider asking for a lintian warning
about references to /usr/bin/nodejs. Not because you intend to drop
/usr/bin/nodejs ever (why do that - see previous emails) but because
it would be better, as I've just discussed, for Debian packages to
contain fewer hurdles to adoption elsewhere.
Regards,
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
[Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
Philip Hands writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental;
urgency=medium"):
> I guess that one could do something like moving the symlink into another
> -legasy style package, and recomend that from the main package for one
> release to keep upgrades happy. Then drop the recomendation, and wait
> for popcon to show that people are not installing the package any more.
> Then remove the package in testing early in a cycle and see if anyone
> reports bugs about it.
Even that would be quite unfriendly, because third party scripts might
easily be deployed onto new Debian installs as well as existing ones.
Also, it is imposing an administrative burden on all Debian users (the
metadata for the -legacy package, spurious search hits, etc.). That
burden might be small but would be completely unjustified.
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
[Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium
Jérémy Lal writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental;
urgency=medium"):
> Maybe i didn't express myself properly: the idea is to keep /usr/bin/nodejs
> until it's no longer needed - be it other debian packages or other user
> scripts.
Earlier you said only "other Debian packages":
My plan was to simply keep /usr/bin/nodejs around for some time
until no debian package rely on it.
Now you say "other user scripts". I don't know how you would ever
tell whether "other user scripts" were relying on it. There is no way
to for us to tell what people are doing on their computers (and nor
should there be).
> If it was to be really removed, it shouldn't be done without some
> deprecation warning and time for users to notice and change their
> code.
Why would you bother with a deprecation warning, and forcing a lot of
users to change their code ? Why not just leave the symlink
permanently ?
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] tech-ctte: please help maintainers of packages with a node command to have a reasonable conversation
Jonathan Nieder writes (tech-ctte: please help maintainers of packages with a node command to have a reasonable conversation): The node and nodejs packages both provide a command named node. I'm disappointed to see this is still rumbling on. There is only one correct solution, and it is this: In the long term, I would be happiest if both were renamed. I think the TC should rule along the following lines: 1. We agree with the Policy requirements in this area. 2. In this case, neither package is entitled to this name. 3. All relevant packages must be changed (in unstable, experimental and testing) not to provide a command node. This means that no package may: - install a file node in any of the common PATH directories; - install a manpage for a command node; - attempt by any other means to provide a command node; or - declare conflicts against nodejs or node; except as approved by the TC, or as explicitly agreed by the maintainers of both the node and nodejs packages, such agreement to be notified to the TC. 4. If any package in unstable or experimental violates the rules above later than 28 days from now, this is cause for an NMU, and in that case we specifically encourage the maintainer of the competing package to make such an NMU. Each maintainer is entitled to do this even if they have not yet fixed their own package. 5. If such an NMU is needed the person doing it is entitled to simply rename offending files in the package without considering compatibility or transitional arrangements. 7. Bugs arising in Debian due to the renaming of either version of node are bugs in the depending packages, not in any package which no longer provides node. Specifically, compatibility issues due to the renaming should not block testing propagation of the renamed packages. 8. If a fix is needed in testing and cannot be made expeditiously via unstable, the potential NMUer should consult the release team to ask how to proceed (perhaps an update via testing-proposed-updates will help). 9. No package may in the future provide a command node without permission from the TC. This gives each maintainer 4 further weeks to construct and implement a transition plan for their package. Such a transition plan is of course something each maintainer should already have ready, since the policy requirement is very clear. There is no further excuse for any delay. 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] Bug#614907: tech-ctte: please help maintainers of packages with a node command to have a reasonable conversation
Russ Allbery writes (Bug#614907: tech-ctte: please help maintainers of packages with a node command to have a reasonable conversation): I also think the current Policy suggestion to rename both programs in the event of an unreconciled naming conflict is not a very good idea, and think it should change to instead list the Technical Committee as the decision-maker of last resort. Renaming both programs is likely to be the right move only in cases where both programs are pretty obscure and fairly new. I really feel it's unfair to allow johnny-come-lately's who couldn't be bothered to choose a reasonable name for their program, and who couldn't be bothered even to look up whether the name was already taken, to just blunder their way into stealing names like this. We should be pushing this pain back onto their users, if anyone. Remember that it is only them who can change their name upstream, and this is definitely something they can do. They could support it as an alternative. AX.25 have two much better excuses: they're from an age when this kind of thing was less important and also less recognised as being important. And they came first. Or to put it more succinctly, I think justice is more important than expedience. 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
