Mike,
2 jobs for Icehouse and Juno equal 2 different repository with packages for
Fuel 6.0. This can be problem for current osci workflow.
For example: We need building new packages. Which repository we must put
packages? to icehouse or/and Juno ?
if new packages will break icehouse repository,
What would be your suggestions then on the issue? We want to avoid breaking
of our fuel-library and other code without knowing about it, so it's not an
option to simply forget about compatibility with Icehouse packages.
And I'm actually +1 for introducing Kilo CI jobs as soon as we can, so to
Roman,
In the workflow with 2 package repositories per 1 fuel branch set
(e.g. icehouse juno for 6.0, or juno kilo later in 6.0 release
cycle), we should aim to keep packages targeted for both repositories
as close as possible, so default mode of operation should be to put
new packages in both
+1 to DmitryB, I think in this particular time and case we should open
stable/5.1. But not to call it HCF [1].
Though I think we should retrospect our approaches here.
1. Sometimes we can squash 30 bugs a day, and formally reach HCF. Though
the day after we will get 30 New bugs from QA. We
Mike,
just to clarify - do we want consider this as an exception, which is
not going to be repeated next release? If not, we might want to
consider updating the statement It is the time when master opens for
next release changes, including features. in [1]. If I got you
correct, we are going to
Currently I think we should take it as an exception, and discuss two points
which I brought up. Obviously, if we open stable/5.1, then we are opening
master for new features.
We will modify HCF definition once we settle on final decision.
Thanks,
On Tue, Sep 9, 2014 at 1:02 PM, Igor Marnat
As I understand your proposal, we need to split our HCF milestone into two
check points: Branching Point and HCF itself.
Branching point should happen somewhere in between SCF and HCF. And though
It may coincide with HCF, it needs its own list of requirements. This will
give us the possibility to
Thanks Alexandra.
We land a few patches a day currently, so I think we can open stable
branch. If we see no serious objections in next 12 hours, let's do it. We
would need to immediately notify everyone in mailing list - that for every
patch for 5.1, it should go first to master, and then to
+1 on adding flow based criteria for HCF and Branching Point. Tracking
down how many bugs was reported in LP on a given day is a bit tricky,
so I think in both cases it would be easier to rely on flow of commits
(which after Soft Code Freeze becomes a direct indicator of how many
bugs are fixed
All OSCI action items for prepare HCF check list has been done
On Tue, Sep 9, 2014 at 6:27 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Thanks Alexandra.
We land a few patches a day currently, so I think we can open stable
branch. If we see no serious objections in next 12 hours,
What we need to achieve that is have 2 build series based on Fuel
master: one with Icehouse packages, and one with Juno, and, as Mike
proposed, keep our manifests backwards compatible with Icehouse.
Exactly. Our Fuel CI can do 4 builds against puppet modules: 2 voting, with
Icehouse packages; 2
Our Fuel CI can do 4 builds against puppet modules: 2 voting, with
Icehouse packages; 2 non-voting, with Juno packages.
Then, I'd suggest to create ISO with 2 releases (Icehouse, Juno) actually
before Juno becomes stable. We will be able to run 2 sets of BVTs (against
Icehouse and Juno), and it
Aleksandra,
you've got us exactly right. Fuel CI for OSTF can wait a bit longer, but 4
fuel-library tests should happen right after we create stable/5.1. Also,
for Fuel CI for OSTF - I don't think it's actually necessary to support
5.0 envs.
Your questions:
1. Create jobs for both Icehouse
A clarification on 2: we are going to keep fuel_5.1_* jobs around for
the benefict 5.1.x maintenance releases, that should take care of
Icehouse testing for us, so I don't think we should keep Icehouse jobs
in 6.0/master after Juno is stabilized. What we should do instead is
drop Icehouse jobs and
Hello Fuelers,
Right now we have the following policy in place: the branches for a
release are opened only after its 'parent' release have reached hard
code freeze (HCF). Say, 5.1 release is parent releases for 5.1.1 and
6.0.
And that is the problem: if parent release is delayed, we can't
TL;DR: Yes, our work on 6.0 features is currently blocked and it is
becoming a major problem. No, I don't think we should create
pre-release or feature branches. Instead, we should create stable/5.1
branches and open master for 6.0 work.
We have reached a point in 5.1 release cycle where the
16 matches
Mail list logo
