19:06:48 #startmeeting 19:06:49 Meeting started Thu Jun 2 19:06:48 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:06:50 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:07:25 http://wiki.openstack.org/Governance/PPB - agenda is listed there 19:07:46 most of this has already been discussed on the list so we should be able to move pretty quickly through it 19:08:14 #topic core project promotion only for releases 19:08:44 Thierry's proposal was that projects can only be promoted to core for the following release cycle rather than allowing it in the middle of a cycle. Seemed like most people agreed with that 19:08:51 +1 to thierry's recommendation 19:08:54 ho/ 19:09:06 +1 19:09:09 I updated the new project process to include the following language to make this the policy: 19:09:11 "Once a project is approved for addition as an core project, it will be promoted in the next release cycle. All projects must be approved for promotion to core 6 weeks before a release cycle's design summit. After approval, a new PTL will be elected for the project in the regular PTL election cycle." 19:09:43 +1 from me as well 19:09:45 +1 19:09:49 +1 19:09:51 +1 19:10:28 #agreed Projects will only be promoted to core for the following release cycle as stated in the updated new project process 19:10:44 #topic incubation process policies 19:11:01 http://wiki.openstack.org/ProjectTypes 19:11:02 http://wiki.openstack.org/Governance/Proposed/Incubation 19:11:02 http://wiki.openstack.org/Projects/IncubatorApplication 19:11:24 Those 3 documents together lay out the purpose and process for a project applying and being approved to be an official incubation project 19:11:33 jbryce: has you discussed the incubation process with RS legal. At some point we need to make sure all previous contributers have signed the CLA, right? 19:12:00 we've discussed most of them but have made a number of iterative changes over the past few weeks and i'd like to actually get a vote on them on record 19:12:14 dendrobates: good point. i will make sure that is part of the process. 19:12:55 #action Make sure incubation projects follow CLA procedures and previous contributors have agreed to CLA 19:13:04 If the project is not approved, it may continue as an incubated project? 19:13:26 if the project is not approved for core? we previously said yes 19:13:49 no that is on incubation page 19:14:26 ahh...that's in reference to step for--the application for core promotion 19:14:28 i will make that more clear 19:14:57 updated 19:15:03 cool 19:15:06 +1 from me 19:15:12 +1 19:15:40 +1 19:15:47 seems to me that there should be some explicit provision for removing an incubated project 19:15:57 is that "If the project fails to make progress..."? 19:16:03 yes 19:16:08 it's basically PPB discretion 19:16:28 so what are the changes you are making? 19:16:37 * jaypipes reading back.. 19:16:37 i changed #5 19:17:00 from "If the project is not approved, it may continue as an incubated project" to "If the project is not approved by the Policy Board to be promoted to a core project, it may continue as an incubated project" 19:17:52 jbryce: typo on #6: s/may remove is/may remove it/ 19:18:10 Sorry, just catching up a bit here. 19:18:22 jaypipes: thanks. fixed. 19:18:34 The CLA is an agreement between the contributor and who else? 19:18:56 I think it would be useful to mention what the *benefit* of being in an incubated status is on that document 19:18:58 I don't remember and don't have a copy at hand. 19:19:02 soren: rackspace 19:19:05 +1 on the docs 19:19:19 jaypipes: that's covered in http://wiki.openstack.org/ProjectTypes 19:19:23 soren: http://wiki.openstack.org/CLA 19:19:38 notmyname: oh, doh. thx :) 19:19:51 So if some other entity (be it corporate or otherwise) has a project that ends up in openstack, their contributors have to sign an agreement with *Rackspace* because... 19:20:14 soren: patent protections mainly, I believe 19:20:15 Is there going to be a wiki or web page that lists projects that are in incubated status? 19:20:22 soren: it's between the contributor and OpenStack LLC (owned by Rackspace right now) because OpenStack LLC is the Project Manager who is actually granting the Apache License on OpenStack projects 19:20:27 soren: OpenStack, LLC 19:20:33 dendrobates: So why don't we sign a similar agreement with everyone else involved? 19:20:44 jaypipes: yes. i will add a section to wiki.openstack.org/Projects 19:20:48 dendrobates: patents are covered in the apache license 19:20:56 jbryce: coolio. 19:21:14 notmyname: but that is not valid in every country unless specifically agreed to, hence the CLA 19:21:38 or so I understand from the lawyers 19:21:42 the CLA explicitly grants OpenStack LLC the write to perpetually release the code under Apache for all contributions the contributor makes 19:21:42 jbryce: one more typo on last paragraph: s/have successfully release/have successfully released/ 19:21:44 I don't think it's clear at all that OpenStack is a legal entity. 19:21:52 dendrobates: correct 19:21:56 and even less so that it's owned by Rackspace. 19:22:32 I felt that was pretty explicitly talked about in the initial business sessions at the summit 19:22:33 jaypipes: thanks for the proofreading. i'm usually the grammar nazi. = ) 19:22:40 :) np 19:22:41 soren: I agree that should be more clear in the doc, but it is referred to as a LLc which is a legal entity 19:22:41 But I guess that's a discussion for another day. It just seems weird to require legally binding agreements to add code to openstack. 19:23:10 dendrobates: I don't just mean in the agreement, but more generally. 19:23:10 +1 that it could be made more clear in official docs 19:23:39 also +1 that it's a discussion for a different day :-) 19:23:52 Yeah. 19:24:17 yes 19:24:30 is it another day yet? :) 19:24:37 jk 19:24:42 this last line: "In general, a project will need to have successfully release at least two milestones before it will be considered as a core project." I think it may be better to be more specific on that. Perhaps something like: "Project must have made at least 2 consistent, regular milestone releases. Project must participate in an integration release (6 month release cycle), the first of which will be considered 19:24:42 :) 19:24:42 alpha-quality)" Or something like that? 19:25:24 basically, I'm keen to make more specific the way the incubated project treats *the first integrated release* 19:25:46 and how the other core projects treat the incubated project during the integrated release... 19:26:25 because the integrated releases only happen every 6 months, that would push core promotion out an additional 6 months if they have to go through an entire integrated release as well, right? 19:26:28 what are the specific expectations for each of the parties involved? Is the release manager responsible for treating incubated projects differently during integration release time? 19:27:27 jbryce: well, I guess I'm saying that if Lunr releases 2 milestone releases, but doesn't participate in the integration release, I don't think they should become core. But if they *do* participate in the integration release, I think they would.. 19:27:29 as laid out currently, they would have to meet all requirements for promotion and be approved by the ppb 6 weeks before a release cycle design summit 19:27:38 Lunr is just an example here of course, nothing more. 19:27:55 then, starting the next release cycle, they would be core and in the process through the entire 6 months 19:28:14 so taking lunr, they would not be able to be in diablo and would need to be approved 6 months before the design summit this fall 19:28:14 jbryce: yeah, I'm trying to suggest one of those PPB promotion requirements is participation in the integration release process :) 19:28:39 if approved, their first core release would be e next spring which would be managed by the release manager through the entire 6 months cycle 19:28:50 jbarratt_: in other words, how can we promote a project to core that hasn't demonstrated "integratability" 19:28:51 ? 19:28:57 ah, gotcha 19:29:08 jaypipes: do we need a "transitional" state? 19:29:09 so you're saying they couldn't be core until F, but we would treat them as core from a release perspective in e? 19:29:29 where the project is pending-core, but does not have an integrated release out yet? 19:29:40 jmckenty: maybe, but I don't necessarily think so. I just think one of the promotion requirements should be a plan for integration and demonstrated participation in the area of integration. 19:29:43 jmckenty: isn't that incubator? 19:29:56 no 19:30:06 I think a lot of incubated projects might never become core 19:30:11 i think with 6 month releases, this pushes it out too far 19:30:23 i'd rather put a specific requirement in like jaypipes says around integration 19:30:26 k 19:30:41 but not necessarily make it a requirement that they go through an entire integration release before they get promoted 19:31:14 jbryce: I'm just saying that "Integration with OpenStack processes around testing, releases, and community management" may be a bit vague and proposed projects might appreciate a bit more detail on what we expect from them regarding integration. 19:31:25 jbryce: sure. 19:31:34 well, I can see confusion if they're listed as an openstack core project, but they're not yet available in an official release 19:32:04 or am I misreading that 19:32:07 jmckenty: i think we can make that clear in the messaging around the releases 19:32:20 jmckenty: How can a project be core that hasn't demonstrated its ability to be integrated into the official distribution? 19:32:39 jaypipes: which official distribution? ;) 19:32:58 jaypipes: something like this: "In general, a project will need to have successfully released at least two milestones and demonstrated a satisfactory level of integration with existing core projects before it will be considered as a core project." 19:33:01 ? 19:33:13 jbryce: good. 19:33:32 ok 19:33:35 sure. Maybe we can use that to promote openstack-common ;) 19:33:42 jbryce: of course "what is a satisfactory level of integration" is the next question a project lead will ask ;) 19:34:10 jbryce: so we should spend some time over the next few months to brainstorm what we mean by that. 19:34:11 i think there will be a lot of variance between different types of projects. some of it will have to just be PPB discretion. 19:34:24 jbryce: but leaving it right now with that language is good for me. 19:34:28 good with me... 19:34:32 +1 19:34:37 agreed that we should flesh out more of an evaluation checklist for core consideration 19:34:39 revote on the 3 incubation documents? 19:34:51 #vote +1 19:34:59 #vote +1 19:35:11 #vote +1 19:35:22 +1 19:35:26 #vote +1 19:35:29 #vote +1 19:35:35 #vote +1 19:35:38 woot 19:36:02 soren? 19:36:17 Sorry, got distracted. 19:36:31 +1 19:36:34 #agreed Approved incubation project documents 19:36:55 #action jbryce to notify list of incubation process 19:37:26 #topic Addition of Dashboard for OpenStack and Scalr as core projects 19:37:39 ooh, fun 19:37:52 Do we have an application that matches the new process? 19:37:59 Or can we push back and ask for that? 19:38:02 exactly 19:38:09 I'm assuming devcamcar is proposed PTL for dashboard 19:38:24 and stadil is proposed PTL for Scalr 19:38:36 but I'd love docs around license, codebase and repo, etc 19:38:46 based off that and the earlier decision to not promote projects in the middle of a release cycle, it seems like we should defer for now and request them to either enter incubation or to apply towards the end of the cycle? 19:39:10 Well, I can see Scalr taking a substantial amount of debate 19:39:14 i thought dash was applying for incubation 19:39:21 both on the language issues and the guest agent aspects 19:39:33 jmckenty: me too 19:39:37 so I would recommend they apply early 19:39:43 yeah 19:40:07 if dashboard is applying for incubation, I think we could get devcamcar to fill out the app pretty quickly 19:40:11 vishy: according to his openstack list email, it sounds like he wanted to move to core 19:40:33 i can respond to both and ask them to fill out incubation application. i'm sure they'll respond pretty quickly. 19:40:38 is that the route we want to go? 19:41:01 yes 19:41:03 I think so 19:41:08 I think incubation is the best for both 19:41:22 application for incubation :-) 19:41:35 ok 19:41:46 #action jbryce to contact dashboard and scalr and request they apply for incubation 19:42:18 #topic Meeting schedule 19:42:25 can we wait 19:42:29 last comment on that 19:42:41 can we make sure we have a separate agenda item for each application in the future 19:42:41 the incubation process wasn't totally clear before, but now that we have agreed on it, they should follow it... 19:43:01 we may also want to limit the number of apps we consider per meeting, otherwise we could get buried before summits 19:43:09 jmckenty: agreed 19:43:43 #info currently the meeting schedule is everything Thursday at 1900UTC/2:00 PM central 19:44:02 That still works well for me, mostly 19:44:09 Are there concerns? 19:44:10 i've had a few requests to decrease frequency, which i am ok with 19:44:20 it seems like we don't always have a full agenda so we've been ad hoc skipping them 19:44:21 bi-weekly for 1.5-2 hours? 19:44:41 I don't mind ending early, but I would hate to not have enough time 19:44:47 i'd rather have a fixed schedule that we stick to and have good attendance 19:45:20 what do others think? bi-weekly? 1-1.5 hours? 19:45:28 -1 19:45:38 notmyname: what's the thinking? 19:45:42 too slow to respond? 19:46:24 I'd prefer shorter meetings (as needed) normally scheduled weekly as we are currently doing instead of long bi-weekly meetings 19:46:26 I'd rather do it every week and have it be shorter 19:47:04 side note if anyone wants an irccloud invite, I'm loving it. 19:47:14 I'm OK with this slot, and either weekly or biweekly, as long as we get the calendar entries straight. 19:47:16 +0 19:47:24 ok 19:47:26 I'd prefer an iCal feed 19:47:28 i'm fine with that as well 19:47:30 biweekly. 19:47:34 that way I can track cancellations 19:47:35 there is an ical feed from the google calendar 19:47:40 oh, nice :) 19:47:51 and the google calendar is correct on the time 19:48:08 prefer biweekly, but I'm flexible on it :) 19:48:21 +0 19:48:22 I don't particularly enjoy this time slot, fwiw. 19:48:30 I ended up with two entries, one after the other, when the time changed. I presume that feed didn't cancel the first one, or something. 19:48:45 #info ical feed: https://www.google.com/calendar/ical/6i49nddt8eqqi1kv0uoc8noh94%40group.calendar.google.com/public/basic.ics 19:48:49 ewanmellor: now you have a free hour! 19:49:00 #info html: https://www.google.com/calendar/embed?src=6i49nddt8eqqi1kv0uoc8noh94%40group.calendar.google.com&ctz=America/Chicago 19:49:03 I have much more interesting things I could do on a Thursday evening. 19:49:12 soren: tmi 19:49:15 (9-10 PM) 19:49:21 jmckenty: You ain't seen nothing yet. 19:49:34 i'm a little offended that soren doesn't find us interesting. = ) 19:49:42 we could go to 12pm Central (1700UTC) as far as I'm concerned 19:49:55 Earlier than that is evil 19:50:00 that's even worse. 19:50:09 later, then? 19:50:11 i am completely flexible on timing and happy to try a different time slot if there's one that works, but we haven't seemed to come up with something better 19:50:34 Maybe an hour before the weekly openstack meeting? 19:50:44 s/an/the/ 19:50:47 that's Tuesday, right? 19:50:51 It is. 19:50:51 so 2000 UTC / 3:00 PM central on tuesdays? 19:50:56 Yes. 19:51:07 I'm working then anyway, because that evening is screwed. 19:51:10 ok 19:51:12 +1 19:51:13 +1 19:51:23 running away now, sorry. 19:51:42 i'll send a note to the list suggesting that 19:51:43 toodles 19:51:45 me too, another meeting to prepare for. 19:51:52 that's all i've got for today anyway 19:52:00 That slot is fine by me. 19:52:01 any last pressing issues from anyone? 19:52:19 #action jbryce to send email about new potential PPB meeting time of 2000 UTC on tuesdays 19:52:35 all right. thanks everyone! 19:52:38 #endmeeting