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

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 17:39 +0000, Emil Velikov wrote:
> On 16 March 2018 at 16:56, Mark Janes <mark.a.janes at intel.com> wrote:
> > "Juan A. Suarez Romero" <jasuarez at igalia.com> writes:
> > 
> > > On Fri, 2018-03-16 at 12:03 -0400, Ilia Mirkin wrote:
> > > > On Fri, Mar 16, 2018 at 11:52 AM, Juan A. Suarez Romero
> > > > <jasuarez at igalia.com> wrote:
> > > > > On Fri, 2018-03-16 at 11:38 -0400, Ilia Mirkin wrote:
> > > > > > On Fri, Mar 16, 2018 at 11:27 AM, Juan A. Suarez Romero
> > > > > > <jasuarez at igalia.com> wrote:
> > > > > > > On Fri, 2018-03-16 at 09:51 -0400, Ilia Mirkin wrote:
> > > > > > > > On Fri, Mar 16, 2018 at 8:40 AM, Juan A. Suarez Romero
> > > > > > > > <jasuarez at igalia.com> wrote:
> > > > > > > > > Nominated means that these patches does not enter in this release due they
> > > > > > > > > arrived a bit late, but they are proposed to cherry-pick them for the next
> > > > > > > > > release (in 1 or 2 weeks).
> > > > > > > > > 
> > > > > > > > > The reason is that some days before this pre-announcement is sent, we close the
> > > > > > > > > list of patches that enter in the release, and we do a lot of testing to verify
> > > > > > > > > nothing is broken). If there's some regression, we just try to fix them. And
> > > > > > > > > when everything is ready, we send the pre-announcement email.
> > > > > > > > > 
> > > > > > > > > The nominated patches are those that arrive after we close the list, and we are
> > > > > > > > > under the testing process. As we don't want to restart the full process again
> > > > > > > > > and again, we just nominate them for the next release. Otherwise that would
> > > > > > > > > delay the release too much.
> > > > > > > > 
> > > > > > > > Why not send the pre-announcement right when it's closed? Since your
> > > > > > > > testing doesn't cover all drivers, shouldn't everyone just be able to
> > > > > > > > test at the same time, and then be able to add to the existing list
> > > > > > > > with additional fixes (or removals of picked commits)?
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Because we want to propose a release candidate that has been tested as much as
> > > > > > > possible, to avoid bothering people with a proposal that we need to change
> > > > > > > because it is causing regressions (and believe me this is quite common). So we
> > > > > > > do different tests, thanks to Intel CI which covers a lot of tests and
> > > > > > > configurations, before doing the pre-announcement.
> > > > > > > 
> > > > > > > Note that between we start the testing and do the pre-announcement there is a
> > > > > > > difference of few hours, and hence the list of nominated patches is quite
> > > > > > > reduced (either none, or a couple of them). This time wasn't the case, and it
> > > > > > > took some days. But it is not the usual case.
> > > > > > 
> > > > > > Hm. It feels like it's the usual case. Perhaps it's not meant to be.
> > > > > > Why not just pick up all the nominated patches right before you do the
> > > > > > couple hours of testing?
> > > > > > 
> > > > > 
> > > > > That is what we do. We pick up all the patches until the last minute, just
> > > > > before starting the test. And as soon as we verify it is correct, we write and
> > > > > send the pre-announcement email.
> > > > 
> > > > Then why can it be days in between? If the tests get delayed/messed
> > > > up/have to be done over again, just pick up all the nominated patches
> > > > and go again.
> > > > 
> > > 
> > > I think that days is very infrequent, and due exceptionally reasons. Usually
> > > less than a day, and mainly due different time zones.
> > 
> > Examples of issues that can delay CI confirmation of the stable branch:
> > 
> >  - Regressions detected in the proposed release, which need to be
> >    bisected, fixed, and retested.
> > 
> >  - Intel CI downtime.  This can be due to lab maintenance, or
> >    instability with systems.
> > 
> > In this release iteration, we encountered both of these issues.  The
> > first proposed 17.3.7 was broken, as was the first fix after bisect.
> > Resolving the issue was delayed because we upgraded CI to Linux 4.14 to
> > support Vulkan 1.1, and that kernel has a bug that impacted our results.
> > 
> 
> I think with some of the proposed changes, we can attribute for those,
> while keeping other teams happy.
> 


Right. I'm checking the nominated patches, as well as Greg's rejected one, to
propose to enqueue them in the final release (of course, after checking
everything works fine).


	J.A.

> -Emil
>