[Mesa-dev] Mesa 10.2 release plan strawman

[Ian Romanick]

On 04/07/2014 11:47 AM, Ian Romanick wrote:
> On 04/07/2014 09:14 AM, Eric Anholt wrote:
>> Ian Romanick <idr at freedesktop.org> writes:
>>
>>> On 04/04/2014 05:52 PM, Matt Turner wrote:
>>>> On Fri, Apr 4, 2014 at 5:18 PM, Ian Romanick <idr at 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?