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

Ilia Mirkin imirkin at alum.mit.edu
Tue Jun 19 17:20:19 UTC 2018

On Mon, Jun 18, 2018 at 12:56 PM, Dylan Baker <dylan at pnwbakers.com> wrote:
> Quoting Juan A. Suarez Romero (2018-06-18 00:22:02)
>> On Fri, 2018-06-15 at 12:47 -0400, Ilia Mirkin wrote:
>> > On Fri, Jun 15, 2018 at 12:36 PM, Dylan Baker <dylan at pnwbakers.com> wrote:
>> > > I don't even understand why we make these announcements TBH. I have a public
>> > > 18.1-proposed branch that I push to *every weekday*. Anyone can pull that branch
>> > > *anytime* to get the latest version. The only thing the announce email really
>> > > serves AFAICT, is to say "the staging/proposed branch has been merged to the
>> > > release branch". I don't think that's all that interesting TBH.
>> >
>> > "any time" means "no time". The announcement is "speak now or forever
>> > hold your peace". Gives driver teams a chance to review the list and
>> > test things out before they go out into a full release. Should they be
>> > doing this daily/continuously? Probably. But that's not the current
>> > state.
>> >
>> I agree on this. And I think the reason to wait 48h is to give time enough for
>> teams to do proper testing, specially when there are many timezones that people
>> get the pre-announcement several hours later.
>> But, I also think that the pre-announcement is too much verbose. It includes lot
>> of information that can be easily get from the git branch itself. The only thing
>> I would probably keep is about trivial conflicts, sending an explicit email to
>> the authors to say "I [slightly] changed your commit; please, take a look just
>> in case", and the rejected patch list, also mailing the authors.
> I follow up with authors about changes immediately. If it was rejected I reply
> to the original patch letting them know I'm not planning to pull the commit and
> why. If there's conflicts I ask the original author to look at the changes I've
> made before pulling them into the staging branch.

That's really helpful, thanks!

> It feels much too late to be
> asking someone to do that when the release is happening shortly.

In order for me to find it useful, the flow has to be:

1. Pre-announce saying which patches you're taking
2. Take feedback from driver maintainers regarding patches to remove or add
3. Do release (or go to 1 if the requested changes were substantial,
at your discretion)

I realize you're doing this as part of your job, and since I'm not
your employer, I have little say over how you actually do this ... my
options are whether I opt into the stable process or not. I've been
frustrated with the process for a long time - since the mid 10.x's, as
evidenced by my periodic outbursts on the matter, and I've largely
opted out since around 18.0 - it's not worth the heartache for me.
Which is fine - I just tell people to build from HEAD and all is well.
Perhaps I'm in a unique situation and can be ignored -- like I said,
I'm perfectly fine with the status quo of not caring about stable.
Basically no one uses nouveau anyways.


More information about the mesa-dev mailing list