5 ms·
Why not work on it and release in smaller batches though?
by dv_dt 5y ago
Why not work on it and release in smaller batches though?
- Bayart 5y agoHe says himself he didn't see major improvements before 1500 commits.
- detaro 5y agoAs the RFC email clearly explains, they were experimenting, restarted multiple times and to go quite deep into it until they got to a point where this was worth announcing as something that might be worthwhile to merge.
- vlovich123 5y agoYeah. I’ve done this in the past. The first few attempts are about learning where the pain points are and to get ideas about what a good way to structure the patch set might look like. Edit: obviously not at this scale. 2300 patches at once in a fork is a lot.
- dv_dt 5y agoWell at this point i think it’s good work but now that the change is identified as good and fairly concrete - it’s still likely a benefit to break it up into smaller more reviewable chunks to take in over time. Maybe by major subsystem so their expert maintainers can take closer looks at it.
- detaro 5y agoSure, hence the email here about "here's all I have, lets discuss if and how to best merge this"?
- xenadu02 5y agoSometimes it is only in the last 10-30% of the changes that any significant benefit is realized, yet the preceding work is a necessary foundation. That makes it a very difficult sell to the rest of the organization (whether OSS contributors or a corporation). Until the last bit it looks like you're making a neverending stream of pointless changes. Large-scale changes also suffer from "too many cooks in the kitchen" and bikeshedding that can make getting the changes accepted a real slog. It is difficult to get people to buy into your vision purely with words, either because they don't see the value in it or they reflexively disagree that the benefits are achievable (sometimes motivated by their own burnout or cynical attitude). The solution is to work on it in semi-secret until you can get things to a point where the value is demonstrated. That bypasses endless bikeshedding and pointless feedback rounds because everyone can see the value of the end state (if you've chosen something worthwhile to work on).
- ncann 5y agoIt's also a common pattern with code review: make a 100 lines change and you'll get at least 10 comments with endless bikeshedding, make a 100k lines change and people will say LGTM in no time.
- metabagel 5y agoLGTM = “Let’s Go To the Moon”?
- bee_rider 5y agoA 100k LGTM is the bad outcome for something important like the Linux Kernel, though, right?
- ncann 5y agoYes, but at the same time, I'm not sure how many people can thoroughly go through 2k commits and 100k diff for a single pull request. Most people, I assume, in that situation will just try to understand the main ideas behind the changes, scan through the areas that they're somewhat familiar with to see if there's any glaring issue, and trust that the highly-reputed maintainer who submitted the PR knew what he was doing.
- db48x 5y agoHow else would you divide the work up? We all need to go look at the commits on this branch that touch our favorite driver and make sure that they don’t break anything.