[PATCH 1/4] drm: qxl: Drop misleading comment

[Gerd Hoffmann]

  Hi,

> drm-misc runs with the committer model, i.e. a few maintainers to do pull
> requests and backmerges, a big pile of people directly pushing patches.

[ looked at docs too meanwhile ]

Sounds good.  I guess switching over simplifies things for all of us.
We'll avoid issues like the one at hand.  Patch flow would be faster
too.  Right now I'm only doing 1-2 drm-qemu pull requests per kernel
release due to low patch volume even for all four qemu drivers combined.

> Someone wreaked the entire 01.org domain, but you can get at all the
> tooling and documentation with
> 
> git://anongit.freedesktop.org/drm-intel maintainer-tools

Hmm.  On a quick glance most of dim (except apply-patch) seems to be
more useful for maintainers which do merges etc, not so much for
committers.

I'm used to use https://github.com/stefanha/patches for qemu, and
started using it for drm-qemu too.  It makes applying patches easier.
It manages a patch database, using notmuch mail storage, and can apply
patches and patch series from the patch database.  That way I don't have
to save the patches as mbox somewhere.  The tool also picks up
[Reviewed,Tested,Acked}-by lines from replies, and it stores the message
id (but unlike dim it doesn't build a patchwork link out of it).

See bfac9f4fb4d87881375ccdc5c85d5ad59f2f115d for example.

Would that format be acceptable for drm-misc?

> And then run make in there. We're not yet clear how exactly drivers within
> drm-misc would look like (wrt which drivers and how much review and stuff
> like that), hence the RFC.

Ok.  How quickly could I start using drm-misc?  I have some pending
patches for the 4.11 merge window.  Any chance I can push them through
drm-misc-next?  Or should I better send a pull req to Dave?

cheers,
  Gerd

PS: I'm kraxel at freedesktop.org