Ian Romanick <i...@freedesktop.org> writes:

> On 02/25/2013 05:17 PM, Brian Paul wrote:
>> On 02/25/2013 11:10 AM, Jordan Justen wrote:
>>> Reviewed-by: Jordan Justen<jordan.l.jus...@intel.com>
>>>
>>> On Sat, Feb 23, 2013 at 7:29 AM, Brian Paul<bri...@vmware.com>  wrote:
>>>> This series removes the dependencies on the mfeatures.h file and the
>>>> file
>>>> itself.
>>>>
>>>> I'd appreciated someone doing a test build of this series to
>>>> double-check my
>>>> work.
>>>
>>> Do you have a public repo where you push changesets like this?
>>
>> No, but here's a tarball of the patch series.  I added a tenth patch
>> that touches intel_screen.c
>
> In the future, a git tree for a large patch series would be a lot 
> better.  A lot of times git-am will fail if the tip of the tree has 
> changed much since the patches were sent out.  That can make it a lot 
> harder to build, test, etc. large series.
>
> One of the guys around here suggested this morning that we make that 
> part of the patch policy, and I think that's a good idea.  Everyone with 
> commit access to any project hosted on fdo has (should have?) an account 
> on people.freedesktop.org, so there should be no problems with hosting.

Incidentally, that was in the context of my debug series, and I ended up
agreeing that it's pretty reasonable -- people often end up polling the
submitter to put up a tree, and it costs me little to mention a branch
name up front.  It can help review when you get to go grep the tree
after the fact, which can show things hard to see in a diff.

> For what value of N should we set the bound?

I'm not that into hard and fast rules, but it seems likely that if I
thought there was enough extra context to deserve "--compose" for my
series, it probably also deserves posting to a branch in my personal
tree.  And especially for patches that have sed-job aspects (granted,
not the patch series I just did, but several I've been involved in
recently)

Attachment: pgpDU7bIwn_0l.pgp
Description: PGP signature

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to