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

Fri Mar 16 16:56:52 UTC 2018

"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.

> If we detect issues in the branch under testing, and we need to prepare a new
> one, usually I include all the new stable patches that arrived as part of the
> new queue to test. So we try to test all the nominated patches.
>
> Of course, if a new patch arrives after the testing started, and the test
> success, we just send the announcement, putting the patch as Nominated in the
> email. Because we don't want to start again, as it always arrives patches, and
> we want to avoid delaying the release.
>
>
>> > > > And finally, that is the reason why there is a couple of days between the pre-
>> > > > announcement and the final announcement: for people to do more tests with
>> > > > different configurations, and propose inclusions/removals.
>> > > 
>> > > What are the criteria for such inclusions? (Why do the nominated
>> > > patches not meet them?) IME such requests for inclusion are met with
>> > > "next release" replies (or "never").
>> > > 
>> > 
>> > I think this depends on the authors, and how critical/urgent are those patches
>> > that they can't wait for the next release (which happens every 2 weeks).
>> 
>> Except when it doesn't.
>> 
>> > By default, nominated patches are queued for next release. If the release is the
>> > last one, then it is never (bear in mind that as said in a different email,
>> > 17.3.7, is not the last one, and we need to update the calendar).
>> > 
>> > Exceptionally, people can request to include the nominated patch in the final
>> > release if the problem it fixes is critical/urgent, that can't wait for the next
>> > release. Likewise, if it is the last release I think it is fine for people to
>> > request a new release more to include those changes.
>> 
>> I'm sure everyone thinks that their patches are fairly urgent. They
>> fix issues for users, and developers are the ones who end up doing a
>> lot of user support. Having things fixed leads to less headaches for
>> developers. Of course it's doubtful that millions of people would die
>> due to any particular patch not being in, so "urgent" is all relative.
>> 
>> > All in all, I appreciate a lot your comments for improving the release process.
>> > Actually there is a thread about this improvement. Pretty sure you can add also
>> > comments there.
>> 
>> I'm sure you've seen my comments in those threads. I see too much
>> decision power in the hands of the people doing releases, and not
>> enough in the hands of the developers who know the code, write the
>> patches, and support the users.
>> 
>
>
> In my case, I totally rely on people nominating patches, and hence I include all
> the patches I can that has been nominated for stable. I only left out those that
>  don't apply and it is difficult for me to solve the conflicts, or those that
> produce regressions. And well, those that arrive in the very last minute, after
> starting the testing of the candidates, to try to stick as much as possible to
> the release calendar. And in all those cases, authors are notified about these
> issues, so they can help to solve them in the final release.
>
> In the case of the patches Alex mentioned, I just clarified what Nominated
> means; he is fine with adding them in the next 17.3.8 release, so nothing else
> to do in this case.
>
>
>> As you may be aware, my solution to this problem has been to stop
>> worrying about stable releases and tell users to use HEAD if they want
>> any support. But others may not be able to make use of such a
>> solution. And frankly, I'd like to be able to tell users that stable
>> releases include the fixes they need.
>> 
>>   -ilia
>> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev