> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
We should not confuse beta and rc builds, normally betas predate RCs and
serve a different purpose. In that sense, the nightlies we currently
publish are closest to what beta builds should be.
As discussed earlier in the thread, we already have full versioning and
provenance information in each bu
ster
> and continue development here. After that pre-6.0 is abandoned.
>
> What do you think?
>
> Thanks,
>
> Dmitry
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/c
gt;> give us the possibility to untie two events and make a separate decision on
>> branching without enforcing all HCF criteria.
>>
>> From the DevOps point of view it changes almost nothing, it just adds a
>> bit more discussion items on the management side and slig
y notify everyone in mailing list - that for every
>>>>> patch for 5.1, it should go first to master, and then to stable/5.1.
>>>>>
>>>>> Is everything ready from DevOps, OSCI (packaging) side to do this? Fuel
>>>>> CI, OBS, etc.?
>>>
>>>>>
>>>>> 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
&g
OW2 volume?
Thanks,
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
o consider other fields of
image_meta (e.g. size) when deciding whether an image can be cloned.
Thanks,
Dmitry Borodaenko
On Mon, Dec 2, 2013 at 11:29 AM, Dmitry Borodaenko
wrote:
> Hi OpenStack, particularly Cinder backend developers,
>
> Please consider the following two competing fixes f
into triggering disruptive cold migrations instead.
I think we should reopen this blueprint and put it back into the queue.
Thanks,
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
perceding blueprint properly? All I
could do is add a link in the whiteboard, so that no one else gets
confused.
Thanks!
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
and the related problem of reopening or hijacking
unrelated bugs has been an anti-pattern in our Launchpad bugs lately,
please take above into consideration when reporting bugs.
Thank you,
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-
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
Vitaly,
It's there a document or spec or a wiki page that describes the current
status of this discussion in the context of the whole pluggable
architecture design?
Jumping into this thread without having the whole picture is hard. Knowing
what is already agreed, what is implemented so far, and h
#x27;s too long to paste here)
I think we should also create a separate dashboard for fuel-specs, and
exclude both repos from the primary Fuel dashboard.
Thoughts?
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstac
/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr
27;s risky because fuel client is installed on the host system, not
> into the container, hence in case if something goes wrong we cannot
> make automatic rollback.
>
> Thanks,
>
> On Mon, Jan 12, 2015 at 8:24 PM, Dmitry Borodaenko
> wrote:
>>
>> On Mon, Jan 12, 2
ntact the sender and delete all copies; any review or
> distribution by others is strictly prohibited.
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists
FWIW 1GB works fine for me on my laptop, I run the master setup manually.
So I'm against increasing RAM requirement, we have better things to spend
that RAM on.
On May 10, 2014 1:37 AM, "Mike Scherbakov" wrote:
> It is not related to RAM or CPU. I run installation on my Mac with 1Gb of
> RAM for
sk in
every OpenStack component
<https://lists.launchpad.net/openstack/msg15111.html>
- https://review.openstack.org/34949
Please respond if you know about any other HA fixes and improvements
that can help avoid breakage of OpenStack, RabbitMQ, and MySQL on
failover.
Thanks,
--
Dmitry
the rule #0, too: do not
merge commits into stable branches until it was merged into master or
documented why it doesn't apply to master.
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstac
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
, Jun 2, 2014 at 12:33 PM, Dmitry Borodaenko
wrote:
> Our experience in backporting leftover bugfixes from MOST 5.0 to 4.1
> was not pleasant, primarily because too many backport commits had to
> be dealt with at the same time.
>
> We can do better next time if we follow a couple
/fuel.dash
Feedback is welcome.
Thanks,
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
A better download link that remains valid through updates:
https://raw.githubusercontent.com/angdraug/gerrit-dash-creator/fuel-dashboard/dashboards/fuel.dash
On Wed, Jun 11, 2014 at 11:28 AM, Dmitry Borodaenko
wrote:
> Fuelers,
>
> You can now use the Fuel Review Dashboard based on ge
V8o0Fk7BoAlsGHEoIfs/edit?usp=sharing
>>>>>>>>>>>
>>>>>>>>>>> I will place it in fuel-docs repo as soon as specification will
>>>>>>>>>>> be full enough to start POC, or if you think that
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Dmitry Borodaenko
___
OpenStack-dev mail
make the discussion more
concrete. Link:
https://review.openstack.org/99807
On Mon, Jun 16, 2014 at 3:07 PM, Dmitry Borodaenko
wrote:
> Mike,
>
> We discussed this in our team syncup meeting earlier today. The
> agreement was that HA is the biggest risk with the current approac
/etc.
Having this kind of limitation defeats the whole purpose of having RBD
driver in Nova, you might as well use the local storage on compute
nodes to store ephemeral disks.
Thank you,
-Dmitry Borodaenko
On Thu, Mar 6, 2014 at 3:18 AM, Sebastien Han
wrote:
> Big +1 on this.
> Missin
t;
>> We have a hard deadline of Tuesday to get these FFEs merged (regardless
>> of gate status).
>>
>
> As alt release manager, FFE approved based on Russell's approval.
>
> The merge deadline for Tuesday is the release meeting, not end
On Tue, Mar 11, 2014 at 1:31 PM, Matt Riedemann
wrote:
>>> There was a bug reported today [1] that looks like a regression in this
>>> new code, so we need people involved in this looking at it as soon as
>>> possible because we have a proposed revert in case we need to yank it
>>> out [2].
>>>
>>
ck.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
>
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
penStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
At the moment OpenStack infrastructure doesn't allow to customize the
bugs it creates, we should propose a patch at some point to implement
that. When we do, I think we should assign such bugs automatically to
fuel-docs team.
I don't think we should separate user and dev docs bugs, we're working
i
in each plugin (for
>>>>> >> >> plugin
>>>>> >> >> disabling/enabling)
>>>>> >> >> on the backend we have to enable all of the plugins for
>>>>> >> >> environment,
>>>>> >> >> because user can d
ld have
>>> different plugins available). These checkboxes should be hidden by default
>>> and only appear after user clicks a button named like "customize used
>>> plugins". I think we should use the word "use" here instead of "enable" as
on only.
>>
>> Best Regards,
>> Sergii Golovatiuk
>>
>> On 08 Oct 2014, at 21:08, Mike Scherbakov
>> wrote:
>>
>> Thanks Dmitry,
>> let's try to go this way and correct process if needed when we get first
>> results.
>>
>
; of merging. We should be very careful when we merge patches from
>>>>>>>>> non-core
>>>>>>>>> members as
>>>>>>>>>
>>>>>>>>> 1. This patch may correlate with p
enStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t;>>> experience (how hard to test, get error messages, etc) and the experience
>>>>> for the user who deploys the plug-in into an environment.
>>>>>
>>>>>
>>>>> -Nathan
>>>>>
>>>>> On Fri, Oct 17, 2014 at 4:13 PM, Roman Alekseenkov
; ___
>> 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
>
>
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
deployment/puppet/openstack/manifests/ha/mysqld.pp#L28-L33
> [3] https://blueprints.launchpad.net/fuel/+spec/pacemaker-improvements
>
> Regards,
> Aleksandr Didenko
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.o
-dev
>>>
>>
>>
>>
>> --
>> Andrew
>> Mirantis
>> Ceph community
>>
>> ___
>> 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
--
Dmitry Borodaenko
___
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
>
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
one with triaging, we can start proposing
> >>>> fixes for bugs. I suggest to extensively use #fuel-dev IRC for
> >>>> synchronization, and while someone fixes some bugs - the other one can
> >>>> participate in review of fixes. Don't hesitate to ask for code
> reviews.
> >>>>
> >>>> Regards,
> >>>> --
> >>>> Mike Scherbakov
> >>>> #mihgen
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Mike Scherbakov
> >>> #mihgen
> >>>
> >>
> >>
> >>
> >> --
> >> Mike Scherbakov
> >> #mihgen
> >>
> >
> >
> >
> > --
> > 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
>
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
vities and dedicate
>> this day to bugs only. Follow instructions from last bug squashing day [2].
>> Among other bugs, please give the higher priority to those with
>> "customer-found" tag.
>>
>> Please, use #fuel-dev for synchronization. I'll be
-8
In progress67
736736
Customer-found27
25-225-2
Confirmed/Triaged/In progress for 5.1
392
392
24Total open for 5.143928428-11428-1117
Spreadsheet:
https://docs.google.com/a/mirantis.com/spreadsheets/d/10mUeRwOplnmoe_RFkrUSeVEw-__ZMU2nq23BOY-gzYs/edit#gid=1683970476
--
Dmitry Borodaenko
ervisors.29>
.
Thank you all for participating, let's do even better next week!
-DmitryB
On Tue, Jun 24, 2014 at 12:41 PM, Dmitry Borodaenko <
dborodae...@mirantis.com> wrote:
> Mid-day numbers update:
>
>
> start delta from 2014-06-17mid-day delta from startend delta fro
ug, should be either converted to blueprint and closed as
Invalid, or closed as Won't Fix
Thanks,
-DmitryB
On Tue, Jun 24, 2014 at 9:07 PM, Dmitry Borodaenko wrote:
> Updated numbers from the end of the day:
>
>
> start delta from 2014-06-17mid-day delta from startend delta fr
.g. priority is not high enough to do
a backport), mark it Won't Fix for that series.
If there are no objections to this approach, I'll put it in Fuel wiki.
Thanks,
-DmitryB
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev
ons have to be solved for 5.0.1 too.
>
> Thanks,
> Igor
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Dmitry Borodaenko
On Thu, Jul 3, 2014 at 7:05 AM, Aleksandr Didenko wrote:
>> I think we should allow user to delete unneeded releases.
>
> In this case user won't be able to add new nodes to the existing
> environments of the same version. So we should check and warn user about it,
> or simply not allow to delete
to remove
>> it, from my testing, this at least allows the deployment to continue.
>>
>> --
>> Andrew
>> Mirantis
>> Ceph community
>
>
>
>
> --
> Andrew
> Mirantis
> Ceph community
>
> ___
> OpenStack-dev ma
t https://review.openstack.org/105850 to remove
>>> it, from my testing, this at least allows the deployment to continue.
>>>
>>> --
>>> Andrew
>>> Mirantis
>>> Ceph community
>>
>>
>>
>>
>> --
>> Andrew
>> Mirantis
>> Ceph c
d about this patch series on ceph-users ML:
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2014-March/028097.html
--
Dmitry Borodaenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
m using
> the default ubuntu packages since Icehouse lives in core and I'm not
> sure how to apply the patch series. I would love to test and review it.
>
> With regards,
>
> Dennis
>
> On 07/16/2014 11:18 PM, Dmitry Borodaenko wrote:
>> I've got a bit
t;
>> -Original Message-
>> From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On Behalf Of
>> Dmitry Borodaenko
>> Sent: Wednesday, July 16, 2014 11:18 PM
>> To: ceph-us...@lists.ceph.com
>> Cc: OpenStack Development Mailing List (not for usage questions)
___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Dmitry Borodaenko
___
OpenStack-dev mailing li
to ask for changes :)
[4] https://wiki.openstack.org/wiki/Fuel/8.0_Release_Schedule
If you find a problem, please don't hesitate to report it on IRC (#fuel)
or in Launchpad [5].
[5] https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Test_and_report_bugs
Tha
it's safe to say that vast majority of Fuel code is now covered
by gate checks running unit tests and syntax checks on OpenStack CI.
Nice work Alexey, Alex, Alexander, Sebastian, Vladimir, and Vladimir!
Many thanks to the OpenStack Infra team for encouraging and supporting
this effort!
--
Dm
sum up, I think we've reached the point where the value contributed
to the Puppet OpenStack project outweighs the burden of onboarding and
code review initially carried by Puppet OpenStack core reviewers, and
the value Fuel project gains from directly consuming u
Good point, replaced the tag with fuel-library.
On Oct 30, 2015 12:53 AM, "Emilien Macchi" wrote:
> Why do you use [puppet] tag?
> Is there anything related to Puppet OpenStack modules we should take
> care of?
>
> Good luck,
>
> On 10/29/2015 11:24 PM, Bogdan Dobrelya wrote:
> > Hello.
> > There
ng into OpenStack on many levels, Technical Committee is
appreciative of that and supportive of our efforts, additional scrutiny
is there because they want to get this right. Lets prove that their
trust in us is not misplaced.
--
Dmitry Borodaenko
___
hink you could do it. When I look back and consider how far Fuel has
come since it was first released in March 2013, how much it evolved in
terms of architecture flexibility and engineering process maturity, all
I can think of is: we can do anything!
--
Dmitry Borodaenko
for moving a spec to the 8.0 folder if the feature was implemented in
8.0. If it's not likely that it will be implemented before FF, better to
move it all the way to the 9.0 folder.
--
Dmitry Borodaenko
__
OpenStack
g MSK time, and will have lost 2 business days (Thu-Fri) during
which we won't be able to merge bugfixes. In addition to that, someone
from QA and everyone from CentOS7 support team has to work on Saturday,
and someone from CI will have to work a few hours on Sunday.
--
Dmitry Borodaenko
On T
apologies about that.
[3] https://wiki.openstack.org/wiki/Fuel#Release_Milestones
--
Dmitry Borodaenko
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
> Andrey Maximov
>
>
> On Wed, Dec 2, 2015 at 12:48 AM, Dmitry Borodaenko <
dborodae...@mirantis.com> wrote:
>>
>> With bit more details, I hope this covers all the risks and decision
>> points now.
>>
>> First of all, current list of outstanding commits
x27;d like to call once
again for volunteers to self-nominate for component leads of
fuel-library, fuel-web, and fuel-ui. We've got 2 days left until
nomination period is over, and no volunteer so far :(
--
Dmitry Borodaenko
On Mon, Apr 04, 2016 at 04:05:28PM +0300, Matthew Mosesohn wrote:
> I've seen several cases where core reviewers bully contributors into
> refactoring a particular piece of logic because it contains common
> lines relating to some non-ideal code, even if the change doesn't
> relate to this logic.
>
nStack modules which we reuse in Fuel
Library to become stable no later than around mitaka-3. For that, Puppet
OpenStack itself needs stable rpm and deb packages of OpenStack
components and their dependencies at least by mitaka-2.
None of the above will happen without our active involvement and clo
-December/082655.html
--
Dmitry Borodaenko
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman
Yes, you can merge any commits that do not change Fuel's dependencies.
On Dec 25, 2015 01:15, "Vitaly Kramskikh" wrote:
> Aleksandra,
>
> What are "base packages"? Can we merge to fuel-web?
>
> 2015-12-24 18:01 GMT+03:00 Aleksandra Fedorova :
>
>> Hi, everyone,
>>
>> we merged all versioning patc
+1 for "fuel: recheck". A nice to have addition would be:
"fuel: recheck verify-fuel-library-tasks"
to retrigger just one failed job.
--
Dmitry Borodaenko
On Mon, Nov 23, 2015 at 01:32:35PM +, Bob Ball wrote:
> There was a conversation a while ago around explic
.
[7] https://git.openstack.org/cgit/openstack/fuel-specs/tree/policy
Thoughts, comments, objections?
--
Dmitry Borodaenko
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opens
uel master branch, but please watch out for Critical
bugs, we're not yet completely done with 8.0.
[3] https://launchpad.net/fuel/+milestone/8.0
Thanks,
--
Dmitry Borodaenko
__
OpenStack Development Mailing List (not for
master branch.
--
Dmitry Borodaenko
On Mon, Feb 08, 2016 at 04:13:55PM +0300, Evgeniy L wrote:
> Hi,
>
> Some time ago we started Bareon project [1], and now we have some
> fixes landed to fuel-agent only, the question is what are the best
> practises on keeping two repos in sync w
+1 to Stas, supplanting VCS branches with code duplication is a path to
madness and despair. The dubious benefits of a cross-release backwards
compatible plugin binary are not worth the code and infra technical debt
that such approach would accrue over time.
On Wed, Feb 10, 2016 at 07:36:30PM +030
Vladimir,
You have identified the root cause of the problem:
> The key issue here is that our CI tests are using some code not from
packages of particular releases, but from other sources, e.g. pypi for
python.
Using frozen pypi, rubygems, nodejs and other language specific package
mirrors is a
+1
Great work, Denys!
On Wed, Jul 15, 2015, 00:04 Irina Povolotskaya
wrote:
> Fuelers,
>
> I'd like to nominate Denys Klepikov for the fuel-docs-core team.
>
> He has contributed a lot into documentation to Fuel over the past several
> months with being diligent reviewer.
>
> He has been workin
I'm with Stanislaw on this one: abandoning reviews just to make numbers
*look* better will accomplish nothing.
The only benefit I can see is cleaning up reviews that we *know* don't need
to be considered, so that it's easier for reviewers to find the reviews
that still need attention. I don't see
+1
On Thu, Jul 16, 2015 at 8:57 AM Sergii Golovatiuk
wrote:
> +1
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Thu, Jul 16, 2015 at 10:20 AM, Vladimir Sharshov <
> vshars...@mirantis.com> wrote:
>
>> Hi,
>>
>> we have created separate project for fuel-nailgun
done on time by reviewing their changes and offering
advice. It is a small but crucial step towards full convergence with upstream,
it would help a lot if we could confirm now that this approach is viable.
Thank you,
--
Dm
o actually make it possible to
run multi-node deploy tests on OpenStack Infrastructure. I guess we can at
least start that discussion in Tokyo...
Am I missing any major risks or additional requirements here? Do the dates ma
;no progress" and "reduced contribution from Fuel" when making
further progress is limited by Puppet OpenStack team's ability to review
incoming patches much more than by Fuel team's commitment to proposing and
updating them.
--
Dmitry Borodaenko
ommit from all sections of the
dashboard, if necessary (e.g. author is MIA) by abandoning it.
Reviewing that list once a week might be a good way to put stuck reviews
on the meeting's agenda, and would benefit all contributors, not only
rom Fuel contributors on the Puppet
OpenStack weekly meeting, hopefully that and gerrit dashboard tweaks
would be enough to improve the situation. I think we should do another
review of our collaboration around end of July, after two more weekly
meetings.
--
Dmitry Borodaenko
__
Looks like we have a consensus, I've added Denys to the fuel-docs-core
group.
Congratulations Denys, please keep up the good work!
On Thu, Jul 16, 2015 at 11:30 AM Mike Scherbakov
wrote:
> +1
>
> On Thu, Jul 16, 2015 at 8:40 AM Miroslav Anashkin
> wrote:
>
>> +1
>>
>> --
>>
>> *Kind Regards*
>
+1
On Thu, Jul 23, 2015, 09:32 Stanislaw Bogatkin
wrote:
> +1
>
> On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov
> wrote:
>
>> +1
>>
>> On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov
>> wrote:
>>
>>> At the moment we have several core reviewers for the fuel-main project.
>>>
>>> Roman Vyalov i
two weeks in most
areas, however patch sets to commits ratio remains the most important problem
and has seen no improvement so far.
--
Dmitry Borodaenko
__
OpenStack Development Mailing List (not for usage questions)
Un
sagreements" section highlights reviews that have both positive and
negative code review votes. This worked out pretty well for Puppet
OpenStack, lets try to use it in Fuel, too.
The remaining sections are rearranged to exclude commits that match the two
new section
;ve still got 50 more modules to convert in
Fuel 8.0, many will require commits to be merged in upstream before they
can be completely un-forked. Having such commits wait for a month at a
time only to be summarily rejected puts this effort at risk, lets figure
out what went wro
also asked someone on my team who is a
> swift expert (but not a puppet core) to take a look and weigh-in. I don't
> know what our official policy is, but I would expect your author to reach
> out to the person who left the -1 and attempt to resolve it with them
> before one of us wou
ewhere,
please feel free to add them to the discussion here, but make sure you
do so before the end of this week.
Thanks,
--
Dmitry Borodaenko
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
24 серп. 2015 о 20:29 Dmitry Borodaenko написав(ла):
We have several problems with Fuel branching strategy that have become
enough of a bottleneck to consider re-thinking our whole release
management process. In this email, I will describe the problems, propose
a couple of alternative strategies,
plan is too detailed and elaborate to work out exactly as laid out,
but I think it's achievable. Lets see if there's anything that we know
can't work the way I described, and what kinds of decisions we need to
make now or
e Fuel 8.0 cycle shorter simply won't work, and making it
longer isn't useful.
Short FF in 8.0 allows us to start 9.0 cycle earlier, so with 9.0 we still
have options.
--
Dmitry Borodaenko
__
OpenStack Devel
Huge +1 from me, Alex has all the best qualities of a core reviewer: great
engineer, great communicator, diligent, and patient.
On Wed, Sep 2, 2015 at 3:24 PM Jay Pipes wrote:
> I'm not a Fuel core or anything, but +1 from me. Alex has been very
> visible in the community and his work on librari
+1, Evgeny has been a #1 committer in fuel-docs for a while, it's great to
see him pick up on the reviews, too.
On Wed, Sep 2, 2015 at 3:24 PM Irina Povolotskaya <
ipovolotsk...@mirantis.com> wrote:
> Fuelers,
>
> I'd like to nominate Evgeniy Konstantinov for the fuel-docs-core team.
> He has con
nStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ______
>
+1
Great work Olga!
On Fri, Sep 11, 2015, 11:09 Irina Povolotskaya
wrote:
> Fuelers,
>
> I'd like to nominate Olga Gusarenko for the fuel-docs-core.
>
> She has been doing great work and made a great contribution
> into Fuel documentation:
>
>
> http://stackalytics.com/?user_id=ogusarenko&relea
1 - 100 of 194 matches
Mail list logo
