Ian Romanick <i...@freedesktop.org> writes: > 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.
4 weeks is fine to me. It's not like having a stable branch is disruptive to development these days. I just want to make sure that once we're working on making a release, we're getting a tarball into distro's hands so they can start getting bug reports in to us. > A 1 week cadence for RCs would result in 4 RCs. That seems somewhat > excessive. Do you have a suggestion for RC pacing? Seems fine to me. If making an RC tarball takes more than half an hour (because a piglit run is like 20 minutes), that should get fixed (so this shouldn't be a big burden).
pgp30OsQhRAv4.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
