<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker <span dir="ltr"><<a href="mailto:dylan@pnwbakers.com" target="_blank">dylan@pnwbakers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Quoting Jason Ekstrand (2018-03-07 20:22:51)<br>
<span class="gmail-">> Yes, that is what happened.  That said, wrote that patch in September and<br>
> you've had about 6 months to look at it.  The only particularly active Mesa<br>
> contributor who hasn't had access is Ilia.<br>
<br>
</span>No, just no. Having a patch in a branch does not count, especially not in a<br>
closed branch. I have plenty of patches that have sat in branches for months,<br>
years even. You're saying it's okay for me to send them to the list and push<br>
them a couple hours later because I wrote them a long time ago? </blockquote><br><div>No, that's not what I'm saying.  However, I think there's a 
difference between a private branch that you've had sitting around for a
 while and a mostly public branch that you've been pestering your 
coworkers to review for the past 6 months and gotten zero takers.  Every
 single patch I sent had been reviewed and many of them by multiple 
people.<br><br></div><div>This is something that we as a community (and 
team) need to sort out.  With both hardware enabling and new extension 
work, we are working with embargoes.  Sometimes large pieces of work go 
into enabling said hardware and features.  This series was fairly small 
at 56 patches; If you look at all of Vulkan 1.1, it's probably more like
 500.  If we wait until it's public to get code review, you may be 
looking at weeks or months before you can land it.<br><br></div><div>This problem is only getting worse now that the mesa project is getting caught up on features.  It used to be that we could do basically everything publicly because we were several whole GL versions behind and basically zero feature work was embargoed.  The only people working with an embargo were people doing hardware enabling and they were sending the patches out months before the hardware was available to anyone so waiting a week or two doesn't matter.  Now, basically everything we do that isn't refactoring or optimization work has to happen behind closed doors.  It's unfortunate, but it's also reality.<br><br>How do we deal with that as an open-source community?  That's a good question and one which I'm happy to discuss.  I'm not sure what the right balance is here but the "it doesn't exist 
until it's public" model just isn't fair to the people who are in the 
unfortunate circumstance of working under an embargo.<br></div><div><br></div>On Thu, Mar 8, 2018 at 10:37 AM, Michel Dänzer <span dir="ltr"><<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2018-03-08 06:10 PM, Dylan Baker wrote:<br>
><br>
> When I was given commit access I was told that I should wait 24 hours<br>
> after sending patches unless they were trivial or fixed something<br>
> critical, ie, without them you can't compile or nothing works.<br>
<br>
</span>FWIW, I think that's a good rule, and I follow it.<br>
<br>
If one doesn't wait for at least 24 hours, e.g. somebody living in a<br>
different timezone may not get a chance to send feedback before the<br>
patch is applied. So it's kind of implying one isn't interested in<br>
feedback from such people.<span class=""><br></span></blockquote><div><br></div><div>I agree.  24 hours means one turn of the globe and pushing much faster than that does sort-of imply that you don't care about that feedback.  In this case, the only thing that's implied is that I don't care too much about feedback from the 5% of the mesa community who doesn't have a Khronos account.  Maybe that makes me a jerk, but I didn't think it did.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I know we've always given a lot of flexibility to vendor specific code<br>
> (i965 or nouveau), but you hope everyone can understand my 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>
</span>I can. I guess Jason got a bit carried away by the Vulkan 1.1 excitement.<br></blockquote></div><br></div><div class="gmail_extra">Perhaps.  :-)  I do think that being there day-1 is important.  If nothing else, it shows the rest of the graphics community (who already fears the concept of open-source) that working in the open isn't going to cramp their style.  If we can deliver full-featured and fully conformant Vulkan 1.1 drivers on day 1, then they can to.  I think that's an important message for the open-source community to send.<br><br></div><div class="gmail_extra">--Jason<br></div></div>