On 31.10.2011, at 18:35, Peter Maydell wrote: > On 1 November 2011 00:08, Alexander Graf <ag...@suse.de> wrote: >> On 31.10.2011, at 06:12, Peter Maydell <peter.mayd...@linaro.org> wrote: >>> On 29 October 2011 14:52, Alexander Graf <ag...@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.)
Phew, eager goals :). I like the idea though! > >>> 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. Sure, but reduced utility is a good starting point. It's certainly better than no 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. The main improvement is that you could enhance distro versions of QEMU. And inside a stable version we would also stay ABI compatible usually. Alex