19:03:33 <jbryce> #startmeeting
19:03:34 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:03:35 <jbryce> = )
19:04:09 <jbryce> agenda - http://wiki.openstack.org/Governance/PPB
19:04:13 <jbryce> #topic previous actions
19:04:36 <ttx> Eric and I had to draft a project model description
19:04:47 <jbryce> ttx and I sent out drafts
19:04:53 <ttx> Visible at http://etherpad.openstack.org/PQ7dy5in2B
19:04:59 <anotherjesse> here!
19:05:04 <ttx> yay, quorum
19:05:06 <jbryce> I went ahead and added it to the http://wiki.openstack.org/ProjectTypes page
19:05:18 <ttx> jbryce: ok
19:05:33 <johnpur> jbryce: i had a couple of comments, sent back on the list
19:06:49 <anotherjesse> project resources <- kinda confusing to say that - since code has its own license
19:07:17 <anotherjesse> maybe defining resources as things like domains, ...?
19:07:49 <anotherjesse> strike that
19:08:13 <ttx> Anne suggests we add "documentation" as a Commonality?
19:08:19 <ttx> I'll add it
19:08:23 <ewanmellor> 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 <annegentle> 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 <johnpur> 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 <eday> 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 <ttx> jbryce: agree with johnpur that "incubation assets" needs a definition
19:11:10 <jbryce> johnpur: they seemed like broader concepts so i just stuck them at the top
19:11:23 <johnpur> for instance, related projects don't have the constraints or the supportgiven tot he other 2 classes
19:11:37 <ewanmellor> eday: That's what I expected.  I think the language could do with some work.
19:12:01 <jbryce> johnpur: feel free to edit the page
19:12:15 <johnpur> ha ha... walked into that one!
19:12:29 <jbryce> 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 <ttx> johnpur: at least, you are free to try
19:12:46 <ttx> wikis are not tha tgood at simuletaneous edits
19:13:03 <jbryce> we said they could get a subdomain, they could potentially use the build infrastructure....what else should go in there?
19:13:21 <johnpur> i'll defer any edits until later to give others room to update
19:13:22 <jmckenty> should we pull that page into etherpad for some editing
19:13:26 <jmckenty> ?
19:13:36 <jmckenty> jbryce: what about the mailing lists?
19:13:49 <ttx> jmckenty: that's where my part was originally placed :)
19:14:09 <eday> jmckenty: that's really a community thing, anyone can use the mailing list, incubated or not :)
19:14:16 <ewanmellor> "approved for entry into the Incubator program": should that read "approved by the PPB"?
19:14:30 <jmckenty> yes, although it's implied
19:14:39 <ttx> ok, stop editing, I'll push to etherpad
19:15:02 <johnpur> 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 <ttx> http://etherpad.openstack.org/PQ7dy5in2B
19:15:33 <jmckenty> 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 <jmckenty> otherwise I would be tempted to shout "off topic" occasionally
19:15:53 <eday> makes sense
19:15:59 <jmckenty> the volume on that list means I rarely read it now
19:16:05 <jmckenty> I only read 100% on the -poc list
19:16:36 <ttx> please edit on etherpad
19:18:35 <jmckenty> edit-in-progress....
19:19:53 <jbryce> 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 <jbryce> related to that second item, we actually had a proposal: http://wiki.openstack.org/Governance/Proposed/QuestionAndAnswerSoftware
19:20:23 <johnpur> related projects do or do not have the "right" to the channels, ml, etc.?
19:21:00 <ttx> anotherjesse: does my new paragraph fit the bill for your concern ?
19:21:38 <ttx> (distribution)
19:21:48 <jmckenty> jbryce: looking at QnA now...
19:21:56 <anotherjesse> looks good
19:22:22 <jbryce> johnpur: not sure how to define those rights
19:22:30 <eday> johnpur: I would say do, are we really going to moderate? We should avoid business advertising, but project announcements seem appropriate
19:22:42 <jmckenty> eday: how do you differentiate those?
19:22:52 <johnpur> 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 <jmckenty> e.g., if I have a freemium product, can I announce that?
19:23:27 <jbryce> 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 <jmckenty> 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 <jmckenty> e.g., everyone who wants a new tool needs to step up and help moderate content ACROSS tools
19:24:19 <jmckenty> pulling discussions out of forums and adding them to QnA, etc
19:24:23 <eday> jmckenty: I would say free as in beer and source code
19:24:55 <johnpur> my fear is that if the communication channels are wide open that we may have scoping issues
19:25:01 <jmckenty> 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 <jmckenty> johnpur: I agree on the scoping issues as well
19:25:20 <vishy> I'm pretty happy about the QnA site idea
19:25:33 <vishy> i find launchpad questions to be pretty annoying
19:25:36 <jmckenty> Who owns it, then - spector?
19:26:00 <ttx> vishy: yes, we need something that allows the best questions and the best answers to be very apparent
19:26:10 <jmckenty> or is that something that anne gentle can help with?
19:26:51 <johnpur> 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 <jmckenty> 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 <vishy> ttx: and allows questions and answers to be edited later when things change
19:27:09 <jmckenty> johnpur: I have an awesome candidate for you
19:27:25 <johnpur> send the name along, with contact info!
19:27:30 <ttx> jmckenty: we all have :)
19:27:49 <johnpur> next week i am going full court press on finding the right person
19:27:51 <jmckenty> really? If you have awesome candidates for ANYTHING, you should be emailing me ;)
19:28:01 <jmckenty> sorry, OT
19:28:06 <ttx> jmckenty: heh
19:28:18 <jmckenty> back, to my other point - anyone second calling this a working group?
19:28:30 <jmckenty> I'm really concerned about an Ad-hoc approach here, I think we'll end up with shark tank
19:28:53 <ttx> jmckenty: I think we can ask on the ML for QnA lovers
19:28:58 <jmckenty> http://brandonhays.com/blog/2011/05/03/why-i-still-dont-contribute-to-open-source/
19:29:04 <ttx> to set up the core moderator group
19:29:22 <ttx> someone with experience with QnA would be a +
19:29:28 <jmckenty> ttx: +1
19:29:34 <johnpur> jmckenty: +1 to setting up some structure around community tools
19:30:01 <vishy> I'm willing to contribute a lot to answers on the site
19:30:02 <johnpur> i can take this and organize
19:30:20 <jbryce> #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 <jmckenty> vishy: I'm much less worried about answers than I am about cross-tool collaboration
19:30:48 <jmckenty> e.g., pulling discussions from ML and Forum and turning them into QnA, and sending QnA pointers to the ML
19:30:57 <ttx> johnpur: you'll push an email to ML asking for volunteers to admin the QnA site ?
19:30:58 <johnpur> jmckenty: define cross-tool collaboration?
19:31:00 <jmckenty> also making sure the THEMES / HEADERS for the various sites all link to each other
19:31:11 <anotherjesse> vishy: what do you want for lunch? vishy: want to get a drink,  .... ;)
19:31:13 <jmckenty> e.g., like having one schedule for the conferences
19:31:20 <ttx> jmckenty: that can be a group of moderators from each media
19:31:26 <jbryce> 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 <jmckenty> as long as they work together, yes <-- ttx
19:31:39 <johnpur> jbryce: agree
19:31:44 <ttx> I prefer several groups working with each other, rahter than a single group being expoert in forums+QnA
19:31:59 <vishy> anotherjesse: probably, asking those questions would be more effective if you did them through the site
19:32:02 <vishy> :p
19:32:13 <johnpur> ttx: we will figure out the right structure
19:32:26 <jmckenty> k, last request, then:
19:32:35 <jmckenty> can we make sure the set of community tools is an openstack project
19:32:38 <jmckenty> with a buglist
19:32:41 <jmckenty> a release schedule
19:32:41 <jbryce> jmckenty: i'm going to hold you to that
19:32:44 <jmckenty> and a PTL?
19:32:47 <jmckenty> :p
19:33:02 <jmckenty> There have been community complaints about not being able to get bugs on the .org site fixed
19:33:22 <jmckenty> And I think a "patches-welcome" approach to these tools *might* help
19:34:25 <johnpur> 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 <ttx> hmm... not sure there is enough commonality on the tools
19:34:55 <johnpur> let me think about this, i will report back next week
19:34:55 <ttx> rather have several separate ways to track requests
19:35:46 <jmckenty> well, they're bug reports, not requests
19:35:48 <jbryce> ok
19:35:52 <jmckenty> that's the mindset issue that I'm bringing up
19:36:07 <jmckenty> if you think of them as community resources, and the community wants to fix something, it's a bug
19:36:10 <jmckenty> not a request to RAX
19:36:37 <johnpur> 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 <jmckenty> yes, exactly. But we're proliferating those assets
19:36:59 <johnpur> we need to provide more clarity here
19:37:01 <jmckenty> without having defined the controls
19:37:30 <johnpur> jbryce: another action, for you and me to work on together?
19:37:59 <jmckenty> can I again push back and suggest you include a non-RAX person in that?
19:38:13 <johnpur> volunteers?
19:38:16 <jmckenty> just for outsider perspective
19:38:20 <jbryce> #action jbryce, johnpur work on tracking/managment of openstack.org and new community properties
19:38:27 <jmckenty> I nominate ewanmellor ;)
19:38:36 <jmckenty> But I'll take it if he doesn't
19:38:37 <jmckenty> :)
19:39:03 <jbryce> we'll loop you in
19:39:11 <jbryce> let's keep moving
19:39:16 <jbryce> #topic Pre-Announced vs. Dynamic milestone plan for core projects
19:39:24 <jbryce> ttx: want to lead this one?
19:39:53 <ttx> yep
19:40:02 <ttx> I've been working on the release schedule for Diablo for approval by the PPB
19:40:10 <ttx> It can be seen at http://wiki.openstack.org/DiabloReleaseSchedule
19:40:23 <ttx> As you can see we have a full milestone plan for Nova and Glance
19:40:35 <ttx> But just the "next milestone" for Swift.
19:40:49 <ttx> The question is: do we accept, for core projects, some restricted visibility on the milestone plan
19:41:08 <ttx> 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 <ttx> I think this affects openness and transparency: potential contributors, as well as downstream users (other than rackspace) would get restricted information
19:41:51 <ttx> It also drifts from our principle of time-based milestones
19:42:22 <ttx> so I was wondering if that was ok with the PPB, and we can ack the schedule as is
19:43:25 <ttx> if yes, let me know if I can consider the release schedule, as presented, "confirmed" :)
19:43:51 <eday> 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 <jbryce> i know we have a principle of time-based releases, but did we have a principle of time-based interim milestones?
19:44:16 <vishy> i don't really mind.  I think it makes sense for a project that is essentially feature complete
19:44:43 <notmyname> whew. sounds like I may not have to give my speech ;-)
19:44:53 <ttx> eday: we decided that they could come with the plan they want, not that the plan could be dynamic
19:45:06 <ttx> eday: but we can decide that dynamic milestone plan is ok :)
19:45:19 <eday> ahh, ok
19:45:49 <johnpur> the major issue with not declaring the plan up front is lack of direction tot he community
19:46:10 <johnpur> making it hard for outside folks to contribute
19:46:18 <ttx> johnpur: right, it's not the best way to attract contributors
19:46:24 <jmckenty> that sounds like a topic for the design summit
19:46:26 <notmyname> plans for the entire release (eg diablo) are still announced
19:46:34 <ttx> johnpur: also makes yout roadmap a bit less readable
19:46:52 <jmckenty> 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 <jbryce> i would expect most of the community to be planning around the releases anyway, especially on a more mature project
19:47:34 <ttx> ok, we can try that and see in 6 months how well it flew.
19:47:43 <johnpur> jbryce: perhaps
19:47:47 <jbryce> 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 <johnpur> 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 <ttx> johnpur: good point
19:49:14 <johnpur> at least have an idea when features will show up in a stable version of trunk
19:50:22 <jbryce> notmyname: do you have any plan for handling the other milestones or the features that aren't in the first one?
19:50:29 <notmyname> yes
19:50:43 <notmyname> we plan to track features in diablo
19:51:11 <notmyname> and as they near completion we will be able to better set dates for milestones
19:51:38 <ttx> notmyname: so it's feature-based milestones and time-based releases ?
19:51:58 <notmyname> 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 <notmyname> ttx: yes
19:52:09 <jbryce> is there a way for others to track that? to see what features are being worked/nearing completion?
19:52:28 <eday> jbryce: status on blueprints targetted for diablo
19:53:01 <ttx> https://blueprints.launchpad.net/swift/diablo
19:55:03 <jbryce> ok...well perhaps we should take an actual vote on approving the diablo schedule as stands with dynamic milestones for swift
19:55:12 <ttx> 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 <ttx> notmyname: is it that it delays features delivery in milestones too much in corner cases ?
19:55:58 <notmyname> I'd argue that it actually reduces transparency for the releases we have
19:56:30 <ttx> notmyname: explain?
19:56:46 <notmyname> if the PPB declares, we can do time-based releases. we'd prefer not two. we have 2 reasons for this
19:57:12 <notmyname> s/two/to
19:57:26 <notmyname> 1) letting the project have more autonomy and more control over it's interim releases
19:58:07 <notmyname> 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 <dendrobates> damn, the meeting is on my google calendar for now.  How did I get an hour off?
19:59:05 <johnpur> notmyname: can you explain your internal release rythym?
19:59:07 <jbryce> 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 <notmyname> 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 <eday> notmyname: is it possible to adjust internal releases to the public openstack cycles?
20:00:02 <notmyname> not as much as I'd like because there are more people involved (ops, qa, product)
20:01:26 <ttx> notmyname: I fear that alignment with RS operational needs will ultimately lead to milestones being announced at the very last moment
20:01:55 <ttx> notmyname: though I understand your will to not duplicae QA
20:02:01 <ttx> duplicate
20:02:50 <notmyname> 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 <jbryce> i'm still on the side of letting swift try the dynamic milestone plan for now
20:03:28 <jbryce> looking at the blueprint link, you can see that there's not an unending list of features to sift through
20:03:31 <notmyname> 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 <jbryce> and if it becomes a problem, i'm sure we'll hear complaints about it and can adjust
20:04:36 <ttx> I'm ok with trying this and reconsider at next design summit.
20:04:48 <ttx> We'll see how well it flew by then.
20:04:53 <jbryce> yep
20:04:57 <notmyname> 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 <ttx> jbryce: can the PPB approve the release schedule as it stands ?
20:05:58 <jbryce> +1 from me
20:06:11 <eday> +1
20:06:16 <ttx> that means setting Sep 22 as the release date
20:06:39 <ttx> +1 from me, obviously :)
20:06:48 <notmyname> +1
20:06:54 <eday> (and lets revisit after release to see how things worked out)
20:06:57 <vishy> +1
20:07:17 <johnpur> +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 <jbryce> #agreed Diable release schedule approved: http://wiki.openstack.org/DiabloReleaseSchedule
20:08:21 <jbryce> #topic Other topics
20:08:23 * ttx sets status to "approved"
20:08:30 <johnpur> 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 <jbryce> that's going to be hard to do with time-based milestones or not
20:10:07 <johnpur> an action that came out of the ds was a strong desire for guidance past the upcoming release...
20:10:28 <vishy> not sure how to approach that exactly
20:10:33 <jbryce> 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 <vishy> I don't really see the value of planning outside of customer feedback for > 6 months
20:11:06 <johnpur> 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 <jbryce> 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 <vishy> we haven't come accross any features that need more than six months unless you count slippage
20:11:30 <johnpur> lol
20:11:34 <vishy> :)
20:11:39 <johnpur> vishy: federation?
20:11:42 <dendrobates> johnpur: they want influence not visibility
20:11:53 <johnpur> vishy: workload portability?
20:12:06 <johnpur> vishy: advanced networking?
20:12:13 <johnpur> etc
20:12:33 <ttx> johnpur: will be difficult to get with 6-month elected PTLs
20:12:43 <johnpur> dendrobates: visibility implies discussion, ie influence
20:13:01 <vishy> those are all not available in this 6 month window
20:13:11 <vishy> but i don't think they require > 6 months to implement
20:13:17 <johnpur> vishy: my point!
20:13:46 <vishy> 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 <ttx> It's difficult already to get a clear feature plan for diablo... ;)
20:14:05 <eday> 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 <johnpur> 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 <vishy> eday: I agree.  It is just imaginary feature planning
20:14:49 <jbryce> 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 <johnpur> i will stop now :)
20:15:12 <johnpur> but ptls... you are forwarned!
20:15:14 <jbryce> they'd like to know if thing X is even something people are thinking about
20:15:28 <vishy> 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 <jbryce> and something like the networking services is definitely going to extend beyond diablo
20:15:37 <notmyname> in that case, make a blueprint for it and don't target it to a series yet
20:16:08 <ttx> johnpur: each dev group can have their own +12m roadmap
20:16:23 <ttx> but the project, in itself, would be hard-pressed to guarantee it
20:16:28 <jbryce> blueprints that aren't targeted are fine
20:16:28 <johnpur> 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 <ttx> 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 <vishy> johnpur: what value does saying that it is a planned feature if we can't implement it though outside of marketing?
20:17:22 <ttx> "OpenStack" ? not so much
20:17:57 <vishy> Large features are dependent on an actual implementation team/group
20:18:04 <ttx> I mean, nobody knows what will be in the Linux kernel in one year.
20:18:20 <ttx> though lots of companies are betting their business on it.
20:18:20 <vishy> 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> vishy: I'm happy to do it for marketing reasons though :)
20:18:46 <jbryce> it's not just marketing
20:18:49 <johnpur> vishy: it gives direction to current implementations, if there are dependencies or potential side effects
20:19:04 <jbryce> it will encourage people to pitch in on the things they care about
20:19:22 <ttx> jbryce: I need to go now...
20:19:23 <johnpur> i believe the networking effort is a good example of this
20:19:31 <jbryce> ttx: ok
20:19:44 <jbryce> actually i have to head off as well
20:20:12 <vishy> 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 <jbryce> thanks for joining everyone
20:20:48 <johnpur> vishy: thx
20:20:57 <jbryce> #endmeeting