On Thu, Jun 25, 2015 at 01:50:31PM +0200, Marek Olšák wrote: > It would be nice if patchwork could filter patches according to touched files.
Yeah that would definitely be useful for mesa and also for dri-devel. Probably not a top priority for drm/i915 though since it's all for one maintainer only anyway. But good idea. Also adding Damien, in case someone else has another idea. -Daniel > > Marek > > On Tue, Jun 23, 2015 at 11:53 AM, Daniel Vetter <dan...@ffwll.ch> wrote: > > On Fri, Jun 19, 2015 at 09:12:15PM +0100, Jose Fonseca wrote: > >> On 19/06/15 20:45, Ilia Mirkin wrote: > >> >On Fri, Jun 19, 2015 at 3:39 PM, Jose Fonseca <jfons...@vmware.com> wrote: > >> >>On 19/06/15 13:32, Timothy Arceri wrote: > >> >>> > >> >>>Hi all, > >> >>> > >> >>>Unfortunately since its introduction patchwork hasn't seen a lot of love > >> >>>in the Piglit and Mesa projects so I thought I'd try something out to > >> >>>bring it out of the shadows and into the limelight. > >> >>> > >> >>>The idea is simple we have many useful but long forgotten patches > >> >>>sitting on the mailing list that would serve us much better sitting in > >> >>>the git repo, so once a week I (or anyone else that wants to help out) > >> >>>would pick 10 seemingly random older patches that could do with a > >> >>>review/update/etc. > >> >>> > >> >>>I'm hoping this will help with both clearing out the backlog of patches > >> >>>and getting people thinking about patchwork. > >> >>> > >> >>>I'm interested in feedback on what people think about this idea. > >> >> > >> >> > >> >>Patchwork seems to fail to recognize submited patches. Eg. one of my > >> >>patches is https://patchwork.freedesktop.org/patch/51379/ but it has been > >> >>commited on > >> >>http://cgit.freedesktop.org/piglit/commit/?id=540972b46e51ee1d4acbb3757b731a066e2b6ba5 > >> >> > >> >>Why is that? > >> > > >> >It's very strict about matching patches. The diff has to be identical. > >> >Which it often isn't if you made minor changes, or rebased, or > >> >whatever. > >> > >> Without a bit of fuzzy matching I'm afraid this looks a bit hopeless to me: > >> > >> I believe the bulk of the patches are committed, and only a few is > >> forgotten. Looking at the patchwork backlog it's fair to say a large > >> portion of those committed don't get detected due to small changes. So the > >> end result is that developers have to click through and babysit the bulk of > >> their changes in patchwork, so that the few truly forgotten patches get to > >> stand out? > >> > >> I don't think this will ever going to work. There's no incentive in the > >> system for the most prolific developers to spend so much of their time, for > >> the sake of the occasional contributor. The patchwork system seems bound > >> to > >> echo what happens on the mailing list: their patches get to be lost > >> twice... > >> > >> > >> There 's another concern -- one can only change the status of our own > >> patches. So if one commits on behalf of somebody else, and that patch > >> doesn't get recognized, one needs to get that other person to register and > >> click through patchwork? > >> > >> > >> > >> > >> > >> I wonder if it wouldn't be better to have a more comprehensive solution for > >> review and tracking, ala github pull requests. Maybe have an official > >> mirror for mesa/piglit in github, or deploy gitlab > >> (https://about.gitlab.com/features/) in fdo.org, or something along those > >> lines, and start tracking this sort of things as pull requests. > >> > >> I known it might look (and be) a wild idea at the moment, but I believe > >> this > >> will be the future eventually: with things like cloud-based CI systems > >> (Travis CI, AppVeyor), projects can have testsuites run automatically on > >> pull requests (No GPU HW available, but one can still ensure builds don't > >> fail, run unit tests, and even rendering tests with SW renderers) and > >> detect > >> issues even before reviewing or committing. > >> > >> I've seen this happen first-handed: I once make a pull request to an > >> open-source project I had never contributed on github, a few minutes later > >> bot added a comment saying that the project built fine and all unit tests > >> passed, and all the maintainer had to do was clicking a button. > >> > >> I'm now trying to repro this on some of my open source projects. (E.g, > >> Apitrace). I still have a long way to go, but already it is showing fruits > >> -- I immediately know when a Linux developr proposes a Apitrace change that > >> breaks Windows vuild (or a Windows developer breaks Linux build) , and I > >> can > >> point them to the logs and they can often fix them selves. I hope one day > >> I > >> have unit tests and more there too. > > > > We (the i915 kernel folks) are working on an improved patchwork (aiming to > > push it all to upstream patchwork ofc) which should address a lot of your > > concerns. It can trakc entire patch series, resends and has better > > automagic detection of when a related/rebased/slightly changed patch shows > > up or gets merged. Atm we're testing it internally a bit, but I hope we > > can roll it out to the public soonish. Damien is the one working on it > > mostly. > > -Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > _______________________________________________ > > Piglit mailing list > > Piglit@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/piglit -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Piglit mailing list Piglit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/piglit