fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

Hi Fuelers,
I'd like to reiterate the discussion on definitions of soft code freeze &
hard code freeze for Fuel, to ensure the quality and that we all stay on
the same page.

Before I give definitions, you may want to look how it's being done for
OpenStack core projects:
https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
https://wiki.openstack.org/wiki/Release_Cycle#Release_candidate_1.

Fuel schedule for 5.0:
https://wiki.openstack.org/wiki/Fuel/5.0_Release_Schedule

So I'd like to suggest following definitions, which changed just a bit from
what we had in 4.1:
*Soft Code Freeze* - last day when we accept bugfixes into master with
priority < High. After this day, we merge only High & Critical priority bug
fixes. For exceptional bugs, we can increase priority and provide
explanation how risky it is in terms of breaking other features. Remained
Medium & Low priority bugs are moved to next release, some of them are
being documented as Known Issues.

*Hard Code Freeze* - last day when we accept fixes on High priority bugs.
When we reach hard code freeze, we should have 0 critical bugs and no more
than 5 high priority bugs open. If we have more high priority bugs, or even
one critical, we move hard code freeze unless the condition is met. When we
meet this condition, and hard code freeze is announced, then it is being
announced with information about stable branch created and Release
Candidate is created. It is the time when master opens for next release
changes, including features. Critical bugs, if found after this day, cause
the following procedure:

   - Fix is proposed to both master & stable/<rel-version> branch. It must
   be merged into master first, and core developers only approve patches into
   stable branch if corresponding patchset with same ChangeID was accepted
   into master
   - New RC is created

QA team starts final acceptance testing on RC. If new RC is created, we
respin acceptance cycle. Process is repeated unless we get a stable release
version. It is done in a similar way for
OpenStack.<https://wiki.openstack.org/wiki/Release_Cycle#Other_release_candidates>
There can be exception though, when we don't need to respin a cycle. It
happens, if change is considered to be local to very limited affection
area. PTL & core development leads decide whether it is the case.

You are very welcome to provide your thoughts on the process.
Thanks,
-- 
Mike Scherbakov
#mihgen