On 08/21/2012 03:01 PM, Livnat Peer wrote:
On 21/08/12 15:31, Mike Burns wrote:
> On Tue, 2012-08-21 at 00:30 +0300, Itamar Heim wrote:
>> in general, I think it should be a 3-month version (we said we wanted to
>> move to 6 months cycle after the first few versions. I think we should
>> stay on 3 months especially since 3.1 took longer to get the final
>> blockers out and until released).
> I think I agree on the shorter time-table for 3.2. I also think we
> should get a list of features and commit to it and track against it on
> the weekly call. The 3-month schedule would put us in mid-November to
> early-December which I think is reasonable.
My only concern committing to a 3 month cycle for this release is that
all we would have time for are bug fixes. Especially with work on RHEV
3.1 happening in parallel.
I agree we should keep the short cycles, so many things changed and
many fixes were pushed, I see no reason to hold the next release for
longer than 3 month + some blockers delay.
How long was 3.1 in feature freeze? Are there newer features or
developments that were done on a devel branch while it was in stabilisation?
I'd prefer not to see us plan for delays! If they happen, so be it, but
we should be able to identify most of the blockers early enough to avoid
schedule skips, I hope.
I am not sure we must have new features in each release, a release
bug fixes seems also reasonable to me. Why not keep it only time-based
release regardless of commitments for new features for the release.
I like giving people good reasons to upgrade, but also good reasons to
install the current version - and in terms of communication, if we say
that 3.2 will be "3.1, with lots of bug fixes", and that it will be
along in 3 months, why would anyone install 3.1? We've just said it's a
buggy release that will soon be obsoleted anyway.
IMHO, it's better to say "here's what 3.1 does well, here's what 3.2
will be able to do that 3.1 doesn't". I'm not suggesting a revolution
with every release, but one thing which is identifiable as "new in 3.2"
doesn't seem like a lot to ask.
That said, I have previously worked on a project, where we had one full
release cycle whose goal was "make it work better on Linux", and it was
a very positive release cycle, lots of new contributors and energy,
because it was a goal people cared about. So purely bug-fix &
stabilisation releases can work, if you have a measurable goal to
We can ask what new features are planned/expected to be pushed in
near future, if we get reply with a lot of features then we can call it
major version (4.0) if we get only minor features we can use a minor
version (3.2, 3.3, etc).
I don't care about major/minor versions - I have been in far too many
discussions in both GNOME and GIMP on whether a release is "worth" a new
major version. Personally, I have a view which is much like that of
Queen Victoria towards bathing: I'm happy with incrementing the major
version every year or two, whether it's needed or not.
Community Action and Impact
Open Source and Standards Team, Red Hat
Phone: +33 9 50 71 55 62