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
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
keep
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, bu
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
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
> 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
> 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 n
All OSCI action items for prepare HCF check list has been done
On Tue, Sep 9, 2014 at 6:27 PM, Mike Scherbakov
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, let's do it. We
> would
+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 per
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 stabl
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
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 wrot
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 o
+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
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 scope
15 matches
Mail list logo