On 4/23/24 3:41 AM, Marc Hartmayer wrote:
On Tue, Apr 23, 2024 at 10:06 AM +0100, Daniel P. Berrangé
<berrange(a)redhat.com> wrote:
> On Tue, Apr 23, 2024 at 10:46:14AM +0200, Marc Hartmayer wrote:
>> On Tue, Apr 23, 2024 at 09:10 AM +0100, Daniel P. Berrangé
<berrange(a)redhat.com> wrote:
>>> On Tue, Apr 23, 2024 at 10:03:35AM +0200, Marc Hartmayer wrote:
>>>> On Fri, Apr 19, 2024 at 02:23 PM -0500, Jonathon Jongsma
<jjongsma(a)redhat.com> wrote:
>>>>> On 4/19/24 9:49 AM, Marc Hartmayer wrote:
>>>>>> It's better practice for all functions called by the threads
to
>>>>> pass the driver
[…snip…]
>>
>> Hmm, is the downside of doing a full codebase reformat greater than
>> always doing the code formatting manually? Probably it is, otherwise it
>> would have already be done :)
>>
>> If we would have such a big commit we could list it in a
>> `.git-blame-ignore-revs` file so it will ignored by git blames.
>
> Yes, that's great for git blame. The bigger problem though is that
> a bulk reformat will immediately kill the ability of distro
> maintainers to cleanly cherry-pick patches across the big reformat
> commit. Cherry-picking the reformat likely won't be clean either,
> so they'll be faced with many patches needing manual editting.
Yes, but isn't that already the case most of the time? But since I do
not backport libvirt fixes, I cannot answer this for sure :)
As a downstream package maintainer, I always shake my fist at these types of
reformat changes when they break clean cherry-picks. But I also understand
progress, modernization, etc can't be hamstrung by downstream convenience :-).
Regards,
Jim
Anyhow, we shouldn't misuse this mail thread for the side discussion :)
Is it worth starting a separate thread for it or is the answer a clear
NACK?
>
> The tricky question is whether it is none the less worthwhile doing
> it. The distro maintainer pain will be very real, but also somewhat
> timelimited, as the need to backport fixes to a given release
> as it ages.
If the people doing the backporting are more or less libvirt developers,
it might be a good trade for them in the long run.
>
> With regards,
> Daniel
> --
> |:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
> |:
https://libvirt.org -o-
https://fstop138.berrange.com :|
> |:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|
>