[Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Emil Velikov]

Hi Ilia,

On 6 March 2018 at 20:09, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Tue, Mar 6, 2018 at 2:34 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> So while others explore ways of improving the testing, let me propose
>> a few ideas for improving the actual releasing process.
>>
>>
>>  - Making the current state always visible - have a web page, git
>>    branch and other ways for people to see which patches are picked,
>>    require backports, etc.
>
> Yes please! A git branch that's available (and force-pushed freely)
> before the "you're screwed" announcement is going to help clear a lot
> of things up.
>
Agreed.

We do send an email before the "you're screwed" point, although we must
make it 100% consistent. In case of rejections being "too large" or
otherwise problematic (like the Mesa 17.3 + LLVM 6 thread) a broad
developer approval is needed.

Having exceptions are fine, but we should:
 - ensure they stay exceptions
 - ensure that developers are aware and on board with it

... which seems to align what you're suggesting below.

>>
>>  - Per team maintainer - each team has person (a few people) to check,
>>    coordinate and remind people for high priority bugs and backports.
>
> Yes! I think this role is highly necessary, but not for the reasons
> you outline here. My main issue thus far with the stable release
> process has been that I don't appear to have any control over what
> patches are included in a particular release. Reasons for rejection
> have varied from "well, there will be another release in 2+ weeks" to
> "this patch doesn't fit some arbitrary criterion".
>
There's a couple of things to consider:
 - Mesa releases are only checked on the Intel CI, officially at least

 - the above can some take time - be that regressions or in general
delays do occur

We use the Intel CI to test against CTS/Piglit/etc, and if something
serious comes up then we usually block the release until this is fixed.
One issue we're seeing with that is that interpreting the results can
require manual intervention.

 - subsystem only changes are kind of an exception to the above

> What I'd like to propose is a system where the team maintainer is able
> to request any particular patch to be included in a stable release (as
> long as it's done by a certain pre-announced deadline, which happens
> *after* the initial release nominations email). If a release manager
> disagrees, they can make that disagreement known, but it's ultimately
> up to the team maintainer for driver code. If it's in shared code
> (i.e. not driver-specific - winsys, core mesa, state trackers used by
> multiple drivers), the override would be 1 additional team maintainer
> acking, and conversely any team maintainer would be able to nak it (so
> the condition in case of disagreement would be at least 2 team
> maintainers in favor, and 0 against).
>

Makes perfect sense. Small suggestion - since we want to have a broad
consensus and awareness, it makes sense to have 50% of the maintainers
on board.

> As you may know, I've stopped tagging things for stable since a while
> back since it seems completely pointless - nothing I can do to
> actually cause a patch to be included in a release. Telling people to
> just use HEAD seems way more reliable. I'm not particularly happy with
> this arrangement, but it's at least supportable.
>
Agreed - things did not go perfectly all the time. By refining the
process we can resolve that.

I do see and share your frustration. My end is when distros are stuck
with a fairly old stable release without a clear documentation why.

> Hopefully others here agree with me. Otherwise I'll just go back to
> doing what I'm doing (and perhaps my contribution level has dropped
> sufficiently to not worry about it).
>
You've put very good points and I can see them happening. Modulo broad
consensus of course.

Meaning:

People who has shared their feedback - thank you!

Everyone else -  please let us know what you think! If you see a way the above
suggestions can be improved, or alternative routes we should explore do
bring them forward.

Thanks
Emil