On 04/07/2014 11:47 AM, Ian Romanick wrote: > 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.
The alternative, which has been rejected every time it has been proposed, is to "close" master for feature work for some amount of time before making the release branch. Since people are accustomed to pushing to master whenever patches are reviewed, and we have no mechanism to control that, this seems unlikely to succeed. This is also effectively what the release branch is, so it feels a bit like tomayto versus tomahto. Look at master for the last two weeks... for at least some users the build has been broken for a good portion of that time. Who does it help to have a release candidate of that? Either way... we previously loosely agreed to a month stabalization period for bug fixes between feature freeze and release. I don't really care how we accomplish that... as long as it will actually work. If you guys feel really strongly about having an RC the moment the branch is made, tell me how to make that successful. Taking the thing that was master 30 seconds previously is not that. What is your suggestion? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
