From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Jan Beulich <JBeulich@novell.com>
Subject: Re: Re: [PATCH] Xen watchdog driver
Date: Wed, 06 Oct 2010 09:11:16 -0700 [thread overview]
Message-ID: <4CAC9FA4.9030907@goop.org> (raw)
In-Reply-To: <1286183752.23155.2061.camel@zakaz.uk.xensource.com>
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
next prev parent reply other threads:[~2010-10-06 16:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-30 14:01 [PATCH] Xen watchdog driver Jan Beulich
2010-09-30 16:16 ` Jeremy Fitzhardinge
2010-10-01 6:56 ` Jan Beulich
2010-10-01 22:22 ` Jeremy Fitzhardinge
2010-10-04 9:15 ` Ian Campbell
2010-10-06 16:11 ` Jeremy Fitzhardinge [this message]
2010-09-30 17:03 ` Olaf Hering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CAC9FA4.9030907@goop.org \
--to=jeremy@goop.org \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@novell.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.