Re: target-pending/for-next patches
On Wed, 2017-11-08 at 01:37 -0800, Nicholas A. Bellinger wrote: > On Sun, 2017-11-05 at 08:05 -0800, James Bottomley wrote: > > > > On Sat, 2017-11-04 at 18:14 -0700, Nicholas A. Bellinger wrote: > > > > > > Hi all, > > > > > > Just a friendly email after catching up on patches this week, the > > > majority of those outstanding on the list have been merged into > > > target-pending/for-next. Please see below. > > > > > > For those who submitted patches, please have a look and let me > > > know if anything is else missing. Note there are two exceptions > > > that have been left out for now that I'll be following up with > > > separately. > > > > > > Thus far it's all been either straight-forward bug-fixes, minor > > > cleanups, or small miscellaneous enhancements. AFAICT, nothing > > > looks particularly concerning. > > > > The concern would be you dumping a tree on the eve of a merge > > window, which you're presumably going to send to Linus in a week or > > so, when the last time you appeared was a fixes pull in 12 August, > > because it suggests this lot is just some randomly chosen selection > > to try to keep the tree alive. > > No. The tree contains outstanding bug-fixes and very minor > improvements. > > Do you have an objection to a particular patch..? Just the CommitDate on all of them as I said. The main problem is that it's 4 November and there's no other commit activity for an earlier date in this merge window cycle. > > I really wouldn't do it like this: I know Linus doesn't care too > > much for SCSI stuff and if you're lucky he may be too busy yelling > > at Jens to notice, but if not, you'll find yourself on the > > receiving end of his ire and that will damage the reputation of > > your tree a lot. > > I'd rather target-pending/for-next be judged on patches, and not > preconceived fear of including bug-fixes that address end-user issues > close to a merge window. A tree is judged on the trustworthiness of its maintainer. Linus uses process, feedback, regression handling and other markers to make that assessment. Having a three month gap in the CommitDate indicates a haphazard approach to the process of maintaining the tree. > > If the work of running the target tree has got too much, get a > > patch wrangler who can help with the process stuff you're > > completely lacking, like reviews and testing and long incubation in > > linux-next for exposure to 0day. > > The past release has been exceedingly slow in drivers/target/, with > the rate of incoming patches is down to ~2 per week. Those queued > are specific to drivers/target/ and don't run afoul of linux-next and > 0-day builds. Neither has actually caught up fully to your tree yet, if you check so the results should start coming in soon. > Personally, I'm still focused on bug-fixing and ensuring patches make > it back to v4.x.y linux-stable.git. However, there are still few > people working on bugs specific to host <-> fabric <-> target-core <- > > backend configurations, beyond individual components fixes. > > > > > I'm sure we can find several volunteers. > > Sure, a patch wrangler would be helpful. > > Where things tend to run into trouble is when someone starts merging > subsystem changes, but aren't directly responsible for distro > releases or production users running linux-stable.git code. > > That said, I'd prefer someone with 'skin in the game' and end-users > they support. OK, so did you have anyone in mind? James
Re: target-pending/for-next patches
On Sun, 2017-11-05 at 08:05 -0800, James Bottomley wrote: > On Sat, 2017-11-04 at 18:14 -0700, Nicholas A. Bellinger wrote: > > Hi all, > > > > Just a friendly email after catching up on patches this week, the > > majority of those outstanding on the list have been merged into > > target-pending/for-next. Please see below. > > > > For those who submitted patches, please have a look and let me know > > if anything is else missing. Note there are two exceptions that have > > been left out for now that I'll be following up with separately. > > > > Thus far it's all been either straight-forward bug-fixes, minor > > cleanups, or small miscellaneous enhancements. AFAICT, nothing looks > > particularly concerning. > > The concern would be you dumping a tree on the eve of a merge window, > which you're presumably going to send to Linus in a week or so, when > the last time you appeared was a fixes pull in 12 August, because it > suggests this lot is just some randomly chosen selection to try to keep > the tree alive. No. The tree contains outstanding bug-fixes and very minor improvements. Do you have an objection to a particular patch..? > I really wouldn't do it like this: I know Linus > doesn't care too much for SCSI stuff and if you're lucky he may be too > busy yelling at Jens to notice, but if not, you'll find yourself on the > receiving end of his ire and that will damage the reputation of your > tree a lot. I'd rather target-pending/for-next be judged on patches, and not preconceived fear of including bug-fixes that address end-user issues close to a merge window. > > If the work of running the target tree has got too much, get a patch > wrangler who can help with the process stuff you're completely lacking, > like reviews and testing and long incubation in linux-next for exposure > to 0day. The past release has been exceedingly slow in drivers/target/, with the rate of incoming patches is down to ~2 per week. Those queued are specific to drivers/target/ and don't run afoul of linux-next and 0-day builds. Personally, I'm still focused on bug-fixing and ensuring patches make it back to v4.x.y linux-stable.git. However, there are still few people working on bugs specific to host <-> fabric <-> target-core <-> backend configurations, beyond individual components fixes. > I'm sure we can find several volunteers. Sure, a patch wrangler would be helpful. Where things tend to run into trouble is when someone starts merging subsystem changes, but aren't directly responsible for distro releases or production users running linux-stable.git code. That said, I'd prefer someone with 'skin in the game' and end-users they support.
Re: target-pending/for-next patches
On Sat, 2017-11-04 at 18:14 -0700, Nicholas A. Bellinger wrote: > Hi all, > > Just a friendly email after catching up on patches this week, the > majority of those outstanding on the list have been merged into > target-pending/for-next. Please see below. > > For those who submitted patches, please have a look and let me know > if anything is else missing. Note there are two exceptions that have > been left out for now that I'll be following up with separately. > > Thus far it's all been either straight-forward bug-fixes, minor > cleanups, or small miscellaneous enhancements. AFAICT, nothing looks > particularly concerning. The concern would be you dumping a tree on the eve of a merge window, which you're presumably going to send to Linus in a week or so, when the last time you appeared was a fixes pull in 12 August, because it suggests this lot is just some randomly chosen selection to try to keep the tree alive. I really wouldn't do it like this: I know Linus doesn't care too much for SCSI stuff and if you're lucky he may be too busy yelling at Jens to notice, but if not, you'll find yourself on the receiving end of his ire and that will damage the reputation of your tree a lot. If the work of running the target tree has got too much, get a patch wrangler who can help with the process stuff you're completely lacking, like reviews and testing and long incubation in linux-next for exposure to 0day. I'm sure we can find several volunteers. James
target-pending/for-next patches
Hi all, Just a friendly email after catching up on patches this week, the majority of those outstanding on the list have been merged into target-pending/for-next. Please see below. For those who submitted patches, please have a look and let me know if anything is else missing. Note there are two exceptions that have been left out for now that I'll be following up with separately. Thus far it's all been either straight-forward bug-fixes, minor cleanups, or small miscellaneous enhancements. AFAICT, nothing looks particularly concerning. Thank you, --nab 17c45b9 iSCSI-target: Use common error handling code in iscsi_decode_text_input() 6eaf69e target/iscsi: Detect conn_cmd_list corruption early cfe2b62 target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd() e1dfb21 target/iscsi: Modify iscsit_do_crypto_hash_buf() prototype de3493a target/iscsi: Fix endianness in an error message 919765e target/iscsi: Use min() in iscsit_dump_data_payload() instead of open-coding it 8d973ab target/iscsi: Define OFFLOAD_BUF_SIZE once c017069 target: Inline transport_put_cmd() d7e595d target: Suppress gcc 7 fallthrough warnings c48e559 target: Move a declaration of a global variable into a header file 0d44374 tcmu: fix double se_cmd completion a271eac target: return SAM_STAT_TASK_SET_FULL for TCM_OUT_OF_RESOURCES 55435ba target: fix ALUA state file path truncation bdc79f0 target: fix PR state file path truncation 1ae0172 cxgbit: Abort the TCP connection in case of data out timeout b849b45 target: Add netlink command reply supported option for each device b5ab697 target/tcmu: Use macro to call container_of in tcmu_cmd_time_out_show c22adc0 tcmu: fix crash when removing the tcmu device a0884d4 iscsi-target: fix memory leak in iscsit_release_discovery_tpg() 12d5a43 iscsi-target: fix memory leak in lio_target_tiqn_addtpg() 24528f0 target:fix condition return in core_pr_dump_initiator_port() a2db857 target: fix match_token option in target_core_configfs.c 79dd6f2 target: add sense code INSUFFICIENT REGISTRATION RESOURCES e437fa3 target: fix double unmap data sg in core_scsi3_emulate_pro_register_and_move() c58a252 target: fix buffer offset in core_scsi3_pri_read_full_status 88fb2fa target: fix null pointer regression in core_tmr_drain_tmr_list 594e25e target/file: Do not return error for UNMAP if length is zero
