On Wed, 2019-02-20 at 07:33 -0500, John Ferlan wrote: > On 2/20/19 2:37 AM, Michal Privoznik wrote: > > On 2/19/19 9:19 PM, John Ferlan wrote: > > > Assuming extraction (sigh) of the VIR_AUTOFREE, > > > > While I'd definitely want this to be split into two patches if it was > > fixing something under src/, but this is under tests/ and therefore I > > did not bother. The reason for splitting a patch into smaller > > semanticaly divided patches is to help distro maintainers to ease > > backports. And reviewers, and people digging through history possibly years down the line. Whether the change is in src/, tests/ or whatever else shouldn't make a difference, it's all code and we routinely have to fix bugs both in the library and in the corresponding test suite. There is barely ever a reason *not* to split changes into smaller, independent units; having to write "at the same time" in the commit message should be your hint that you're doing it wrong ;) > > I don't think they will need to backport this patch, nor will > > they want only a part of it. > > Just going with precedent I've seen for other patches regardless of > where they're found in the tree. Personally, I'm fine with doing it all > at once. But I think perhaps some one should take the time to write > down what the "house rules" are on the hacking page. Makes it easier > that way. We *kinda* have that already: Split large changes into a series of smaller patches, self-contained if possible [...] Perhaps we could reword that passage so it's clearer, and extend it by going into more detail. -- Andrea Bolognani / Red Hat / Virtualization