[Mesa-dev] [PATCH 04/56] anv/entrypoints: Generalize the string map a bit

[Jason Ekstrand]

On Thu, Mar 8, 2018 at 11:58 AM, Eric Anholt <eric at anholt.net> wrote:

> Jason Ekstrand <jason at jlekstrand.net> writes:
>
> > On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker <dylan at 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 <michel at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180308/2dc2d7ad/attachment.html>