6 Matching Annotations
- Jan 2023
-
-
This will no longer be necessary if this MR is merged #101
-
-
github.com github.com
-
If this MR had been merged it would have saved us a lot of time and trouble.
-
- Dec 2020
-
www.npmjs.com www.npmjs.com
-
No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.
This could be both good and bad.
potential downside: If people only fix things locally, then they may be less inclined/likely to actually/also submit a merge request, and therefore it may be less likely that this actually (ever) gets fixed upstream. Which is kind of ironic, considering the stated goal "No more waiting around for pull requests to be merged and published." But if this obviates the need to create a pull request (does it), then this could backfire / work against that goal.
Requiring someone to fork a repo and push up a fix commit -- although a little extra work compared to just fixing locally -- is actually a good thing overall, for the community/ecosystem.
Ah, good, I see they touched on some of these points in the sections:
- Benefits of patching over forking
- When to fork instead
-
-
github.com github.com
-
Can this be merged please, this fixes a problem I have
-
- Oct 2020
-
-
But maybe this PR should still be merged until he finds time for that?
Tags
- open-source software: progress seems slow
- waiting for maintainers to review / merge pull request / give feedback
- not a blocker (issue dependency)
- pull request stalled
- big change/rewrite vs. continuous improvements / smaller refactorings
- don't let big plans/goals get in the way of integrating/releasing smaller changes/improvements
- iterative process
Annotators
URL
-
- Aug 2020
-
github.com github.com
-
The collection of changes to fix the issues we want to address would be probably of the same size, but it would make easier to review and merge if we could break this PR in many steps. I find it really hard to believe we need to change 170 lines in a single commit to be able to fix this issue. We probably could break the first commit in many commits, test the class better and that would give more confidence over what is being changed. Right now I see a huge diff, with a few assertions changes and no real reason why all those lines had to change.
-