Hi, 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 so 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 of 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 compare against.
We can ask what new features are planned/expected to be pushed in the 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. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62