3 ms·
I invariably end up reading the library/framework/whatever sources as well, if only to clarify a particular point of documentation or something. But, when bugh
by shabble 14y ago
I invariably end up reading the library/framework/whatever sources as well, if only to clarify a particular point of documentation or something.
But, when bughunting, there's often the dilemma of whether to fix the bug at the source (and hopefully, submit a patch to upstream), or to work around it (which can lead to horrific hacks) in your app code.
With the former, you're stuck having to deploy custom packages with your fix in until/if it gets accepted into upstream and a new release is rolled, so all too often I've found myself doing both. I don't know what the solution is; even a perfect patch to a superhumanly responsive maintainer is going to take some time to merge and deploy.
On an entirely unrelated note, a superb way to drive yourself insane is to edit the currently installed system version of the package in question, and then forget that you did some time later.
- eric-hu 14y agoI'm only about 1-2 years into web dev and OSS, and a couple of months into feeling like I can contribute meaningfully to a gem. With that said, this is my current ideal Github workflow: - fork the gem to make changes/fixes - complete fix and point my app dependency to my branch - add testing and docs around my fix - submit pull request to project owner - point my app dependency back to original gem when merged That all said, I consider the activity of a gem before I even bother submitting a pull request. If it hasn't been touched in a month, or if there are open pull requests from 1 month or older, I weigh heavily just writing a 'my team only' solution. This is admittedly selfish, but I'm hedging my time and emotional energy. I don't want to put care into crafting something that I believe to be useful only to watch it sit around unused because someone else doesn't want to review my work.