19:00:11 <catherineD> #startmeeting refstack
19:00:11 <openstack> Meeting started Tue May 31 19:00:11 2016 UTC and is due to finish in 60 minutes.  The chair is catherineD. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:15 <openstack> The meeting name has been set to 'refstack'
19:00:38 <catherineD> Roll call
19:01:17 <pvaneck> o/
19:01:19 <andrey-mp> o/
19:02:01 <catherineD> #link meeting agenda and notes, please feel free to add items https://etherpad.openstack.org/p/refstack-meeting-16-05-31
19:02:33 <catherineD> Let's start
19:02:52 <catherineD> #topic     Add preliminary support for schema version 1.5  (  https://review.openstack.org/#/c/319057/  )
19:03:44 <catherineD> So for this time we will just update the website by creating tag while we deciding on refstack branching
19:03:59 <catherineD> I will create a tag today
19:04:05 <sslypushenko> o/
19:04:20 <catherineD> sslypushenko: Hi
19:04:49 <catherineD> Meeting agenda https://etherpad.openstack.org/p/refstack-meeting-16-05-31
19:05:00 <sslypushenko> Thx!
19:05:18 <catherineD> while we are on this topic let's discuss topic #5
19:05:32 <catherineD> #topic RefStack branches decision for refstack.openstack.org site
19:06:33 <catherineD> As we discussed last time, we want to investigate how other OpenStack website uses branches
19:06:36 <sslypushenko> we need some branching model.. it is pretty clear
19:07:16 <catherineD> seems like OpenStack document is hosting from  master
19:07:29 <catherineD> #link     OpenStack document published only from the master branch http://docs.openstack.org/contributor-guide/docs-builds.html   https://github.com/openstack/openstack-doc-tools )
19:07:35 <hogepodge> Most projects don't branch
19:07:47 <sslypushenko> mainly it is because we have some functionality, witch, for example app-catalog  does not have
19:07:56 <catherineD> so are App-catalog and Storyboard
19:08:24 <sslypushenko> it is really strange that storyboard publishes from aster
19:08:28 <sslypushenko> *master
19:08:39 <catherineD> sslypushenko: ++ ... especially the UI ... we do not want to publish the UI prematurely
19:10:03 <sslypushenko> yeap....
19:10:07 <catherineD> so our UI code (like https://review.openstack.org/#/c/318997/ ) will merge to refstack master but we may not want to expose that to the user yet
19:10:33 <sslypushenko> it should be possible to develop big features without publishing it
19:11:16 <catherineD> sslypushenko: yea and at the same time support publishing small update like supporing new DefCore schema to the website
19:11:44 <sslypushenko> so, we need branches definately
19:11:51 <hogepodge> I'd like to see a focus on core features without a distraction on side features
19:12:13 <hogepodge> Otherwise it's a glorified fork
19:12:14 <catherineD> hogepodge: it is the core feature to create vendor
19:12:49 <sslypushenko> hogepodge:  anyway, it should be possible to deliver feature in a few patches, not in one god-like-patch
19:13:25 <catherineD> the other options is to cherry pick patches ... but I see that would be harder
19:13:41 <sslypushenko> catherineD:  yeap
19:13:53 <andrey-mp> sslypushenko: we can develop in branches and merge features to master. antoher model will not be suitable due publishing from master
19:14:14 <catherineD> offering vendor and product creation is the main feature we are discussing ...
19:14:29 <sslypushenko> andrey-mp:  this workflow is not usual for openstack projects...
19:15:07 <andrey-mp> sslypushenko: yes :)
19:16:00 <sslypushenko> I think we can setup puppet-refstack to publish latest commit from latest non-master branch
19:16:32 <catherineD> sslypushenko: so we create a production branch?
19:16:35 <pvaneck> feature branches seem to be relatively in use in the community: http://docs.openstack.org/infra/manual/drivers.html#feature-branches
19:16:40 <sslypushenko> some think like we will publish branch with name 2016.06 - and it will be published automatically
19:17:08 <andrey-mp> sslypushenko: right now it takes latest tag as I remember
19:17:22 <sslypushenko> catherineD:  it looks like production branch is not aslo the best solution
19:17:45 <sslypushenko> andrey-mp:  yeap... it should work like tags
19:18:01 <hogepodge> I guarantee the branches will drift and this will be a huge headache, especially as non core work is developed on branches
19:18:19 <sslypushenko> but we can cherrypick some commits into it, if necessary
19:18:46 <sslypushenko> hogepodge:  non-cores will work with master
19:18:59 <sslypushenko> so it should not be a problemm
19:19:27 <catherineD> so we will develop new features in a branch ?
19:19:28 <sslypushenko> we need branches only for delivering
19:19:40 <sslypushenko> catherineD:  nope...
19:20:00 <catherineD> sslypushenko: could you please describe ..
19:20:08 <hogepodge> Ok, for manging deployed should be OK
19:20:11 <sslypushenko> I suggest to work branches like advance tag
19:20:18 <hogepodge> Just watch out for scope creep
19:20:41 <catherineD> sslypushenko: create tag by cherry picking?
19:20:44 <sslypushenko> at some checkpoint we create a branch with consistent functionality
19:20:52 <hogepodge> Feature branches will cause heartache
19:20:57 <sslypushenko> for example 2016.05
19:21:05 <sslypushenko> hogepodge:  +1
19:21:29 <catherineD> sslypushenko: I follow you ... so we create a brach 2016.05 ... what is next ?
19:21:31 <sslypushenko> catherineD:  so we will publish 2016.05 version of refstack
19:21:45 <sslypushenko> than we can continue develop in master
19:22:07 <hogepodge> Thanks for clarifying for me
19:22:14 <sslypushenko> if it is necessary, we can cherrypick something in to 2016.05
19:22:33 <sslypushenko> but we still work only with master
19:22:52 <sslypushenko> when we need publish new version of web site
19:23:09 <sslypushenko> ww will create branch 2016.09
19:23:26 <pvaneck> why not just one branch "prod" or something, then just merge master into it occasionally
19:23:37 <sslypushenko> and puppet will publish the newer version
19:23:55 <catherineD> pvaneck: I like the idea of prod branch
19:23:58 <sslypushenko> pvaneck:  it will take to much for support
19:24:43 <catherineD> The only thing I see that may need update for  the product is schema update
19:25:11 <pvaneck> when we create a new branch, do we delete the previous?
19:25:14 <sslypushenko> not all patches can be applyed in random order
19:25:30 <sslypushenko> pvaneck:  we can delete it, yeap
19:25:36 <catherineD> pvaneck: is schema update can be isolated?
19:26:20 <pvaneck> can you elaborate what you are talking about
19:27:32 <catherineD> let say DefCore update their Guideline schema to a new version which include new JSON element ... do you need to update the js?
19:28:15 <catherineD> the same js that you had updated to support vendor and product? I just want to see whether cherry picking is possible
19:28:39 <pvaneck> depends on the change, but if it is just a new field, then no. It'll just be ignored until we support it
19:28:42 <sslypushenko> pvaneck:  hmmm, I just realized that my idea sounds pretty close to idea with prod brach) but there is one difference. when we publish new branch, we still have a chance to rollback to old version. in case with prod branch it will be somewhat difficult
19:30:46 <pvaneck> sslypushenko: yea, true. In any case, to be able to push merges we'd have to add a new gerrit acl line into project config to allow us to pushMerge
19:30:51 <catherineD> the only thing I see we may need to update the site  is DefCore schema update
19:31:20 <pvaneck> catherineD, branches will allow us to cherrypick changes easily
19:31:40 <sslypushenko> pvaneck:  hmm.. can you specify details?
19:31:45 <catherineD> pvaneck: only if what we pick are isolated files?
19:32:34 <pvaneck> sslypushenko, described here: http://docs.openstack.org/infra/manual/drivers.html#merge-commits In this case, they are talking about merging master into a feature branch or vice versa
19:33:02 <pvaneck> catherineD, cherry-picks are based on commits/changes
19:33:25 <pvaneck> we make the change to master, then cherry pick that into the branch the site is running off of
19:33:36 <sslypushenko> hmm... I don't see why we need pushMerge... we need only cherrypick and creating new branches
19:34:07 <pvaneck> yea, if we go the branch as a tag route
19:34:29 <pvaneck> i'll have to explore to see how i can get puppet to get the latest non-master branch
19:34:38 <catherineD> if the commit that we pick involves file that have been updated  for other purposes ... I guess that will result in merge conflict
19:35:39 <sslypushenko> catherineD:  yeap... support extra branches always takes some extra effors. it is true
19:36:37 <sslypushenko> but I hope that only minor changes need to be cherrypicked.... like schema adjustments or description updates
19:36:59 <catherineD> sslypushenko: yea
19:37:34 <catherineD> seems like we lean on creating feature branches for production ...
19:37:54 <pvaneck> wouldnt call it a feature branch
19:38:15 <catherineD> pvaneck: prod branch?
19:38:17 <hogepodge> It's more like release branches
19:38:32 <pvaneck> yea, pretty much
19:39:38 <catherineD> pvaneck: will investigate how to update the site with non-master branch
19:39:39 <sslypushenko> hogepodge:  exactly, but without pinning to OpenStack releases
19:40:16 <hogepodge> sslypushenko: +1 yeah, it is definitely not the same
19:40:39 <catherineD> seems like we all agree on release branches
19:41:06 <andrey-mp> catherineD: pvaneck: site is upgraded from latest tag as i remember ...
19:41:16 <catherineD> just need to invetigate how to update the refstack site from release branches automatically like we do with tag today
19:41:32 <catherineD> andrey-mp: yes it is from latest tag
19:41:39 <pvaneck> andrey-mp, yea, a puppet change will be needed
19:41:49 <andrey-mp> why you don't want to stay with tags?
19:41:53 <catherineD> andrey-mp: can we create tag with cherrypick?
19:41:59 <andrey-mp> no
19:42:17 <andrey-mp> tag is like a branch - tag is a link to specific commit
19:42:21 <andrey-mp> and branch is too
19:42:55 <catherineD> andrey-mp:  but with branch we can cherrypick commit to it
19:43:12 <sslypushenko> andrey-mp:  we need tags with cherrypick... so we need branches
19:43:46 <andrey-mp> catherineD: its a git - when you commit to branch, git makes new commit and moves branch onto. with tag you'll need to do it manually
19:43:58 <andrey-mp> you can move tags also
19:44:14 <andrey-mp> or create minor version tags
19:44:42 <andrey-mp> 1.0.0 -> 1.0.1 -> 1.0.2
19:44:54 <sslypushenko> andrey-mp:  it will not work... to create a minor tag on each minor change
19:44:58 <andrey-mp> while master has new commits without tags
19:45:24 <andrey-mp> sslypushenko: it will work but its too boring )
19:45:43 <catherineD> andrey-mp: I don't mind investigate if it works
19:45:57 <andrey-mp> with release branches we will drop tags model )
19:45:59 <sslypushenko> I can not understand how it will work...
19:46:08 <catherineD> then less work for puppet update ..
19:46:49 <andrey-mp> catherineD: I do the same for our another git repositories
19:47:00 <sslypushenko> if we have only master branch, it means that we have only single chain of commits
19:47:09 <andrey-mp> but its not clear when tag moves
19:47:16 <catherineD> The discussion here is do we keep tag (that can cherrypick) --> this is the preferred method
19:47:34 <sslypushenko> but we want to have different chain for publishing
19:47:42 <andrey-mp> sslypushenko: you're right - we need release branches anyway
19:48:03 <andrey-mp> but we can make releases by tags - not by every commit in release branch
19:48:34 <catherineD> sslypushenko: the publishing in the branches will be for both branches and master ... but not all commits in the master should go to the branch
19:48:47 <andrey-mp> (like Nova, Cinder, ... and some other Openstack components)
19:49:24 <catherineD> andrey-mp: so you mean we create a release branch and then create tag from the branch
19:49:25 <sslypushenko> ok...
19:49:27 <andrey-mp> catherineD: do you know how branches and releases work in Nova (for example) ?
19:49:42 <catherineD> andrey-mp: no I don't
19:50:23 <sslypushenko> it looks like everyone got the final idea... we need standard release workflow just without pinning to OpenStack releases
19:50:40 <andrey-mp> catherineD: yeah. but not 'from'. tag is a link on specific commit - you can create (and recreate) it everywhere
19:50:44 <rockyg> o/
19:50:45 <sslypushenko> it should be pretty simple to do and support
19:50:56 <pvaneck> I will epxlore what changes puppet-refstack will need
19:51:00 <andrey-mp> sslypushenko: +1
19:51:38 <andrey-mp> sslypushenko: but Openstack can release update for previous version  - we don't need it
19:51:46 <catherineD> so we agree that refstack site will be published from tag created from a release branch?
19:52:08 <andrey-mp> catherineD: from latest tag (as now)
19:52:28 <andrey-mp> because we can have many tags/branches
19:52:31 <catherineD> today the tag is created from master branch
19:52:59 <sslypushenko> catherineD:  we can create tags on release branches... but I think that only publish the latest commit will also work
19:53:31 <andrey-mp> release tags are need (and can be created) if we need to fix something in current version but master is not stable now
19:54:07 <catherineD> I am not clear on what we agree here
19:54:09 <sslypushenko> ok... lets stick to tag approach
19:54:29 <sslypushenko> it looks a little bit flexible
19:54:42 <andrey-mp> so release tag is created on commit with latest tag. then we merge something to this branch. then we tag new commit with new tag.
19:54:45 <sslypushenko> I mean tag from release branch
19:54:53 <andrey-mp> and cherry-pick this commit to master
19:55:13 <andrey-mp> when master will be stable - we tag it with higher major version
19:55:47 <sslypushenko> andrey-mp:  yeap
19:55:54 <catherineD> Let's Paul did some investigation on the puppet ans we will revisit this topic next week
19:56:22 <pvaneck> puppet pulls from pypi, will non-master tags be released on pypi?
19:56:26 <catherineD> meanwhile we will create a tag to update the site to support DefCore schema version 1.5
19:56:53 <andrey-mp> pvaneck: all tags are released on pypi
19:57:02 <andrey-mp> but pypi hides lower versions
19:58:38 <catherineD> andrey-mp: can you explain  lower version?
19:58:58 <andrey-mp> if you release version 1.0.1 then pypi will hide 1.0.0 version
19:59:12 <catherineD> ok
19:59:20 <catherineD> thx
19:59:36 <catherineD> I need to end meeting
19:59:51 <andrey-mp> but if you want - you can go to the pypi and unhide all versions )
19:59:57 <catherineD> andrey-mp: can  I talk to you on #refstack on the product API tag
20:00:03 <andrey-mp> yeah
20:00:06 <andrey-mp> i'm there
20:00:11 <catherineD> tag --> patch
20:00:22 <catherineD> thank you all
20:00:29 <catherineD> #endmeeting