On Mon, Jun 18, 2018 at 12:56 PM, Dylan Baker <dy...@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 <dy...@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. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev