3 ms·

The other day I opened an issue on a project to mention that the project is not respecting some powerful convention (by dumping stuff when the user's configurat

The other day I opened an issue on a project to mention that the project is not respecting some powerful convention (by dumping stuff when the user's configuration is to not dump stuff), and the project maintainer replied by saying that he doesn't care... that he thinks his choice is better. I'm quite angry because I spent time investigating this problem and now it won't be fixed and it is not logical and I've lost my time.

jerf 6y ago
Don't underestimate that "fork" button. If the software otherwise does what you want, but you need some particular change, fork away. Obviously one needs to be judicious with this, but I've scored some big wins from this. In addition to bypassing projects who don't want to accept the (IMHO) perfectly reasonable contributions, I've also some cases where the upstream project shouldn't accept my changes and I shouldn't submit them. I've got one case where I forked a package and essentially twisted it so hard that it destroys it for its original purpose, even though it now does exactly what I need. A couple of others where the upstream is obviously dead. Another case I can think of where in principle the upstream could accept it, but it adds a subtle and easy-to-misuse feature to the package that I understand fairly well having written it, but would really encourage users to mess themselves up and is hard to document properly, so I probably won't ever submit it. It's not something I do all the time by any means... the above paragraph describes nearly all the cases where I've done it. It's 3 or 4 in as many years. But each of them was a fairly large win.
- MaxBarraclough 6y ago
  > If the software otherwise does what you want, but you need some particular change, fork away. You'll then have to maintain the fork, re-applying your changes whenever the upstream repo is updated
  - dialamac 6y ago
    Microsoft or Oracle will be glad to sell you something then. Geeze the babies around here.. not every project maintainer is going to agree with you as was apparently the crux of the original complaint. You don’t always get your way. And Apparently just having the ability to fork the source and do whatever the fuck you want is not enough for these pratts.
  - jerf 6y ago
    Obviously, one needs to be judicious with this.
  - type0 6y ago
    It might not work with big projects but libraries and other smaller software is perfectly fine.
shock 6y ago
Presumably the project you mention is open source, so you've not lost your time – the time spent investigating the issue puts you in a better position to fork the project an implement the change to your specifications without involving the maintainer. I don't understand the anger, are you angry because he doesn't have the same opinion as you and doesn't want to make the implementation behave according to your opinion?
mitjak 6y ago
it's.. not your project. if you disagree, fork away. your anger is on you.
whimsicalism 6y ago
> I'm quite angry because I spent time investigating this problem and now it won't be fixed and it is not logical and I've lost my time. I guess the lesson is that there is always someone angry over something unreasonable.

jerf 6y ago

Don't underestimate that "fork" button. If the software otherwise does what you want, but you need some particular change, fork away. Obviously one needs to be judicious with this, but I've scored some big wins from this. In addition to bypassing projects who don't want to accept the (IMHO) perfectly reasonable contributions, I've also some cases where the upstream project shouldn't accept my changes and I shouldn't submit them. I've got one case where I forked a package and essentially twisted it so hard that it destroys it for its original purpose, even though it now does exactly what I need. A couple of others where the upstream is obviously dead. Another case I can think of where in principle the upstream could accept it, but it adds a subtle and easy-to-misuse feature to the package that I understand fairly well having written it, but would really encourage users to mess themselves up and is hard to document properly, so I probably won't ever submit it. It's not something I do all the time by any means... the above paragraph describes nearly all the cases where I've done it. It's 3 or 4 in as many years. But each of them was a fairly large win.

MaxBarraclough 6y ago
> If the software otherwise does what you want, but you need some particular change, fork away. You'll then have to maintain the fork, re-applying your changes whenever the upstream repo is updated
- dialamac 6y ago
  Microsoft or Oracle will be glad to sell you something then. Geeze the babies around here.. not every project maintainer is going to agree with you as was apparently the crux of the original complaint. You don’t always get your way. And Apparently just having the ability to fork the source and do whatever the fuck you want is not enough for these pratts.
- jerf 6y ago
  Obviously, one needs to be judicious with this.
- type0 6y ago
  It might not work with big projects but libraries and other smaller software is perfectly fine.

shock 6y ago

Presumably the project you mention is open source, so you've not lost your time – the time spent investigating the issue puts you in a better position to fork the project an implement the change to your specifications without involving the maintainer. I don't understand the anger, are you angry because he doesn't have the same opinion as you and doesn't want to make the implementation behave according to your opinion?

mitjak 6y ago

it's.. not your project. if you disagree, fork away. your anger is on you.

whimsicalism 6y ago

> I'm quite angry because I spent time investigating this problem and now it won't be fixed and it is not logical and I've lost my time. I guess the lesson is that there is always someone angry over something unreasonable.