11:31 a.m.
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...
[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
11:50 a.m.
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
12:26 p.m.
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
1:45 p.m.
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
1:50 p.m.
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
3649
days inactive
3649
days old
4 comments
2 participants
participants (2)
-
Sandro Bonazzola -
Sven Kieske