Hacker News new | past | comments | ask | show | jobs | submit login

People legitimately object to accepting a patch that fixes one issue but can lead to other problems down the line. IMHO, even not accepting the patch, but with suggestions for additional improvements would have been better behaviour.

As it stands, the communication was:

1. There's a problem, here's a patch.

2. NAK, because (valid reasons).

3. Radio silence.

Perhaps better behaviour would have been:

2. NAK, because (valid reasons). However, I acknowledge the problem; perhaps you can fix it (some other way).

This way, the discussion is more likely to keep going and end up with a proper fix to the issue.

The communication to me looked more like:

1. There's a problem, here's a patch.

2. We won't apply it because it doesn't fix it perfectly. Sure it's better than what we did, and you offered the patch for free out of the kindness of your heart, but we aren't going to apply it until you work on it some more.

3. But... it's better in every way!

If you write a patch for a project that is an improvement in every way, but not yet perfect and they don't apply it... Well you're probably not going to spend much more time helping that project are you?

>> But... it's better in every way!

And this is where we disagree. I believe it's worse. The original crashes the system, which is really bad. The cases where this happens are few, and people are going to be aware of what they did to cause it (unzipping a bunch of files in there was suggested as a trigger). With the proposed patch, nothing will happen. The user will not be aware of the issue and the system will not update with the changes. The user may not even notice their action had no effect and if they do, it'll be a harder mystery than the crash to figure out.

Some prefer the system to crash than silently ignore input. Error codes and messages are better than either of those.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact