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

[Ian Romanick]

On 06/19/2015 01:12 PM, 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:

FYI... git-push will tell you which patches were recognized and which
ones were not.  That generally makes it easy to know you need to go in
and manually mark some.

> 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.
> 
> 
> Jose
> _______________________________________________
> Piglit mailing list
> Piglit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/piglit
>