20:00:08 #startmeeting 20:00:09 Meeting started Tue Aug 9 20:00:08 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:19 jbryce: ! 20:00:32 termie: ! 20:00:55 o/ 20:00:55 which ppb members do we have? 20:01:02 here 20:01:08 chuck norris: ! 20:01:10 here 20:01:13 present 20:01:28 heyo 20:01:36 o/ 20:01:44 * jmckenty_ waves 20:01:58 here 20:02:06 o/ 20:02:07 no ewan expected, right? 20:02:13 wow good turnout 20:02:13 he's in some weird time zone 20:02:14 o/ 20:02:18 missing ewan and purrier 20:02:57 well let's get started. agenda: http://wiki.openstack.org/Governance/PPB 20:03:03 #topic previous action items 20:03:26 jmckenty_: any update on FITS or academic cooperation? 20:03:27 I have two of those 20:03:39 FITS has a mailing list set up, and a reasonably representative set of members 20:03:53 We haven't done a kickoff yet, was waiting to hear how things went with Dell first 20:04:02 as it probably changes our mandate somewhat 20:04:48 Academics, I've spoken with Stephen Spector and a few others directly (Qatar Foundation, etc), should have a proposal in shape in a few weeks, but I was thinking we should set aside a couple of blocks at the summit 20:05:06 * jaypipes wonders if I missed some ML post on FITS... 20:05:21 jaypipes: what, specifically? 20:05:31 Hi - is there a PPB mtg today? 20:05:39 zns: yes. going on right now 20:05:39 zns: it's on 20:05:39 zns: you're in it :) 20:06:06 jmckenty_: about FITS. Were you going to introduce the concept on the ML and invite people to comment? 20:06:06 Cool. Multi-tasking.. :-) 20:06:39 jaypipes: wasn't planning on it. 20:06:47 jmckenty_: any reason? 20:06:48 not until we had a proposal 20:07:00 I think it makes a very messy public discussion topic 20:07:14 Would rather come to the community with two or three distinct proposals 20:07:23 jmckenty_: ah, ok. but after you have a proposal, you will, correct? 20:07:27 and some background research that's well articulated 20:07:29 current 20:07:34 current / correct 20:07:40 :) gotcha. ok, cool. 20:07:50 ok 20:08:01 other outstanding action item is the next item on the agenda 20:08:13 project autonomy? 20:08:16 #topic common project tooling/processes aka autonomy 20:08:29 http://wiki.openstack.org/Governance/Proposed/ProjectToolingAndPractices 20:08:56 i plan on adding that to the existing project description page that already covered some of the project philosophy ideas 20:09:00 http://wiki.openstack.org/ProjectTypes 20:09:10 jbryce: I sent my comments to the thread 20:09:30 otherwise lgtm 20:09:41 ttx: i haven't been getting lp email today, but i just saw them on the web archive 20:09:51 i am in basic agreement with ttx 20:10:09 i'll add in a note about default 4-week milestone 20:10:26 I'd rather hold off on approving that doc until we get a status update from the vetting process for github+gerritt 20:10:26 already responded, lgtm.. 20:10:39 If we're going to have vetted options, we should have more than one, imo 20:10:43 why? 20:11:00 meaning, why does one affect the other? 20:11:03 because a very large community contingent has asked for it 20:11:08 jmckenty_: some people are waiting for doc approval to vote, so it looks like a catch-22 20:11:21 so, you're fine with vetted options as long as they're the vetted options you approve of... 20:11:21 jmckenty_: once approved, i will update this list 20:11:36 but that's not what the vote is on. The vote is whether to have a set or a single vetted option. 20:11:38 the bottom section would change anytime we add new options or categories 20:11:40 notmyname: were there any specific things you were waiting on from project autonomy docs? I know you had been asking for it 20:11:42 I expected we'd discuss whether we'd have "one true set of tools" vs. "a set of vetted optoins" before we discussed a document that specifically speaks of "the vetted options". 20:11:54 soren: we did that already 20:11:57 and voted on it 20:12:04 and then reviewed it 20:12:05 jmckenty_: not everyone is convinced of that. 20:12:12 I can pull up the ppb meeting logs 20:12:16 jmckenty_: it ended in a tie 20:12:18 no, we didn't. 20:12:20 So why was the question raised again on the mailing list? 20:12:27 really? I don't remember a tie 20:12:46 jmckenty_: someone changed their vote, and we didn't have enough folks attending to break the tie 20:12:51 If it's the meeting I remember, it ended up a tie as dendrobates changed his vote. 20:13:01 ah, gotcha 20:13:08 sorry 20:13:14 we did discuss it in subsequent meetings 20:13:17 :) 20:13:21 eday: that's what I was waiting on :-) 20:13:25 yes, but I was never clear about why we were discussing it again 20:13:31 it's clear now 20:13:48 so, we ready to vote on it? 20:14:08 wait 20:14:13 we still don't have a set of options 20:14:15 the last discussion it seemed that most people were on the side of a vetted set of options (which could be a set of one) 20:14:16 we have a single option 20:14:21 in every case 20:14:40 hence my feeling that voting is premature 20:14:45 the next step was to attempt to draft the summary of the discussion that went on over multiple weeks 20:14:49 jmckenty_: are you ok with the idea of having a set of options? 20:14:52 hence the document with the link 20:14:57 notmyname: yes 20:15:14 jmckenty_: the document includes existing approved options which is only one currently 20:15:20 but I'm not okay with approving that as our official mechanism when there's only one option 20:15:25 if we approved additional options they get added to the document 20:15:28 so we can settle the single option/vetted list issue? 20:15:31 jmckenty_: the point is to vote on whether to have a single option or more than one, not whether LP or Gerrit/GitHub IS the single option or one of the options. 20:15:35 "a set of options" actually includes "only one option" 20:15:43 Whether we want a set of vetted options vs "one true set of options" is orthogonal to whatever the vetted options would be, hopefully. 20:15:48 it's not semantics per se... 20:15:48 jmckenty_: i'm totally fine with a set only have one element 20:15:58 I'm not 20:16:17 Then what's the problem? 20:16:23 jmckenty_: you are if it's the option you prefer. 20:16:25 so you want to always force multiple options to be available? 20:16:27 You've clearly decided on what your vote is going to be. 20:16:39 jaypipes: not true 20:16:40 how about "should we ever support more than one project hosting option?" 20:16:50 eday: right, that is the question. 20:17:08 at least, until we vote on this again :/ 20:17:12 ugh 20:17:19 ok 20:17:52 jmckenty_: i don't understand your issue. are you saying you want to require more than one option in every category? 20:17:59 no 20:18:14 I'm just saying that voting to approve multiple options, when we don't have a SINGLE alternative, 20:18:19 right 20:18:22 is a bunch of sycophantic posturing 20:18:27 no 20:18:30 jmckenty_: no, it's not. 20:18:33 It's not at all. 20:18:36 step one is to approve a philosophy that allows for multiple options 20:18:37 sycophantic? 20:18:42 step two is to add the addition options 20:18:57 jmckenty_: replace Launchpad with "BLAHBLAH". It doesn't matter what is on there to vote on whether ot have >1 option. 20:19:06 * johnpur gets out his dictionary 20:19:10 "http://www.thefreedictionary.com/sycophantic" 20:19:16 this document attempted to capture the idea that there can be multiple options 20:19:17 johnpur: give it to me when you're done 20:19:21 it's voting to allow approval of a second option without having to categorically remove the first option at the same time 20:19:25 jmckenty_: thanks 20:19:35 next item on the agenda was to vote on if there's a second option in 2 of these categories 20:20:04 mtaylor: +1 20:20:22 fine, I won't hold it up. 20:20:46 so can we vote on this: http://wiki.openstack.org/Governance/Proposed/ProjectToolingAndPractices 20:20:53 No? 20:21:05 That's the entire point. It speaks of "vetted options". 20:21:08 What if we don't want such a concept? 20:21:08 don't we need to vote on >1 vs. 1 option? 20:21:10 (although me would like to put out there, as a person who supports a good amount of this - that he'd prefer long term to only be supporting a single infrastructure- but is fine with "set of vetted options" 20:21:20 I had a minor observation on the autonomy point 20:21:24 jaypipes: yes. that is what the document discusses 20:21:41 just that, although swift works perfectly well standalone, nova depends on glance, and glance (at scale) depends on swift 20:21:45 the key point of the document being that for certain categories there are predefined default options that projects should choose from 20:21:45 jbryce: ah, so you're saying since the document says vetted options, we are voting up or down on that? 20:22:24 jaypipes: correct 20:22:31 Ah. 20:22:31 ready when you are. 20:22:33 +1 for vetted options 20:22:34 But... 20:22:35 is there a "preferred" designation on the betted options? 20:22:44 johnpur: separate vote? 20:22:47 the bottom is just a catalog that we would update as things change 20:22:56 What if we reject this document? 20:22:58 What happens then? 20:23:08 then someone else gets to draft the next one. = ) 20:23:21 and go through 6 weeks of meeting logs to try to understand the discussion 20:23:25 hahaha 20:23:26 inded 20:23:30 +1 as vetted options is still very open-ended :) 20:23:38 -1 20:23:49 -1 for vetted options 20:23:50 ttx: no, it's not... it's merely a vote on 1 or >1 option. 20:24:03 -1 on vetted options. +1 on singular option. 20:24:03 +1 for vetted options 20:24:05 jaypipes: no, it's a vote on 1 or >=1. 20:24:14 ttx: sure, yes. 20:24:15 ttx++ 20:24:18 Then I don't undertand what we're voting? 20:24:20 At all. 20:24:26 -1 for vetted (since we voted one project, we shouldn't split it) 20:24:32 -1 20:24:39 soren: we are voting on enforcing 1 optoin... or deciding to keep the option to have >=1 20:24:45 I'd like to retract my vote on the grounds of not having the faintest idea what we're voting on. 20:25:04 aha! 20:25:06 should it be ==1 or >=1 option. 20:25:13 But. 20:25:13 Ok. 20:25:14 fine. 20:25:15 eday: to be precise we voted on one product made up of independent projects 20:25:17 Then ==1 20:25:20 fetch me... an HALIBUT! 20:25:25 That's unambiguous. 20:25:37 soren: if you want no flexibility on whether an openstack project gets to choose from a list of vetted options, vote -1. 20:25:49 -1 20:25:51 Wicked. 20:26:01 jaypipes: Thanks. 20:26:04 np. 20:26:20 (then why did people start saying "no" when someone tried to sum it up that way?) 20:26:20 who's missing a vote? 20:26:25 +1 20:26:36 jbryce: your vote? 20:26:43 +1 20:26:48 what is the score? 20:26:53 i have no idea 20:26:59 trying to scrollback and see where everyone ended up 20:27:05 Vetted = jmckenty, jbryce, vishy, johnpur 20:27:06 6 -2 i think 20:27:10 * ttx retracts to +0 if it's tied. 20:27:16 oh, and ttx 20:27:35 and mtaylor, or no? 20:27:36 k missed a few 20:27:39 notmyname: I'm kind of baffled here. You've spent the last 7 meetings talking about autonomy and letting people choose their own tools, but now you're voting against having options? 20:27:42 * mtaylor doesn't get a vote 20:27:43 I don't really mind -- I expect that the PPB will only vet one option at a time anyway. 20:27:46 * mtaylor just lurks and talks 20:27:48 right, sorry 20:27:52 the pluses confused me 20:27:57 notmyname: yeah - reasoning? 20:28:23 so 1 option is -> ewan, soren, jaypipes, dendrobates, eday 20:28:35 single option = eday, dendrobates, soren, jaypipes 20:28:40 so 5 -5 ? 20:28:43 was that ewans? 20:28:46 k 20:28:51 so we're deadlocked on ttx 20:28:52 fun 20:28:56 i thought he said one option in his email 20:29:01 yeah, he did 20:29:04 where is ewan? 20:29:06 anotherjesse can tie break 20:29:07 my understanding of the original autonomy descision is that openstack is a single unit with cooperating components. I think my current vote goes along with that. I was never for a vetted set. I originally wanted no set approved or otherwise 20:29:09 he doesn't want to teach his devs git and bzr 20:29:17 jbryce: Sleeping, probably. He's in India (where it's 2 AM). 20:29:20 nah, notmyname votes -1 20:29:26 so -1 wins 20:29:27 so where did his vote come in? 20:29:35 notmyname: k - I agree 20:29:50 and vote with notmyname 20:29:50 jbryce: PPB ML post 20:29:53 k, I'm happy 20:29:57 so single option wins 6 - 5? 20:30:16 yes 20:30:29 so we chuck that page, then 20:30:34 anotherjesse: did you vote? 20:30:47 he voted with notmyname 20:30:52 yes same as notmyname - not sure if that is + or - 20:30:53 ;) 20:30:58 ok 20:30:59 I voted -1 20:31:06 for single option 20:31:14 who's missing? 20:31:17 we have 12, right? 20:31:23 oh, ttx 20:31:26 abstained 20:31:32 #agreed VOTE: Not vetted set of options allowed. All projects must use same tooling. result 7 - 5 20:31:45 jbryce: it's 6-5 20:31:53 with one abstention 20:31:55 right? 20:32:01 i thought ttx was abstaining if it was tied? 20:32:09 oh, I see 20:32:10 gotcha 20:32:25 #topic GItHub + gerrit 20:32:25 jbryce: Hang on, hang on. 20:32:35 soren: ok 20:32:49 jbryce: You said explicitly that voting against this only meant that we rejected that document. Not that any specific other options was then chosen. 20:33:08 soren: that's correct. 20:33:15 um... no? 20:33:15 jaypipes:soren: if you want no flexibility on whether an openstack project gets to choose from a list of vetted options, vote -1. 20:33:16 [3:25pm]soren:-1 20:33:16 [3:25pm]soren:Wicked. 20:33:16 [3:26pm]soren:jaypipes: Thanks. 20:33:19 jbryce let's quickvote on "single optoin everywhere" then 20:33:24 +1 20:33:28 +1 20:33:35 * jmckenty_ is avoiding further ambiguity 20:33:43 +1 20:33:44 +1 20:33:45 +1 20:33:48 +1 20:33:53 +1 20:33:54 I want a rule, whatever that ends up being. 20:33:55 jmckenty_: I asked what happened if we voted against it. The answer was htat someone would get th epleasure of coming up with a new document. 20:34:21 that was in reference to a previously proposed vote, not the vote we ended up having, though 20:34:21 right? 20:34:27 we didn't vote on the doc 20:34:33 soren: right, and the change would be everywhere it says "vetted options" would be replaced with "a single option". 20:34:34 we revoted on the ==1 or >1 20:34:38 i'm assuming the new document would represent the outcome of the vote 20:34:46 right 20:34:48 ...but I'm perfectly happy to *not* have someone do that. I just want us to actually be consistent in what we're saying we're voting on and then what we state for the record was decided. 20:34:50 which is that we don't want to allow a vetted set of options 20:35:50 so tooling is now by PPB decree, right? 20:36:30 that is what i understand it to mean 20:36:35 cool 20:36:36 done 20:36:37 ? 20:36:39 I think this was beaten to death, let's move on 20:36:42 jmckenty_: no the *policy* for tooling is directed by the ppb 20:36:42 jmckenty_: well, it has been since the vote a few weeks ago, now it's just only one option choosen by PPB, not many choosen by PPB 20:36:50 right 20:37:03 the actual tooling needs wider community input (ala the github thing) 20:37:13 so on github, this is now an interesting situation 20:37:22 can we get a status update? 20:37:28 sure 20:37:40 we've moved glance over to git/gerrit 20:37:49 which went much better than the keystone move :) 20:38:43 and then in the openstack-ci meeting earlier today, we got agreement from me, jay, notmyname AND termie that continuing to mirror to github and installing a hook that automatically closes pull requests submitted with instructions on submitting to gerrit was acceptable 20:38:57 * jaypipes was amazed.. 20:39:04 * mtaylor believes that some pigs flew 20:39:17 So I set up my own mirrors to Github last weekend 20:39:24 because the openstack ones had bitrotted 20:39:31 in any case- that means that the overall system as put forward is the one we have now 20:39:33 will that be part of the CI infrastructure going forward? 20:39:34 jmckenty_: the swit one is kept up-to-date ;-) 20:39:42 jmckenty_: they aren't bitrotted 20:39:44 *how* up to date? 20:39:46 jmckenty_: well, once nova/swift are in gerrit, that will be done automatically on merge 20:39:47 <_0x44> Piston is also volunteering to write the app that integrates gerrit+github pull-requests so the auto-closing can go away. 20:39:49 jmckenty_: latest commit 20:39:53 jmckenty_: nova is current as of yesterday most recently 20:40:20 jmckenty_: but to answer your question - yes, if we move forward with this setup, that will be part of CI infrastructure 20:40:22 termie: I'm on a 20-minute task 20:40:23 k 20:40:25 cool 20:40:32 jmckenty_: nova is now 1 second old 20:40:39 Would be great to get pull requests in. But does the vote on "one option" mean we only support LP or github now? 20:40:40 of course, based on the last descision, either the other projects need to move to github+gerrit or glance/keystone need to move back 20:40:50 zns: That remains to be decided. 20:41:24 soren: when/how will it be decided? 20:41:32 zns: Momentarily, I imagine. 20:41:34 I would put forward, that since we are in a transition period- as long as the decision has been made and plans are afoot, that immediate moving in either direction isn't required, no? 20:41:38 zns: that's the current discussion 20:41:49 mtaylor: I would support that. 20:41:54 I wouldn't 20:42:04 I believe we made a previous decision to resolve this in time for Diablo summit 20:42:10 as in - if the ppb votes yay in the next 5 minutes we don't have to IMMEDIATELY throw a switch - we just need to plan to throw the switch 20:42:11 sorry, essex summit 20:42:21 jmckenty_: in time for essex summit sounds reasonable 20:42:25 jmckenty_: +1 20:42:55 jmckenty_: We have different ideas of what "immediate" means, apparently. 20:43:01 jmckenty_: nova is a bit late already, I'd hate to lose time in a transition before d4... and I'd hate to transition in the last weeks before release 20:43:12 There's plenty of room for plenty of immediates before the Essex summit in my calendar. 20:43:14 ttx: are you nervous about the timing of all of this? 20:43:15 mtaylor: ++ 20:43:17 any other questions? ready to vote on approving github + gerrit as the source control system for all core openstack projects with a timeline of moving to it by essex design summit? 20:43:23 johnpur: yes 20:43:23 _0x44: +1000 20:43:37 so, the proposal to vote on is: the official option is code=>GitHub, review=>Gerrit, bugs/blueprints/release stay on LP for now? 20:43:44 vishy: jeblair and I will work with Piston on that for sure 20:43:48 the most important votes are the ptls 20:43:58 johnpur: what? 20:43:59 eday: yes. 20:44:02 eday: correct 20:44:02 mtaylor: ++ 20:44:07 the point of having a vote is that all votes are equakl 20:44:20 the ptls are on the hook to make sure their stuff and processes work after a move 20:44:29 everyone is on that hook 20:44:35 the ptl is holding the hook that's all 20:44:43 not discounting your opinion of course :) 20:44:51 something tells me /me will be on the hook if it fails ... :) 20:44:56 I'd say mtaylor and his posse is more on the hook in that respect than anyone else. 20:45:02 ttx: moving Nova in the final "integrated milestone release" cycle might actually be better, since fewer features going in... 20:45:22 jaypipes: ...or just after release. 20:45:28 negative 20:45:33 we hashed this already 20:45:34 jaypipes, ttx: I've been thinking immediately after D4 myself 20:45:38 ttx: when features are lined up to go in? 20:45:56 ttx: As opposed to when we're trying to polish a release? 20:46:00 err.. 20:46:01 vishy: miletsone-proposed branch handling is not baked yet 20:46:03 jaypipes: As opposed to when we're trying to polish a release? 20:46:07 ttx: having just gone through this with glance, I don't think it will be too bad to do Nova after d4, but that's vishy's decision... 20:46:11 ttx: it can be 20:46:22 ttx: we can set up some tests over to the side 20:46:29 anyway, that's out of scope 20:46:31 soren: meh, no good time, really. :( 20:46:39 I agree on "before essex summit" 20:47:08 depending on how ready milestone-proposed is (glance will need it) maybe post-D4 is ok for Nova 20:47:12 #info VOTE: GitHub for Source Control; Gerrit for merge; everything else stays the same. Goal of having all core projects moved before Essex design summit. 20:47:23 +1 20:47:24 +1 20:47:28 +1 20:47:36 +1 20:47:36 At one point (at diablo summit I think) we decided to have a community-wide survey once we had a git-based option. Should we still do this before having a PPB vote? 20:47:42 +1 20:47:46 +1 20:47:53 I guess that is a no :) 20:47:54 +1 20:48:06 eday: if they riot, we'll revisit it? 20:48:08 eday: PPB CRUSH PUNY COMMUNITY 20:48:27 "I'm on the brute squad."... "You ARE the brute squad" 20:48:48 +1 20:48:56 +1 20:48:58 anotherjesse: ? 20:49:13 I think we can count ewan at +1 as well 20:49:14 +1 20:49:15 jbryce: we might have time for the next topic, hurry up :) 20:49:30 eday - vote? 20:49:37 does it matter? :) 20:49:47 0, I'd rather have seen community survey feedback first 20:49:47 I like to have the counts right :) 20:49:52 fair enough 20:50:00 #agreed GitHub for Source Control; Gerrit for merge; everything else stays the same. Goal of having all core projects moved before Essex design summit. 10 +, 2 abstain 20:50:00 +0 or -0 ? 20:50:07 #topic Deadline for Essex core projects applications 20:50:18 ttx: this one yours? 20:50:21 I think ttx offered Setp 3rd? 20:50:24 sure 20:50:32 +1 20:50:33 Sept 3rd seems reasonable 20:50:33 Sept 3rd. Good with folks? 20:50:37 +1 20:50:43 Any feedback on the PTL voting mechanism? 20:50:44 =1 20:50:50 er +1 20:50:52 +1 20:50:53 +1 20:50:54 +1 20:50:57 +1 20:51:07 +1 20:51:08 I'm fine with first PTL being not elected. 20:51:09 +0 20:51:10 vishy: now you are just confusing us 20:51:31 +1 20:52:01 #agreed September 3rd is the deadline for core project applications. 9 +, 3 abstain 20:52:13 the idea is that they can participate in design summit org, as well as the newly-elected PTLs 20:52:18 this has been the most productive PPB meeting in months. or ever. 20:52:24 #topic open discussion 20:52:37 jaypipes: the first few were good 20:52:38 anyone have any random thoughts or observations? 20:52:43 quick question - should I submit openstack-ci to be a project? or are we fine with managing it how it is now? 20:52:50 it helps to have a full contingent present 20:52:57 mtaylor: I'd like to see it as a project 20:52:57 mtaylor: I woulnd't bother. 20:52:58 jaypipes: that's just because you won every vote. 20:53:04 jbryce: I have lots of random thoughts, but probably shouldn't say them. 20:53:05 but I'm not fussy 20:53:08 mtaylor: it's not a code project. 20:53:23 mtaylor: It's not going to do releases, for instance. It seems pointless. 20:53:26 it's an infrastrtcture thing 20:53:27 it's not - and I'm fine with it not being- I just wanted to make sure folks were happy 20:53:59 mtaylor: yeah, leaving it as-is is fine I think... 20:54:11 do we expect core promotions for Essex ? 20:54:12 ok 20:54:25 keystone? 20:54:25 is one of the incubated projects considering filing for core ? 20:54:30 ttx: thought you wanted to vote on Sept 3rd? :) 20:54:32 ttx: i'll check with keystone and dashboard and see if they want to try 20:55:02 I think keystone should try for core 20:55:08 anotherjesse: thoughts? 20:55:09 I'd rather have them present *before* Sep 3rd 20:55:10 jbryce: those are the two i would think 20:55:16 ttx: ah, yes. 20:55:16 ttx: I agree 20:55:26 otherwise it's a straight yes/no, no second chance. 20:55:37 I'd rather see keystone go first, fwiw 20:55:51 Since I'd love to see dashboard support keystone well before it goes in 20:56:29 all right...last call 20:56:31 jmckenty_: I think keystone needs to go to core … but we need to get the extensions stuff done 20:56:46 thanks jbryce 20:56:50 thanks everyone 20:56:50 i think the dashboard is somewhat inevitable, and they can work to improve keystone support over time 20:56:51 hey, any dell update? 20:56:54 #endmeeting