<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 8, 2018 at 11:58 AM, Eric Anholt <<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes: > On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker <<a href="mailto:dylan@pnwbakers.com">dylan@pnwbakers.com</a>> wrote: > >> Quoting Jason Ekstrand (2018-03-07 20:22:51) >> > Yes, that is what happened. That said, wrote that patch in September and >> > you've had about 6 months to look at it. The only particularly active >> Mesa >> > contributor who hasn't had access is Ilia. >> >> No, just no. Having a patch in a branch does not count, especially not in a >> closed branch. I have plenty of patches that have sat in branches for >> months, >> years even. You're saying it's okay for me to send them to the list and >> push >> them a couple hours later because I wrote them a long time ago? > > > 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. > > 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. > > 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. > > 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. > > On Thu, Mar 8, 2018 at 10:37 AM, Michel Dänzer <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> wrote: > >> On 2018-03-08 06:10 PM, Dylan Baker wrote: >> > >> > When I was given commit access I was told that I should wait 24 hours >> > after sending patches unless they were trivial or fixed something >> > critical, ie, without them you can't compile or nothing works. >> >> FWIW, I think that's a good rule, and I follow it. >> >> If one doesn't wait for at least 24 hours, e.g. somebody living in a >> different timezone may not get a chance to send feedback before the >> patch is applied. So it's kind of implying one isn't interested in >> feedback from such people. >> > > 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. > > >> > I know we've always given a lot of flexibility to vendor specific code >> > (i965 or nouveau), but you hope everyone can understand my frustration >> > with a 56 patch series that I sent review for 8 hours after it was >> > posted to the list and I got told "Oh, I merged that hours ago, >> > patches welcome." >> >> I can. I guess Jason got a bit carried away by the Vulkan 1.1 excitement. >> > > 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. </div></div>I completely agree here. We have git. We can change code after it lands. The value we as a project get from having day 1 support is huge, and the value of getting our python style polished before any patches land is... well, it doesn't even compare. Also, I feel that if the Vulkan driver implementors are happy with this Vulkan driver support code, then that trumps style requests from others. </blockquote></div> </div><div class="gmail_extra">Don't get me wrong. I definitely value Dylan's opinion about python code. My python code is always vastly better after he's reviewed it. That's why I asked him to look over it back in September. </div></div>