On Mon, Sep 30, 2019 at 05:24:00PM +0200, Peter Krempa wrote: > On Mon, Sep 30, 2019 at 16:10:11 +0100, Daniel Berrange wrote: > > On Mon, Sep 30, 2019 at 05:03:47PM +0200, Peter Krempa wrote: > > > On Mon, Sep 30, 2019 at 15:53:35 +0100, Daniel Berrange wrote: > > > > On Mon, Sep 30, 2019 at 04:05:57PM +0200, Andrea Bolognani wrote: > > > > > On Mon, 2019-09-30 at 13:41 +0100, Daniel P. Berrangé wrote: > > > > > > On Mon, Sep 30, 2019 at 02:18:17PM +0200, Andrea Bolognani wrote: > > > > > > > On Mon, 2019-09-30 at 13:56 +0200, Pavel Hrdina wrote: > > [...] > > > > > 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. > > > > > > I don't see how. If the end-goal is to convert everything to the new > > > form you will get into potential pain/conflicts sooner or later anyways. > > > > If we incrementally convert methods, then when backporting a patch > > related to that method, we have good chance of being able to cherry-pick > > the small conversion patch. If we bulk convert entire file at a time, > > across the whole codebase, attempting to cherry-pick the conversion patches > > will have much higher conflict liklihood. > > I doubt that there will be any motivation to start a incremental > coversion. While when adding VIR_AUTOFREE and coverting to it there was > a clear benefit of simplification in doing so, converting from > VIR_AUTOFREE to g_autofree has exactly 0 benefit. The motivation for conversion is something under our direct control as reviewers. eg we could define a coding style rule that any function which makes a call to any glib API (ie a g_XXX prefix) must be converted as a prior step. > > > Or the other option is to leave it as a half-done lingering refactor and > > > that doesn't help either. > > > > It don't be in a half-done state forever. We can let things be converted > > incrementally over the next 3-6 months. At the end of say 6 months if > > anything is left we bulk convert it them. That gets the benefits opf > > incremental work without downside of stuff remaining unconverted forever. > > How is this not a big-bang conversion? Most of the conversion patches will be small & targetted. Obviously it assumes that 95% of the stuff gets converted this way during the first period. So the final conversion at the end is quite small. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
