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@freedesktop.org