Open Stack

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 <xarses at 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 <mscherbakov at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Andrew
> Mirantis
> Ceph community
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/b5cb8cbc/attachment.html>