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
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 fu
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 d
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 followin
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
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 Kramskik
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 stab
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,
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,
Sof
