On Thu, Mar 8, 2018 at 11:58 AM, Eric Anholt <e...@anholt.net> wrote:
> 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. > 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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
