From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Survey Results - Part 1 : Improving Xen Project Governance and Conventions Date: Tue, 6 Oct 2015 13:43:29 +0100 Message-ID: <1444135409.5302.144.camel@citrix.com> References: <0F60A9E1-7AE3-4FEC-9549-7B7F85EAA583@gmail.com> <5612A60302000078000A82D7@prv-mh.provo.novell.com> <1444127205.5302.124.camel@citrix.com> <5613D9C802000078000A883C@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5613D9C802000078000A883C@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Lars Kurth , Xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, 2015-10-06 at 06:25 -0600, Jan Beulich wrote: > > > > On 06.10.15 at 12:26, wrote: > > Now arguably any maintainer of a piece of libxl ought to be familiar with > > all of that. But, personally I don't think that is very reasonable either > > as a burden for those feature maintainers or particularly as a strategy for > > ensuring the library remains coherent. > > Agreed. But rather than always requiring multiple acks, wouldn't it be > more reasonable for the "small" maintainer to explicitly request an ack > from the "large" one in such cases? I suppose it requires the feature maintainer to be more aware of the library level stuff, i.e. aware enough of those issues to know when to ask. But that's a bit of a lame answer and I think it could reasonably be expected, so it's not all that different I guess. I'm not sure what proportion of feature patches to libxl would require taking this "trap" to the library maintainers, my gut says it would be that it is more often than not. Ian.