21:02:16 <dhellmann> #startmeeting crossproject
21:02:17 <openstack> Meeting started Tue Mar 10 21:02:16 2015 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:21 <openstack> The meeting name has been set to 'crossproject'
21:02:25 <dhellmann> Our agenda for today, as usual:
21:02:25 <dhellmann> #link http://wiki.openstack.org/Meetings/CrossProjectMeeting
21:02:27 <asalkeld> o/
21:02:36 <dhellmann> #topic Hacking import change
21:02:36 <dhellmann> #link https://review.openstack.org/#/c/159196/
21:02:42 <dhellmann> jokke_, do you want to talk about this one?
21:02:42 <jokke_> o/
21:02:47 <jokke_> sure
21:03:09 <jokke_> So just wanted to draw bit of attention to it and get feel how people thinks
21:03:33 <jokke_> I think having those renames from six on their own block would help readability a lot
21:03:36 <SergeyLukjanov> o/
21:03:55 <jokke_> and help drive by contributors to identify what's going on at the overwrites
21:03:56 <dhellmann> I think we recently dropped the rules to enforce separation for other types of imports, didn't we?
21:04:03 <dhellmann> jogo: ^^
21:04:23 <jokke_> dhellmann: I think the test is not there as I couldn't find it
21:04:43 <dhellmann> right, I think it became too hard to determine whether a module was stdlib or not
21:05:00 <dhellmann> so this would need more thought, and an implementation
21:05:02 <jogo> dhellmann: yeah we don't enforce sections at all
21:05:21 <jogo> jokke_: you are refering to putting six.* in its own section?
21:05:24 <jokke_> but I think there is difference between enforcing and guideline
21:05:26 <asalkeld> so this is going to be not enforced?
21:05:26 <dhellmann> jogo: yeah
21:05:49 <jokke_> jogo: basically either whole six or the meta module renames from six.moves
21:05:49 <jogo> my take on that is, let a few projects adopt this organically if they want
21:05:53 <asalkeld> personally seems low value for the code churn
21:05:59 <dhellmann> jogo: ++
21:06:00 <jogo> and if enough do add it in.
21:06:07 <jogo> but I agree with asalkeld just seems silly honestly
21:06:35 <eglynn> asalkeld: agreed also
21:06:46 <dhellmann> ok, please provide feedback on the review if you have an opinion and we'll see where that goes
21:07:05 <dhellmann> #topic dropping SQL schema downgrades
21:07:05 <dhellmann> #link https://review.openstack.org/#/c/152337/
21:07:15 <jokke_> well the problem seems to be that enforcing or not some people seems to be reading hacking like devil reads the bible ... so if it's not allowed there, it won't be taken in the projects
21:07:20 <dhellmann> as was mentioned in the TC meeting, the folks at the Ops summit have expressed agreement with this
21:07:52 <jokke_> IMO it just clarifies a lot if for example from six.moves import range is separate so it's easy to spot being overwriten
21:07:56 <jogo> jokke_: each project has its own hacking file that can override/add things as needed
21:07:57 <dhellmann> I think we'll be approving it after that event is done and the TC members who are there are back online
21:08:04 <jungleboyj> o/
21:08:07 <dhellmann> folks, please, use the review for further discussion
21:08:25 <dhellmann> #topic Library Stable Branch Management
21:08:25 <dhellmann> #link https://review.openstack.org/#/c/155072/
21:08:26 <dhellmann> We're reaching the end of the cycle, and Oslo will be following this policy this time around.
21:08:26 <dhellmann> It would be good for the client projects to do the same, so please take a look and provide feedback if you think the policy is flawed.
21:08:53 <dhellmann> does anyone have questions about this one?
21:09:20 * jungleboyj needs to read that.  :-)
21:09:25 <asalkeld> i haven't read that
21:09:41 <dhellmann> please do, the intent is for it to apply to all client libraries
21:09:54 <dhellmann> it's important that we coordinate how we handle them now that we're capping requirements in stable branches
21:10:09 <jungleboyj> dhellmann: Will do.
21:10:10 <dhellmann> #link https://review.openstack.org/162656
21:10:15 <dhellmann> ^^ has the caps for oslo libs so far
21:11:36 <dhellmann> the goal is to strike a balance between releasing libraries as needed and maintaining stable branches for the app stable branches to use
21:12:24 <dhellmann> #topic managing stable branch requirements
21:12:25 <dhellmann> #link https://review.openstack.org/#/c/161047/
21:12:26 <dhellmann> somewhat related to the previous one, this spec calls for even tighter pinning of requirements
21:12:51 <asalkeld> dang, the spec keep rolling ;)
21:12:57 <adam_g> i just pushed up a new patchset there based on lots of discussion last week
21:13:01 <dhellmann> this will also have an impact on how testing works in some cases
21:13:11 <dhellmann> adam_g: good, I need to catch up on the latest draft
21:13:31 <adam_g> i think we have a good path for managing things centrally as opposed to relying on bot syncs to merge into projects
21:14:39 <adam_g> one question i had, and would ask to consider in feedback, is if we want to require developers making changes to global-requirements.txt to be responsible for keeping a corresponding .gate file up to date. this feels similar to sample config files, which have been painful for some
21:15:05 <dhellmann> yes, it is a similar issue -- things outside of your control can make that file become out of date
21:15:16 <jokke_> quick question as I'm notthat familiar with pbr ... does it support something like <major>.<minor>-stable<num>?
21:15:30 <adam_g> alternative is to keep that entirely bot managed--not sure if we do anything similar currently, will need to check with -infra folk
21:15:36 <dhellmann> jokke_: we use semver, and the patch version for that
21:15:56 <jokke_> dhellmann: so does our libs support that?
21:15:57 <dhellmann> adam_g: I think only by having the bot submit changes, but the infra team might know otherwise
21:16:04 <dhellmann> jokke_: in what sense?
21:17:24 <jokke_> dhellmann: thinking that capping for stables. Do wi cap on minor and expect that in no case the .patch will break to fix bugs affecting stable or do we need to make some circus moves on stable versioning to fix the bugs?
21:17:43 <fungi> we don't have any jobs which automatically change contents of git repos, if that's what you're asking
21:17:47 <dhellmann> jokke_: that is part of what the spec is talking about
21:17:56 <dhellmann> jokke_: we currently assume that patch releases are stable
21:17:59 <adam_g> fungi, yeah, essentially
21:18:00 <fungi> we only have jobs which propose new patches to git repositories and then humans need to inspect and approve them
21:18:16 <adam_g> fungi, thats what i thought
21:18:33 <fungi> this is a safety valve in my opinion
21:18:37 <dhellmann> fungi: ++
21:18:46 <fungi> otherwise, you risk some interesting feedback loops
21:18:49 <adam_g> yup
21:18:51 <fungi> also skynet ;)
21:19:39 <jokke_> dhellmann: ok, will put the question there then as at least by first read that was not clear to me ;)
21:19:42 <dhellmann> are there other questions on stable branches, libraries, and requirements?
21:19:54 <dhellmann> jokke_: ok
21:20:30 <jokke_> dhellmann: in general I like both of those specs that was just the only thing left unclear, on which level we do those
21:20:37 <dhellmann> jokke_: in https://review.openstack.org/#/c/155072/ I am proposing that we trust our own library maintainers and in adam_g and jogo are proposing a tighter safety net
21:20:41 <dhellmann> oops, in https://review.openstack.org/#/c/161047/3
21:21:23 <dhellmann> #topic Return Request ID to caller
21:21:24 <dhellmann> #link https://review.openstack.org/#/c/156508/
21:21:25 <dhellmann> There was some discussion last week of making this more general.
21:21:26 <dhellmann> There is a new draft up, so it's ready for another read-through.
21:22:19 <dhellmann> the name of the file still says cinder, though, so maybe there's more work to be done
21:23:04 <dhellmann> #topic Other open specs
21:23:04 <dhellmann> #link https://review.openstack.org/#/q/project:openstack%2Fopenstack-specs+is:open,n,z
21:23:04 <dhellmann> There are a bunch of other specs that have few comments or votes.
21:23:04 <dhellmann> Democracy only works if you participate! :-)
21:24:04 <dhellmann> does anyone have any specs they want to highlight?
21:24:17 <asalkeld> dhellmann: we spend most of our day "voting" ;)
21:24:24 <dhellmann> asalkeld: you have no idea :-)
21:24:27 <asalkeld> phew
21:24:55 <dhellmann> #topic Oslo feature freeze
21:25:08 <dhellmann> Oslo's official freeze is the 12th, thursday
21:25:19 <dhellmann> however, we have released most of our libraries already and our goal is to make those releases the last versions for this cycle
21:25:20 <asalkeld> brb, waking kids up
21:26:06 <dhellmann> we'll be working on updating the requirements lists in projects following the process described in the spec mentioned earlier after thursday
21:26:20 <jungleboyj> dhellmann: +1
21:26:49 <dhellmann> that should give plenty of time to land the requirements changes in all of the other projects before the release candidate period starts
21:27:06 <dhellmann> #topic open discussion
21:27:13 <dhellmann> does anyone else have anything to raise this week?
21:27:38 <asalkeld> not from me
21:27:38 <dhellmann> are there issues to be addressed as we head into the feature freeze period?
21:27:43 * devananda returns, catches up on scrollback
21:28:05 <asalkeld> dhellmann: that's the 19'th ?
21:28:07 * dhellmann would like to cut the meeting short, and end in ~3 min
21:28:13 <dhellmann> asalkeld: yes, that's right
21:28:30 <asalkeld> the last scramble..
21:28:32 <dhellmann> that will be the feature, string, and dependency freeze
21:28:49 <dhellmann> according to the schedule the feature proposal freeze, for projects that follow that, has already passed
21:29:03 <dhellmann> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
21:29:07 <asalkeld> yip
21:29:21 <jungleboyj> Yep.  For Cinder today is the last day to merge new features.
21:29:39 <jungleboyj> Wanted some time before the official freeze to make sure nothing broke badly.
21:29:45 <dhellmann> jungleboyj: nice, I didn't realize you were cutting off early, too
21:30:13 <jungleboyj> dhellmann: Yep, has caused some confusion for those trying to get bug fixes in.
21:30:23 <dhellmann> jungleboyj: I can imagine
21:30:36 <jungleboyj> dhellmann: Not sure where my remaining Oslo changes will hang.
21:30:43 <jokke_> glance is cutting out at Thu as well
21:31:01 <dhellmann> jungleboyj: maybe early in liberty?
21:31:13 <dhellmann> jokke_: that's good to know, thanks
21:31:28 <jungleboyj> Yeah, if people don't want them in the next couple of days.  Have been busy reviewing code for others.
21:32:03 * dhellmann nods
21:32:07 <dhellmann> unless anyone else has anything to bring up I propose that we adjourn
21:32:20 <asalkeld> yip, thanks dhellmann
21:32:22 <jokke_> o/~
21:32:28 <jokke_> thanks
21:32:29 <dhellmann> go spend the extra 25 minutes reviewing patches :-)
21:32:32 <jungleboyj> +2  Thanks!
21:32:36 <eglynn> thanks all
21:32:40 <dhellmann> thanks, everyone
21:32:45 <dhellmann> #endmeeting