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@xxxxxxxxxxxxxxx _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
