On Wed, Apr 28 2021, Derrick Stolee wrote: > On 4/28/2021 12:26 PM, Ævar Arnfjörð Bjarmason wrote: >> Simplify the setup code in repo-settings.c in various ways, making the >> code shorter, easier to read, and requiring fewer hacks to do the same >> thing as it did before: > > This patch is interesting, and I'll review it when I have some more > time. Probably tomorrow. > > But I thought that I would point out that this pattern of adding a > patch within the thread of a larger series makes it very difficult > to separate the two. I use an email client that groups messages by > thread in order to help parse meaningful discussion from the list > which otherwise looks like a fire hose of noise. Now, this patch is > linked to the FS Monitor thread and feedback to either will trigger > the thread as having unread messages. > > I find it very difficult to track multiple patch series that are > being juggled in the same thread. It is mentally taxing enough that > I have avoided reviewing code presented this way to save myself the > effort of tracking which patches go with what topic in what order. > > Since I've committed to reviewing the FS Monitor code, I'd prefer if > this patch (or maybe its v2, since this is here already) be sent as > a top-level message so it can be discussed independently. As a practical matter I think any effort I make to accommodate your request will be dwarfed by your own starting of a sub-thread on E-Mail/MUA nuances :) When [1] was brought up the other day (showing that I'm probably not the best person to ask about on-list In-Reply-To semantics) I was surprised to find that we don't have much (if any) explicit documentation about In-Reply-To best practices. There's a passing mention in Documentation/MyFirstContribution.txt, but as far as I can tell from a cursory glance that's it. Personally I draw the line at "this random unrelated thing occurred to me while reading X" v.s. "this is directly in reply to X". Reading the upthread I don't really see a good point at which to start breaking the reply chain and not make things harder for others reading along with clients that aren't yours (which, looking at your headers seems to be Thunderbird 78). I.e. the one feedback on the patch idea is your upthread "waiting until such a change". With threading you can see the context, but without you'd need to get it via some not-MUA side-channel (presumably lore.kernel.org link). Sending a v2 (if any) without threading would break the chain again. 1. https://lore.kernel.org/git/nycvar.QRO.7.76.6.2103191540330.57@xxxxxxxxxxxxxxxxx/
