
How not to behave on GitHub issues - wfjeff
https://github.com/mishoo/UglifyJS2/issues/2054
======
_seemethere
I can see where both sides are coming from, but I think if it's as simple as
just uploading a new package with a version bump then the maintainer should
just go ahead and do it.

It's not worth it to interrupt the workflow of everyone else just because you
want to "stand your ground" and not spend 5 minutes re-uploading a package.

~~~
brepl
Not surprised the maintainer gave such short shrift. These commenters should
provide a clear fix or demonstration that re-publishing will fix the problem,
or just use the previous release. There's also nothing stopping them forking
the project and publishing their own 2.8.29-foo as uglify-js-bar and getting
on with their lives. Being rude to open source maintainers is very unlikely to
make them more helpful.

~~~
marczellm
That doesn't help when you have a transitive dependency.

------
BinaryIdiot
Well that was a pretty frustrating read through.

I understand the maintainers don't want to be held to fix other people's
tooling issues but at the same time, when you release something that has
invalid meta data in it, why would you ignore that and kick it further down
the road while leaving the ticket closed even after acknowledging that it's an
issue but low priority?

It certainly doesn't help that both parties are constantly being rude to each
other.

------
hueving
Took an interesting twist at the end and it turned out to be an npm build
tooling problem om windows so republishing it without figuring that out
wouldn't have fixed it.

Perfect demonstration of why you don't want to behave so dramatically like
eric-tucker did. One bit of new information hits that changes the foundation
of your stance and you look like a complete asshole.

~~~
joatmon-snoo
The problem that eric-tucker raised, a very valid one, is that the corruption
of file metadata in the published release posed a serious stability risk for
anyone whose environment depends on uglify-js. At the very least, from the
comments still present (i.e. not deleted) on the issue, it seems absurd to me
that the maintainers closed the issue without either (1) publishing a
workaround or (2) resolving the issue in production. Similarly, though, I find
it reprehensible that it took so long for someone to step forward and help
trace the issue - or even make an offer to do so.

On a broader note: by now, I think it is a true and established fact that
there is no such thing as bug-free software. Bugs exist everywhere, and there
is plenty of code out there to defend against the existence of such bugs. It
is absolutely and undeniably negligent to say that you won't fix a
demonstrable issue in a software release because it triggers known issues in
other software, especially when a non-harmful remedy is at hand.

------
matzipan
This feels like a lot of work being taken for granted. That is why support
services exist. You pay a fee and the developer agrees to fix things for you.
Open-source doesn't have to be for free.

------
evadne
I walked away from reading this thread in GitHub with exactly two points to
make:

1\.
[https://docs.npmjs.com/cli/shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap)
is a good thing. Please consider doing it for all of your projects using NPM.

2\. Consider also putting your node_modules under version control.

~~~
scottmf
Isn't that what yarn.lock and NPM shinkwrap are for? I wouldn't recommend
putting the entire node_modules dir in git...

~~~
jondwillis
Yes, but there are actually some positive and negative side-effects of
checking in dependencies. See “Should I check the Pods directory into source
control?” at [https://guides.cocoapods.org/using/using-
cocoapods.html](https://guides.cocoapods.org/using/using-cocoapods.html) for a
bit of discussion on the concept.

------
matisoffn
Which side is behaving inappropriately? Hard to tell..

~~~
mdlap
Inappropriate: Users being impolite and overly demanding. Inappropriate:
Maintainers (and supporters) insisting that a problem in their publishing
process (whether or not they caused it) isn't their problem because the code
works.

Both sides had legitimate grievances, and both sides did a poor job of trying
to resolve them.

~~~
tinus_hn
You make a stupid mistake and people politely ask you to fix it. If you
dismiss the polite people it's only a matter of time before you run into
someone who is not polite.

It also doesn't help if your attitude is that if you think everyone else is
being an idiot you don't stop and check if maybe the problem is with yourself.

~~~
boyakasha
What stupid mistake? It was an NPM bug.

~~~
divs1210
Yes, but the package on npm is, indeed, corrupt and the latest semantic
version.

Anyone creating a fresh project right now with uglifyjs somewhere down the
build chain will face this issue.

The only way to resolve this is by publishing a fresh, correct version to npm
ragardless of what caused the issue.

The authors have failed to do this till now and the issue remains closed.

------
click170
This whole thing seems to stem from the authors inability to reproduce and
understand the problem.

Has anyone submitted a test case demonstrating the problem? I don't see one
linked in the comments. It may also help to explain how you deploy and why you
do it that way, not everyone does this as their day job so some perspective
can be enlightening.

Closing an issue like this that is ostensibly a problem for a lot of people
and projects isn't good etiquette. At the same time, Foss authors dont owe us
or anyone else anything. The least we can do is help them reproduce the issue
when they have trouble doing it themselves. Seems like failures on both sides
here to me.

Edit: I also don't want to criticize the author for not pushing a patch they
don't understand. I wouldnt merge a patch if I didn't understand the problem
it was solving, but I _would_ ask for details and a test case to understand it
better instead of closing the ticket.

~~~
justinsaccount
What are you talking about? It was explained multiple times that the released
tarball had broken timestamps.

> I also don't want to criticize the author for not pushing a patch they don't
> understand.

This issue had absolutely nothing to do with patches. The maintainer published
a broken tarball. The users were asking the maintainer to re-publish a non-
broken tarball.

~~~
edmccard
>The users were asking the maintainer to re-publish a non-broken tarball.

Yes, with such helpful suggestions as changing to a fresh directory because
the original directory was "corrupt". Except that wouldn't have fixed it; the
problem was eventually discovered to be a bug in npm on Windows[1], so every
single "republished" package would have also been broken.

[1][https://github.com/npm/npm/issues/16734](https://github.com/npm/npm/issues/16734)

~~~
justinsaccount
And the maintainers have not re-published a fixed tarball yet and the issue
remains closed. Even after the underlying issue has been fixed in npm.

I think it's pretty clear which side here is acting inappropriately.

