qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Leon Alrae <leon.alrae@imgtec.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Ian Oliver <ian.oliver@imgtec.com>,
	aliguori@amazon.com, Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [Qemu-devel] pending target-mips patches
Date: Wed, 01 Oct 2014 18:33:14 +0200	[thread overview]
Message-ID: <542C2CCA.30806@suse.de> (raw)
In-Reply-To: <542C1F52.6070901@imgtec.com>

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

Hi Leon,

Am 01.10.2014 um 17:35 schrieb Leon Alrae:
> I noticed that it's quite difficult to get target-mips changes
> reviewed/accepted. There is already a queue of relatively big features
> and bug fixes which are stuck for months. Does anyone have an idea how
> to improve this situation? Wouldn't it help to have a target-mips
> co-maintainer assisting Aurelien?

In February I talked to one of your directors and suggested whether
someone from Imagination could step up as co-maintainer to tackle this.
I admit, we never followed up on that conversation so far...

So, from my view what someone should do by now is this:

* Set up one or more public Git branches for officially queuing
target-mips/ and hw/mips/ patches. That helps track pending patches and
facilitates testing. I assume you have some shared internal tree anyway,
just split between what that maintainer considers good and what is still
work-in-progress.

* From time to time, send a PULL request that either Aurélien or Peter
can merge. Aurélien used to commit patches himself traditionally,
whereas I am suggesting to adopt the workflow used for ARM and Power.

The underlying assumption is that such MIPS patches would not touch
generic code without explicit ACKs, thereby not breaking x86 code.

Also, as usual, the person needs to have been around qemu-devel a little
and beware of what common style/functional issues to look out for and of
what legacy machines/CPUs exist that might break when implementing new
stuff - having test images to verify would be ideal.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2014-10-01 16:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-01 15:35 [Qemu-devel] pending target-mips patches Leon Alrae
2014-10-01 16:32 ` Peter Maydell
2014-10-02  8:46   ` Leon Alrae
2014-10-01 16:33 ` Andreas Färber [this message]
2014-10-16 10:12 ` Aurelien Jarno
2014-10-16 10:19   ` Leon Alrae

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=542C2CCA.30806@suse.de \
    --to=afaerber@suse.de \
    --cc=aliguori@amazon.com \
    --cc=aurelien@aurel32.net \
    --cc=ian.oliver@imgtec.com \
    --cc=leon.alrae@imgtec.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).