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
> <jasua...@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
> > > <jasua...@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.
> > 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).
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.
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.
Thanks!
J.A.
> -ilia
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
