3 ms·
It sounds like within a year or so the underlying system was refactored enough that the patch couldn't be landed as-is, which makes sense. It's big enough that
by kevingadd 5y ago
It sounds like within a year or so the underlying system was refactored enough that the patch couldn't be landed as-is, which makes sense. It's big enough that I can also imagine it being hard to get a review if only 1-2 people know the system well enough and don't find the time to review it... still quite unfortunate.
I run into this sort of situation with OSS a lot lately, for one PR I spent probably at least a dozen days total of my time just rebasing it over and over because a project with hundreds of contributors lands lots of commits every day.
- throwaway984393 5y agoI don't know your PR, but the way this is helped in corporate-land is with very small PRs and feature flags. Some maintainers are a lot more of a pain in the ass than others, though.
- yjftsjthsd-h 5y agoThis is great when it works, but I'm personally not convinced that it works for every change. Some things are genuinely just big changes, and doing them piecemeal is (IMO) actually impractical. Granted, this is more likely to be true with refactoring then features or bugfixes. All of which is not to say that it's not a preferred style when it does work. And as a policy choice it is perfectly reasonable to simply decree that the codebase will never be refactored at that scale.
- LadyCailin 5y agoAnother alternative is to have code freezes, though that comes with its own sets of cons. But you just need them to be long enough to do the last rebase and merge, so in theory can be relatively short.