[Piglit] Weekly 10 Picks from Patchwork for review and friendly reminder to clean out your old patches

[Daniel Vetter]

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 <daniel at 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 <jfonseca at 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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/piglit

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch