On Wed, Apr 25, 2018 at 01:57:01PM -0600, Warner Losh wrote: > Every Open Source project has its own quirks. Nobody wants the 520 commits > on the branch that I started with (too many merged rather than rebases in > the last 5 years). The 320 real commits are a mess. I’ve been preening them > to get rid of the silly stuff like (back this out, put it back, all the > ‘spelling/typo/white space’ fixes). At the end of the rebase, I still > wasn’t to ‘the same’ so I had a bunch of ‘true up’ commits to make it the > same...
> My first question seems almost rhetorical: that’s not an acceptable state > of affairs, and curation is needed to upstream. Right? Yeah, no one is going to want to review 300 patches ! > (4) Deal with the cases where multiple people have worked on a patch by > putting SoBs for all of them (or reworking them if I can’t get a hold > of the original authors) on the commits that are merged. I didn’t see > a specific policy for this, but this seems sane. The alternative seems > worse (having elements that don’t compile) The signed off by line is attesting that you agree to this: http://developercertificate.org/ IIUC nothing there requires you to add a SoB line for each author, but you have to be confident that you can agree to terms a) & b), given the the work you are building on top of. > (5) Send them in small batches. I’d go insane trying to manage > 200 concurrent code reviews, and I can’t image that I’m unique > in this. I also image that fixes in the early part of the series > may have ripples to the later parts if my past experience with > these things has any relevance. Can't disagree with that ! > Thanks for any help you can give me. IIUC, the current bsd-user code in GIT is completely broken & unusable. After all 500 patches have been applied, I'm wondering how much of the original code is actually left ? If it is a very small percentage, an alternative strategy might be to send a patch deleting everything in tree, and then treat your code as if you were adding bsd-user as a brand new feature. This could potentially let you merge & restructure the patches into a smaller more easily reviewable set of work. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|