It would be nice if patchwork could filter patches according to touched files.
Marek On Tue, Jun 23, 2015 at 11:53 AM, Daniel Vetter <[email protected]> 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 <[email protected]> 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/piglit _______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
