Re: Shift 3.7.0 or 3.7.X releases - was: ANNOUNCE: Release plan updated - two weeks between RCs

Bjoern Michaelsen píše v Čt 30. 08. 2012 v 17:41 +0200:
> On Thu, Aug 30, 2012 at 05:14:02PM +0200, Petr Mladek wrote:
> > As mentioned, the 3.7.0 release and 3.7.1-rc1 are planed for the same
> > week now. It is bad because there is no time to proceed feedback from
> > 3.7.0 users.
>
> Comparing:
>
>  https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
>  http://wiki.documentfoundation.org/ReleasePlan/3.7
>
> I find currently:
>
> - the 3.7.0 is already too late for a Alpha1/FeatureFreeze

Well, the LO feature freeze is already for beta1 in December. The hard
code freeze is three weeks before the .0 release. I guess that 3.6.0-rc2
would be fine for Ubuntu alpha1.

> - the 3.7.1 is already currently is ok for the BetaFreeze (LibreOffice is seeded)
> - the 3.7.2 release is fitting in just before Final Freeze

I see. OK, we can't move it later.

> - the 3.7.3 release is already a SRU (stable release update)


> > Possible solutions:
> >
> > 1. Make 3.7.0 two weeks earlier. I am not happy to change this so close
> >    to the feature freeze.

It might be possible. Let's discuss it on ESC call this week.

> > 2. Make 3.7.X bugfix releases 1 or 2 weeks later. It might cause
> >    troubles for Ubuntu, Fedora, and other distros who planed to use .3
> >    bugfix release in their distro releases.
> >
> >    Well, they might use 3.7.3-rc1 or 3.7.2. They should be pretty good
> >    as well. The number of weeks for bugfixing stays the same.
>
> 3.x.3 is already too late for us currently -- however, pushing back two weeks
> would make 3.7.2 miss final freeze. In that case I would have to seriously
> consider to not ship that series at all -- shipping with a 3.7.1 is very likely
> too early.

This is no way. We do not want to break your release.


> > 3. Remove 3.7.0-rc3 or some beta. It would mean to do the hard code
> >    freeze 1 or two weeks earlier => less time for testing and fixing
>
> Personally, that sounds like the best option for me for 3.7.

I am not much happy with it because it could cause worse quality of .0
release.


> > 4. Do 3.7.0-RCs every week (use the original schedule). There is not
> >    enough time for feedback => demotivating for QA.

After all, this is still good solution. We released, 3.5 and 3.6 this
way and it somehow worked. The .0 release is always hectic and we get
many fixes every week, so the two weeks delay between rc2 and rc3 would
be too long.

If ESC rejects moving the whole release two weeks earlier, I would go
with tho 4th solution and do builds every week for 3.7.0 and 3.7.1
releases. Of course, I would shift the whole release in the future.

Thanks for feedback.


Best Regards,
Petr