On 16 March 2018 at 16:56, Mark Janes <[email protected]> wrote: > "Juan A. Suarez Romero" <[email protected]> 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 >>> <[email protected]> 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 >>> > > <[email protected]> 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 >>> > > > > <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
