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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 15/12/15 11:20, Daniel P. Berrange wrote:
> 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
> 

Since nobody raised another objection and it's been around a week (6
days to be exact) as Martin proposed, I pushed the revert.

Merry Christmas,
Erik

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]