Message ID | 20191125165702.1013-1-r.bolshakov@yadro.com (mailing list archive) |
---|---|
Headers | show |
Series | scsi: qla2xxx: Bug fixes | expand |
On 11/25/19 8:56 AM, Roman Bolshakov wrote: > The patch series contains fixes for qla2xxx and solves two visible > issues: [ ... ] As explained in Documentation/process/2.Process.rst, please post patches outside the merge window. Thanks, Bart.
On Tue, Nov 26, 2019 at 12:56:51PM -0800, Bart Van Assche wrote: > On 11/25/19 8:56 AM, Roman Bolshakov wrote: > > The patch series contains fixes for qla2xxx and solves two visible > > issues: [ ... ] > > As explained in Documentation/process/2.Process.rst, please post patches > outside the merge window. > > Thanks, > > Bart. Hi Bart, Thank you for the reference. Could you please assess if my understanding of the document is correct: The fixes might go into 5.5-rc2 after the release of rc1 which closes the merge window. No patches except critical for -rc1 should be posted when the merge window is opened. Best regards, Roman
On 11/27/19 9:24 AM, Roman Bolshakov wrote: > On Tue, Nov 26, 2019 at 12:56:51PM -0800, Bart Van Assche wrote: >> On 11/25/19 8:56 AM, Roman Bolshakov wrote: >>> The patch series contains fixes for qla2xxx and solves two visible >>> issues: [ ... ] >> >> As explained in Documentation/process/2.Process.rst, please post patches >> outside the merge window. > > Thank you for the reference. Could you please assess if my understanding > of the document is correct: > The fixes might go into 5.5-rc2 after the release of rc1 which > closes the merge window. > > No patches except critical for -rc1 should be posted when the > merge window is opened. Hi Roman, During the merge window many maintainers and core contributors are busy with identifying and addressing regressions introduced during the merge window. I think that is why the merge window is not the best time to post patches and why that text was added to the kernel documentation. What happens with patches posted during the merge window depends on the maintainer (Martin Petersen). Sometimes patches posted during the merge window are ignored. Sometimes such patches are queued after the merge window has closed. Sometimes contributors are asked after the merge window has closed to rebase their patch series, to retest it and to repost it. The latter makes sense because the changes accepted during the merge window (e.g. core kernel API changes) may require matching changes in a patch series. You may want to ask Martin directly which approach he prefers after the merge window has closed. Bart.
Bart, > What happens with patches posted during the merge window depends on > the maintainer (Martin Petersen). Sometimes patches posted during the > merge window are ignored. Sometimes such patches are queued after the > merge window has closed. Sometimes contributors are asked after the > merge window has closed to rebase their patch series, to retest it and > to repost it. Bug fixes are OK at any time, as far as I'm concerned. Although this series is a bit big to deal with given that we're now in the merge window. As a rule of thumb, I won't look closely at anything resembling new feature series until -rc1 is out.
Roman, > The patch series contains fixes for qla2xxx and solves two visible > issues: > - Target port in N2N topology doesn't perform login if it has higher > WWPN than initiator > - ABORT TASK TMF leads to crash if it's received shortly after ACL of > an initiator is deleted and there's active I/O from the initiator I was concerned about the churn in this series but the actual code changes are mostly simple and to the point. Applied to 5.5/scsi-fixes with a couple of checkpatch tweaks. Thanks!