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

[Jason Ekstrand]

On Fri, Mar 9, 2018 at 8:57 AM, Alex Deucher <alexdeucher at gmail.com> wrote:

> On Fri, Mar 9, 2018 at 11:04 AM, Jason Ekstrand <jason at jlekstrand.net>
> wrote:
> > On March 9, 2018 00:35:06 Michel Dänzer <michel at daenzer.net> wrote:
> >
> >> On 2018-03-08 07:53 PM, Jason Ekstrand wrote:
> >>>
> >>> On Thu, Mar 8, 2018 at 8:45 AM, Dylan Baker <dylan at pnwbakers.com
> >>> <mailto:dylan at pnwbakers.com>> wrote:
> >>>
> >>>     > 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.
> >>
> >>
> >> The code was there on day 1 anyway. If being available in Git ASAP is
> >> that important (not sure why though), it can be made available in a
> >> repository other than the main shared one.
> >
> >
> > Thanks to things such as the oibaf ppa, landing in master means also
> landing
> > in the hands of users.  There's a little extra delay but there are piles
> of
> > people who now have a Vulkan 1.1 driver who wouldn't build from source.
> > Maybe not a huge deal but landing in master does matter over having a
> > branch.
> >
> >>> 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.
> >>
> >>
> >> It wasn't following the normal Mesa development process, so I'm not sure
> >> it's really useful for showing anything about that to anyone.
> >
> >
> > I'm not sure I follow.
> >
>
> One could argue it shows people that are leery of open source to go
> ahead and push out whatever you have ASAP to meet a schedule and fix
> it up later which seems to contradict the whole idea of group review
> and making sure your code is the best it can be.  In my experience,
> one of the biggest concerns people that are not familiar with open
> source tend to have is that it takes too long to get upstream because
> of all the code review.  I'm not really trying to argue, I realize it
> is a fine line...
>

Yeah.  It is a fine line.  I also recognize that anything short of "at
least 24 hours on the public list" is a bit of a slippery slope.  If you
can push without giving everyone in the world (timezone wise) a chance for
review, what's the threshold?  12 hours? 8 hours? 4?  Can you just push
without sending it to the list at all?  There's no real good threshold
below 24.  And, if needs be, we can always get in contact with the guy who
does the oibaf PPA and have him apply the patches or pick up a branch so
that users get it.  Or we can just count on the fact that no one will have
any games that require Vulkan 1.1 on the first day and hope that developers
who want to write Vulkan 1.1 code know how to apply patches build mesa from
source.

That said, I think it is good, when working with embargoes, for people who
do have early access to do early review.  That way the later review process
goes much more smoothly if there are any comments at all.  What
closed-source developers (and companies) are afraid of is not the 24 hour
window, it's the 5-10 respins/rebases of 100+ patches over the course of 2
weeks - 6 months.  Now, mesa is a fairly reasonable community and you're
more likely looking at 2-3 respins and 1-2 weeks for a series like this.
However, it's still going to be a lot more than 24 hours if there is
significant late-breaking feedback.

I'm sorry if I'm venting a bit here.  I sucks to be the guy working under
an embargo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180309/d96d8009/attachment.html>