On Mon, Jan 30, 2017 at 06:14:49PM +0100, Gerd Hoffmann wrote: > 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. Yeah, with dim I do send out pull requests every 1-2 weeks, depending upon how much pending stuff there is. > > 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. That sha1 isn't in linux-next, so no idea. But in principle, yes dim isn't all that much about handling patches, and much more about handling branches. One part that imo really should stick around is the drm-tip integration tree rebuilding. That allows us to distribute conflict handling (e.g. between drm-misc-fixes and drm-misc-next), and with more people and more drivers in drm-misc I expect more conflicts. > Would that format be acceptable for drm-misc? The other bit is that dim is a nice place for catching obvious screw-ups. E.g. for drm-intel it checks that the patch only touches i915, and if not if there's an ack from Dave on it. So I think standardizing on that tool has benefits (as long as we can't just enforce such simple checks with CI on the server side). But dim apply-branch is a supposed to be a drop-in replacement for git apply-mbox, so should be simple to integrate into another set of scripts to manage the mails. And if there's changes to dim needed to make that happen, we can do that (we push patches to it at a regular pace). > > 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? If you want you can get started right away. I plan to type some small docs for this experiment, but the only thing you need is an fdo account with drm-misc commit rights. Simplest to ping me (and fdo admins) on #dri-devel. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
