[PATCH 1/4] drm: qxl: Drop misleading comment
Gerd Hoffmann
kraxel at redhat.com
Mon Jan 30 17:14:49 UTC 2017
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
More information about the dri-devel
mailing list