On Fri, Mar 16, 2018 at 11:52 AM, Juan A. Suarez Romero <jasua...@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 >> <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.
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. >> > 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. 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
