[Mesa-dev] Mesa 10.2 release plan strawman

[Ian Romanick]

On 04/11/2014 10:07 AM, Eric Anholt wrote:
> 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).

- 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140411/2057853e/attachment.sig>