16:02:06 <xarses> #startmeeting fuel
16:02:07 <openstack> Meeting started Thu Sep 24 16:02:06 2015 UTC and is due to finish in 60 minutes.  The chair is xarses. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:10 <openstack> The meeting name has been set to 'fuel'
16:02:15 <kozhukalov_> hi
16:02:18 <angdraug> \o
16:02:20 <mwhahaha> there we go
16:02:21 <xarses> #chair xarses
16:02:22 <xenolog13> \~/
16:02:27 <openstack> Current chairs: xarses
16:02:34 <xarses> who's here?
16:02:36 <maximov> hi
16:02:46 <xarses> Todays Agenda:
16:02:47 <xarses> #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:02:55 <ashtokolov> o/
16:03:20 <mihgen> xarses: lots of people said hi, you are late )
16:03:28 <xarses> ok, lets get going then =)
16:03:38 <xarses> #topic librarian-puppet-simple integrations round 2 (mwhahaha)
16:03:46 <mwhahaha> We've been making some progress towards our switch to librarian. I sent a note earlier this month with a list of simple modules that were prepared for cutover.
16:03:46 <mwhahaha> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/074603.html
16:03:46 <mwhahaha> We have merged these as this week so we have continued to make progress towards getting the upstream modules managed via librarian.
16:03:48 <mwhahaha> We are also working on getting the upstream openstack modules converted as well. You can follow along with this the bp/fuel-puppet-librarian topic.
16:03:50 <mwhahaha> #link https://review.openstack.org/#/q/status:open+project:stackforge/fuel-library+branch:master+topic:bp/fuel-puppet-librarian,n,z
16:03:52 <mwhahaha> Additionally, I have started the work to switch to the upstream rsyslog module and added tests to our openstack module so we have coverage where the rsyslog module is actually configured.
16:03:54 <mwhahaha> #link https://review.openstack.org/#/c/223395/
16:03:56 <mwhahaha> #link https://review.openstack.org/#/c/222758/
16:03:58 <mwhahaha> It would be good to get additional eyes on the rsyslog changes to ensure we aren't breaking any UI components as it relates to logging.
16:04:00 <mwhahaha> Along with the rsyslog module, we still have 4 other modified upstream modules that we need to address. puppetlabs-corosync, puppetlabs-haproxy, puppetlabs-mysql and puppetlabs-rabbitmq.
16:04:02 <mwhahaha> #link https://docs.google.com/a/mirantis.com/spreadsheets/d/1P8xJbYyHXnb0W7fVme3jkOUYj4OTCfbplZEYLX7SC0E/edit?usp=sharing
16:04:04 <mwhahaha> Thanks, also remember to use librarian-puppet-simple and not librarian-puppet when managing modules.
16:04:15 * mattymo_ 's brain explodes
16:04:56 <holser> mwhahaha: puppet-corosync is very unstable
16:05:04 * aglarendil feeling that he is a slowpoke
16:05:15 <xarses> mwhahaha: there was a bug that I saw for the newer version of rsyslod(package) that needs new options, is that covered already in the new module?
16:05:26 <mwhahaha> xarses: should be
16:05:32 <kozhukalov_> btw, there is adjacent bug https://bugs.launchpad.net/fuel/+bug/1484162 which in a sense contradicts to the librarian based approach, doesn't it?
16:05:33 <openstack> Launchpad bug 1484162 in Fuel for OpenStack "package upstream puppet modules as build dependencies" [High,Triaged] - Assigned to MOS Puppet Team (mos-puppet)
16:05:42 <mwhahaha> holser: that's fine, we can keep the one we have or deal with something else. we just need to figure out what we want to do and communicate it
16:05:59 <mihgen> hey guys, not sure how librarian related it is. But I've heard that we faced some issue in neutron config just again, as we synced upstream modules in, and those override our settings for scale
16:05:59 <holser> dilyin: is making a new version by community request
16:06:00 <mwhahaha> kozhukalov_: they should go hand in hand
16:06:01 <aglarendil> mwhahaha: actually corosync is not the best module to sync downstream. we have our own pacemaker module which would be preferrable to publish.
16:06:11 <holser> mwhahaha: feel free to talk to him
16:06:24 <mwhahaha> aglarendil: thats fine, but lets communicate it plz. mailing list when making these decisions
16:06:55 <xarses> holser: can you share mail about that?
16:07:06 <holser> xarses: about what?
16:07:16 <mwhahaha> switching away from puppetlabs-corosync, writing out own module, etc
16:07:21 <xarses> dilyin: is making a new module
16:07:23 <mwhahaha> timelines, who's workign on int
16:07:29 <holser> it’s on review ...
16:07:37 <mwhahaha> yes but what's the back story?
16:07:40 <mwhahaha> that's not part of the review
16:07:53 <holser> well, let’s talk offline
16:07:57 <holser> it’s very long story
16:07:59 <aglarendil> let's move it to ML
16:08:01 <mwhahaha> sure
16:08:15 <xarses> yes, that's what I wanted to do =)
16:08:27 <xarses> moving on then
16:08:27 <mwhahaha> anyway those 4 modules we just need to figure out what we want to do
16:08:33 <mihgen> guys back to my question. How can we prevent this happening over and over?
16:08:44 <xarses> or not
16:09:00 <xarses> mihgen: we need to stop using the intermidate composition layer
16:09:15 <aglarendil> what is intermidiate composition layer?
16:09:16 <xarses> i think the setts that you noted where lost where because they are not in the task
16:09:19 <mihgen> xarses: I'm not sure it's about that
16:09:22 <holser> we need integration tests :)
16:09:40 <mihgen> I think it's about templates of configs even modified, and we don't notice that in large changesets
16:09:46 <holser> that will assure that all configs don’t have regression after applying new manifest
16:09:49 <mattymo_> mihgen, do you know which patches we lost for scale?
16:10:01 <xarses> aglarendil: our openstack module is a redundant composition layer to the task's implmentation
16:10:13 <aglarendil> mihgen: I think this is about the lack of noop tests, is not it
16:10:21 <aglarendil> xarses: do not rely on it - just check the final result
16:10:23 <mihgen> I can request scale lab to send me a bug link, I know it's neutron-related
16:10:24 <aglarendil> use noop and beaker
16:11:06 <mihgen> before we have all great tests, etc., we need a careful process of syncing....
16:11:21 <mihgen> I remember I was bugging about it for a few times
16:11:24 <mihgen> and it still an issue
16:11:31 <mwhahaha> right so the mos-puppet team has been working on those modules and porting our forks
16:11:32 <mwhahaha> https://review.fuel-infra.org/#/q/project:puppet-modules/puppet-neutron
16:11:36 <xarses> mike, we aren't supposed to be changing the underlying manifests
16:11:38 <mihgen> it's the problem that we finally find such issues too late in the cycle
16:11:49 <xarses> which is why we keep, and will keep losing changes
16:11:52 <aglarendil> mihgen: we need a bug first
16:11:57 <aglarendil> to discuss whether it happened or not
16:12:04 <mihgen> aglarendil: I'll find and follow up
16:12:06 <aglarendil> I do not see any confirmation on the issue right now
16:12:13 <mihgen> xarses: pls put an action item on me
16:12:20 <xarses> ok, moving on?
16:12:35 <mihgen> xarses: yes, let's push these changes upstream then, but now simply lose our scale tunings
16:12:55 <xarses> #action mihgen to find bug about missing neutron options found by scale
16:13:04 <xarses> #topic elections and team structure https://review.openstack.org/225376 (angdraug)
16:13:12 <angdraug> the Fuel Elections 2015 announcement is out:
16:13:12 <angdraug> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/074878.html
16:13:12 <angdraug> I've also proposed a formal policy document to describe Fuel team structure:
16:13:12 <angdraug> #link https://review.openstack.org/225376
16:13:12 <angdraug> based on mihgen's proposal:
16:13:13 <angdraug> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
16:13:15 <angdraug> lets discuss the remaining open questions now and get the policy proposal merged
16:13:38 <angdraug> the most recent questions from aglarendil:
16:13:41 <angdraug> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/075329.html
16:14:03 <angdraug> answer to 1: see Governance Process section of the policy
16:14:27 <angdraug> fuel-library is, well, fuel-library
16:14:32 <angdraug> and fuel-python is in fuel-web
16:14:39 <angdraug> that defines your electorate
16:14:39 <aglarendil> okay, what about fuel-astute ?
16:14:42 <aglarendil> fuel-agent?
16:14:47 <aglarendil> fuel-nailgun-agent?
16:14:59 <angdraug> "In other repositories, technical decisions are made by consensus of core
16:14:59 <angdraug> reviewers, and disputes are resolved by Fuel PTL."
16:15:01 <angdraug> it's all there
16:15:47 <angdraug> the answer to question 2 is also there:
16:15:49 <angdraug> Fuel component leads are elected twice a year immediately after PTL elections,
16:15:50 <angdraug> following the same process. Same person can't be PTL and component lead in the
16:15:50 <angdraug> same cycle.
16:16:09 <holser> angdraug: the problem is we don’t know how many people have rights
16:16:14 <aglarendil> okay, who is voting for fuel-python and who is voting for fuel-library?
16:16:17 <aglarendil> and again
16:16:31 <aglarendil> Mike's letter says - CL is being elected by core reviewers
16:16:37 <aglarendil> you say it is the same process
16:16:39 <angdraug> holser: "have rights"?
16:16:44 <aglarendil> the same electorate ?
16:16:47 <holser> yes
16:16:48 <mattymo_> angdraug, who participates in the vote, he means
16:16:49 <aglarendil> as for PTL?
16:16:57 <holser> Who is electorate for PTL
16:17:01 <xarses> by? or from?
16:17:04 <aglarendil> who is eligible to vote for PTL, who is eligible to vote for CL
16:17:39 <aglarendil> can we get exact list?
16:17:44 <holser> mattymo_:
16:17:55 <angdraug> aglarendil: this is exactly why I've pushed a proposal up for review, so that exact wording can be approved by fuel cores
16:18:39 <aglarendil> angdraug: we are running the election without knowing who can nominate and vote
16:18:41 <angdraug> electorate for PTL is all committers to all fuel repos on stackforge since a year ago
16:18:41 <holser> angdraug: I didn’t get you ...
16:18:51 <aglarendil> okay, PTL is easier
16:18:57 <aglarendil> who is voting for CL of Library?
16:19:34 <angdraug> aglarendil: committers to fuel-library since a year ago are voting for CL of fuel-library
16:19:44 <holser> How many commits should contributor do to have rights?
16:19:48 <angdraug> committers to fuel-web since a year ago are voting for CL of fuel-python
16:19:51 <ogelbukh> just 1
16:19:51 <holser> 1, 5, 10, 100
16:19:54 <aglarendil> 1 merged, I guess
16:19:57 <ogelbukh> yep
16:19:57 <angdraug> 1 merged, yes
16:20:02 <xarses> 1 merged
16:20:03 <aglarendil> but, folks, let's just put it down in writing
16:20:09 <aglarendil> let's not confuse people
16:20:17 <angdraug> as I said on the ML, there's plenty of documentation in openstack wiki about all this
16:20:20 <ogelbukh> I believe it is written somewhere for us :)
16:20:23 <mattymo_> A committer with 1 vote in fuel-docs 51 weeks ago has the same vote as a core reviewer to PTL, but a non-core with 400+ commits can't vote for CL
16:20:25 <aglarendil> saying "the process is the same" is not the best option to describe things the first time
16:20:26 <ogelbukh> angdraug: +1
16:20:30 <angdraug> there's even a script that generates the list of electorate
16:21:05 <angdraug> aglarendil: saying the process is the same and providing a link is better than cut-n-pasting the whole set of wiki pages into our own policy
16:21:13 <xarses> ok, so we have the electorate sorted. who can be in these positions?
16:21:25 <ogelbukh> anyone? :)
16:21:43 <xenolog13> aglarendil, +1
16:21:43 <angdraug> xarses: anyone from electorate can self-nominate
16:21:44 <holser> I guess core reviewers ...
16:21:45 <ogelbukh> well, anyone can nominate himself
16:21:51 <aglarendil> angdraug: it is always the best option to show en example for the first time.
16:22:03 <ogelbukh> yes, anyone eligible to vote can also apply for position
16:22:38 <angdraug> holser: aglarendil: xenolog13: did you read my ML post from yesterday?
16:22:39 <xarses> ok, so then are there other outstanding issues?
16:22:40 <angdraug> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/075311.html
16:23:01 <ogelbukh> I guess we need to compile a list of repos somewhere and record the decision about which component they belong to/vote for ?
16:23:12 <angdraug> ogelbukh: in the policy
16:23:18 <xarses> ogelbukh: its in the policy
16:23:20 <ogelbukh> ok
16:23:55 <angdraug> to reiterate: all commiters in past year can vote and can self-nominate
16:24:05 <xarses> fuel-web, and fuel-library respectively, have their own lead, and ever one else has the project PTL
16:24:14 <angdraug> for PTL: all stackforge/fuel-* repos
16:24:21 <mihgen> is it my client stuck or we are waiting angdraug to reply?
16:24:21 <mihgen> My understanding is that it's easy, we just need to get all committers to fuel-library and they can vote for CL
16:24:24 <angdraug> for fuel-library CL: stackforge/fuel-library
16:24:40 <angdraug> for fuel-python CL: stackforge/fuel-web
16:24:43 <ogelbukh> what about fuel-ui?
16:24:52 <ogelbukh> should it have CL of its own?
16:24:58 <angdraug> ogelbukh: no
16:25:14 <xarses> ogelbukh: it uses PTL directly
16:25:19 <ogelbukh> it's excluded from 'python' component, as far as I see
16:25:28 <ogelbukh> got it
16:25:43 <angdraug> mihgen: test
16:25:54 <mihgen> angdraug: thanks I had client stuck
16:26:11 <angdraug> any remaining questions about the policy or about the election process?
16:26:42 <ogelbukh> I'm reading through the policy and I don't see a list of repos to define the electorate
16:26:51 <ogelbukh> sorry for being dumb
16:27:12 <angdraug> ogelbukh: there is a list of repos for CLs
16:27:20 <angdraug> for PTL, it's all repos
16:27:32 <angdraug> we can enumerate them in the elections wiki page
16:27:50 <ogelbukh> angdraug: yep, I just suggest we do dit explicitly
16:27:56 <angdraug> in the next elections 6 months later, the list is going to change
16:28:08 <angdraug> ogelbukh: ok, I'll do that
16:28:30 <ogelbukh> angdraug: thanks, that's awesome
16:28:37 <angdraug> in the wiki, not in the policy (don't want to change policy every time we add a new repo)
16:29:06 <kozhukalov_> fuel-octane certainly should be among those repos
16:29:14 <angdraug> yes
16:29:19 <angdraug> but not fuel-plugin-*
16:29:51 <ogelbukh> kozhukalov_: thanks :)
16:29:55 <maximov> why ? people who expand our fuel should have a chance to influence PTL
16:30:14 <ogelbukh> this is why I want it explicit, you see :)
16:30:16 <angdraug> maximov: yeah good point
16:30:24 <xarses> ya, I was just thinking that
16:30:47 <xarses> if they bothered to post the plugin on stackforge with us, they should get to vote
16:30:54 <xarses> but not every random plugin
16:31:13 <angdraug> ok, stackforge/fuel-* should cover that
16:31:33 <xarses> and stackforge/python-fuelclient
16:31:41 <kozhukalov_> fuel-plugin-* do those repos follow the same review flow as other fuel-* projects?
16:32:18 <mihgen> xarses: time?
16:32:23 <xarses> kozhukalov_: in that they use, gerrit, yes
16:32:30 <kozhukalov_> if no, then it is easy to implement the scheme when PTL will be far from expected
16:32:47 <kozhukalov_> xarses, ok, thanks
16:32:59 <xarses> ya, we need to move on, lets discuss more in the ML
16:33:08 <xarses> #topic Fuel 8.0 schedule: https://wiki.openstack.org/wiki/Fuel/8.0_Release_Schedule (mihgen)
16:33:17 <mihgen> You can see that we are introducing 3 weeks long iterations
16:33:22 <mihgen> Majors changes compared to previous releases will be no .1 release (no 7.1, go to 8.0 directly)
16:33:27 <mihgen> and that we will be creating stable branch at the time of SCF
16:33:31 <mihgen> accoring to agreement we've had here:
16:33:36 <mihgen> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/073110.html
16:33:44 <mihgen> any questions?
16:34:53 <xarses> what's going to happen if a bp slips the iteration but not hcf?
16:35:16 <mihgen> it's assumed that team will work on bp until it's complete
16:35:22 <mihgen> not taking another bp
16:35:31 <kozhukalov_> i like iterations much more than our previous dev process
16:35:58 <mihgen> you guys may question how many backports we will have after SCF
16:36:10 <ogelbukh> I was under impression that we want to keep sync 1/2 year cadence with OpenStack releases
16:36:16 <mihgen> so to mitigate that, let's watch bugfix team's progress closely
16:36:23 <ogelbukh> but this schedule implies shorter cadence
16:36:34 <kozhukalov_> mihgen, yes, it is a bit frightening
16:36:42 <ogelbukh> is it going to stay, or we just want to shorten the delay
16:36:55 <mihgen> even though it will have to come with sacrifise to features
16:36:57 <ogelbukh> and following cycles will be longer?
16:37:18 <mihgen> ogelbukh: we want to shorten the time when master is closed from new features
16:37:39 <ogelbukh> mihgen: I see that
16:37:45 <mihgen> and majority of the team should work continiously on features
16:37:51 <ogelbukh> my question is about the whole length of the cycle
16:38:10 <angdraug> ogelbukh: the whole cycle is 6 month
16:38:22 <mihgen> goal here would be to align with openstack schedule in a long run
16:38:30 <ogelbukh> ok, maybe I need to recalculate :)
16:38:34 <angdraug> the feature work for next cycle begins immediately after SCF of the current cycle
16:39:06 <xarses> so the next cycle (after this first one) will get more time for features?
16:39:18 <mihgen> important thing about bp implementation: if we discover critical bugs in immplemented funcitonality, instead of taking new bps in next iteration - let's fix bugs first
16:39:36 <mihgen> it won't be bugfix team's responsibility
16:40:10 <holser> what about QA tests?
16:40:12 <mihgen> xarses: we will see. if we introduce less bugs with new features, we will have more time to work on features
16:40:14 <angdraug> xarses: starting with 10.0, we'll have full 6 months from SCF to SCF for feature work
16:40:19 <holser> they may slip fueture
16:40:45 <mihgen> holser: ideally they should be ready with tests at the end of iteration
16:40:46 <angdraug> in 8.0 and 9.0, we'll have less than 6 months for feature work
16:40:55 <mihgen> if they are not - let's solve this tactically
16:41:02 <mihgen> guys I think we need to move on
16:41:18 <mihgen> if there are questions on proposal, etc. - let's openstack-dev or #fuel-dev later ..
16:41:27 <xarses> mihgen: holser ideally we'd be ready with tests during the whole iteration, thinking about tests late, is well too late
16:41:40 <xarses> yes lets move on
16:41:52 <xarses> #topic MAINTAINERS: https://review.openstack.org/#/c/225457/ (mihgen)
16:41:55 <mihgen> According to
16:42:00 <mihgen> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
16:42:05 <mihgen> we are introducing maintainers in Fuel. Please check out my patch above as a first example.
16:42:22 <mihgen> Let's review, merge it, and I'd encourage cores of repos to propose/merge MAINTAINERS files everywhere
16:42:23 <mattymo_> This is the same as CL, right?
16:42:43 <mihgen> nope. Please read my email.. they are not
16:42:54 <mihgen> you are maintainer of fuelmenu
16:43:01 <mihgen> it means subject matter expert
16:43:05 <mihgen> but you are not core
16:43:14 <mattymo_> all the responsibility without the superpowers
16:43:19 <mihgen> so the idea is that people would ask maintainers who are not cores to review code first
16:43:27 <mihgen> yes
16:43:42 <mihgen> then maintainer can become a core reviewer
16:43:48 <xarses> what happens if we contribute with multiple emails?
16:44:04 <mihgen> xarses: why that matters?
16:44:16 <xarses> then why would you need the email in the first place?
16:44:30 <xarses> i figured it was needed for scripting to find changes or something
16:44:33 <mihgen> for script to automatically add you
16:44:38 <vkramskikh> so cores shouldn't be this file?
16:44:42 <mihgen> to reviewers
16:44:55 <vkramskikh> *in this file
16:44:55 <mihgen> vkramskikh: ideally, no cores
16:45:07 <mattymo_> xarses, you should unify your emails on your gerrit account
16:45:13 <mihgen> but some areas we will have only core reviewer as a maintainer
16:45:33 <xarses> mihgen: why not?
16:45:42 <mihgen> it will actually show that core reviewer should find someone else in the team and mentor, so that one becomes maintainer
16:46:12 <mihgen> xarses: bacause I want to offload work from core reviewers. They are super-maintainers, if you want such term
16:46:47 <kozhukalov_> there small projects, where both roles will be definitely on the same guy
16:47:05 <kozhukalov_> like fuel-agent for example
16:47:16 <mihgen> I want leutenant-dictator model
16:47:17 <mihgen> kozhukalov: that's ok if it is so
16:47:34 <mihgen> I'd encourage cores for delegation of their work
16:47:36 <mihgen> that's the idea
16:47:52 <mihgen> so cores have more time to spend on bigger, strategy-wise things
16:48:07 <mihgen> ok guys just 13 min left (
16:48:34 <mihgen> xarses: moving on?
16:48:39 <xarses> #topic Enhancements Team Status (ashtokolov)
16:48:57 <mihgen> vkramskikh: kozhukalov guys please ask questions in openstack-dev if you have any still, or find me in #fuel-dev
16:48:58 <ashtokolov> We've analysed our backlog and currently we have
16:49:08 <ashtokolov> LP: 79 (was 69) bugs with “feature” tag (fuel-library - 12, fuel-python - 67)
16:49:18 <ashtokolov> and 5 JIRA stories: PRODs 773, 778, 1245, 1405
16:49:34 <mihgen> can we move those 5 to launchpad?
16:49:45 <xarses> ashtokolov: so you will move them to LP then?
16:49:49 <mattymo_> maybe you mean blueprints?)
16:49:55 <mihgen> you have 4 numbers btw )
16:49:56 <ashtokolov> we work in trello
16:50:24 <ashtokolov> so we are splitting them on small parts and fill cards
16:50:25 <mihgen> depends on how large stories are. if they are > 5 man days, then enhancements team should not work on those
16:50:37 <mihgen> and blueperints is the right place
16:50:47 <ashtokolov> mihgen: you are right + 1472
16:51:03 <mihgen> if they are small, then since we have 79 already in bugs in LP, why do we keep backlog somewhere else
16:51:13 <mihgen> it makes nearly impossible to track everything..
16:51:16 <ashtokolov> so current status Inbox/Todo - 34, In progress - 4 + 2 stories, On review - 13, QA - 8, Done - 1
16:51:26 <ashtokolov> troll it's just a showroom
16:51:45 <ashtokolov> I wrote a script to sync LP to Trello
16:51:45 <xenolog13> guys, what about PROD-1295 ?  it's a very important story for Telco...
16:52:02 <ashtokolov> it's just to choose next item to work with
16:52:10 <mihgen> troll?
16:52:11 <ashtokolov> LP is a primary source
16:52:28 <xarses> ashtokolov: please create a wiki page documenting your working tools so we can follow along
16:52:55 <mihgen> ok let's take it offline ashtokolov
16:53:00 <xarses> lets move on
16:53:06 <xarses> #topic Fuel UI Team status (vkramskikh)
16:53:07 <ashtokolov> mihgen not troll but Trello =)
16:53:08 <mihgen> It's great to see progress
16:53:12 <ashtokolov> sorry)
16:53:15 <vkramskikh> Hi, we've started breaking down UI and UI-related Epics and creating corresponding blueprints. Here is the list:
16:53:15 <vkramskikh> https://etherpad.openstack.org/p/fuel-ui-8-0-userstories
16:53:15 <vkramskikh> For now we've finished with blockers and criticals, so DTLs of other teams can link these blueprint with theirs. They mostly lack description, so feel free to contact me and jkirnosova for further design and discussion. Any questions?
16:53:17 <mihgen> even when we are not over with 7.0
16:53:43 <mihgen> ashtokolov: I want whole backlog of items for the team to be in one single open place, but let's discuss it offline
16:54:05 <ashtokolov> mihgen: ok
16:54:19 <mihgen> vkramskikh: great, thanks vkramskikh!
16:54:35 <mihgen> do we have any specs already created?
16:54:43 <vkramskikh> not yet
16:55:05 <vkramskikh> we need to decide what we do in the 1st iteration, and then prepare specs for that stuff, right?
16:55:17 <mihgen> yep
16:55:32 <mihgen> I would say that we should start specs work in advance
16:55:38 <mihgen> so even for 2nd iteration
16:55:41 <vkramskikh> ok, we'll make the decision soon with the help of other teams
16:55:56 <mihgen> as it usually takes too long to involve all required parties
16:56:02 <vkramskikh> got it
16:56:13 <mihgen> thanks. moving on?
16:56:16 <xarses> #topic Upgrades team status (ogelbukh)
16:56:22 <mihgen> did we skip dpyzhov's update?
16:56:30 <dpyzhov> yep )
16:56:48 <xarses> oops
16:56:53 <xarses> #topic Bugfix Team Status (dpyzhov)
16:56:54 <mihgen> dpyzhov: may be you inserted yourself in the mid of agenda?) let's always put at the end
16:56:54 <dpyzhov> I guess I was late adding my line into agenda
16:57:07 <mattymo_> woo bugfixing!
16:57:10 <mihgen> you go Dima
16:57:11 <dpyzhov> Bugfix team started to work on 16th of September. We are focused on bugs that are already exist in Fuel.
16:57:11 <dpyzhov> So our priority is bugs created before 7.0 release date.
16:57:11 <dpyzhov> New bugs should be analysed and assigned to the team that introduced them.
16:57:11 <dpyzhov> Looks like the best way to achieve this is to update our bug triage instruction.
16:57:20 <dpyzhov> At the moment we ignore bugs with ‘feature’ or ‘tech-debt’ tag and bugs linked to blueprints.
16:57:20 <dpyzhov> Currently we have 67 in UI, 149 bugs in python and 99 bugs in library.
16:57:20 <dpyzhov> We keep squashing bug lists by invalidating some of them and marking some of them as feature requests or technical debt.
16:57:28 <dpyzhov> I’m little bit concerned by ‘tech-debt’ tag. Looks like it is deprioritized.
16:57:28 <dpyzhov> And it is possible that nobody will start fixing our tech debt before SCF.
16:57:28 <dpyzhov> And it will be too late and all the bugs will be postponed again.
16:57:39 <dpyzhov> Cmd-C, Cmd-V =)
16:58:05 <mihgen> dpyzhov: why deprioritized? let's use same priority mechanism..
16:58:19 <dpyzhov> Who will fix them? Enh team?
16:58:25 <mattymo_> dpyzhov, I've been thinking about tech-debt and how we should balance things. We should all do our fair share of tech debt bugs, but I expect we'll rotate in and out of 100% bugs and try to squeeze in some 1-2 days a week knocking away tech debt bugs
16:58:33 <mattymo_> they're not enhancements... it's another category
16:58:34 <xarses> shouldn't tech debt be taken up be enhancements when possible?
16:58:50 <mihgen> depends on bugs perhaps, +1 to xarses
16:59:06 <xarses> some of them will need full features
16:59:14 <xarses> in which case, we need to create bp
16:59:25 <mihgen> if it's just 1-2 days fix bug, not a real gap in functionality - it seems to be bugfix team should work on it
16:59:32 <mattymo_> xarses, tech-debt is usually about resyncing with upstream or removing deprecated this or that, or some minor refactoring
16:59:55 <mihgen> guys who has time, let's spend 5 more min in #fuel-dev for the remaining items
17:00:04 <dpyzhov> We can spend, let's say, 20% of time on tech-debt in my team
17:00:18 <xarses> #endmeeting