From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: [PATCH] Xen watchdog driver Date: Wed, 06 Oct 2010 09:11:16 -0700 Message-ID: <4CAC9FA4.9030907@goop.org> References: <4CA4B4420200007800019CAB@vpn.id2.novell.com> <4CA4B7F2.7060606@goop.org> <4CA5A2280200007800019E79@vpn.id2.novell.com> <1286183752.23155.2061.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1286183752.23155.2061.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 10/04/2010 02:15 AM, Ian Campbell wrote: > > I think we all need to start trying to move from the mindset that > xen.git is the only target of our development efforts and instead work > much more directly/closely with Linux upstream, in particular with > subsystem maintainers of other areas touched by our patches. > > Many Xen patches differ from the norm in that they are cross-subsystem > (e.g. they implement Xen functionality in the context of some other > subsystem such as networking, block, watchdog subsystems) rather than > being obviously single subsystem with the more normal linear progression > through driver maintainer to subsystem maintainers to Linus etc. > > I think it should be the responsibility of the patch contributor to get > review and thence an Acked-by from both/all subsystem maintainers (IOW > both Jeremy and the other subsystem's maintainers), regardless of which > tree the patch eventually gets committed to. > > For cases where there is no impediment to sending stuff directly > upstream pushing stuff only towards xen.git works against the goal of > having first class Xen support in the upstream kernel. Even in cases > where a patch depends on something which is currently only in xen.git I > think taking it to the relevant subsystem and getting an > in-principle-Acked-by makes sense in many cases and will help with the > eventual upstreaming. > > I could even go so far as to argue that in many cases (especially for > domU stuff) the primary subsystem of interest for a patch is not Xen but > the other one and that only core Xen stuff really needs to go through > xen.git. In other words in most cases the main target of upstreaming > should be the maintainer of the relevant other subsystem, of course with > Jeremy's and/or other Xen community members' Reviewed/Acked/Tested-by. > > This sort of model has already worked well for Stefano's pvhvm drivers > and is looking good for Konrad's swiotlb/pcifront stuff too. Although > the above is really intended as a more general comment on our > development practices I do think a watchdog driver is another good > example of a patch which could go via the watchdog subsystem maintainer > rather than xen.git. Yes, exactly so. J