Andrew,
thanks for pointing this out. Engineering in Europe has code review in
priority #1 after fixing critical issues which block us from further
testing.
Overall, I think it should be simple. If developer didn't push the crowd to
review the patch linked to Low/Medium bug, and it didn't get merged by SCF
- then it should be moved to next milestone. SCF by its definition means
that code has to be in master for Low / Medium bugs, not on review.
Considering the fact that we have so many patches on review, I can propose
the following:
1. Actively ping each other to get those reviewed and merged
2. We can do an exception for those which have at least one +1 from some
developer, but were not addressed by core developer. In this case we can
allow the core developer to review and merge such patches by the end of the
week.
What we are trying to achieve is to limit the code flow into the master, so
avoiding possible regressions which could be introduced by Low/Medium bug
fixes.
Would it work?
Thanks,
On Tue, Jul 22, 2014 at 9:03 PM, Andrew Woodward xar...@gmail.com wrote:
Mike,
I don't think we should SCF until the review queue is addressed, there are
far to many outstanding reviews presently. I'm not saying the queue has to
be flushed and revised (although we should give this time given the size of
the outstanding queue) , but all patches should be reviewed, and merged, or
minused (addressed). They should not be penalized because they are not high
priority and no one has gotten around to reviewing them.
my though is: prior to SCF, the low and medium priority reviews must be
addressed, and the submitter should have one additional day to revise the
patch prior to their code being barred from the release. We could address
this by having a review deadline the day prior to SCF, or watch excepted
intently for revision the day after SCF.
On Tue, Jul 22, 2014 at 8:08 AM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Hi Fuelers,
Looks like we are more or less good to call for a Soft Code Freeze [1] on
Thursday.
Then hard code freeze [2] will follow. It is planned to have no more than
2 weeks between SCF and HCF [3]. When hard code freeze is called, we create
stable/5.1 branch at the same time to accept only critical bug fixes, and
release will be produced out of this branch. At the same time master will
be re-opened for accepting new features and all types of bug fixes.
[1] https://wiki.openstack.org/wiki/Fuel/Soft_Code_Freeze
[2] https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze
[3] https://wiki.openstack.org/wiki/Fuel/5.1_Release_Schedule
Let me know if anything blocks us from doing SCF on 24th.
Thanks,
--
Mike Scherbakov
#mihgen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Andrew
Mirantis
Ceph community
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Mike Scherbakov
#mihgen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
