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

[Alexander Graf]

On 31.10.2011, at 06:12, Peter Maydell <address@hidden> wrote:

> On 29 October 2011 14:52, Alexander Graf <address@hidden> 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.

> 
>> Also, an easy way of counterfighting the feeling ignored part is
>> to tell people that they just hit an unmaintained area. There's
>> nothing more frustrating than sending a patch and get no reply.
>> Receiving a reply "Sorry, this area is unmaintained. Please find
>> someone to review it." would already be enough for most people.
> 
> The difficulty that strikes me with this is that I'm not sure any
> one person can reliably look at a patch and say "that's for an
> unmaintained area" (at least, I know what areas I can review but
> I have no idea about everybody else...) So you can only really
> tell by default, ie if the patch sits for a few weeks without
> any reply...

See above. I think we could script this :)

> 
>> A lot of people seem to also have code that doesn't make sense
>> upstream, for example implementing a one-off device that only
>> really matters for their own devboard which nobody else owns.
>> For such cases, having a plugin framework would be handy. I
>> interestingly enough got into the same discussion on LinuxCon
>> with some QEMU downstreams.
> 
> 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.

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 :).


Alex

>