Re: [openstack-dev] [Fuel] Separate code freeze for repos

2014-11-26 Thread Aleksandra Fedorova
Mike,

from DevOps point of view it doesn't really matter when we do
branching. This is the process we need to perform anyway and this
partial branching doesn't change too much for us.
Although there might be several technical questions like:

 1) When we create /6.1 mirror?
 2) Should we create fuel-main repo branch before others or should we
pass config.mk variables from Jenkins side?

But it can be done one way or the other.

The primary concern here is not the build process and its
implementation, but the question how we are going to test the early
patches.

Right now we have unit tests and general nightly tests which are
analyzed and managed by QA team. The fact that we can create set of
6.1 system test jobs earlier in the process and even run them daily
doesn't mean that there will be people to watch them and analyze their
results. If we do early 6.1-branching while QA team is focused on 6.0
release, who will be dealing with this additional workload?

And if those 6.1 nightly system tests aren't checked properly, we get
code merged to fuel-web for several weeks based on unit-tests only,
which is generally a bad idea. Especially with current state of
fuel-web repository with several projects in one.


On Mon, Nov 24, 2014 at 3:01 AM, Dmitry Borodaenko
dborodae...@mirantis.com wrote:
 1. We discussed splitting fuel-web, I think we should do that before
 relaxing code freeze rules for it.

 2. If there are high or critical priority bugs in a component during soft
 code freeze, all developers of that component should be writing, reviewing,
 or testing fixes for these bugs.

 3. If we do separate code freeze for current components, we should always
 start with fuel-main, so that we can switch repos from master to stable one
 at a time.

 On Nov 17, 2014 4:08 AM, Mike Scherbakov mscherba...@mirantis.com wrote:

 I believe that we need to do this, and agree with Vitaly.

 Basically, when we are getting low amount of review requests, it's easy
 enough to do backports to stable branch. So criteria should be based on
 this, and I believe it can be even more soft, than what Vitaly suggests.

 I suggest the following:
 ___
 If no more than 3 new High / Critical priority bugs appeared in the passed
 day, and no more than 10 High/Critical over the past 3 days appeared - then
 stable branch can be created. ___

 HCF criteria remain the same. We will just have stable branch earlier. It
 might be a bit of headache for our DevOps team: it means that

 6.1 ISO should appear immediately after first stable branch created (we
 need ISO and all set of tests working on master)
 6.0 ISO has to be build on master branches from some repos, but stable/6.0
 from other. Likely it means whether switching to stable/6.0 in fuel-main and
 hacking config.mk, or something else.

 DevOps team, what do you think?


 On Fri, Nov 14, 2014 at 5:24 PM, Vitaly Kramskikh
 vkramsk...@mirantis.com wrote:

 There is a proposal to consider a repo as stable if there are no
 high/critical bugs and there were no such new bugs with this priority for
 the last 3 days. I'm ok with it.

 2014-11-14 17:16 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:

 Guys,

 The idea of separate unfreezing is cool itself, but we have to define
 some rules how to define that fuel-web is stable. I mean, in fuel-web
 we have different projects, so when Fuel UI is stable, the
 fuel_upgrade or Nailgun may be not.

 - Igor

 On Fri, Nov 14, 2014 at 3:52 PM, Vitaly Kramskikh
 vkramsk...@mirantis.com wrote:
  Evgeniy,
 
  That means that the stable branch can be created for some repos
  earlier. For
  example, fuel-web repo seems not to have critical issues for now and
  I'd
  like master branch of that repo to be opened for merging various stuff
  which
  shouldn't go to 6.0 and do not wait until all other repos stabilize.
 
  2014-11-14 16:42 GMT+03:00 Evgeniy L e...@mirantis.com:
 
  Hi,
 
   There was an idea to make a separate code freeze for repos
 
  Could you please clarify what do you mean?
 
  I think we should have a way to merge patches for the next
  release event if it's code freeze for the current.
 
  Thanks,
 
  On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
 
  Folks,
 
  There was an idea to make a separate code freeze for repos, but we
  decided not to do it. Do we plan to try it this time? It is really
  painful
  to maintain multi-level tree of dependent review requests and wait
  for a few
  weeks until we can merge new stuff in master.
 
  --
  Vitaly Kramskikh,
  Software Engineer,
  Mirantis, Inc.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  --
  Vitaly Kramskikh,
  Software 

Re: [openstack-dev] [Fuel] Separate code freeze for repos

2014-11-26 Thread Mike Scherbakov
I envision it in the following way:

   1. stable/6.0 is created for fuel-main along with stable branch for
   other repo, which is under consideration, like fuel-web
   2. In stable/6.0 of fuel-main, config.mk should be changed to refer to
   stable/6.0 for one of the repos, like fuel-web. master branch is still used
   for all other repos
   3. All our jobs (Fuel CI, system tests, etc.) are forked, like we do at
   HCF. One set should point to stable/6.0, another to master of fuel-main.
   4. Mirror has to be created for 6.1 immediately too, as we are opening
   master for fuel-main
   5. System tests should be analyzed for regression by QA or Dev team.
   6. As other repos start satisfying criteria, we can simply change branch
   name in config.mk

 should we pass config.mk variables from Jenkins side
I do not think we should change job configs. Let's do changes only in
source code, otherwise we will end up with having two places for
configuration.

This is pretty massive change, and it will require testing of
infrastructure for possible fork in advance, and creating a separate
checklists for it.

On Wed, Nov 26, 2014 at 3:31 PM, Aleksandra Fedorova afedor...@mirantis.com
 wrote:

 Mike,

 from DevOps point of view it doesn't really matter when we do
 branching. This is the process we need to perform anyway and this
 partial branching doesn't change too much for us.
 Although there might be several technical questions like:

  1) When we create /6.1 mirror?
  2) Should we create fuel-main repo branch before others or should we
 pass config.mk variables from Jenkins side?

 But it can be done one way or the other.

 The primary concern here is not the build process and its
 implementation, but the question how we are going to test the early
 patches.

 Right now we have unit tests and general nightly tests which are
 analyzed and managed by QA team. The fact that we can create set of
 6.1 system test jobs earlier in the process and even run them daily
 doesn't mean that there will be people to watch them and analyze their
 results. If we do early 6.1-branching while QA team is focused on 6.0
 release, who will be dealing with this additional workload?

 And if those 6.1 nightly system tests aren't checked properly, we get
 code merged to fuel-web for several weeks based on unit-tests only,
 which is generally a bad idea. Especially with current state of
 fuel-web repository with several projects in one.


 On Mon, Nov 24, 2014 at 3:01 AM, Dmitry Borodaenko
 dborodae...@mirantis.com wrote:
  1. We discussed splitting fuel-web, I think we should do that before
  relaxing code freeze rules for it.
 
  2. If there are high or critical priority bugs in a component during soft
  code freeze, all developers of that component should be writing,
 reviewing,
  or testing fixes for these bugs.
 
  3. If we do separate code freeze for current components, we should always
  start with fuel-main, so that we can switch repos from master to stable
 one
  at a time.
 
  On Nov 17, 2014 4:08 AM, Mike Scherbakov mscherba...@mirantis.com
 wrote:
 
  I believe that we need to do this, and agree with Vitaly.
 
  Basically, when we are getting low amount of review requests, it's easy
  enough to do backports to stable branch. So criteria should be based on
  this, and I believe it can be even more soft, than what Vitaly suggests.
 
  I suggest the following:
  ___
  If no more than 3 new High / Critical priority bugs appeared in the
 passed
  day, and no more than 10 High/Critical over the past 3 days appeared -
 then
  stable branch can be created. ___
 
  HCF criteria remain the same. We will just have stable branch earlier.
 It
  might be a bit of headache for our DevOps team: it means that
 
  6.1 ISO should appear immediately after first stable branch created (we
  need ISO and all set of tests working on master)
  6.0 ISO has to be build on master branches from some repos, but
 stable/6.0
  from other. Likely it means whether switching to stable/6.0 in
 fuel-main and
  hacking config.mk, or something else.
 
  DevOps team, what do you think?
 
 
  On Fri, Nov 14, 2014 at 5:24 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
 
  There is a proposal to consider a repo as stable if there are no
  high/critical bugs and there were no such new bugs with this priority
 for
  the last 3 days. I'm ok with it.
 
  2014-11-14 17:16 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:
 
  Guys,
 
  The idea of separate unfreezing is cool itself, but we have to define
  some rules how to define that fuel-web is stable. I mean, in fuel-web
  we have different projects, so when Fuel UI is stable, the
  fuel_upgrade or Nailgun may be not.
 
  - Igor
 
  On Fri, Nov 14, 2014 at 3:52 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
   Evgeniy,
  
   That means that the stable branch can be created for some repos
   earlier. For
   example, fuel-web repo seems not to have critical issues for now and
   I'd
   like master branch of 

Re: [openstack-dev] [Fuel] Separate code freeze for repos

2014-11-23 Thread Dmitry Borodaenko
1. We discussed splitting fuel-web, I think we should do that before
relaxing code freeze rules for it.

2. If there are high or critical priority bugs in a component during soft
code freeze, all developers of that component should be writing, reviewing,
or testing fixes for these bugs.

3. If we do separate code freeze for current components, we should always
start with fuel-main, so that we can switch repos from master to stable one
at a time.
On Nov 17, 2014 4:08 AM, Mike Scherbakov mscherba...@mirantis.com wrote:

 I believe that we need to do this, and agree with Vitaly.

 Basically, when we are getting low amount of review requests, it's easy
 enough to do backports to stable branch. So criteria should be based on
 this, and I believe it can be even more soft, than what Vitaly suggests.

 I suggest the following:
 ___
 If no more than 3 new High / Critical priority bugs appeared in the passed
 day, and no more than 10 High/Critical over the past 3 days appeared - then
 stable branch can be created. ___

 HCF criteria remain the same. We will just have stable branch earlier. It
 might be a bit of headache for our DevOps team: it means that

- 6.1 ISO should appear immediately after first stable branch created
(we need ISO and all set of tests working on master)
- 6.0 ISO has to be build on master branches from some repos, but
stable/6.0 from other. Likely it means whether switching to stable/6.0 in
fuel-main and hacking config.mk, or something else.

 DevOps team, what do you think?


 On Fri, Nov 14, 2014 at 5:24 PM, Vitaly Kramskikh vkramsk...@mirantis.com
  wrote:

 There is a proposal to consider a repo as stable if there are no
 high/critical bugs and there were no such new bugs with this priority for
 the last 3 days. I'm ok with it.

 2014-11-14 17:16 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:

 Guys,

 The idea of separate unfreezing is cool itself, but we have to define
 some rules how to define that fuel-web is stable. I mean, in fuel-web
 we have different projects, so when Fuel UI is stable, the
 fuel_upgrade or Nailgun may be not.

 - Igor

 On Fri, Nov 14, 2014 at 3:52 PM, Vitaly Kramskikh
 vkramsk...@mirantis.com wrote:
  Evgeniy,
 
  That means that the stable branch can be created for some repos
 earlier. For
  example, fuel-web repo seems not to have critical issues for now and
 I'd
  like master branch of that repo to be opened for merging various stuff
 which
  shouldn't go to 6.0 and do not wait until all other repos stabilize.
 
  2014-11-14 16:42 GMT+03:00 Evgeniy L e...@mirantis.com:
 
  Hi,
 
   There was an idea to make a separate code freeze for repos
 
  Could you please clarify what do you mean?
 
  I think we should have a way to merge patches for the next
  release event if it's code freeze for the current.
 
  Thanks,
 
  On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
 
  Folks,
 
  There was an idea to make a separate code freeze for repos, but we
  decided not to do it. Do we plan to try it this time? It is really
 painful
  to maintain multi-level tree of dependent review requests and wait
 for a few
  weeks until we can merge new stuff in master.
 
  --
  Vitaly Kramskikh,
  Software Engineer,
  Mirantis, Inc.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  --
  Vitaly Kramskikh,
  Software Engineer,
  Mirantis, Inc.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Vitaly Kramskikh,
 Software Engineer,
 Mirantis, Inc.

 ___
 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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Separate code freeze for repos

2014-11-17 Thread Mike Scherbakov
I believe that we need to do this, and agree with Vitaly.

Basically, when we are getting low amount of review requests, it's easy
enough to do backports to stable branch. So criteria should be based on
this, and I believe it can be even more soft, than what Vitaly suggests.

I suggest the following:
___
If no more than 3 new High / Critical priority bugs appeared in the passed
day, and no more than 10 High/Critical over the past 3 days appeared - then
stable branch can be created. ___

HCF criteria remain the same. We will just have stable branch earlier. It
might be a bit of headache for our DevOps team: it means that

   - 6.1 ISO should appear immediately after first stable branch created
   (we need ISO and all set of tests working on master)
   - 6.0 ISO has to be build on master branches from some repos, but
   stable/6.0 from other. Likely it means whether switching to stable/6.0 in
   fuel-main and hacking config.mk, or something else.

DevOps team, what do you think?


On Fri, Nov 14, 2014 at 5:24 PM, Vitaly Kramskikh vkramsk...@mirantis.com
wrote:

 There is a proposal to consider a repo as stable if there are no
 high/critical bugs and there were no such new bugs with this priority for
 the last 3 days. I'm ok with it.

 2014-11-14 17:16 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:

 Guys,

 The idea of separate unfreezing is cool itself, but we have to define
 some rules how to define that fuel-web is stable. I mean, in fuel-web
 we have different projects, so when Fuel UI is stable, the
 fuel_upgrade or Nailgun may be not.

 - Igor

 On Fri, Nov 14, 2014 at 3:52 PM, Vitaly Kramskikh
 vkramsk...@mirantis.com wrote:
  Evgeniy,
 
  That means that the stable branch can be created for some repos
 earlier. For
  example, fuel-web repo seems not to have critical issues for now and I'd
  like master branch of that repo to be opened for merging various stuff
 which
  shouldn't go to 6.0 and do not wait until all other repos stabilize.
 
  2014-11-14 16:42 GMT+03:00 Evgeniy L e...@mirantis.com:
 
  Hi,
 
   There was an idea to make a separate code freeze for repos
 
  Could you please clarify what do you mean?
 
  I think we should have a way to merge patches for the next
  release event if it's code freeze for the current.
 
  Thanks,
 
  On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
 
  Folks,
 
  There was an idea to make a separate code freeze for repos, but we
  decided not to do it. Do we plan to try it this time? It is really
 painful
  to maintain multi-level tree of dependent review requests and wait
 for a few
  weeks until we can merge new stuff in master.
 
  --
  Vitaly Kramskikh,
  Software Engineer,
  Mirantis, Inc.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  --
  Vitaly Kramskikh,
  Software Engineer,
  Mirantis, Inc.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Vitaly Kramskikh,
 Software Engineer,
 Mirantis, Inc.

 ___
 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


Re: [openstack-dev] [Fuel] Separate code freeze for repos

2014-11-14 Thread Evgeniy L
Hi,

 There was an idea to make a separate code freeze for repos

Could you please clarify what do you mean?

I think we should have a way to merge patches for the next
release event if it's code freeze for the current.

Thanks,

On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh vkramsk...@mirantis.com
wrote:

 Folks,

 There was an idea to make a separate code freeze for repos, but we decided
 not to do it. Do we plan to try it this time? It is really painful to
 maintain multi-level tree of dependent review requests and wait for a few
 weeks until we can merge new stuff in master.

 --
 Vitaly Kramskikh,
 Software Engineer,
 Mirantis, Inc.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Separate code freeze for repos

2014-11-14 Thread Vitaly Kramskikh
Evgeniy,

That means that the stable branch can be created for some repos earlier.
For example, fuel-web repo seems not to have critical issues for now and
I'd like master branch of that repo to be opened for merging various stuff
which shouldn't go to 6.0 and do not wait until all other repos stabilize.

2014-11-14 16:42 GMT+03:00 Evgeniy L e...@mirantis.com:

 Hi,

  There was an idea to make a separate code freeze for repos

 Could you please clarify what do you mean?

 I think we should have a way to merge patches for the next
 release event if it's code freeze for the current.

 Thanks,

 On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh vkramsk...@mirantis.com
  wrote:

 Folks,

 There was an idea to make a separate code freeze for repos, but we
 decided not to do it. Do we plan to try it this time? It is really painful
 to maintain multi-level tree of dependent review requests and wait for a
 few weeks until we can merge new stuff in master.

 --
 Vitaly Kramskikh,
 Software Engineer,
 Mirantis, Inc.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Separate code freeze for repos

2014-11-14 Thread Igor Kalnitsky
Guys,

The idea of separate unfreezing is cool itself, but we have to define
some rules how to define that fuel-web is stable. I mean, in fuel-web
we have different projects, so when Fuel UI is stable, the
fuel_upgrade or Nailgun may be not.

- Igor

On Fri, Nov 14, 2014 at 3:52 PM, Vitaly Kramskikh
vkramsk...@mirantis.com wrote:
 Evgeniy,

 That means that the stable branch can be created for some repos earlier. For
 example, fuel-web repo seems not to have critical issues for now and I'd
 like master branch of that repo to be opened for merging various stuff which
 shouldn't go to 6.0 and do not wait until all other repos stabilize.

 2014-11-14 16:42 GMT+03:00 Evgeniy L e...@mirantis.com:

 Hi,

  There was an idea to make a separate code freeze for repos

 Could you please clarify what do you mean?

 I think we should have a way to merge patches for the next
 release event if it's code freeze for the current.

 Thanks,

 On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh
 vkramsk...@mirantis.com wrote:

 Folks,

 There was an idea to make a separate code freeze for repos, but we
 decided not to do it. Do we plan to try it this time? It is really painful
 to maintain multi-level tree of dependent review requests and wait for a few
 weeks until we can merge new stuff in master.

 --
 Vitaly Kramskikh,
 Software Engineer,
 Mirantis, Inc.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Vitaly Kramskikh,
 Software Engineer,
 Mirantis, Inc.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel] Separate code freeze for repos

2014-11-14 Thread Vitaly Kramskikh
There is a proposal to consider a repo as stable if there are no
high/critical bugs and there were no such new bugs with this priority for
the last 3 days. I'm ok with it.

2014-11-14 17:16 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:

 Guys,

 The idea of separate unfreezing is cool itself, but we have to define
 some rules how to define that fuel-web is stable. I mean, in fuel-web
 we have different projects, so when Fuel UI is stable, the
 fuel_upgrade or Nailgun may be not.

 - Igor

 On Fri, Nov 14, 2014 at 3:52 PM, Vitaly Kramskikh
 vkramsk...@mirantis.com wrote:
  Evgeniy,
 
  That means that the stable branch can be created for some repos earlier.
 For
  example, fuel-web repo seems not to have critical issues for now and I'd
  like master branch of that repo to be opened for merging various stuff
 which
  shouldn't go to 6.0 and do not wait until all other repos stabilize.
 
  2014-11-14 16:42 GMT+03:00 Evgeniy L e...@mirantis.com:
 
  Hi,
 
   There was an idea to make a separate code freeze for repos
 
  Could you please clarify what do you mean?
 
  I think we should have a way to merge patches for the next
  release event if it's code freeze for the current.
 
  Thanks,
 
  On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
 
  Folks,
 
  There was an idea to make a separate code freeze for repos, but we
  decided not to do it. Do we plan to try it this time? It is really
 painful
  to maintain multi-level tree of dependent review requests and wait for
 a few
  weeks until we can merge new stuff in master.
 
  --
  Vitaly Kramskikh,
  Software Engineer,
  Mirantis, Inc.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  --
  Vitaly Kramskikh,
  Software Engineer,
  Mirantis, Inc.
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev