[Mesa-dev] [ANNOUNCE] Mesa 17.3.4 release candidate

[Mark Janes]

Kenneth Graunke <kenneth at whitecape.org> writes:

> On Thursday, February 8, 2018 8:47:00 PM PST Emil Velikov wrote:
>> Rejected (9)
>> ============
>> Jason Ekstrand (2):
>>       e52a9f18d69c94b7cb7f81361cdb9e2582c3d742 i965: Replace
>> draw_aux_buffer_disabled with draw_aux_usage
>>       20f70ae3858bc213e052a8434f0e637eb36203c4 i965/draw: Set
>> NEW_AUX_STATE when draw aux changes
>> Reason: Introduce multiple regressions in the piglit compute shader tests.
>
> Hi Emil,
>
> These are absolutely critical fixes.  These patches fix GPU hangs and
> crashes in Glamor which cause people's X session to die when doing
> exciting things like using their text editor, IDE, or desktop panel.
> It's responsible for a huge swath of our GPU hang bugs on i965.
>
> Did Jason or I miss an email from you about these being rejected,
> other than at the bottom of a large changelog in an RC announcement?
> Which Piglit tests are regressing?  My guess is that we just need to
> nominate another patch, as they aren't broken in master.
>
> At this point, we've done 5 point releases in the 17.3.x series, which
> have had DRI3 crashes when pageflipping (in all drivers), and X server
> hangs and crashes galore in i965/Gen9+.  Worse, we fixed those hangs a
> month ago and haven't managed to ship them yet.  We also managed to
> ship a radv that broke completely.
>
> At this point, 17.3.x is looking like the worst Mesa release in recent
> memory, and I'm about on the verge of advising people to just go back
> to 17.2 until 18.0 comes out.  It's pretty frustrating, and I feel bad
> for our users, who depend on our software for their computer to work.
>
> We have to do better, somehow - myself included.  Ideally, we'd find a
> way to avoid major bugs like this in the first place.  Barring that,
> do we need to have developers take a more active role in backporting
> fixes again?  It seems like our nomination process works for simple
> things, but for more complex series, it doesn't work as well.  Maybe
> we need to proactively put together (tested) pull requests for stable?

It seems to me that patches CCing stable or containing 'Fixes:' could be
automatically be applied to a branch for incremental test.  Anything
that doesn't apply (or generates regressions) could be bounced to the
committer for a manual backport.

The recent issues all stem from patches that do not apply cleanly to the
release branch.  Developers should be on the hook for resolving the
conflicts *and* testing the result.

Finding conflicts shortly before release means the developers have no
chance to fix them.  It also generates pressure on the release manager
to fix up other people's patches.  Personally, I wouldn't want to be in
a position where I could easily impact large numbers of users with a
simple typo.

> --Ken
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev