51–60 of 71 posts
On the other hand, I've actually taken projects with unmerged pull requests, and pulled them into my own repo to use the new functionality/bug fixes. So they aren't necessarily just sitting there uselessly.
The first thing you should always do is create a ticket. There you can discuss if its worth spending time on a patch and what the best implementation could be. Pull requests that come up out of nowhere usually end up in the end of maintainers' queue. Or you can continue calling people who maintain free and open source projects in their spare time douchebags and neckbeards.
Or you can be like OpenLayers and just ignore a ticket with almost a dozen comments and two working patches and a pull request! Sometimes people just don't want your code.
The first thing you should always do is create a ticket. There you can discuss if its worth spending time on a patch and what the best implementation could be. Pull requests that come up out of nowhere usually end up in the end of maintainers' queue. Or you can continue calling people who maintain free and open source projects in their spare time douchebags and neckbeards.
Call me old fashioned, but I still like ticket + attached patches way more than anything else. Recently, I stumbled upon a Google Code project with several defect issues. One guy commented on each of the issue with a link to his github fork which he has applied the fixes. I clicked the link, and found that the fork has been deleted. What a waste.
You don't have to look very far to find douchebag programmers, but I've always had friendly encounters on GitHub.
I'm with you. I added parallel test execution to PHPUnit, which its maintainers have been promising since 2005. When I started writing it, they found me and encouraged me along. So I spent two weeks on it at 16 hours a day. When I was done, they invented reasons not to merge. When I was done fixing the reasons they had invented, they said they didn't want to merge it because they were going to write it themselves.
He describes a social problem which is very dependent on the actual maintainers, but blames it on the mechanism. Yeah, some projects have prickly/uncooperative maintainers... so what? That's true regardless of the collaboration mechanism used, and there's no obvious reason why pull requests make this problem worse than other mechanisms. Indeed, I would guess that pull requests make things better than many other metho…
I'm with you. I added parallel test execution to PHPUnit, which its maintainers have been promising since 2005. When I started writing it, they found me and encouraged me along. So I spent two weeks on it at 16 hours a day. When I was done, they invented reasons not to merge. When I was done fixing the reasons they had invented, they said they didn't want to merge it because they were going to write it themselves.
Do you still have a fork? I'd love some parallel test execution.
Earlier quoted context omitted.
That's not always the case, and sometimes if you don't know the language very well - in my case, Ruby - then certain patterns aren't available to you and it looks hokey without you realizing it.
Completely forgivable. This pull request[0], on the other hand, is probably more along the lines of what mirsadm was thinking of. [0]: https://github.com/Aaronius/Stupid-Table-Plugin/commit/fbf3d...
Earlier quoted context omitted.
Completely forgivable. This pull request[0], on the other hand, is probably more along the lines of what mirsadm was thinking of. [0]: https://github.com/Aaronius/Stupid-Table-Plugin/commit/fbf3d...
https://github.com/Aaronius/Stupid-Table-Plugin/commit/fbf3d... people.