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

[Stuart Young]

Whichever way this goes, is it possible to have the pre-announce include a
link to the git repo/branch in question?

This way, even if it's not part of the main repo, people can easily find it
and check out the pre-release in full.

FWIW: An advantage of not requiring it to be in the main repo is that if
for whatever reason the main repo isn't available on the day (eg: outage,
major re-org, gitlab down for a few hours, network issues, etc), it can be
uploaded elsewhere and people can still proceed to check things out till
the main repo is available again.

Personally I think it makes sense to be in the main repo where possible,
but allowing for the possibility of it not being there in certain
circumstances, by explicitly linking to it in the pre-release so it's
unambiguous. Of course, it should be in the main repo for final release.


On Wed, 20 Jun 2018 at 03:23, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> 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.
>
>   -ilia
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


-- 
Stuart Young (aka Cefiar)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180620/1cfa76e5/attachment.html>