On Mon, 2019-09-30 at 15:53 +0100, Daniel P. Berrangé wrote: > On Mon, Sep 30, 2019 at 04:05:57PM +0200, Andrea Bolognani wrote: > > I see your point about backports being more painful when you have > > a bunch of unrelated changes mixed in, but I would still prefer if > > we converted everything at once and at the same time introduced a > > suitable syntax-check rule preventing more instances of whatever > > function we just removed all callers of from creeping back in, or > > actually just dropping the function altogether. > > > > Doing the conversion incrementally will IMHO result in dragging it > > for much longer, causing more pain in the long run than ripping the > > bandaid would. > > There's really not any significant real world pain from mixing the > two styles. It is visually distasteful but doesn't cause any functional > problems at runtime, nor complexity for maintainers. A large conversion > over the whole codebase does cause very significant pain in conflicts > for anyone cherry picking patches. That is just not a net win overall. > I'll take visually mixed styles any day over creating patch conflicts > in backports. If we allow both at the same time, then we'll keep using both going forward because there's no incentive *not* to mix the two styles; one of the stated advantages of adopting GLib, making the libvirt code base more approachable to people familiar with QEMU and other GLib-using projects, will then not be realized. Both the conversion from one style to the other and, consequently, addressing any conflict resulting from it, can be tackled in a purely mechanical fashion: a bit annoying, sure, but hardly worth keeping the conversion ongoing forever for in my opinion. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
