On 04/07/2014 03:27 PM, Eric Anholt wrote: > Ian Romanick <i...@freedesktop.org> writes: > >> On 04/07/2014 09:14 AM, Eric Anholt wrote: >>> Ian Romanick <i...@freedesktop.org> writes: >>> >>>> On 04/04/2014 05:52 PM, Matt Turner wrote: >>>>> On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick <i...@freedesktop.org> wrote: >>>>>> Fast forwarding 3 months from the 10.1 release (March 4th, planned for >>>>>> February 28th) is May 30th. I'd like to propose the following set of >>>>>> dates: >>>>>> >>>>>> May 2nd: Feature freeze / 10.2 branch created. >>>>>> >>>>>> May 16th: RC1 >>>>> >>>>> Same comment as last time. It's not clear to me that we need a week >>>>> between the branch and RC1. We're not going to get users testing the >>>>> branch until there's an RC that distros can offer. >>>> >>>> The thinking behind having some gap is that a lot of people don't change >>>> from feature work to bug fixing until the branch is made. There are >>>> usually a bunch of bug fixes landed right after the branch is made... >>>> there's also often a bunch of... chaos right before the branch is made. >>>> Having an RC that doesn't build, has lot of known bugs, etc is useless. >>>> Having a time gap between features landing and making RC1 allows things >>>> to settle down a bit. >>>> >>>> I thought your complaint before was that a week wasn't long enough. >>>> That's why I bumped it to two weeks this time. I guess I must have >>>> misunderstood the concern. >>> >>> FWIW, I also don't see the point in having the branch but no RC. >> >> What's the point of having an RC is that is complete garbage? If you >> can explain that to me, I will do the work of creating it. Otherwise, >> I'll just skip the pointless busywork kthanks. > > Mesa master runs for me almost all the time, and I haven't experienced > Mesa master being any less likely to run right around the branchpoints. > So, I disagree with you saying that not delaying would produce a garbage > RC.
That doesn't match my experience doing the last 5+ Mesa releases, but we can try it and see. There's always a bunch of work that lands in the last week before the branch that introduce regressions in some drivers or build breaks for some other Mesa developers. I feel pretty strongly about have 4 weeks between the branch and the release. We generally don't even start looking at bugs until the branch, and less than a month means that difficult bugs are unlikely to get resolved. The extra day or two of lag in the review -> master -> stable-branch progression is also a factor. On 10.1 we had a number of fairly important fixes that just missed the release. A 1 week cadence for RCs would result in 4 RCs. That seems somewhat excessive. Do you have a suggestion for RC pacing?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
