Re: [libvirt] [PATCH] Revert "admin: Rename virAdmConnect to virAdmDaemon"

On Tue, Dec 15, 2015 at 08:30:41AM +0100, Martin Kletzander wrote: > On Mon, Dec 14, 2015 at 09:31:33AM +0100, Erik Skultety wrote: >> On 10/12/15 15:54, Daniel P. Berrange wrote: >>> On Thu, Dec 10, 2015 at 03:46:45PM +0100, Erik Skultety wrote: >>>> Commmit df8192aa introduced admin related rename and some minor >>>> (caused by automated approach, aka sed) and some more severe isues along with >>>> it. First reason to revert is the inconsistency with libvirt library. >>> >>> We have release 1.3.0 with this header file, so IMHO we can't just >>> rename the public APIs now. >>> >> Yes, I understand that Daniel and I know our policy, but what I thought >> was that since it's still disabled and cannot be used properly (besides >> editing the code and rebuilding upstream and still wouldn't do much), >> there might be an exception to this...obviously, it's not, so at least >> we could revert the client internal changes, I guess. >> > > Yes, moreover the header file is not distributed yet, I took the > precautions so that we can discuss API-incompatible changes for now and > finally come to a conclusion about some of these details and move on. Ok, I'll withdraw my objection > Thinking about it over and over again, I'm probably OK with being > consistent with the libvirt library even though I don't like it as > much. One other thing to solve both naming problems, but it would add > APIs that are not needed now, is to have virAdmConnectGetDaemon which > would return virAdmDaemonPtr. But that might be getting too > complicated. > > I would say that if nobody chimes in with another opinion (for, let's > say, around a week) the safest way will be sticking with the naming > that's consistent with libvirt library, despite the fact that I, > personally, am not in favor of that. As a general rule I've a preference for consistent naming across libvirt, as long as it doesn't result in mis-leading names. Regards, Daniel