Re: [openstack-dev] [Fuel] Separate code freeze for repos
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 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 > 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" > 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 > >> 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 : > > 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 > wrote: > > Evgeniy, > > > > That means that the stable branch can be created for some repos >
Re: [openstack-dev] [Fuel] Separate code freeze for repos
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 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" 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 >> 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 : 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 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 : >> >> 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 >> 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
Re: [openstack-dev] [Fuel] Separate code freeze for repos
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" 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 > 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 : >> >>> 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 >>> 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 : >>> >> >>> >> 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 >>> >> 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-bi
Re: [openstack-dev] [Fuel] Separate code freeze for repos
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 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 : > >> 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 >> 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 : >> >> >> >> 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 >> >> 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
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 : > 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 > 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 : > >> > >> 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 > >> 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
Re: [openstack-dev] [Fuel] Separate code freeze for repos
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 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 : >> >> 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 >> 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
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 : > 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 > 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
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 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
[openstack-dev] [Fuel] Separate code freeze for repos
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
