[QE][ACTION REQUIRED] oVirt 3.6.0 status
Hi, Release criteria discussion started on 2014-10-22 and will end today 2014-11-26 as discussed in last oVirt sync meeting [1]. If no objections will be raised, the proposed changes [2] will be accepted. Release management for 3.6.0 has been created [3] The key milestones for this release must be scheduled: Key Milestones Release criteria discussion start: 2014-10-22 Release criteria ready: 2014-11-26 Feature freeze: 60 Days before release First Test Day: 45 days before release Release Candidate: 30 days before release Release: 6 months after oVirt 3.5.0 release External Project Schedules Fedora 21: 2014-12-09 Fedora 22: 2015-XX-XX GlusterFS 3.7: 2015-04-29 OpenStack Kilo: 2015-04-30 Two different proposals have been made about above scheduling [4]: 1) extend the cycle to 10 months for allowing to include a large feature set 2) reduce the cycle to less than 6 months and split features over 3.6 and 3.7 Feature proposed for 3.6.0 must now be collected in the 3.6 google doc [8] and reviewed by maintainers. A tracker bug for 3.6.0 has been created [5] and currently shows no blockers. There are 439 bugs [6] targeted to 3.6.0. Excluding node and documentation bugs we have 419 bugs [7] targeted to 3.6.0. [1] http://resources.ovirt.org/meetings/ovirt/2014/ovirt.2014-11-19-15.01.log.ht... [2] http://lists.ovirt.org/pipermail/devel/2014-September/008695.html [3] http://www.ovirt.org/OVirt_3.6_Release_Management [4] http://lists.ovirt.org/pipermail/users/2014-November/028875.html [5] https://bugzilla.redhat.com/show_bug.cgi?id=1155425 [6] http://goo.gl/zwkF3r [7] http://goo.gl/ZbUiMc [8] http://goo.gl/9X3G49 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 26/11/14 09:31, Sandro Bonazzola wrote:
If no objections will be raised, the proposed changes [2] will be accepted.
I fear I got an objection: quote:
* Alpha release should come after feature freeze Nothing more to say about it
I really think you are twisting the way what is commonly known as an "alpha": from wikipedia: "[..]The alpha phase usually **ends** with a feature freeze[..]" https://en.wikipedia.org/wiki/Alpha_software#Alpha emphasis added by me. you are doing it the wrong way: first release an alpha, than make a feature freeze. _After_ feature freeze you can release a beta. I really like this terminology and think it is commonly known and accepted and it works very well. thoughts? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Il 26/11/2014 09:50, Sven Kieske ha scritto:
On 26/11/14 09:31, Sandro Bonazzola wrote:
If no objections will be raised, the proposed changes [2] will be accepted.
I fear I got an objection:
quote:
* Alpha release should come after feature freeze Nothing more to say about it
I really think you are twisting the way what is commonly known as an "alpha":
from wikipedia: "[..]The alpha phase usually **ends** with a feature freeze[..]" https://en.wikipedia.org/wiki/Alpha_software#Alpha emphasis added by me.
you are doing it the wrong way: first release an alpha, than make a feature freeze. _After_ feature freeze you can release a beta.
"The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be **feature complete**." So if you mean alpha release requirements are: substantially complete and in a testable state enabled by default -- if so specified by the change And for feature freeze you mean: "no more changes in the feature because the feature is complete" I agree with you, feature freeze must be after alpha. what I was trying to describe with having feature freeze before alpha is that we must not have features included in the alpha release which are: - not substantially complete - not in a testable state such kind of features must not be in alpha release.
I really like this terminology and think it is commonly known and accepted and it works very well.
thoughts?
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
I'm not 100% sure if I understand your definitions: On 26/11/14 10:26, Sandro Bonazzola wrote:
"The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be **feature complete**."
So if you mean alpha release requirements are:
substantially complete and in a testable state enabled by default -- if so specified by the change
??? I define an alpha release as the following: features may get added or removed during alpha cycle, of course you can add your own policy about which features you accept.
And for feature freeze you mean: "no more changes in the feature because the feature is complete" I agree with you, feature freeze must be after alpha.
no. feature freeze means exactly that: no more new features are accepted, after feature freeze. after feature freeze the accepted features stabilize in the beta phase, you just fix bugs.
what I was trying to describe with having feature freeze before alpha is that we must not have features included in the alpha release which are: - not substantially complete - not in a testable state
you should not call this "feature freeze" as this is not what is commonly understood (imho) when you talk about feature freeze (see my explanation above). You might want to call this "feature acceptance criteria" or something like that, at least it would be more clear (to me) what you mean. HTH -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Il 26/11/2014 11:45, Sven Kieske ha scritto:
I'm not 100% sure if I understand your definitions:
On 26/11/14 10:26, Sandro Bonazzola wrote:
"The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be **feature complete**."
So if you mean alpha release requirements are:
substantially complete and in a testable state enabled by default -- if so specified by the change
???
I define an alpha release as the following: features may get added or removed during alpha cycle, of course you can add your own policy about which features you accept.
And for feature freeze you mean: "no more changes in the feature because the feature is complete" I agree with you, feature freeze must be after alpha.
no. feature freeze means exactly that:
no more new features are accepted, after feature freeze. after feature freeze the accepted features stabilize in the beta phase, you just fix bugs.
what I was trying to describe with having feature freeze before alpha is that we must not have features included in the alpha release which are: - not substantially complete - not in a testable state
you should not call this "feature freeze" as this is not what is commonly understood (imho) when you talk about feature freeze (see my explanation above).
You might want to call this "feature acceptance criteria" or something like that, at least it would be more clear (to me) what you mean.
make sense, well, since it's a milestone, maybe better something like "feature acceptance review"
HTH
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
participants (2)
-
Sandro Bonazzola -
Sven Kieske