[Mesa-dev] [PATCH] gallium/swr: update rasterizer (532172)

[Rowley, Timothy O]

> On Mar 23, 2016, at 12:52 AM, Justen, Jordan L <jordan.l.justen at intel.com> wrote:
> 
> On 2016-03-22 20:55:10, Rowley, Timothy O wrote:
>> 
>> Yes, there’s a lot in this patch. I froze the public version of the
>> rasterizer when I began the upstreaming process mid February, so
>> this is syncing up with about a month’s worth of development.
>> 
>> I also have this change as a series of 81 commits. Not sure if that
>> would be preferable by the community or if people would be
>> interested in reviewing the series, as issues with early commits
>> might already be addressed later in the patch set.
> 
> There seems to be some things working against community code review.
> 
> * Expected broken commits earlier in the series (We would normally ask
>  that commits are cleaned up before posting them.)

There aren’t known broken commits in the series (besides the rare source control “whoops” which can happen with pretty much any development workflow, and which I can squash in the commit series pushed upstream), it’s just that with a backlog of changes improvements which might have been suggested for an early commit might already be addressed later in the series.

> * External development (What would happen to any code review asking
>  for reworks, given that the patches are already merged elsewhere?)

We’ve only had to deal with this in a limited fashion to this point (back when we were developing on github).  Depending on the impact of the suggested changes, I’d either do it myself or work with an internal developer to implement them, and amend the commit to include the changes.  Keeping the two repositories in sync is non-trivial, and I expect there might be times where a review for the rasterizer might have to addressed as “noted, will try to address in the future” if changes become stacked to where the commit history can’t be reordered/squashed before pushing.

> * A large backlog of changes. :)

I hope to do updates on a more regular basis; the upstreaming and follow-up on issues arising caused the long period this time and the resulting backlog.

> I still think it would be better to see the 81 commits split up in the
> history as long as they won't cause problems for others. Since most
> people are unlikely to be building openswr, I don't think the commits
> will affect them.

Once we sort out some more of the build issues we’d like to propose adding openswr to the default driver build list, but as you say for now people aren’t building this code unless they intentionally turned it on.

> We rarely use merges, but perhaps it is appropriate since openswr is
> developed externally. You could start a branch at the last openswr
> commit, add your 81 commits. Then you could merge the resulting branch
> into master.

I’ve been respecting the “no merges” mesa git workflow.  I have a script which can convert from our internal repository to git commits relative to master head.

- Tim