21:03:38 #startmeeting project 21:03:39 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:03:42 The meeting name has been set to 'project' 21:03:43 First meeting from Juno era 21:03:44 o/ 21:03:47 * SergeyLukjanov flying above Boston atm, lurking 21:03:52 Smallish agenda, should be quick 21:04:10 I sometimes wonder when Sergey sleeps or takes vacation 21:04:25 #link http://wiki.openstack.org/Meetings/ProjectMeeting 21:04:34 Following a suggestion from notmyname at the summit, here is the combined log of the 1:1s sync from today: 21:04:44 #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-05-20-11.45.html 21:05:24 #topic Juno Release Schedule 21:05:31 #link https://wiki.openstack.org/wiki/Juno_Release_Schedule 21:05:38 So this is the proposal from the Design Summit 21:05:39 wow, combined log looks pretty nice 21:05:47 which we should officialize ASAP 21:05:57 let me check my emails for complains 21:06:08 . 21:06:15 SergeyLukjanov: +1 to that, it's quite nice! 21:06:16 which weeks are shaping up for mid-cycle meetups? 21:06:26 ok, no objection so far 21:06:50 ttx: no complains here 21:06:53 eglynn: July 9, 10, 11 for keystone 21:06:56 Unless something significant is raised that makes me reconsider, I'll probably set it in stone by Thursday 21:07:06 we've got a swift hackathon the first week of june 21:07:07 eglynn: first half of July is a popular option 21:07:18 eglynn: Neutron has one June 17-19 (for LBaaS) and July 9-11 (nova-network parity) 21:07:25 ttx, dolphm: yep I was thinking along similar lines for ceilo 21:07:39 ttx: juno-2 clashes with OSCON 21:07:45 ttx: do you see that being a problem? 21:07:48 mikal: known issue, won't fix? 21:08:01 I'm ok with that, just checking 21:08:10 mikal: we discussed it. sdague proposed to run the milestone 21:08:28 Cool 21:08:49 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 eglynn: Trove is going later (Aug) due to some restrictions on the part of the organizers. 21:08:59 feature freeze is more... challenging 21:09:18 no plans for running mid-cycle meetup re sahara atm 21:09:43 #link http://lists.openstack.org/pipermail/openstack-dev/2014-May/035340.html 21:09:50 SlickNik: August more problematic for us lazy Europeans, peeps want to do crazy things like go off on vacation ;) 21:09:54 are there any projects that *don't* want to participate at all in feature proposal freeze? 21:10:05 so if you see an issue with it, just reply to the thread while it's still time 21:10:15 dolphm: how slushy would it be? 21:10:38 eglynn: slushy? 21:10:38 dolphm: swift does not follow the common feature freeze, so doesn't follow FPF either 21:10:52 IME telling people there is a FPF is helpful even if you don't enforce it ;) 21:10:58 dolphm: slushy == not strictly enforced 21:10:59 dolphm: I think ceilometer never followed FPF yet 21:11:14 dolphm: yes, what zaneb said 21:11:15 that's about it 21:11:31 eglynn: it's not enforced centrally, so you can do what you like :) 21:11:33 zaneb: +1 21:11:35 ack 21:11:38 ttx, I'm planning to make soft FPF in Juno for sahara 21:11:47 "not enforced centrally" means I don't enforce anything 21:11:48 historically, how strictly has it been enforced in projects for which it applies? 21:12:00 (even if not centrally enforced) 21:12:27 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 eglynn: it's not about preventing stuff, it's about focus and communication 21:12:48 ttx: cool enough, got it 21:12:54 ttx: ++ 21:12:59 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 zaneb: fair point 21:13:12 make sure the change is worth late review disruption 21:13:22 if you don't have review contention, then FPF is useless 21:13:55 OK, anything else on that topic ? 21:13:59 so just to clarify FPF is only ever applied to the *-3 milestone? 21:14:12 ... i.e. we go to the wire on j1 & j2 21:14:18 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 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 eglynn: yes 21:14:32 eglynn: yes it's applied to feature freeze, which coincides with j-3 21:14:37 notmyname: well put 21:14:40 eglynn: yes, correct. 21:14:54 notmyname: +1 21:15:03 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 dolphm: -specs are new, so that's TBD (at least for swift) 21:15:26 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 I still need to test the process 21:15:48 so being on labor day week will have limited impact 21:16:11 notmyname: ++ i just want devs to have consistent expectations across projects 21:16:37 dolphm: that's sane 21:17:05 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 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 notmyname: agree, i'm just worried there's room for a conflicting interpretation this cycle 21:17:51 surely the churn in the specs repos will be naturally frontloaded to the start of the cycle? 21:18:05 dolphm: I'd say specs proposals to be merged -- but yeah that's a bit open to discussion 21:18:41 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 eglynn: you're new to the job, aren't you ? 21:19:07 lol 21:19:09 ttx: touche! 21:19:16 eglynn: unfortunately, people propose stuff ALL THE TIME 21:19:34 which makes tracking incoming features so challenging 21:19:37 ttx: I agree with notmyname; FPF should mean implementation patches posted 21:19:54 zaneb: that's how we always did it yes 21:20:10 zaneb: so it should also mean design merged, obviously :) 21:20:11 sure, but we effectively do a soft "lock down" on the specs repos after a certain point in the cycle? 21:20:11 I'm unsure what the big concern is? Projects always have had exception process if needed? 21:20:15 "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 I don't actually care about blueprints at all ;) 21:20:37 zaneb: +1 :-) 21:20:39 s/suddenly OpenStack/OpenStack suddenly/ 21:20:40 eglynn: I'd say it's open for projects to choose. It's still very much an experiment at this point 21:20:55 spec repo is just a communication tool 21:21:01 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 eglynn: i assume you'd just be landing specs to a K directory rather than Juno 21:21:21 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 :) 21:21:23 eglynn: we'll let projects play with options and maybe try to converge later 21:21:25 historically FPF was an attempt to move the wild end rush that hits nova, neutron, and cinder back 21:21:26 dolphm: yep, that would work 21:21:37 so that code was actually landable by freeze 21:21:52 notmyname: yep, that makes sense 21:22:25 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 notmyname: great! 21:22:56 OK, I think it's time to move to next topic, unless someone has another question about schedule 21:23:21 #topic One-to-one sync points with incubated projects 21:23:50 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 they should have their own 1:1s sync points 21:24:18 ttx: 's calendar just became very booked 21:24:28 I'm fine with trying that, if we can do them on a day that is not Tuesday 21:24:54 devananda, kgriffs, jraim: if you are around, feel free to comment 21:24:56 ttx: so, monday? 21:25:21 monday works for me 21:25:28 Monday could work. Otherwise I was thinking wednesday or thursday :) 21:25:39 will depend on which times are available 21:25:48 but i'll try to have them all on same day 21:26:06 devananda, kgriffs, jraim: i'll be in touch with each of you 21:26:15 thanks! 21:26:18 to see if we can find a common day 21:26:24 that would just be a 15-min slot 21:26:57 #action ttx to contact devananda, kgriffs, jraim to plan incubated project 1:1s sync 21:27:14 devananda: makes sense to move to 1:1 sync rather than wait until meeting end ? 21:27:33 ttx: it makes sense to me 21:27:48 ttx: at least for ironic, which is tracking the release process closely now 21:27:50 we might even be able to fit in a 10-min slot for each project 21:27:59 given the discussions we had last cycle 21:28:13 they all fit is way less :) 21:28:23 OK, we'll try this 21:28:31 #topic Open discussion 21:28:36 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 examples: cinder, glance, neutron, nova, oslo -specs repos all exist today; swift, ceilometer, ironic are proposed. 21:28:36 some specs repos named for programs do exist: qa, tripleo, infra; though none of them have flagship projects 21:28:36 this came up because of a proposal to create the identity-specs repo 21:29:02 jeblair: hmm, good point 21:29:04 jeblair: I'd very much prefer some amount of convergence there 21:29:12 ironic has at least one substantial other-project, IPA 21:29:17 I'd prefer to defer renaming until we have fewer open reviews to be honest 21:29:30 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 jeblair: yep, I'd be happy with telemetry-specs 21:29:50 or where ironic-specs might be confusing if we lump both together 21:29:53 Renaming would be a mild pain at the moment, I agree with mikal. 21:30:02 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 IMO program-based name works better for it, but launchpad project is named after the main project in program 21:30:12 markwash: ttx: "ttx agrees with expanding the glance-ptl group to more than one person (ttx, 16:12:49)" ? 21:30:12 objectstorage-specs is more unwieldy than swift-specs 21:30:18 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 SergeyLukjanov: +1 21:30:19 any context there 21:30:21 mikal: renaming doesn't affect open reviews, but we can ceirtanly defer 21:30:24 dolphm: for glanceclient releases 21:30:40 dolphm: the -ptl group is the one allowed to tag releases in Gerrit 21:30:44 notmyname: how about bare-metal-provisioning-specs :) 21:30:54 dolphm: -releasers would be more accurate 21:31:02 data-processing-service-specs 21:31:06 devananda: now that's just crazy. unless you are naming it that ironically 21:31:21 jeblair: were the -specs repo creation patch hasn't landed yet, best to rename sooner rather than later, or? 21:31:28 dolphm: so if you want to delegate that task, you add people to the -ptl group. Makes sense ? 21:31:34 jeblair: ... /me thinking of https://review.openstack.org/94044 for ceilometer-specs 21:31:35 ttx: yeah 21:31:48 also on -specs, the question was raised on ironic's proposal. how do folks feel about separating -core from -specs-core? 21:31:53 eglynn: yeah, we're holding off on the pending ones until at least now to see if we should change them 21:32:00 devananda: I'm pretty much against that 21:32:25 I prefer a separate -core from -specs-core for glance 21:32:27 devananda: the implication being that you have a subset of -core that is -specs-core? 21:32:32 devananda: we discussed this with the ceilo core team and didn't see the need for a smallish core group 21:32:35 markwash: why? 21:32:37 jeblair: next time you have ideas for contentious topics like this, feel free to add to the agenda :) 21:32:38 devananda: nova has 2 separate groups 21:32:39 but one can always add -core as an included group in -core-specs 21:32:49 nova already has different core groups for the two repos 21:32:50 devananda: but that is the way nova do it (with nova-drivers << nova-core) 21:32:59 One is currently a subset of the other though 21:33:05 mikal: why bother? 21:33:06 there historically was always a nova-drivers that had the ability to target blueprints, which was a subset 21:33:06 ttx: indeed. sorry. 21:33:20 dolphm: its historical mostly 21:33:25 * ttx thought he could get to bed early :) 21:33:26 notmyname: core is mostly about good code review, drivers is mostly about product sanity 21:33:28 mikal: any plans for intersecting rather than subset-of groups? 21:33:34 ttx heh 21:33:43 devananda: FWIW trove has 2 separate groups too. (core and drivers) 21:33:50 devananda: as in having people in specs-core who aren't nova-core? 21:33:56 mikal: right 21:34:06 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 sdague: not a subset. a different group that usually was a subset 21:34:11 I wouldn't be comfortable choosing who from heat-core to kick out of heat-drivers 21:34:20 I have a glance-specs-core member who is not a glance-core 21:34:26 devananda: I am not opposed to it, but I know some of the drivers members don't like the idea 21:34:27 mikal: might be crazy. but also might be good for folks with deep operational knowledge who aren't review core 21:34:33 its a good way to get product involvement from openstack companies 21:34:35 not always just devs 21:34:55 The counter arguement is that it sets expectations that a design is "ok to merge" when nova-core might not agree 21:34:57 i wouldn't want that involvement from companies (they'll just approve their own BPs) but rather from operators 21:35:10 mikal: yep, was about to say that 21:35:14 mikal: ++ that's my concern 21:35:15 i.e. a consistent bar is required across both 21:35:16 but - that may be achievable merely by better socialization 21:35:21 devananda: I think you can get plenty of feedback in the current system 21:35:25 mikal: and putting load on reviewers that may or may not agree with design 21:35:27 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 operators can +1 / -1 things 21:35:28 Neutron has a separate group which currently encompasses neutron-core. 21:35:35 The flip side is that I feel like we're failing to acknowledge the importance of ops reviews at the moment 21:35:38 sdague: gotcha 21:35:43 I like the idea of adding operators outside the scope of -core though. 21:35:44 I'm fine with people experimenting with both options at this point 21:35:54 BUT we kinda need to chosse on the naming front 21:36:01 choose* 21:36:11 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 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 right, but having someone who isn't delivering code be able to approve in blueprints seems... pretty antithetical to our culture 21:36:16 between program-based naming and project-based naming 21:36:18 ttx: I think ultimately some sort of openstack-wide guideline would be a good idea 21:36:23 ttx: but perhaps that's a TC thing 21:36:34 mikal: right, but I'd wait for the end of the experiment :) 21:36:39 Its less confusing to newcomers if we're consistent 21:36:41 ttx: project please... proliferation isn't going to be helpful in this case I don't think 21:36:45 jeblair: for specs repos? 21:36:50 dolphm: yes 21:36:50 ttx: do you have a timeline for declaring the experiment done in mind? 21:36:52 at this point let's let a thousand (or a dozen) flowers bloom! 21:36:55 ttx: "juno"? 21:36:58 program-based makes much more sense if we're using specs for programs like infra and tripleo 21:37:01 mikal: yes 21:37:02 we should decide very quickly one way or the other on naming 21:37:06 jeblair: nova chose nova-specs, keystone chose identity-specs 21:37:16 ... otherwsise we block the new -specs repos being created 21:37:27 devananda: ++ and for including the client in the -specs process 21:37:27 ... at a time when there should be a flood of specs 21:37:34 clients* 21:37:40 yeah, without convergence, discovery will be sucky 21:37:50 ttx: what about handing ops -2 / +2, but not approve? Could that even be expressed in gerrit? 21:37:54 i.e. I woudn't necessarily find identity-specs 21:38:12 mikal: you only need to hand folks -2 if their -1s are valid, and being ignored 21:38:13 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 culture really fixes most of this 21:38:29 basically because so many programs went with the project name 21:38:36 as awkward as it is in some cases, this should be {program}-specs 21:38:48 mikal: won't answer for gerrit. For the rest, try whatever you think will work for you, we'll converge later 21:38:50 sdague: and ditto for +1's if you leave out approve rights 21:38:55 notmyname: i agree 21:39:02 sdague: mikal: how often do operators seriously oppose a change such that they would -2? 21:39:05 because how else does one know where to look for client and other projects? 21:39:07 but giving +2 without approve would sure be confusing 21:39:16 jeblair: keystone-specs is project-named, though, right? 21:39:25 dolphm: but on the counter, how often are they -1ing things and getting run rough shot over? 21:39:27 oh nm 21:39:29 Can't we address naming confusion by putting the specs repo name in the contributing file for each project? 21:39:33 markwash: yep. okay, let me try again 21:39:37 jeblair: so that being said, our current proposal should be renamed from swift-specs to objectstorage-specs 21:39:47 mikal: that's plan B if we can't converge on naming yes 21:39:47 dolphm: I have no data on that, but I am sure there are things core likes which ops don't 21:39:50 markwash: identity-specs is what is proposed atm 21:39:55 question 1) should the _end goal_ be to use project-name or program name? 21:39:55 A bit suboptimal imho 21:40:15 sdague: i suppose that's what i'm asking - how often would a -2 come in handy 21:40:17 I like project-specs due to the speculative nature of the specs 21:40:26 what's the reasoning for using {project}-specs? is it only for ease of speaking it (in English)? 21:40:27 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 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 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 jeblair: program-specs reflects the fact that we said "one repo per program" 21:40:41 in the last 2 months nova overrode -1s ~ 3% of the time 21:40:54 sdague: oh interesting, I wasn't aware of any numbers on that 21:41:07 jeblair: I'd prefer a decision now, that we then stick to 21:41:10 mikal: I ran it this morning, on list, let me point 21:41:14 jeblair: but then for programs with a main project it creates mouthful specs repo name 21:41:24 where the project name can easily be used 21:41:30 mikal: http://lists.openstack.org/pipermail/openstack-dev/2014-May/035269.html 21:41:43 sdague: tahnks 21:41:47 so actually, we do have "short" program names 21:41:50 * mikal is still digging out of email backlog post summit 21:41:59 but similar things for CI systems. Smokestack only had 2 -1s in 2013 that were overridden 21:42:01 we have "object-api" rather than "object-storage-api" 21:42:12 so we could go with "object-specs" for swift 21:42:22 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 jeblair: I'm good with that :-) 21:42:40 sdague: I am sure that's different for our current third party CIs 21:42:46 mikal: it is 21:42:51 jeblair: but we don't want to keep maintaining object-api, netconn-api, we'd rather those act like specs too 21:42:54 jeblair: speculative 21:42:58 but this was counter to the fact that people ignore reliable CI systems 21:43:03 they don't 21:43:03 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 we are a concensus driven culture, and reasonable objects are very very rarely ignored 21:43:37 annegentle_: identity-api is super useful to us - what do you propose we do with all those docs? 21:43:43 notmyname: so you would have one repo per project under swift ? 21:43:50 sdague: reasonable objections? 21:43:51 ttx: absolutely 21:43:57 i.e. python-swiftclient-specs ? 21:44:01 eglynn: that too :) 21:44:15 annegentle_: we also discussed identity-specs proposals linking to in-progress identity-api reviews to illustrate api impact 21:44:16 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 notmyname: why? 21:44:24 dolphm: yep that would be cool 21:44:24 ttx: one specs repo for swift, python-swiftclient, and swift-bench 21:44:25 i see no benefit to splitting the specs repositories for projects that are part of the same program apart 21:44:25 jeblair: looks like some programs want to go per-project for their specs repo anyway 21:44:35 sdague: don't underestimate the power of inertia ;) 21:44:38 ... or "facts on the ground" 21:44:42 :) 21:44:48 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 annegentle_: i'd buy that as an argument for putting the api docs into -specs 21:44:52 ttx: who? 21:44:55 jgriffith: because oftentimes a single feature is needed to be exposed in both the server and client projects 21:45:00 dolphm: would love that. 21:45:04 notmyname: i think your "absolutely" was meant as "no" 21:45:05 jeblair: swift 21:45:12 notmyname: sure, but the specs process now enables us to add that sort of thing 21:45:14 ttx: i believe notmyname wants 'object-specs' and it will encompass all 3 programs 21:45:17 er projects 21:45:20 devananda: depends on your lag of when who said what :-) 21:45:21 notmyname: right? 21:45:25 Now I'm confused 21:45:32 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 jeblair: no, he wants three specs repos 21:45:47 jeblair: that is correct. I want one shared specs repo for swift, python-swiftclient, and swift-bench 21:45:55 annegentle_: identity-api is essentially documentation driven design already 21:45:55 notmyname: gahhh 21:45:59 notmyname: excellent idea, i fully support it. ;) 21:46:00 hehehe 21:46:04 ok, everybody is apparantly saying the same thing 21:46:04 dolphm: yes 21:46:06 notmyname: i think you win the the most-confusingly-timed-reply award today. 21:46:17 notmyname: I agree 21:46:25 yes please put all the specs in -specs 21:46:28 notmyname: why would you answer "absolutely" to my "notmyname: so you would have one repo per project under swift ?" ? 21:46:28 including api specs 21:46:38 notmyname: /me similarly for telemetry (encompassing ceilo, ceiloclient & pycadf) 21:46:46 annegentle_: (was that also a dig against -specs?) 21:46:47 okay, i'm not hearing any huge objection to program-specs; and some amount of consensus for it 21:46:59 ++ program-specs 21:47:05 dolphm: jeblair I'm against program-specs 21:47:18 notmyname: that's where my confusion stems from :) 21:47:19 ttx: either there was some miss timing or I was reading it as swift the program, not project (my own confusion) 21:47:26 annegentle_: why? 21:47:27 ok 21:47:48 dolphm: jeblair: because we could one day have multiple repos in a single program -- like Deployment 21:47:54 ttx: also, I'm on pain meds today ;-) 21:47:56 we still have 13 more minutes to violently agree 21:48:05 annegentle_: we have lots of repos in single programs 21:48:11 would a non-binding vote clarify to see if there's any kind of rough consensus emerging? 21:48:14 notmyname: oh right. get well soon, btw 21:48:16 annegentle_: we already have that. and that's precisely why fokls want a single specs repo per project 21:48:30 gah 21:48:33 annegentle_: we already do: keystone, python-keystoneclient, and (soon) keystonemiddleware 21:48:34 annegentle_: infra has 43 projects in one program. :) 21:48:38 s/project/program/ in my previous sentence 21:48:52 proposed vote: one repo per program. named as {program}-specs 21:49:05 annegentle_: i think the single specs repo per program helps with that case 21:49:17 annegentle_: and notmyname gave a very good specific example 21:49:20 yep let's nail our colours to the mast 21:49:24 notmyname: +1 21:49:28 ttx: can you run a vote next week? 21:49:31 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 notmyname: those are two separate questions imo 21:49:42 ttx: or now, if everyone is here 21:49:55 I'd prefer now 21:49:57 dolphm: I don't think we need to vote, every -specs user so far has +1ed it 21:50:00 i asked at this meeting because i thought that getting ptl consensus was the most emportant 21:50:02 important 21:50:11 jeblair: yes, that 21:50:18 Anne disagrees but hen she doesn't have a -specs repo :P 21:50:31 discoverability doesn't seem that hard to me to be honest 21:50:35 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 ttx: i want to understand her argument though :) 21:50:37 annegentle_: tripleo-specs, if they're getting involved in the tripleo program 21:50:46 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 so I don't see a really big need for consistency 21:51:06 ttx: :) 21:51:09 ttx: I would rather not block the creation of ironic-specs another week waiting for a vote 21:51:20 devananda: yeah that's why I may be either conflating or borrowing from the future 21:51:26 ok let's record this 21:51:30 devananda: +1 (s/ironic/ceilo/) 21:51:33 ttx: are you going to rename nova-specs to compute-specs? 21:51:36 if a "program" has isolated communities with, let's say, non-converging interests, they should be separate programs IMO 21:51:41 perhaps I just misunderstand program names 21:52:01 dolphm: right 21:52:04 annegentle_: i think we would want to rename nova-specs to compute-specs if we decide to go this way 21:52:05 assuming they both have justifiable reasons to co-exist (which is obviously the case for the chef & puppet example) 21:52:18 dolphm: but let's not bikeshed on that now :) 21:52:27 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 I wouldn't have a problem with nova-specs being renamed compute-specs, but I don't see the rush either 21:52:40 #startvote End goal of one spec repo per program, named program-specs ? yes, no, abstain, i_want_all_options_opened 21:52:41 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 Vote using '#vote OPTION'. Only your last vote counts. 21:52:52 #vote yes 21:52:54 #vote yes 21:52:54 #vote yes 21:52:57