On Fri, 2018-03-16 at 17:39 +0000, Emil Velikov wrote:
> 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.
>
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
>
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
