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

[Eric Anholt]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180308/8e89b7be/attachment.sig>