On Wed, 18 Nov 2015, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Sun, Nov 08, 2015 at 12:31:36AM +0000, Damien Lespiau wrote: >> Hi all, >> >> I've added a feature to sort the patches sent to intel-gfx into 3 >> buckets: i915, intel-gpu-tools and libdrm. This sorting relies on >> tagging patches, using the subject prefixes (which is what most people >> do already anyway). >> >> - i915 (intel-gfx): catchall project, all mails not matching any of >> the other 2 projects will end up there >> >> - intel-gpu-tools: mails need to be tagged with i-g-t, igt or >> intel-gpu-tools >> >> - libdrm-intel: mails need to be tagged with libdrm >> >> This tagging can be set up per git repository with: >> >> $ git config format.subjectprefix "PATCH i-g-t" > > Is there any way we could push this out to users somehow? I have bazillion > of machines, I'll get this wrong eventually ... So will everyone else I > guess. Googling around, I don't think we can automatically force this on people. We could add a script to make it easier for people to set this up. Either a setup that needs to be re-run every time there are changes, or a setup that symlinks a git hook back into a file stored in the repository so changes are deployed automatically. The latter has security implications, so I'd go for the former. BR, Jani. > -Daniel > >> >> And use git send-email as usual. A note of caution though, using the >> command line argument --subject-prefix will override the one configured, >> so the tag will have to be repeated. To limit the number of things one >> needs to think about I'd suggest to use --reroll-count to tag patches >> with the v2/v3/... tags. I'm more and more thinking that wrapping the >> sending logic for developers into the git-pw command would be a good >> thing (especially for --in-reply-to) but that'd be for another time. >> >> There are two new patchwork projects then: >> >> http://patchwork.freedesktop.org/project/intel-gpu-tools/ >> http://patchwork.freedesktop.org/project/libdrm-intel/ >> >> I've also run the sorting on all the existing patches so the entries >> that were historically in the intel-gfx project are now in those new >> projects. >> >> There is still some work left to limit the noise of those lists of >> patches, eg. some patches are still marked as New but, in reality, they >> have been merged. Solving that is quite important and high-ish the TODO >> list. >> >> HTH, >> >> -- >> Damien >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
