20:05:28 <david-lyle> #startmeeting Horizon
20:05:29 <openstack> Meeting started Wed Jul 29 20:05:28 2015 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:05:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:05:32 <openstack> The meeting name has been set to 'horizon'
20:05:42 <david-lyle> sorry lost in space and time
20:05:52 <david-lyle> hello everyone
20:06:04 <TravT> o/
20:06:12 <tyr> howdy!
20:06:12 <hurgleburgler> (◕‿◕✿)ノ
20:06:14 <rhagarty> o/
20:06:16 <matt-borland> guten tag
20:06:21 <fnordahl> good evening
20:06:33 <doug-fish> hi
20:07:16 <rdopiera> gruetzi
20:07:37 <david-lyle> let's get rolling
20:08:00 <david-lyle> We tagged L-2 yesterday, so 2/3 of the way through liberty
20:08:30 <david-lyle> #link https://launchpad.net/horizon/liberty/liberty-2
20:09:47 <david-lyle> Translation support for angular is probably the biggest item in that list
20:10:21 <TravT> Speaking of that, is that all done?
20:10:33 <TravT> did all the patches land needed for angular-gettext?
20:10:50 <david-lyle> all patches linked to the bp
20:10:52 <david-lyle> did
20:11:07 <david-lyle> if others are unattached, I don't know
20:11:10 <TravT> doug-fish: tqtran: can I start using the filter syntax now?
20:11:26 <tqtran> yes
20:11:29 <matt-borland> excellent
20:11:38 <matt-borland> thanks
20:11:41 <TravT> ok, cool. i'll update my TODO out there then.
20:12:23 <david-lyle> Also we held the first Horizon midcycle last week in Fort Collins, CO
20:12:32 <hurgleburgler> yay!
20:12:38 <david-lyle> there were ~20 people in attendance from 3 continents
20:13:14 <david-lyle> overall a very productive sprint type gathering, IMO
20:13:22 <david-lyle> thanks to all who could participate
20:13:48 <david-lyle> the video link broke down on day one and networking difficulties prohibited using it beyond that
20:13:55 <david-lyle> so apologies to all who were remote
20:14:03 <TravT> +1, thanks everybody who could make it.
20:15:45 <david-lyle> Just want to touch on the priorities
20:15:52 <david-lyle> #link https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities
20:16:23 <TravT> I'd like to focus my reviews the next few days on helping complete in flight re-org and jscs cleanup. Is what's listed on the https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities up to date?
20:16:27 <david-lyle> most of the top priority items remain open
20:16:54 <tqtran> Translation is complete, so I dont think its all up to date
20:16:58 <david-lyle> if we can get the tech debt finished off (at least that listed)
20:17:06 <david-lyle> That will help a great deal
20:17:30 <david-lyle> My work on plugins has been side tracked with testing issues
20:18:04 <david-lyle> although lhcheng is working on moving trove to /contrib and robcresswell is removing the router dash from horizon
20:18:25 <david-lyle> so some forward progress is still being made
20:19:03 <david-lyle> django 1.8 still looms
20:19:15 <ducttape_> django 1.8 looked like it had small patches to move it forward  https://review.openstack.org/#/c/201734/ is next
20:19:33 <david-lyle> I tried that but saw issues
20:19:40 <david-lyle> not sure the source
20:19:56 <david-lyle> will look more after testing issues resolved
20:20:08 <david-lyle> if someone doesn't beat me to it
20:20:22 * david-lyle is a slow runner
20:20:56 <tyr> TravT: The dash reorg patch series starts with https://review.openstack.org/#/c/197353 and is now stable. No additional patches are planned. This will complete the re-org work and unblock JSCS.
20:21:19 <david-lyle> ducttape_: did try curvature on a decent sized topology and it was a vast improvement on the existing network topology so please give that a look
20:21:57 <ducttape_> I also tried it again, and it did not draw the graph correctly.  not sure if that is bad data or bad code
20:22:07 <david-lyle> doh
20:22:18 <ducttape_> it works well for simpler network setups though
20:22:33 <david-lyle> more testing would be good by many people
20:22:42 <fnordahl> link to patchset?
20:23:24 <david-lyle> LMLPTFY: https://blueprints.launchpad.net/horizon/+spec/curvature-network-topology
20:23:43 <david-lyle> https://review.openstack.org/#/c/199063/
20:23:57 <fnordahl> thx
20:23:58 <david-lyle> not that patch
20:24:09 <david-lyle> https://review.openstack.org/#/c/141078/
20:24:12 <david-lyle> that patch
20:24:18 <fnordahl> heh, k thx
20:24:31 <david-lyle> not sure what the second one is about
20:24:36 <fnordahl> :-)
20:24:43 <TravT> ducttape_:  you comment is kinda funny.
20:25:04 <TravT> ducttape: you said there are intermittent bugs, but okay to merge?
20:25:41 <ducttape_> I think so, it's tough to object becasue the problems I have seen are in our dev environment - where we do all sorts of crazy things
20:25:59 <ducttape_> could be a bunch of bad things exist in our neutron db
20:26:14 <david-lyle> more eyes would be better
20:26:16 <TravT> ok.  i'm happy to try it out, but my dev env in no way replicates a real network env.
20:26:25 <fnordahl> I'll test.
20:26:36 <david-lyle> TravT: this view is for the projects panel
20:26:49 <ducttape_> yep, this patch set really shines when you have more than one tenant network and several instances
20:27:10 <david-lyle> so while a high level of complexity is possible, it may not be prevalent
20:27:35 <ducttape_> I'd say 3-4 tenant networks with 5 instances on each network if probably more complex than average
20:27:44 <ducttape_> if/is
20:28:07 <TravT> that's not too bad to setup
20:28:32 <fnordahl> Speaking of networking:
20:28:33 <fnordahl> #link https://blueprints.launchpad.net/horizon/+spec/neutron-subnet-allocation
20:28:37 <fnordahl> I have proposed a implementation of the first phase of this blueprint, and would really like to have comments, insults, cheers, feedback and reviews of the patchsets linked to on the Whiteboard.
20:29:59 <david-lyle> fnordahl: looks like amotoki is reviewing, that's the best first step
20:30:34 <david-lyle> that's all the general items I had
20:30:45 <david-lyle> #topic Feature Branches
20:31:12 <david-lyle> I promised to look into what Feature Branches would entail
20:31:31 <david-lyle> #link http://docs.openstack.org/infra/manual/drivers.html
20:31:40 <david-lyle> is the best write up I found
20:32:25 <matt-borland> david-lyle: thanks for looking into that
20:32:47 <david-lyle> so I think I need release mgmt team to create branches we would need
20:33:36 <ducttape_> I think neutron used feature branch for DVR work, they might have tricks to learn
20:33:43 <david-lyle> and commit rights would be based on convention
20:33:54 <matt-borland> and this would be for particularly big sets of changes, right?
20:34:01 <david-lyle> swift used them for erasure codes as well
20:34:08 <david-lyle> matt-borland: yes
20:34:21 <TravT> i'm wondering what comprises a feature branch.
20:34:30 <TravT> in our work.
20:34:40 * notmyname can answer questions about feature branches in swift
20:34:56 <david-lyle> flow: branch created, feature developed, iterations, then one big merge at the end
20:35:11 <matt-borland> probably not the panels I'm working with...I think we have a simple patch structure that will work for now
20:35:15 <david-lyle> notmyname: investigating for long running features
20:35:29 <david-lyle> s/running/building/
20:35:44 <notmyname> there's a few things that we've found to be vital. one big one is frequently merging master to the feature branch
20:35:59 <matt-borland> makes sense
20:36:21 <TravT> notmyname: does gerrit still do merge conflict detection on the feature branch automatically on each patch
20:36:24 <TravT> ?
20:36:36 <TravT> that lands on master
20:36:41 <notmyname> also, because a feature branch (as we've used them) is intentionally "separate", we don't actually merge the feature branch itself. we refactor the patches on the feature branch as a set of logical patches, then do one merge commit to master
20:37:06 <notmyname> TravT: yes, and the UI for it is wonky. mostly, we ignore that part and focus on what git tells us
20:37:39 <david-lyle> notmyname: so do you lose the git history of the branch?
20:38:01 <david-lyle> since it's a merge, it should be maintained no?
20:38:06 <notmyname> no, we tag the original feature branch (and close it for new patches) so we still have the whole history
20:38:41 <david-lyle> so you don't actually merge from the feature branch
20:38:50 <david-lyle> new patches
20:39:04 <david-lyle> didn't grok it the first time :P
20:39:31 <david-lyle> why not just a large merge?
20:40:05 <david-lyle> I can also follow up offline
20:40:08 <ducttape_> you might have a much more complex merge / history on master, for not much value
20:40:15 <notmyname> we created a feature branch: feature/ec. then, every week(-ish) we'd merge master to feature/ec. dev work continued on feature/ec for nearly a year. then we tagged feature/ec, refactored the patches onto feature/ec-review and proposed one merge commit to master from that
20:40:53 <notmyname> the reason we clean up the git history is so that we have something that's (1) easy to review and reason about in logical chunks and (2) later we'll be able to see the logical flow of the implementation
20:41:26 <notmyname> and we do the single merge commit to master so that future debug work (eg with git bisect) will have a single point in history where the feature is introduced
20:41:32 <david-lyle> ok, I think that makes sense
20:41:58 <david-lyle> thanks notmyname, I may have more questions later
20:42:04 <notmyname> we've completed 2 and currently have 2 open now
20:42:11 <notmyname> david-lyle: any time
20:42:47 <david-lyle> ok stepping back a bit, we started talking about feature branches for a couple of reasons
20:43:37 <david-lyle> one was the desire to work collaboratively on a complex feature incrementally has proved difficult with patch chains 10 deep
20:43:53 <david-lyle> two was to resist the desire to merge partial features
20:44:47 <ducttape_> I think we found a better example of how to do ng patches, in a single review too
20:44:58 <david-lyle> some of the work recently has been tagged as taking the first step, but in a few cases it has resulted in/proposed an non-functional panel
20:45:41 <david-lyle> right, so the two options were, if people feel the need to build incrementally, they could use a feature branch
20:46:29 <david-lyle> or just implement the full feature, or a useful chunk before proposing the patch to add said feature
20:46:34 <TravT> I think that you (david-lyle) had proposed that the patches could be broken up just in logical functional chunks and that'd be okay.
20:46:47 <TravT> I think that makes sense.
20:47:02 <david-lyle> TravT: That is fine, but the other patches should be existant, not just promises
20:47:07 <TravT> and for disabled panels, I'm not seeing a large amount of harm in doing it that way.
20:47:18 <david-lyle> I disagree
20:47:23 <ducttape_> howso TravT?
20:47:26 <david-lyle> it's dead code
20:47:28 <TravT> also, i think it is wrong to tell people to not submit their work as reviews even if in WIP state
20:47:39 <TravT> they should however mark as wip
20:48:02 <ducttape_> yeah, WIP reviews are fine / anything goes.  however, it is polite to not try to flood openstack infra with check jobs
20:48:31 <david-lyle> so adds complexity, maintenance for something that's not really there
20:48:42 <doug-fish> also related text get picked up for translation
20:48:44 <david-lyle> it should be merged to tree when it adds value and is usable
20:48:47 <tyr> The review is really the bottleneck. Patches need to be small in order to move through. Feature branches might be nice for the collaborative development, but still suffer a big bang review at the end. How do we accomodate that?
20:48:54 <TravT> not arguing that david-lyle
20:49:03 <TravT> i did say logical, functioning parts
20:49:36 <david-lyle> I think the disagreement would be on "functional"
20:49:42 <TravT> for example, with images, i originally also had non-working action buttons, but after heeding your feedback removed that
20:49:53 <david-lyle> TravT: and that's good
20:50:05 <david-lyle> but an empty panel is of no value
20:50:10 <ducttape_> tyr - if you want speed, go with a feature branch.   master will have greater weight on quality / stability
20:50:13 <david-lyle> which was another example
20:50:21 <TravT> david-lyle: that's fair...
20:50:22 <matt-borland> I think the point about having lined up the "next level of useful patches" is probably a good one.
20:50:37 <david-lyle> another was buttons but no backend implementation for the actions
20:50:38 <TravT> although, we probably need to up some base patches for enabling angular on each dashboard.
20:50:48 <TravT> and merge those in.
20:50:56 <david-lyle> TravT: I'd argue we have
20:51:16 <ducttape_> yeah, we had a good example of how to do angular reasonably well, patch escapes me atm
20:51:18 <david-lyle> there's a lot of angular code in tree, and the end user sees very little result of that yet
20:51:31 <tyr> ducttape_: My point was that a feature branch makes an even larger review...so at some point, commits are broken down into a series of small, easily reviewable pieces anyhow.
20:51:41 <TravT> well, on the images panel, i did put up some extra module stuff just for enablement... partially due to the whole webroot issue
20:52:37 <ducttape_> one big review, where everything works.... vs 10 small reviews, where you aren't sure what should or should not work.... I think the bigger patch is the way to go.  total review time would be less as well
20:52:52 <TravT> i don't know about that ducttape_
20:52:59 <matt-borland> every time we try that people say the patch is too big and must be broken apart
20:53:01 <TravT> we abused tqtran for over a year with that strategy
20:53:03 <ducttape_> or it seems like it should be less, because everything should be working
20:53:08 <matt-borland> there are also some issues with cross-functionality,
20:53:13 <matt-borland> especially with API pathes
20:53:17 <matt-borland> *patches
20:53:32 <TravT> i think reasonable functional level patches make some sense...
20:53:54 <david-lyle> maybe we shouldn't be tackling so much new at once and spend some more time fixing things like broken selenium tests and integration tests
20:54:06 <david-lyle> then the risk of conflict goes down
20:54:18 <ducttape_> or fixing existing bugs
20:54:50 <tyr> With or without feature branches we end up wanting something like 1) each patch is small but functional, 2) most of the patches are in place to be able to see the whole picture.
20:55:00 <david-lyle> fix a bug in master, back port to kilo or juno and operators will actually see it :)
20:55:28 <david-lyle> tyr, true, but the functionality should be there
20:55:41 <david-lyle> and ready to review
20:56:01 <TravT> david-lyle, ducttape_ made a good point earlier about zuul testing on WIP patches...
20:56:16 <matt-borland> david-lyle: wrt panel patches, I do feel that after our discussion we have a good structure that satisfies our interests.
20:56:17 <david-lyle> indeed he did
20:56:19 <TravT> if we WIP the workflow, that still churns up zuul doesn't it?
20:56:37 <ducttape_> I have noticed a lot of people with like 40 or 50 patches for a change.  if you can, avoid doing so many changes
20:56:41 <david-lyle> feature branches would too
20:57:03 <david-lyle> I think coming with a more fully realized feature would reduce churn
20:57:14 <david-lyle> but I can't ever argue with collaboration
20:57:29 <TravT> i will say that sometimes a lot of patches come in in spurts because people are addressing review comments quickly and getting further review
20:57:34 <TravT> there is nothing wrong with that IMO.
20:57:39 <david-lyle> that said, I have used github to collaborate on Horizon patches with other devs in the past
20:57:42 <matt-borland> yeah, that is a good thing TravT
20:58:10 <TravT> but I do see that we should try to ensure all comments are addressed in each submission if possible... etc, to lessen the churn.
20:58:11 <david-lyle> I think 50 patch sets on relatively minor changes is extreme
20:59:32 <david-lyle> the tools are the tools. My main beef is with non-feature realizing patches with nothing following
20:59:45 <david-lyle> that's just silly, IMO
20:59:47 <matt-borland> yep, I think we've agreed on that
21:00:31 <matt-borland> I will strongly push back when people ask to break my Panel patch into smaller patches
21:00:34 <tyr> Yes, being able to download the final patch to see the big picture...even when reviewing only the 1st part is very helpful.
21:00:42 <david-lyle> we're at time, I did want to welcome rdopiera back though
21:00:55 <TravT> rdopiera: good to see you around!
21:00:57 <lhcheng> I try to read all the PS comments before approving to make sure all comments are addressed -  a little less patch set for smaller change would be nice to speed-up review.
21:01:01 <hurgleburgler> rdopiera: welcome back!
21:01:09 <doug-fish> rdopiera: yes, good to have you back!
21:01:11 <tqtran_> rdopiera: wb!!!
21:01:37 <david-lyle> did you have anything you wanted to add before we close rdopiera? I'm trying to get to the config file patch
21:02:25 <david-lyle> any further discussion in #openstack-horizon as usual
21:02:33 <david-lyle> thanks everyone
21:02:36 <david-lyle> #endmeeting