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 <mscherba...@mirantis.com>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
-- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp