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

[Emil Velikov]

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.

-Emil