Jason Ekstrand <ja...@jlekstrand.net> writes: > On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker <dy...@pnwbakers.com> 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 <mic...@daenzer.net> 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.
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.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev