On Wed, Jul 27, 2022 at 10:17 AM Enzo Matsumiya <ematsumiya@xxxxxxx> wrote: > > On 07/27, Steve French wrote: > >I doubt that renaming tcpStatus to "status" helps much. If it has to > >do with the socket, included tcp or socket or connection in the name > >seems plausible/helpful. I don't mind removing the came cause (e.g. > >"tcp_status" or something similar) but prefer other types of cleanup > >to be the focus (moving smb1 code out of mixed smb1/smb2/smb3 c files > >into smb1 specific ones that are compiled out when legacy is disabled > >etc. > > Steve, the way I see it is, if we have a struct names "server_info" or > similar, there's no need to include a prefix in its fields' names, > especially when there's only one "status" variable for that struct > (which should always be the case), e.g. "server->server_status" looks > ugly and one might assume that "server" holds another different status, That point makes sense - but these kind of renames are lower priority than getting the features/bugfixes cleaned up for the merge window. Lots of interesting things to work on relating to multichannel, leases, compression support, signing negotation (helps perf), fixing the swapfile feature, sparse file improvements, more testing of posix extensions etc.
