<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 9, 2018 at 8:57 AM, Alex Deucher <span dir="ltr"><<a href="mailto:alexdeucher@gmail.com" target="_blank">alexdeucher@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Mar 9, 2018 at 11:04 AM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> On March 9, 2018 00:35:06 Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> wrote:<br>
><br>
>> On 2018-03-08 07:53 PM, Jason Ekstrand wrote:<br>
>>><br>
>>> On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker <<a href="mailto:dylan@pnwbakers.com">dylan@pnwbakers.com</a><br>
>>> <mailto:<a href="mailto:dylan@pnwbakers.com">dylan@pnwbakers.com</a>>> wrote:<br>
>>><br>
>>>     > I know we've always given a lot of flexibility to vendor specific<br>
>>> code<br>
>>>     > (i965 or nouveau), but you hope everyone can understand my<br>
>>> frustration<br>
>>>     > with a 56 patch series that I sent review for 8 hours after it was<br>
>>>     > posted to the list and I got told "Oh, I merged that hours ago,<br>
>>>     > patches welcome."<br>
>>><br>
>>>     I can. I guess Jason got a bit carried away by the Vulkan 1.1<br>
>>>     excitement.<br>
>>><br>
>>><br>
>>> Perhaps.  :-)  I do think that being there day-1 is important.<br>
>><br>
>><br>
>> The code was there on day 1 anyway. If being available in Git ASAP is<br>
>> that important (not sure why though), it can be made available in a<br>
>> repository other than the main shared one.<br>
><br>
><br>
> Thanks to things such as the oibaf ppa, landing in master means also landing<br>
> in the hands of users.  There's a little extra delay but there are piles of<br>
> people who now have a Vulkan 1.1 driver who wouldn't build from source.<br>
> Maybe not a huge deal but landing in master does matter over having a<br>
> branch.<br>
><br>
>>> If nothing else, it shows the rest of the graphics community (who already<br>
>>> fears the concept of open-source) that working in the open isn't going<br>
>>> to cramp their style.<br>
>><br>
>><br>
>> It wasn't following the normal Mesa development process, so I'm not sure<br>
>> it's really useful for showing anything about that to anyone.<br>
><br>
><br>
> I'm not sure I follow.<br>
><br>
<br>
</div></div>One could argue it shows people that are leery of open source to go<br>
ahead and push out whatever you have ASAP to meet a schedule and fix<br>
it up later which seems to contradict the whole idea of group review<br>
and making sure your code is the best it can be.  In my experience,<br>
one of the biggest concerns people that are not familiar with open<br>
source tend to have is that it takes too long to get upstream because<br>
of all the code review.  I'm not really trying to argue, I realize it<br>
is a fine line...<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Yeah.  It is a fine line.  I also recognize that anything short of "at least 24 hours on the public list" is a bit of a slippery slope.  If you can push without giving everyone in the world (timezone wise) a chance for review, what's the threshold?  12 hours? 8 hours? 4?  Can you just push without sending it to the list at all?  There's no real good threshold below 24.  And, if needs be, we can always get in contact with the guy who does the oibaf PPA and have him apply the patches or pick up a branch so that users get it.  Or we can just count on the fact that no one will have any games that require Vulkan 1.1 on the first day and hope that developers who want to write Vulkan 1.1 code know how to apply patches build mesa from source.<br><br></div><div class="gmail_extra">That said, I think it is good, when working with embargoes, for people who do have early access to do early review.  That way the later review process goes much more smoothly if there are any comments at all.  What closed-source developers (and companies) are afraid of is not the 24 hour window, it's the 5-10 respins/rebases of 100+ patches over the course of 2 weeks - 6 months.  Now, mesa is a fairly reasonable community and you're more likely looking at 2-3 respins and 1-2 weeks for a series like this.  However, it's still going to be a lot more than 24 hours if there is significant late-breaking feedback.<br><br></div><div class="gmail_extra">I'm sorry if I'm venting a bit here.  I sucks to be the guy working under an embargo.<br></div></div>