SCSI staging branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
Martin K. Petersen	Oracle Linux Engineering



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux