21:03:38 <ttx> #startmeeting project
21:03:39 <openstack> Meeting started Tue May 20 21:03:38 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:42 <openstack> The meeting name has been set to 'project'
21:03:43 <ttx> First meeting from Juno era
21:03:44 <markwash> o/
21:03:47 * SergeyLukjanov flying above Boston atm, lurking
21:03:52 <ttx> Smallish agenda, should be quick
21:04:10 <ttx> I sometimes wonder when Sergey sleeps or takes vacation
21:04:25 <ttx> #link http://wiki.openstack.org/Meetings/ProjectMeeting
21:04:34 <ttx> Following a suggestion from notmyname at the summit, here is the combined log of the 1:1s sync from today:
21:04:44 <ttx> #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-05-20-11.45.html
21:05:24 <ttx> #topic Juno Release Schedule
21:05:31 <ttx> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
21:05:38 <ttx> So this is the proposal from the Design Summit
21:05:39 <SergeyLukjanov> wow, combined log looks pretty nice
21:05:47 <ttx> which we should officialize ASAP
21:05:57 <ttx> let me check my emails for complains
21:06:08 <mikal> .
21:06:15 <mestery> SergeyLukjanov: +1 to that, it's quite nice!
21:06:16 <eglynn> which weeks are shaping up for mid-cycle meetups?
21:06:26 <ttx> ok, no objection so far
21:06:50 <SlickNik> ttx: no complains here
21:06:53 <dolphm> eglynn: July 9, 10, 11 for keystone
21:06:56 <ttx> Unless something significant is raised that makes me reconsider, I'll probably set it in stone by Thursday
21:07:06 <notmyname> we've got a swift hackathon the first week of june
21:07:07 <ttx> eglynn: first half of July is a popular option
21:07:18 <mestery> eglynn: Neutron has one June 17-19 (for LBaaS) and July 9-11 (nova-network parity)
21:07:25 <eglynn> ttx, dolphm: yep I was thinking along similar lines for ceilo
21:07:39 <mikal> ttx: juno-2 clashes with OSCON
21:07:45 <mikal> ttx: do you see that being a problem?
21:07:48 <dolphm> mikal: known issue, won't fix?
21:08:01 <mikal> I'm ok with that, just checking
21:08:10 <ttx> mikal: we discussed it. sdague proposed to run the milestone
21:08:28 <mikal> Cool
21:08:49 <ttx> we don't expect that much of an impact... milestones are just point in time. Crazy ones, I'll admit it, but not so much of a big deal
21:08:57 <SlickNik> eglynn: Trove is going later (Aug) due to some restrictions on the part of the organizers.
21:08:59 <ttx> feature freeze is more... challenging
21:09:18 <SergeyLukjanov> no plans for running mid-cycle meetup re sahara atm
21:09:43 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2014-May/035340.html
21:09:50 <eglynn> SlickNik: August more problematic for us lazy Europeans, peeps want to do crazy things like go off on vacation ;)
21:09:54 <dolphm> are there any projects that *don't* want to participate at all in feature proposal freeze?
21:10:05 <ttx> so if you see an issue with it, just reply to the thread while it's still time
21:10:15 <eglynn> dolphm: how slushy would it be?
21:10:38 <dolphm> eglynn: slushy?
21:10:38 <ttx> dolphm: swift does not follow the common feature freeze, so doesn't follow FPF either
21:10:52 <zaneb> IME telling people there is a FPF is helpful even if you don't enforce it ;)
21:10:58 <eglynn> dolphm: slushy == not strictly enforced
21:10:59 <ttx> dolphm: I think ceilometer never followed FPF yet
21:11:14 <notmyname> dolphm: yes, what zaneb said
21:11:15 <ttx> that's about it
21:11:31 <zaneb> eglynn: it's not enforced centrally, so you can do what you like :)
21:11:33 <SlickNik> zaneb: +1
21:11:35 <dolphm> ack
21:11:38 <SergeyLukjanov> ttx, I'm planning to make soft FPF in Juno for sahara
21:11:47 <ttx> "not enforced centrally" means I don't enforce anything
21:11:48 <eglynn> historically, how strictly has it been enforced in projects for which it applies?
21:12:00 <eglynn> (even if not centrally enforced)
21:12:27 <ttx> eglynn: like all freezes, it's a tool
21:12:29 * eglynn is just wondering whether folks will tend to treat it as the dog that didn't bark
21:12:41 <ttx> eglynn: it's not about preventing stuff, it's about focus and communication
21:12:48 <eglynn> ttx: cool enough, got it
21:12:54 <dolphm> ttx: ++
21:12:59 <zaneb> eglynn: just use your judgement. the value is being able to say 'I told you so' when your judgement is that it's too late
21:13:11 <eglynn> zaneb: fair point
21:13:12 <ttx> make sure the change is worth late review disruption
21:13:22 <ttx> if you don't have review contention, then FPF is useless
21:13:55 <ttx> OK, anything else on that topic ?
21:13:59 <eglynn> so just to clarify FPF is only ever applied to the *-3 milestone?
21:14:12 <eglynn> ... i.e. we go to the wire on j1 & j2
21:14:18 <dolphm> i'm also wondering how other projects envision FPF vs -specs repos -- does FPF still mean the implementation being *proposed* in gerrit? or does it mean the cutoff for -specs proposals to be *merged*?
21:14:19 <notmyname> IMO mostly it comes down to communications. since there isn't a whole lot of enforcement that can actually be done in an open-source project like ours, it's mostly about setting expectations and getting people to focus on the "right" things at the right time
21:14:31 <dolphm> eglynn: yes
21:14:32 <ttx> eglynn: yes it's applied to feature freeze, which coincides with j-3
21:14:37 <eglynn> notmyname: well put
21:14:40 <SlickNik> eglynn: yes, correct.
21:14:54 <zaneb> notmyname: +1
21:15:03 <mestery> notmyname: Agree with that sentiment
21:15:26 * eglynn is thinking that we'll try FPF in ceilo this time, assuming prior buy-in from the core team
21:15:26 <notmyname> dolphm: -specs are new, so that's TBD (at least for swift)
21:15:26 <ttx> FWIW with the simple tagging process we'll be using for milestones, feature freeze might just happen on the Thursday rather than on the Tuesday
21:15:33 <ttx> I still need to test the process
21:15:48 <ttx> so being on labor day week will have limited impact
21:16:11 <dolphm> notmyname: ++ i just want devs to have consistent expectations across projects
21:16:37 <eglynn> dolphm: that's sane
21:17:05 <notmyname> dolphm: specs are just ideas and design guidelines. the code is where the feature is, so I'd imagine that a feature freeze has to do with the code, not the specs repo
21:17:05 <ttx> notmyname: yes. For some freezes it's also about communicating to other teams. Like StringFreeze exceptions needing heads-up to translators team
21:17:51 <dolphm> notmyname: agree, i'm just worried there's room for a conflicting interpretation this cycle
21:17:51 <eglynn> surely the churn in the specs repos will be naturally frontloaded to the start of the cycle?
21:18:05 <ttx> dolphm: I'd say specs proposals to be merged -- but yeah that's a bit open to discussion
21:18:41 <eglynn> i.e. if it ain't in the specs repo by j1, or shortly thereafter, it's not realistically gonna land in Juno, or?
21:18:59 <ttx> eglynn: you're new to the job, aren't you ?
21:19:07 <zaneb> lol
21:19:09 <eglynn> ttx: touche!
21:19:16 <ttx> eglynn: unfortunately, people propose stuff ALL THE TIME
21:19:34 <ttx> which makes tracking incoming features so challenging
21:19:37 <zaneb> ttx: I agree with notmyname; FPF should mean implementation patches posted
21:19:54 <ttx> zaneb: that's how we always did it yes
21:20:10 <ttx> zaneb: so it should also mean design merged, obviously :)
21:20:11 <eglynn> sure, but we effectively do a soft "lock down" on the specs repos after a certain point in the cycle?
21:20:11 <jgriffith> I'm unsure what the big concern is?  Projects always have had exception process if needed?
21:20:15 <dolphm> "Juno development is still open for another week, and here's a critical +10,000 line patch that will make suddenly OpenStack useful."
21:20:28 <zaneb> I don't actually care about blueprints at all ;)
21:20:37 <notmyname> zaneb: +1 :-)
21:20:39 <dolphm> s/suddenly OpenStack/OpenStack suddenly/
21:20:40 <ttx> eglynn: I'd say it's open for projects to choose. It's still very much an experiment at this point
21:20:55 <zaneb> spec repo is just a communication tool
21:21:01 <notmyname> eglynn: I'd encourage you to not have strict rules about who or what can happen when. it's about setting expectations and guiding, not dictating who does what when
21:21:07 <dolphm> eglynn: i assume you'd just be landing specs to a K directory rather than Juno
21:21:21 <dolphm> eglynn: if you even have time/interest to review them during the juno cycle
21:21:21 * jgriffith prefers strict rules, chaos sucks
21:21:22 <jgriffith> :)
21:21:23 <ttx> eglynn: we'll let projects play with options and maybe try to converge later
21:21:25 <sdague> historically FPF was an attempt to move the wild end rush that hits nova, neutron, and cinder back
21:21:26 <eglynn> dolphm: yep, that would work
21:21:37 <sdague> so that code was actually landable by freeze
21:21:52 <eglynn> notmyname: yep, that makes sense
21:22:25 <notmyname> ttx: (et al): speaking of feature freezes, Swift will have one starting next week while we do the storage policy integration work (yay it's almost done and delivered!)
21:22:36 <ttx> notmyname: great!
21:22:56 <ttx> OK, I think it's time to move to next topic, unless someone has another question about schedule
21:23:21 <ttx> #topic One-to-one sync points with incubated projects
21:23:50 <ttx> At the summit it was suggested that rather than having incubated projects have some time at the end of the meeting... (if any left)
21:24:01 <ttx> they should have their own 1:1s sync points
21:24:18 <jgriffith> ttx: 's calendar just became very booked
21:24:28 <ttx> I'm fine with trying that, if we can do them on a day that is not Tuesday
21:24:54 <ttx> devananda, kgriffs, jraim: if you are around, feel free to comment
21:24:56 <dolphm> ttx: so, monday?
21:25:21 <devananda> monday works for me
21:25:28 <ttx> Monday could work. Otherwise I was thinking wednesday or thursday :)
21:25:39 <ttx> will depend on which times are available
21:25:48 <ttx> but i'll try to have them all on same day
21:26:06 <ttx> devananda, kgriffs, jraim: i'll be in touch with each of you
21:26:15 <devananda> thanks!
21:26:18 <ttx> to see if we can find a common day
21:26:24 <ttx> that would just be a 15-min slot
21:26:57 <ttx> #action ttx to contact devananda, kgriffs, jraim to plan incubated project 1:1s sync
21:27:14 <ttx> devananda: makes sense to move to 1:1 sync rather than wait until meeting end ?
21:27:33 <devananda> ttx: it makes sense to me
21:27:48 <devananda> ttx: at least for ironic, which is tracking the release process closely now
21:27:50 <ttx> we might even be able to fit in a 10-min slot for each project
21:27:59 <ttx> given the discussions we had last cycle
21:28:13 <ttx> they all fit is way less :)
21:28:23 <ttx> OK, we'll try this
21:28:31 <ttx> #topic Open discussion
21:28:36 <jeblair> do people have thoughts on how should specs repos be named?  we decided they should be per-program, but many of them are named for the flagship project in that program.
21:28:36 <jeblair> examples: cinder, glance, neutron, nova, oslo -specs repos all exist today; swift, ceilometer, ironic are proposed.
21:28:36 <jeblair> some specs repos named for programs do exist: qa, tripleo, infra; though none of them have flagship projects
21:28:36 <jeblair> this came up because of a proposal to create the identity-specs repo
21:29:02 <devananda> jeblair: hmm, good point
21:29:04 <ttx> jeblair: I'd very much prefer some amount of convergence there
21:29:12 <devananda> ironic has at least one substantial other-project, IPA
21:29:17 <mikal> I'd prefer to defer renaming until we have fewer open reviews to be honest
21:29:30 <devananda> today it's still fairly small, but it could grow to a size where it needs its own specs in a cycle
21:29:31 <eglynn> jeblair: yep, I'd be happy with telemetry-specs
21:29:50 <devananda> or where ironic-specs might be confusing if we lump both together
21:29:53 <mestery> Renaming would be a mild pain at the moment, I agree with mikal.
21:30:02 <ttx> jeblair: i can't wait until the program-concept-haters make us rename all of those because they conflict with openstack names
21:30:04 <SergeyLukjanov> IMO program-based name works better for it, but launchpad project is named after the main project in program
21:30:12 <dolphm> markwash: ttx: "ttx agrees with expanding the glance-ptl group to more than one person (ttx, 16:12:49)" ?
21:30:12 <notmyname> objectstorage-specs is more unwieldy than swift-specs
21:30:18 <mtreinish> jeblair: we used qa-specs because it was supposed to be both tempest and grenade specs, but in practice it's just tempest :)
21:30:19 <jgriffith> SergeyLukjanov: +1
21:30:19 <dolphm> any context there
21:30:21 <jeblair> mikal: renaming doesn't affect open reviews, but we can ceirtanly defer
21:30:24 <markwash> dolphm: for glanceclient releases
21:30:40 <ttx> dolphm: the -ptl group is the one allowed to tag releases in Gerrit
21:30:44 <devananda> notmyname: how about bare-metal-provisioning-specs :)
21:30:54 <ttx> dolphm: -releasers would be more accurate
21:31:02 <SergeyLukjanov> data-processing-service-specs
21:31:06 <notmyname> devananda: now that's just crazy. unless you are naming it that ironically
21:31:21 <eglynn> jeblair: were the -specs repo creation patch hasn't landed yet, best to rename sooner rather than later, or?
21:31:28 <ttx> dolphm: so if you want to delegate that task, you add people to the -ptl group. Makes sense ?
21:31:34 <eglynn> jeblair: ... /me thinking of https://review.openstack.org/94044 for ceilometer-specs
21:31:35 <dolphm> ttx: yeah
21:31:48 <devananda> also on -specs, the question was raised on ironic's proposal. how do folks feel about separating -core from -specs-core?
21:31:53 <jeblair> eglynn: yeah, we're holding off on the pending ones until at least now to see if we should change them
21:32:00 <notmyname> devananda: I'm pretty much against that
21:32:25 <markwash> I prefer a separate -core from -specs-core for glance
21:32:27 <dolphm> devananda: the implication being that you have a subset of -core that is -specs-core?
21:32:32 <eglynn> devananda: we discussed this with the ceilo core team and didn't see the need for a smallish core group
21:32:35 <notmyname> markwash: why?
21:32:37 <ttx> jeblair: next time you have ideas for contentious topics like this, feel free to add to the agenda :)
21:32:38 <sdague> devananda: nova has 2 separate groups
21:32:39 <markwash> but one can always add -core as an included group in -core-specs
21:32:49 <mikal> nova already has different core groups for the two repos
21:32:50 <eglynn> devananda: but that is the way nova do it (with nova-drivers << nova-core)
21:32:59 <mikal> One is currently a subset of the other though
21:33:05 <dolphm> mikal: why bother?
21:33:06 <sdague> there historically was always a nova-drivers that had the ability to target blueprints, which was a subset
21:33:06 <jeblair> ttx: indeed.  sorry.
21:33:20 <mikal> dolphm: its historical mostly
21:33:25 * ttx thought he could get to bed early :)
21:33:26 <markwash> notmyname: core is mostly about good code review, drivers is mostly about product sanity
21:33:28 <devananda> mikal: any plans for intersecting rather than subset-of groups?
21:33:34 <anteaya> ttx heh
21:33:43 <SlickNik> devananda: FWIW trove has 2 separate groups too. (core and drivers)
21:33:50 <mikal> devananda: as in having people in specs-core who aren't nova-core?
21:33:56 <devananda> mikal: right
21:34:06 <notmyname> those who have responsibility for managing the code itself (ie core) should still have the ability to discuss the stuff that will be proposed to the code (specs-core, ie drivers)
21:34:09 <ttx> sdague: not a subset. a different group that usually was a subset
21:34:11 <zaneb> I wouldn't be comfortable choosing who from heat-core to kick out of heat-drivers
21:34:20 <markwash> I have a glance-specs-core member who is not a glance-core
21:34:26 <mikal> devananda: I am not opposed to it, but I know some of the drivers members don't like the idea
21:34:27 <devananda> mikal: might be crazy. but also might be good for folks with deep operational knowledge who aren't review core
21:34:33 <markwash> its a good way to get product involvement from openstack companies
21:34:35 <markwash> not always just devs
21:34:55 <mikal> The counter arguement is that it sets expectations that a design is "ok to merge" when nova-core might not agree
21:34:57 <devananda> i wouldn't want that involvement from companies (they'll just approve their own BPs) but rather from operators
21:35:10 <ttx> mikal: yep, was about to say that
21:35:14 <dolphm> mikal: ++ that's my concern
21:35:15 <mikal> i.e. a consistent bar is required across both
21:35:16 <devananda> but - that may be achievable merely by better socialization
21:35:21 <sdague> devananda: I think you can get plenty of feedback in the current system
21:35:25 <ttx> mikal: and putting load on reviewers that may or may not agree with design
21:35:27 <markwash> mikal: but of course, we already have that situation with part of nova core saying yes and part of nova core saying no
21:35:28 <sdague> operators can +1 / -1 things
21:35:28 <mestery> Neutron has a separate group which currently encompasses neutron-core.
21:35:35 <mikal> The flip side is that I feel like we're failing to acknowledge the importance of ops reviews at the moment
21:35:38 <devananda> sdague: gotcha
21:35:43 <mestery> I like the idea of adding operators outside the scope of -core though.
21:35:44 <ttx> I'm fine with people experimenting with both options at this point
21:35:54 <ttx> BUT we kinda need to chosse on the naming front
21:36:01 <ttx> choose*
21:36:11 <jeblair> back to bikeshedding on the name -- does anyone think that, in the long run, we should use project (eg nova) as opposed to program (compute)?
21:36:14 <eglynn> hmmm, I'd hope such non-code-core specs approvers wouldn't morph into the commercial software world's concept of a "product manager"
21:36:14 <sdague> right, but having someone who isn't delivering code be able to approve in blueprints seems... pretty antithetical to our culture
21:36:16 <ttx> between program-based naming and project-based naming
21:36:18 <mikal> ttx: I think ultimately some sort of openstack-wide guideline would be a good idea
21:36:23 <mikal> ttx: but perhaps that's a TC thing
21:36:34 <ttx> mikal: right, but I'd wait for the end of the experiment :)
21:36:39 <mikal> Its less confusing to newcomers if we're consistent
21:36:41 <jgriffith> ttx: project please... proliferation isn't going to be helpful in this case I don't think
21:36:45 <dolphm> jeblair: for specs repos?
21:36:50 <jeblair> dolphm: yes
21:36:50 <mikal> ttx: do you have a timeline for declaring the experiment done in mind?
21:36:52 <ttx> at this point let's let a thousand (or a dozen) flowers bloom!
21:36:55 <mikal> ttx: "juno"?
21:36:58 <devananda> program-based makes much more sense if we're using specs for programs like infra and tripleo
21:37:01 <ttx> mikal: yes
21:37:02 <eglynn> we should decide very quickly one way or the other on naming
21:37:06 <dolphm> jeblair: nova chose nova-specs, keystone chose identity-specs
21:37:16 <eglynn> ... otherwsise we block the new -specs repos being created
21:37:27 <dolphm> devananda: ++ and for including the client in the -specs process
21:37:27 <eglynn> ... at a time when there should be a flood of specs
21:37:34 <dolphm> clients*
21:37:40 <ttx> yeah, without convergence, discovery will be sucky
21:37:50 <mikal> ttx: what about handing ops -2 / +2, but not approve? Could that even be expressed in gerrit?
21:37:54 <ttx> i.e. I woudn't necessarily find identity-specs
21:38:12 <sdague> mikal: you only need to hand folks -2 if their -1s are valid, and being ignored
21:38:13 <jeblair> i almost think we should go with keystone-specs for now, and then if we want to rename the project-named ones later, do that
21:38:19 <sdague> culture really fixes most of this
21:38:29 <jeblair> basically because so many programs went with the project name
21:38:36 <notmyname> as awkward as it is in some cases, this should be {program}-specs
21:38:48 <ttx> mikal: won't answer for gerrit. For the rest, try whatever you think will work for you, we'll converge later
21:38:50 <zaneb> sdague: and ditto for +1's if you leave out approve rights
21:38:55 <jeblair> notmyname: i agree
21:39:02 <dolphm> sdague: mikal: how often do operators seriously oppose a change such that they would -2?
21:39:05 <notmyname> because how else does one know where to look for client and other projects?
21:39:07 <ttx> but giving +2 without approve would sure be confusing
21:39:16 <markwash> jeblair: keystone-specs is project-named, though, right?
21:39:25 <sdague> dolphm: but on the counter, how often are they -1ing things and getting run rough shot over?
21:39:27 <markwash> oh nm
21:39:29 <mikal> Can't we address naming confusion by putting the specs repo name in the contributing file for each project?
21:39:33 <jeblair> markwash: yep.  okay, let me try again
21:39:37 <notmyname> jeblair: so that being said, our current proposal should be renamed from swift-specs to objectstorage-specs
21:39:47 <ttx> mikal: that's plan B if we can't converge on naming yes
21:39:47 <mikal> dolphm: I have no data on that, but I am sure there are things core likes which ops don't
21:39:50 <dolphm> markwash: identity-specs is what is proposed atm
21:39:55 <jeblair> question 1) should the _end goal_ be to use project-name or program name?
21:39:55 <ttx> A bit suboptimal imho
21:40:15 <dolphm> sdague: i suppose that's what i'm asking - how often would a -2 come in handy
21:40:17 <annegentle_> I like project-specs due to the speculative nature of the specs
21:40:26 <notmyname> what's the reasoning for using {project}-specs? is it only for ease of speaking it (in English)?
21:40:27 <sdague> I've done the -1 override analysis a bunch of times, in different formats, we really don't override people's -1s very often
21:40:32 <annegentle_> and you know me, usually I'd argue for "call it the thing it is" but in this case it's not official at all yet
21:40:34 <jeblair> quostion 2) should we try to converge to the end goal now (and change the current pending proposals); or go with project for a bit then rename them all later?
21:40:36 <ttx> jeblair: program-specs reflects the fact that we said "one repo per program"
21:40:41 <sdague> in the last 2 months nova overrode -1s ~ 3% of the time
21:40:54 <mikal> sdague: oh interesting, I wasn't aware of any numbers on that
21:41:07 <eglynn> jeblair: I'd prefer a decision now, that we then stick to
21:41:10 <sdague> mikal: I ran it this morning, on list, let me point
21:41:14 <ttx> jeblair: but then for programs with a main project it creates mouthful specs repo name
21:41:24 <ttx> where the project name can easily be used
21:41:30 <sdague> mikal: http://lists.openstack.org/pipermail/openstack-dev/2014-May/035269.html
21:41:43 <mikal> sdague: tahnks
21:41:47 <jeblair> so actually, we do have "short" program names
21:41:50 * mikal is still digging out of email backlog post summit
21:41:59 <sdague> but similar things for CI systems. Smokestack only had 2 -1s in 2013 that were overridden
21:42:01 <jeblair> we have "object-api" rather than "object-storage-api"
21:42:12 <jeblair> so we could go with "object-specs" for swift
21:42:22 <notmyname> ttx: except, there do tend to be people who focus on client side rather than server side, and I don't want to add psych barriers to contributions if they have to contribute to the "main" project specs repo. ie don't have classes of projects in the program
21:42:34 <notmyname> jeblair: I'm good with that :-)
21:42:40 <mikal> sdague: I am sure that's different for our current third party CIs
21:42:46 <sdague> mikal: it is
21:42:51 <annegentle_> jeblair: but we don't want to keep maintaining object-api, netconn-api, we'd rather those act like specs too
21:42:54 <annegentle_> jeblair: speculative
21:42:58 <sdague> but this was counter to the fact that people ignore reliable CI systems
21:43:03 <sdague> they don't
21:43:03 <ttx> jeblair: I'd say 1) short program name should be the end goal but 2) some tolerance should be applied to programs with main projects because that would be more discoverable
21:43:25 <sdague> we are a concensus driven culture, and reasonable objects are very very rarely ignored
21:43:37 <dolphm> annegentle_: identity-api is super useful to us - what do you propose we do with all those docs?
21:43:43 <ttx> notmyname: so you would have one repo per project under swift ?
21:43:50 <eglynn> sdague: reasonable objections?
21:43:51 <notmyname> ttx: absolutely
21:43:57 <ttx> i.e. python-swiftclient-specs ?
21:44:01 <sdague> eglynn: that too :)
21:44:15 <dolphm> annegentle_: we also discussed identity-specs proposals linking to in-progress identity-api reviews to illustrate api impact
21:44:16 <annegentle_> dolphm: you're the only project using it like a spec, and we also don't publish it. That's what we want, just inside either -specs or /projectname repos
21:44:18 <jgriffith> notmyname: why?
21:44:24 <annegentle_> dolphm: yep that would be cool
21:44:24 <notmyname> ttx: one specs repo for swift, python-swiftclient, and swift-bench
21:44:25 <devananda> i see no benefit to splitting the specs repositories for projects that are part of the same program apart
21:44:25 <ttx> jeblair: looks like some programs want to go per-project for their specs repo anyway
21:44:35 <eglynn> sdague: don't underestimate the power of inertia ;)
21:44:38 <eglynn> ... or "facts on the ground"
21:44:42 <sdague> :)
21:44:48 <zaneb> ttx: on one hand, that's what we have with launchpad. OTOH that's what we have with launchpad and it is a pain
21:44:52 <dolphm> annegentle_: i'd buy that as an argument for putting the api docs into -specs
21:44:52 <jeblair> ttx: who?
21:44:55 <notmyname> jgriffith: because oftentimes a single feature is needed to be exposed in both the server and client projects
21:45:00 <annegentle_> dolphm: would love that.
21:45:04 <devananda> notmyname: i think your "absolutely" was meant as "no"
21:45:05 <ttx> jeblair: swift
21:45:12 <jgriffith> notmyname: sure, but the specs process now enables us to add that sort of thing
21:45:14 <jeblair> ttx: i believe notmyname wants 'object-specs' and it will encompass all 3 programs
21:45:17 <jeblair> er projects
21:45:20 <notmyname> devananda: depends on your lag of when who said what :-)
21:45:21 <jeblair> notmyname: right?
21:45:25 <ttx> Now I'm confused
21:45:32 <dolphm> annegentle_: but then i want to take that a step further, and put all our user-facing documentation into -specs, so that you're required to show doc impact before your feature is approved :)
21:45:36 <jgriffith> jeblair: no, he wants three specs repos
21:45:47 <notmyname> jeblair: that is correct. I want one shared specs repo for swift, python-swiftclient, and swift-bench
21:45:55 <dolphm> annegentle_: identity-api is essentially documentation driven design already
21:45:55 <jgriffith> notmyname: gahhh
21:45:59 <jeblair> notmyname: excellent idea, i fully support it.  ;)
21:46:00 <notmyname> hehehe
21:46:04 <jgriffith> ok, everybody is apparantly saying the same thing
21:46:04 <annegentle_> dolphm: yes
21:46:06 <devananda> notmyname: i think you win the the most-confusingly-timed-reply award today.
21:46:17 <jgriffith> notmyname: I agree
21:46:25 <annegentle_> yes  please put all the specs in <proj>-specs
21:46:28 <ttx> notmyname: why would you answer "absolutely" to my "notmyname: so you would have one repo per project under swift ?" ?
21:46:28 <annegentle_> including api specs
21:46:38 <eglynn> notmyname: /me similarly for telemetry (encompassing ceilo, ceiloclient & pycadf)
21:46:46 <dolphm> annegentle_: (was that also a dig against <program>-specs?)
21:46:47 <jeblair> okay, i'm not hearing any huge objection to program-specs; and some amount of consensus for it
21:46:59 <devananda> ++ program-specs
21:47:05 <annegentle_> dolphm: jeblair I'm against program-specs
21:47:18 <ttx> notmyname: that's where my confusion stems from :)
21:47:19 <notmyname> ttx: either there was some miss timing or I was reading it as swift the program, not project (my own confusion)
21:47:26 <jeblair> annegentle_: why?
21:47:27 <ttx> ok
21:47:48 <annegentle_> dolphm: jeblair: because we could one day have multiple repos in a single program -- like Deployment
21:47:54 <notmyname> ttx: also, I'm on pain meds today ;-)
21:47:56 <ttx> we still have 13 more minutes to violently agree
21:48:05 <jeblair> annegentle_: we have lots of repos in single programs
21:48:11 <eglynn> would a non-binding vote clarify to see if there's any kind of rough consensus emerging?
21:48:14 <ttx> notmyname: oh right. get well soon, btw
21:48:16 <devananda> annegentle_: we already have that. and that's precisely why fokls want a single specs repo per project
21:48:30 <devananda> gah
21:48:33 <dolphm> annegentle_: we already do: keystone, python-keystoneclient, and (soon) keystonemiddleware
21:48:34 <jeblair> annegentle_: infra has 43 projects in one program.  :)
21:48:38 <devananda> s/project/program/ in my previous sentence
21:48:52 <notmyname> proposed vote: one repo per program. named as {program}-specs
21:49:05 <jeblair> annegentle_: i think the single specs repo per program helps with that case
21:49:17 <jeblair> annegentle_: and notmyname gave a very good specific example
21:49:20 <eglynn> yep let's nail our colours to the mast
21:49:24 <ttx> notmyname: +1
21:49:28 <dolphm> ttx: can you run a vote next week?
21:49:31 <annegentle_> devananda: so how does the review process work if (again speculating) multiple solutions for deployment get proposed? Say chef and puppet people want to work on Deployment program, do they work in deployment-specs? or chef-specs and puppet-specs?
21:49:41 <zaneb> notmyname: those are two separate questions imo
21:49:42 <dolphm> ttx: or now, if everyone is here
21:49:55 <eglynn> I'd prefer now
21:49:57 <ttx> dolphm: I don't think we need to vote, every -specs user so far has +1ed it
21:50:00 <jeblair> i asked at this meeting because i thought that getting ptl consensus was the most emportant
21:50:02 <jeblair> important
21:50:11 <notmyname> jeblair: yes, that
21:50:18 <ttx> Anne disagrees but hen she doesn't have a -specs repo :P
21:50:31 <markwash> discoverability doesn't seem that hard to me to be honest
21:50:35 <annegentle_> so my two concerns may be too futuristic: 1) naming as an "offical" program gives an officialness to the spec and publishing and 2) if there are multiple solutions within a program that may have different specs, how will reviews work?
21:50:35 <dolphm> ttx: i want to understand her argument though :)
21:50:37 <lifeless> annegentle_: tripleo-specs, if they're getting involved in the tripleo program
21:50:46 <devananda> annegentle_: there's another question buried in there -- do chef and puppet tools have a place within the Deployment program? (and that's a much larger discussion)
21:50:51 <markwash> so I don't see a really big need for consistency
21:51:06 <annegentle_> ttx: :)
21:51:09 <devananda> ttx: I would rather not block the creation of ironic-specs another week waiting for a vote
21:51:20 <annegentle_> devananda: yeah that's why I may be either conflating or borrowing from the future
21:51:26 <ttx> ok let's record this
21:51:30 <eglynn> devananda: +1 (s/ironic/ceilo/)
21:51:33 <annegentle_> ttx: are you going to rename nova-specs to compute-specs?
21:51:36 <dolphm> if a "program" has isolated communities with, let's say, non-converging interests, they should be separate programs IMO
21:51:41 <annegentle_> perhaps I just misunderstand program names
21:52:01 <devananda> dolphm: right
21:52:04 <jeblair> annegentle_: i think we would want to rename nova-specs to compute-specs if we decide to go this way
21:52:05 <dolphm> assuming they both have justifiable reasons to co-exist (which is obviously the case for the chef & puppet example)
21:52:18 <devananda> dolphm: but let's not bikeshed on that now :)
21:52:27 <markwash> considering how much work goes into writing a spec, I don't see how the cost of finding the right repo could possibly matter
21:52:34 * dolphm is reels himself back in
21:52:37 <mikal> I wouldn't have a problem with nova-specs being renamed compute-specs, but I don't see the rush either
21:52:40 <ttx> #startvote End goal of one spec repo per program, named program-specs ? yes, no, abstain, i_want_all_options_opened
21:52:41 <openstack> Begin voting on: End goal of one spec repo per program, named program-specs ? Valid vote options are yes, no, abstain, i_want_all_options_opened.
21:52:42 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
21:52:52 <jeblair> #vote yes
21:52:54 <mikal> #vote yes
21:52:54 <devananda> #vote yes
21:52:57 <mtreinish> #vote yes
21:52:58 <ttx> markwash: your option is i_want_all_options_opened
21:52:58 <eglynn> #note yes
21:53:05 <markwash> #vote i_want_all_options_opened
21:53:09 <dolphm> #vote yes
21:53:11 <mestery> #vote yes
21:53:12 <notmyname> #vote yes
21:53:14 <zaneb> #vote yes
21:53:17 <jgriffith> #vote yes
21:53:18 <SlickNik> #vote yes
21:53:21 <markwash> could have just called it "vote 'markwash'"  :-)
21:53:25 <david-lyle> #vote yes
21:53:30 <devananda> eglynn: i think you typo'd s/n/v/
21:53:32 <zaneb> strongly +1 on first part, genuinely don't care about naming
21:53:34 <markwash> eglynn: did you mean note? or vote? :-)
21:53:44 <dolphm> zaneb: vote markwash then
21:53:48 <eglynn> #vote yes
21:53:55 <ttx> do we have all PTLs with specs projects in the vote ?
21:54:07 <eglynn> devananda, markwash: thanks! /me has fat fingers :)
21:54:11 <SlickNik> FWIW, trove isn't moving to a -specs workflow quite yet, but we'd like 1 {database|trove}-spec repo for all projects in the program when we do decide to move to it.
21:54:20 <ttx> I think we do
21:54:24 <ttx> #endvote
21:54:24 <zaneb> dolphm: oh, is that what that meant
21:54:25 <openstack> Voted on "End goal of one spec repo per program, named program-specs ?" Results are
21:54:26 <openstack> yes (12): SlickNik, zaneb, mestery, notmyname, mtreinish, eglynn, jeblair, devananda, jgriffith, mikal, dolphm, david-lyle
21:54:27 <openstack> i_want_all_options_opened (1): markwash
21:54:30 <jeblair> okay, i will ask that pending specs repo reviews be updated with program-specs and will schedule renames of existing repos in a lazy manner (not too soon)
21:54:35 <ttx> zaneb: too late! :)
21:54:46 <dolphm> yes (11), i_want_all_options_opened (2) #zaneb
21:54:48 <annegentle_> jeblair: ttx: ok thanks for hearing me out! I'm fine with the naming
21:54:51 <jeblair> thanks everyone and ttx, sorry for keeping you up
21:54:54 <notmyname> jeblair: can you push a new patch over the ones there?
21:54:55 <ttx> markwash: feel free to be an outlier
21:55:04 <markwash> I don't mind being renamed
21:55:06 <notmyname> markwash: it's fun being an outlier ;-)
21:55:11 <annegentle_> ttx: I have one other comment about -specs repos if I may
21:55:13 <markwash> actually it would be easier to be renamed sooner jeblair
21:55:15 * notmyname has experience from days on TC
21:55:17 <ttx> annegentle_: you may
21:55:20 <markwash> since we just added our template review today
21:55:22 <zaneb> #vote outlier
21:55:25 <eglynn> jeblair: thank you for bringing it to the table in time to avoid needless renaming
21:55:38 <annegentle_> pre-incubating projects, like barbican, shouldn't use an unaltered -spec template as it has some openstack branding apparently?
21:55:46 <markwash> what will we call identity-specs when keystone is no longer an IdP ?
21:55:46 <jeblair> markwash: we are scheduling a rename outage for friday, can do it then
21:55:54 <zaneb> notmyname: pretty sure this is the first meeting where you and I have agreed on everything :D
21:55:57 <annegentle_> so we might need to think about the migration of specs as programs move through incubation
21:56:06 <notmyname> zaneb: :-)
21:56:07 <dolphm> i'd also really like to see a single spec template -- i was just going to reference nova's existing template if possible
21:56:17 <ttx> annegentle_: agree, they probably should not
21:56:33 * ttx admits not having looked at specs template yet
21:56:33 <jeblair> dolphm: there's lots of comonality, but some variation is needed i think
21:56:35 <annegentle_> ttx: that's all I was going to note
21:56:39 <markwash> dolphm: there are some nova-specific notes in it, which makes some sense to me
21:56:52 <ttx> so much for a short meeting :)
21:56:52 <jeblair> dolphm: (eg, horizion has some specific needs, and infra does too)
21:56:56 <markwash> e.g. notes about conductor changes and periodics
21:57:07 * ttx blames jeblair for messing with his meeting time management
21:57:10 <zaneb> ttx: work expands to fill the time available
21:57:14 <dolphm> markwash: all the ones i see could basically be s/nova/keystone/
21:57:14 <markwash> haa
21:57:19 <jeblair> ttx: you're totally going to finish on time.  ;)
21:57:26 <lifeless> so is it nova-specs or compute-specs :)
21:57:32 <dolphm> lifeless: compute-specs
21:57:37 <markwash> nova-compute-specs
21:57:40 <ttx> jeblair: that's because I'm so good at it :)
21:57:49 <markwash> /me lies
21:57:50 <lifeless> so we need to rename the existing ones :/
21:57:53 <ttx> openstack-compute-nova-specs
21:57:54 <jeblair> ttx: you are
21:58:20 <jeblair> lifeless: yes, it's our eternal burden in infra to rename projects
21:58:41 <mikal> jeblair: you love it!
21:58:55 <ttx> ok... Anything else, anyone ?
21:58:58 <dolphm> i thought that's what infra was for
21:59:14 <mikal> dolphm: and restarting etherpad
21:59:19 <dolphm> mikal: +++
21:59:20 <jeblair> dolphm: we just haven't gotten around to renaming ourselves the 'project renaming project'
21:59:21 <eglynn> LOL :)
21:59:33 <dolphm> jeblair: ooh, +1
21:59:34 * anteaya adds that to infra agenda
21:59:50 <SlickNik> lol
21:59:55 <ttx> you should propose a rename-as-a-service for incubation
22:00:08 <jeblair> ttx: i would love that
22:00:12 <ttx> because that process is really way too manual
22:00:16 <ttx> not self-service at all
22:00:17 <mikal> We have that though
22:00:22 <mikal> Just send infra an email, they do the thing
22:00:25 * devananda notes that ironic's program name "bare metal" also duplicates the colloquial reference for the nova "baremetal" driver
22:00:26 <mikal> Its a meat based service
22:00:35 <ttx> mikal: it's fanatical support.
22:00:41 <jeblair> bacon as a service
22:00:43 <ttx> on these last words...
22:00:44 <mikal> ttx: heh
22:00:47 <ttx> #endmeeting