Peter Maydell <peter.mayd...@linaro.org> writes:
> On Wed, 27 Jul 2022 at 18:28, Raphael Norwitz > <raphael.norw...@nutanix.com> wrote: >> >> On Tue, Jul 26, 2022 at 03:57:42PM +0100, Peter Maydell wrote: >> > On Fri, 1 Jul 2022 at 06:41, Markus Armbruster <arm...@redhat.com> wrote: >> > > Could we use a contrib/README with an explanation what "contrib" means, >> > > and how to build and use the stuff there? >> > >> > I would rather we got rid of contrib/ entirely. Our git repo >> > should contain things we care about enough to really support >> > and believe in, in which case they should be in top level >> > directories matching what they are (eg tools/). If we don't >> > believe in these things enough to really support them, then >> > we should drop them, and let those who do care maintain them >> > as out-of-tree tools if they like. >> > >> >> I can't speak for a lot of stuff in contrib/ but I find the vhost-user >> backends like vhost-user-blk and vhost-user-scsi helpful for testing and >> development. I would like to keep maintaining those two at least. > > Right, I don't mean we should just delete contrib/, but for the > things currently in it that we do care about, we should define > what their relationship to QEMU is and put them in a part of > the source tree that says what they actually are. contrib/ > just means "nobody thought about it". I split plugins a while ago between: tests/plugin contrib/plugins where the former are really basic plugins that show usage, exercise the API and are included in the check-tcg tests. The contrib plugins are slightly more random mix of useful (e.g. cache, execlog), downright experimental (lockstep) and stuff I can't actually test (e.g. drcov). I'll quite happily continue to process patches that update and enhance contrib/plugins but at a push a few could be promoted to less of a dumping ground (tools/tcg-plugins?). I guess it would only really matter if we were installing plugins as part of "make install"? -- Alex Bennée
