On 2020-09-02 20:25, Martin K. Petersen wrote: > I have had a few pokes about why patches are slow to show up in > 5.10/scsi-queue. The reason is that there have been an awful lot of > rebases and fixups in the last couple of releases. When I have to go > back and fix things that breaks the commit hash previously sent in the > thank you notes from b4. Which again breaks the lore archive mail thread > links to the git commits, etc. > > As a result I am experimenting with having a staging branch that is > separate from and slightly ahead of scsi-queue. I merge patches and let > them soak in there for a few days to let zeroday and the various code > analyzers do their thing. And once I am reasonably comfortable that I > don't have to go back and fix anything, I'll shuffle the commits over to > 5.10/scsi-queue. > > This also means that there is now a delay between me merging something > and the thank you notes being sent out. I was contemplating hacking b4 > so I could send notes for both staging and queue but it would generate a > lot of potentially duplicate email. > > Another option is that I send a personal note to the submitter once > stuff is staged. And then the public b4 thank you notes once the commits > end up in scsi-queue proper. I'm open to suggestions. > > Patchwork should still accurately reflect the status of posted > patches. Plus my for-next branch shows what is currently staged, of > course. How about one branch per driver and doing an octopus merge before sending a pull request to Linus? Would that be sufficient to prevent that commit hashes break when dropping one patch series? Please note that I'm not sure that this is the best approach. Thanks, Bart.
