On 04/11/2014 10:07 AM, Eric Anholt wrote: > 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).
- Bump VERSION, make a tag, etc. - Make tarballs (slower than it should be because of Mesa build system). - Build & install from tarballs. - piglit, verify piglit results - Upload tarballs - Push tag and updated VERSION - Send announcement e-mail. The whole process is closer to a an hour per RC. The main step that could be optimized is 'make -j1 tarballs'. The whole process doesn't happen very often, so I haven't scripted any of it. I guess I will now... I suspect everything except the last two steps (and verify the piglit results) should be fire-and-forget.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
