[Mesa-dev] Mesa 10.2 release plan strawman

[Eric Anholt]

Ian Romanick <idr at freedesktop.org> writes:

> On 04/07/2014 03:27 PM, Eric Anholt wrote:
>> Ian Romanick <idr at freedesktop.org> writes:
>> 
>>> 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.
>> 
>> 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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140411/6514faf3/attachment.sig>