Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Peter Maydell <peter.maydell@linaro.org>]

On 1 November 2011 00:08, Alexander Graf <agraf@suse.de> wrote:
> On 31.10.2011, at 06:12, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 29 October 2011 14:52, Alexander Graf <agraf@suse.de> wrote:
>>> We should also show people unmaintained areas. The conclusion was a wiki
>>> page with subsystems and status so people know what to expect. Maybe we
>>> could generate this from the MAINTAINERS file?
>>
>> Sounds like a good idea, although I think we might need to expand
>> MAINTAINERS a bit -- I get the impression that there are a lot of
>> "little bits" that fall into the gaps between the top-level areas
>> marked out in MAINTAINERS.
>
> True. We do however have file path matches, so we could easily find unmaintained files.

We'd need to expand MAINTAINERS to be a lot more comprehensive and
detailed than it is now (not necessarily a bad plan). It also doesn't
deal with the "this area is maintained but the maintainer seems to
have been busy for the last three months" issue.

I guess we could try it and see how it worked.

> See above. I think we could script this :)

I think you also want to have some sort of scripting of whether
and what you were still leaving behind -- ie try to identify the
patches which your script thought were maintained but which
still didn't get any response.

(A mildly enhanced version of patchwork might do for that.)

>> If we get the qdev rework done then I think we're probably in
>> a better position to have a plugin framework for devices. (There
>> are some issues about API and ABI stability guarantees, of course.)
>
> I'm not sure why we should. We could just follow the Linux kernel
> model and merely expose what's there. New version means new API.

The "issue" is whether you try to provide any stability guarantee :-)
"We don't" is one answer, but of course it does reduce the utility.

> Remember, I don't want this for commercial fire-and-forget device
> models. I want it for stuff that's either too unclean or too
> useless for upstream :).

I'm not sure that it helps very much for this use case -- if you
have to update and rebuild for any new qemu then you might as well
have it built in (a private copy of) the qemu source tree, because
it'll just be some new files and a patch to the Makefile.

-- PMM