19:03:33 #startmeeting 19:03:34 Meeting started Thu May 19 19:03:33 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:35 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:03:35 = ) 19:04:09 agenda - http://wiki.openstack.org/Governance/PPB 19:04:13 #topic previous actions 19:04:36 Eric and I had to draft a project model description 19:04:47 ttx and I sent out drafts 19:04:53 Visible at http://etherpad.openstack.org/PQ7dy5in2B 19:04:59 here! 19:05:04 yay, quorum 19:05:06 I went ahead and added it to the http://wiki.openstack.org/ProjectTypes page 19:05:18 jbryce: ok 19:05:33 jbryce: i had a couple of comments, sent back on the list 19:06:49 project resources <- kinda confusing to say that - since code has its own license 19:07:17 maybe defining resources as things like domains, ...? 19:07:49 strike that 19:08:13 Anne suggests we add "documentation" as a Commonality? 19:08:19 I'll add it 19:08:23 Is "should strive to use the same standards, in code" meant to imply the same programming language for all core projects? I presume not, but it sounds like it does. 19:09:06 I didn't put together a "doc shepherding guidelines" proposal in time for this meeting, but I can do so in time for next week's 19:10:35 jbryce: the way you havethe page laid out it implies that the 5 bullets at the top apply to all 3 project types... is this what you mean? 19:10:36 ewanmellor: it's mainly about consistency when possible. For example, all Python projects should use similar libs/pep8/etc. Certainly doesn't imply the same language 19:11:07 jbryce: agree with johnpur that "incubation assets" needs a definition 19:11:10 johnpur: they seemed like broader concepts so i just stuck them at the top 19:11:23 for instance, related projects don't have the constraints or the supportgiven tot he other 2 classes 19:11:37 eday: That's what I expected. I think the language could do with some work. 19:12:01 johnpur: feel free to edit the page 19:12:15 ha ha... walked into that one! 19:12:29 on the incubation assets i agree that it's fuzzy, but we haven't really defined what those are yet, so i was hoping to get some input 19:12:31 johnpur: at least, you are free to try 19:12:46 wikis are not tha tgood at simuletaneous edits 19:13:03 we said they could get a subdomain, they could potentially use the build infrastructure....what else should go in there? 19:13:21 i'll defer any edits until later to give others room to update 19:13:22 should we pull that page into etherpad for some editing 19:13:26 ? 19:13:36 jbryce: what about the mailing lists? 19:13:49 jmckenty: that's where my part was originally placed :) 19:14:09 jmckenty: that's really a community thing, anyone can use the mailing list, incubated or not :) 19:14:16 "approved for entry into the Incubator program": should that read "approved by the PPB"? 19:14:30 yes, although it's implied 19:14:39 ok, stop editing, I'll push to etherpad 19:15:02 i agree with where jmckenty is going... we just need to be very explicit about all aspects, on a per project class basis. Or else, folks will be very confused, etc. 19:15:28 http://etherpad.openstack.org/PQ7dy5in2B 19:15:33 eday: I think the fact that the mailing list is a community resource, if that's in fact the case, should be explicitly spelled out 19:15:45 otherwise I would be tempted to shout "off topic" occasionally 19:15:53 makes sense 19:15:59 the volume on that list means I rarely read it now 19:16:05 I only read 100% on the -poc list 19:16:36 please edit on etherpad 19:18:35 edit-in-progress.... 19:19:53 while the editing is happening there, last week we had a couple of actions as well: checking on the forums which are now live and johnpur was going to verify that QnA as a replacement for Launchpad Answers was the route we wanted to take 19:20:22 related to that second item, we actually had a proposal: http://wiki.openstack.org/Governance/Proposed/QuestionAndAnswerSoftware 19:20:23 related projects do or do not have the "right" to the channels, ml, etc.? 19:21:00 anotherjesse: does my new paragraph fit the bill for your concern ? 19:21:38 (distribution) 19:21:48 jbryce: looking at QnA now... 19:21:56 looks good 19:22:22 johnpur: not sure how to define those rights 19:22:30 johnpur: I would say do, are we really going to moderate? We should avoid business advertising, but project announcements seem appropriate 19:22:42 eday: how do you differentiate those? 19:22:52 jbryce: concensus is that Q&A style is preferable... the proposal looks fine... i advocate we use another open source project as the basis. 19:22:52 e.g., if I have a freemium product, can I announce that? 19:23:27 i think we have enough vocal people on the mailing list who will call a spade a spade if someone comes on and does shameless promotion that is annoyingly off topic 19:23:49 jbryce and johnpur - I would suggest that if we're going to proliferate community communication resources (forums, QNA, ML, etc), that we really drive forward an *integration* effort across those 19:24:08 e.g., everyone who wants a new tool needs to step up and help moderate content ACROSS tools 19:24:19 pulling discussions out of forums and adding them to QnA, etc 19:24:23 jmckenty: I would say free as in beer and source code 19:24:55 my fear is that if the communication channels are wide open that we may have scoping issues 19:25:01 in my experience, more tools is not necessarily better, and I think we should push pretty hard on the ownership and management aspects of these - not just selection and install 19:25:17 johnpur: I agree on the scoping issues as well 19:25:20 I'm pretty happy about the QnA site idea 19:25:33 i find launchpad questions to be pretty annoying 19:25:36 Who owns it, then - spector? 19:26:00 vishy: yes, we need something that allows the best questions and the best answers to be very apparent 19:26:10 or is that something that anne gentle can help with? 19:26:51 jmckenty: for now spectorclan can be designated the owner. longer term i am looking to bring in a technical community manager that should pick this up. 19:27:02 can we take the most vocal proponents of both QnA and Forums, plus Spector, plus Gentle, and call that a "Community tools working group"? 19:27:07 ttx: and allows questions and answers to be edited later when things change 19:27:09 johnpur: I have an awesome candidate for you 19:27:25 send the name along, with contact info! 19:27:30 jmckenty: we all have :) 19:27:49 next week i am going full court press on finding the right person 19:27:51 really? If you have awesome candidates for ANYTHING, you should be emailing me ;) 19:28:01 sorry, OT 19:28:06 jmckenty: heh 19:28:18 back, to my other point - anyone second calling this a working group? 19:28:30 I'm really concerned about an Ad-hoc approach here, I think we'll end up with shark tank 19:28:53 jmckenty: I think we can ask on the ML for QnA lovers 19:28:58 http://brandonhays.com/blog/2011/05/03/why-i-still-dont-contribute-to-open-source/ 19:29:04 to set up the core moderator group 19:29:22 someone with experience with QnA would be a + 19:29:28 ttx: +1 19:29:34 jmckenty: +1 to setting up some structure around community tools 19:30:01 I'm willing to contribute a lot to answers on the site 19:30:02 i can take this and organize 19:30:20 #action johnpur to organize a community tools working group 19:30:24 * vishy is tired of being asked the same questions over and over 19:30:25 vishy: I'm much less worried about answers than I am about cross-tool collaboration 19:30:48 e.g., pulling discussions from ML and Forum and turning them into QnA, and sending QnA pointers to the ML 19:30:57 johnpur: you'll push an email to ML asking for volunteers to admin the QnA site ? 19:30:58 jmckenty: define cross-tool collaboration? 19:31:00 also making sure the THEMES / HEADERS for the various sites all link to each other 19:31:11 vishy: what do you want for lunch? vishy: want to get a drink, .... ;) 19:31:13 e.g., like having one schedule for the conferences 19:31:20 jmckenty: that can be a group of moderators from each media 19:31:26 johnpur: you might want to follow up directly with everett as well since he actually went to the effort to propose it 19:31:33 as long as they work together, yes <-- ttx 19:31:39 jbryce: agree 19:31:44 I prefer several groups working with each other, rahter than a single group being expoert in forums+QnA 19:31:59 anotherjesse: probably, asking those questions would be more effective if you did them through the site 19:32:02 :p 19:32:13 ttx: we will figure out the right structure 19:32:26 k, last request, then: 19:32:35 can we make sure the set of community tools is an openstack project 19:32:38 with a buglist 19:32:41 a release schedule 19:32:41 jmckenty: i'm going to hold you to that 19:32:44 and a PTL? 19:32:47 :p 19:33:02 There have been community complaints about not being able to get bugs on the .org site fixed 19:33:22 And I think a "patches-welcome" approach to these tools *might* help 19:34:25 jmckenty: this becomes somewhat of a meta-project... specifically, getting changes to openstack.org is a challenge, as it is not editable by the community. 19:34:31 hmm... not sure there is enough commonality on the tools 19:34:55 let me think about this, i will report back next week 19:34:55 rather have several separate ways to track requests 19:35:46 well, they're bug reports, not requests 19:35:48 ok 19:35:52 that's the mindset issue that I'm bringing up 19:36:07 if you think of them as community resources, and the community wants to fix something, it's a bug 19:36:10 not a request to RAX 19:36:37 i will say that some of this crosses over intot he realm of how the openstack assets are managed, who controls what, etc. 19:36:55 yes, exactly. But we're proliferating those assets 19:36:59 we need to provide more clarity here 19:37:01 without having defined the controls 19:37:30 jbryce: another action, for you and me to work on together? 19:37:59 can I again push back and suggest you include a non-RAX person in that? 19:38:13 volunteers? 19:38:16 just for outsider perspective 19:38:20 #action jbryce, johnpur work on tracking/managment of openstack.org and new community properties 19:38:27 I nominate ewanmellor ;) 19:38:36 But I'll take it if he doesn't 19:38:37 :) 19:39:03 we'll loop you in 19:39:11 let's keep moving 19:39:16 #topic Pre-Announced vs. Dynamic milestone plan for core projects 19:39:24 ttx: want to lead this one? 19:39:53 yep 19:40:02 I've been working on the release schedule for Diablo for approval by the PPB 19:40:10 It can be seen at http://wiki.openstack.org/DiabloReleaseSchedule 19:40:23 As you can see we have a full milestone plan for Nova and Glance 19:40:35 But just the "next milestone" for Swift. 19:40:49 The question is: do we accept, for core projects, some restricted visibility on the milestone plan 19:41:08 notmyname will probably elaborate on Swift team's position, which wants to be able to set the next milestone date and version number a few weeks before its delivery 19:41:33 I think this affects openness and transparency: potential contributors, as well as downstream users (other than rackspace) would get restricted information 19:41:51 It also drifts from our principle of time-based milestones 19:42:22 so I was wondering if that was ok with the PPB, and we can ack the schedule as is 19:43:25 if yes, let me know if I can consider the release schedule, as presented, "confirmed" :) 19:43:51 I thought we previously decided that PTLs can determine their own schedule as long as they may the large integration releases, so are you proposing we possibly remove that previous decision and push for more schedule governance? 19:44:05 i know we have a principle of time-based releases, but did we have a principle of time-based interim milestones? 19:44:16 i don't really mind. I think it makes sense for a project that is essentially feature complete 19:44:43 whew. sounds like I may not have to give my speech ;-) 19:44:53 eday: we decided that they could come with the plan they want, not that the plan could be dynamic 19:45:06 eday: but we can decide that dynamic milestone plan is ok :) 19:45:19 ahh, ok 19:45:49 the major issue with not declaring the plan up front is lack of direction tot he community 19:46:10 making it hard for outside folks to contribute 19:46:18 johnpur: right, it's not the best way to attract contributors 19:46:24 that sounds like a topic for the design summit 19:46:26 plans for the entire release (eg diablo) are still announced 19:46:34 johnpur: also makes yout roadmap a bit less readable 19:46:52 e.g., I don't think we've been asked yet to provide more structure on per-project milestones, isn't that really a PTL ballywhak? 19:46:53 i would expect most of the community to be planning around the releases anyway, especially on a more mature project 19:47:34 ok, we can try that and see in 6 months how well it flew. 19:47:43 jbryce: perhaps 19:47:47 i think i'd prefer to leave it up to the PTL and see if it actually does create barriers to entry or contribution 19:48:40 but RAX is not following this on their production pushes. Why would we think that Internap or other SP's deploying Swift would not want to track interim features and push asap? 19:49:09 johnpur: good point 19:49:14 at least have an idea when features will show up in a stable version of trunk 19:50:22 notmyname: do you have any plan for handling the other milestones or the features that aren't in the first one? 19:50:29 yes 19:50:43 we plan to track features in diablo 19:51:11 and as they near completion we will be able to better set dates for milestones 19:51:38 notmyname: so it's feature-based milestones and time-based releases ? 19:51:58 my goal is to have milestones roughly every 4-6 weeks with an announcement of them 2-4 weeks ahead of time 19:52:00 ttx: yes 19:52:09 is there a way for others to track that? to see what features are being worked/nearing completion? 19:52:28 jbryce: status on blueprints targetted for diablo 19:53:01 https://blueprints.launchpad.net/swift/diablo 19:55:03 ok...well perhaps we should take an actual vote on approving the diablo schedule as stands with dynamic milestones for swift 19:55:12 notmyname: any reason why you can't use monthly milestones, and just let the features that are in be delivered in the next milestone ? 19:55:51 notmyname: is it that it delays features delivery in milestones too much in corner cases ? 19:55:58 I'd argue that it actually reduces transparency for the releases we have 19:56:30 notmyname: explain? 19:56:46 if the PPB declares, we can do time-based releases. we'd prefer not two. we have 2 reasons for this 19:57:12 s/two/to 19:57:26 1) letting the project have more autonomy and more control over it's interim releases 19:58:07 2) if we do time-based releases, it will not line up with the internal releases we do here. what that means is that we will be forced to have "Secret" releases 19:58:19 damn, the meeting is on my google calendar for now. How did I get an hour off? 19:59:05 notmyname: can you explain your internal release rythym? 19:59:07 dendrobates: it's been updated on the google calendar, but it seems like the invite did not get updated for some people 19:59:12 for example, we are currently running 1.3.0-7 right now. it's a release, but a "secret" one because it's not part of a milestone. we would like to be more open about the official releases and have them line up better with the milestones 19:59:33 notmyname: is it possible to adjust internal releases to the public openstack cycles? 20:00:02 not as much as I'd like because there are more people involved (ops, qa, product) 20:01:26 notmyname: I fear that alignment with RS operational needs will ultimately lead to milestones being announced at the very last moment 20:01:55 notmyname: though I understand your will to not duplicae QA 20:02:01 duplicate 20:02:50 I think it's a valid concern. and I don't want to tie swift to RAX. but I also think that we can commit to not doing that. working with these groups at rax and (hopefully) others outside of rax, i can get a good feel of what and when a release should be 20:03:08 i'm still on the side of letting swift try the dynamic milestone plan for now 20:03:28 looking at the blueprint link, you can see that there's not an unending list of features to sift through 20:03:31 historically, we have not fallen into the feature-based-releases-never-ship trap, so in part, I'd like to only solve that issue when/if we actually have it 20:03:54 and if it becomes a problem, i'm sure we'll hear complaints about it and can adjust 20:04:36 I'm ok with trying this and reconsider at next design summit. 20:04:48 We'll see how well it flew by then. 20:04:53 yep 20:04:57 agreed. ttx and I talked for a while about bridging the RAX-openstack release cycle gap before coming to this plan. I like it more that ttx does, but I think it will work 20:05:41 jbryce: can the PPB approve the release schedule as it stands ? 20:05:58 +1 from me 20:06:11 +1 20:06:16 that means setting Sep 22 as the release date 20:06:39 +1 from me, obviously :) 20:06:48 +1 20:06:54 (and lets revisit after release to see how things worked out) 20:06:57 +1 20:07:17 +1 on setting Sep 22 as the date, +0 on having core projects that cannot project timelines over the course of the next announced release (6 month window) 20:08:06 #agreed Diable release schedule approved: http://wiki.openstack.org/DiabloReleaseSchedule 20:08:21 #topic Other topics 20:08:23 * ttx sets status to "approved" 20:08:30 what is going to happen when i go to the ptl's and ask for a 12 month roadmap projection? or ask about a +12m vision for their project? BTW, this is coming at you guys... :) 20:09:26 * jbryce hears crickets 20:09:37 * vishy hides 20:09:44 that's going to be hard to do with time-based milestones or not 20:10:07 an action that came out of the ds was a strong desire for guidance past the upcoming release... 20:10:28 not sure how to approach that exactly 20:10:33 right, but i don't know that time-based milestones is a solution for that. you're looking at multiple 6-month releases at that point 20:10:57 I don't really see the value of planning outside of customer feedback for > 6 months 20:11:06 people are betting their businesses on openstack, they deserve some visibility into the future, business does not run with 6 month visibility windows 20:11:09 which will be fuzzy, for sure, but also i would say we try to connect as much as possible to releases rather than milestones 20:11:19 we haven't come accross any features that need more than six months unless you count slippage 20:11:30 lol 20:11:34 :) 20:11:39 vishy: federation? 20:11:42 johnpur: they want influence not visibility 20:11:53 vishy: workload portability? 20:12:06 vishy: advanced networking? 20:12:13 etc 20:12:33 johnpur: will be difficult to get with 6-month elected PTLs 20:12:43 dendrobates: visibility implies discussion, ie influence 20:13:01 those are all not available in this 6 month window 20:13:11 but i don't think they require > 6 months to implement 20:13:17 vishy: my point! 20:13:46 I don't think we can maintain our idea of design summits planning for next release if we are planning features out at that scale 20:13:48 It's difficult already to get a clear feature plan for diablo... ;) 20:14:05 I wonder how useful a feature list beyond diablo would be? trying to take into account current task slippage, no discussions around those featuers until E design summit, etc. Even if I had that list, I wouldn't bet any business on it :) 20:14:26 it is important that we give guidance to the vision and direction, even if we need to wait 1 or 2 ds cycles to get to the implementation 20:14:49 eday: I agree. It is just imaginary feature planning 20:14:49 i think it would be impossible to give people dates on any of that, but the thing that people are looking for is direction and some approximation 20:14:54 i will stop now :) 20:15:12 but ptls... you are forwarned! 20:15:14 they'd like to know if thing X is even something people are thinking about 20:15:28 johnpur: we can make stuff up and call it "marketing" but i don't see any real value from an implementation perspective 20:15:30 and something like the networking services is definitely going to extend beyond diablo 20:15:37 in that case, make a blueprint for it and don't target it to a series yet 20:16:08 johnpur: each dev group can have their own +12m roadmap 20:16:23 but the project, in itself, would be hard-pressed to guarantee it 20:16:28 blueprints that aren't targeted are fine 20:16:28 vishy: agree to disagree. if we do not succeed in federating os clouds it will be a fail. this is not imaginary, just not being implemented currently. 20:17:10 johnpur: I think "Ozone" for example, can have a +12m plan. They know their resources and what they want to work on 20:17:16 johnpur: what value does saying that it is a planned feature if we can't implement it though outside of marketing? 20:17:22 "OpenStack" ? not so much 20:17:57 Large features are dependent on an actual implementation team/group 20:18:04 I mean, nobody knows what will be in the Linux kernel in one year. 20:18:20 though lots of companies are betting their business on it. 20:18:20 I can say that we plan on federating in 12 months, but without a team to back it up, it is kind of useless imo... 20:18:36 vishy: I'm happy to do it for marketing reasons though :) 20:18:46 it's not just marketing 20:18:49 vishy: it gives direction to current implementations, if there are dependencies or potential side effects 20:19:04 it will encourage people to pitch in on the things they care about 20:19:22 jbryce: I need to go now... 20:19:23 i believe the networking effort is a good example of this 20:19:31 ttx: ok 20:19:44 actually i have to head off as well 20:20:12 johnpur: I am much more confident in fast iterations in an agile style, but we can try to come up with a rough 12m+ roadmap 20:20:23 thanks for joining everyone 20:20:48 vishy: thx 20:20:57 #endmeeting