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

[Ilia Mirkin]

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.

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