fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

One little note: for now, the assumption is count bugs for SCF & HCF only
those which do not have tag "docs" basically excluding documentation.

We need to come out with the ideas on how to track those too. I think we
need to enforce docs bugs to be following same rules, and be counted too,
but I'm not sure if we should do it in this release, with 1 week before SCF.

Regarding devops bugs (with tag devops), I believe we can also apply same
principles: we should fix only critical issues in our infrastructure when
we are close to releasing. Otherwise, we can postpone solution to the next
release.


On Mon, Apr 21, 2014 at 5:07 PM, Mike Scherbakov
<mscherbakov@xxxxxxxxxxxx>wrote:

> 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
>



-- 
Mike Scherbakov
#mihgen