20:06:29 <ttx> #startmeeting
20:06:30 <openstack> Meeting started Tue Jul 31 20:06:29 2012 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:06:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:06:35 <bcwaldon> ttx: we know you can do it!
20:06:38 <ttx> Two topics on http://wiki.openstack.org/Governance/PPB
20:06:57 <ttx> #topic API stability
20:06:58 <ttx> http://wiki.openstack.org/Governance/Proposed/APIStability
20:07:10 <ttx> anyone up to defend this one ?
20:07:13 <mcaway> yep
20:07:24 <mcaway> so, it should be pretty straightforward
20:07:35 <ttx> Your nick now sounds like some express takeaway at McDo.
20:07:43 <markmc> heh
20:07:58 <markmc> idea is that the project should make its stance on API stability a bit more clear
20:08:10 <markmc> with a "this is very important to OpenStack" statement
20:08:35 <jaypipes> markmc: ++
20:08:40 <markmc> and, second, that the PPB should encourage folks to help out with a set of API guidelines
20:08:45 <markmc> the two links are
20:08:46 <ttx> markmc: so this is our "yes we care" moment ?
20:08:55 <markmc> http://wiki.openstack.org/Governance/Proposed/APIStability
20:09:01 <markmc> ttx, pretty much
20:09:03 * markmc shrugs
20:09:09 <markmc> http://wiki.openstack.org/APIChangeGuidelines
20:09:21 <markmc> the guidelines thing will help a lot of we can flesh them out
20:09:54 <ttx> ok, any questions before we formally express whether we care about APi stability or not ?
20:09:57 <markmc> looks like we had a nod to this before:
20:09:57 <vishy> I support guidelines, although they clearly need some more editing
20:09:58 <markmc> http://wiki.openstack.org/Governance/Proposed/APIGoals
20:10:05 <markmc> "Each successive implementation of the APIs should always be backwards-compatible;"
20:10:14 <markmc> vishy, they certainly do
20:10:29 <vishy> for example, I don't think adding post parameters to an api without versioning is acceptable
20:10:53 <vishy> (putting them in an extension is fine by me though)
20:11:04 <markmc> ah, there's a question
20:11:09 <markmc> do extensions fall under this?
20:11:17 <markmc> I had presumed yes
20:11:20 <bcwaldon> extensions should be thought of a mini-apis
20:11:26 <anotherjesse> I think the "example" section is a great way of exploring the api space…
20:11:46 <markmc> bcwaldon, with same or lesser API stability expectations?
20:11:50 <bcwaldon> markmc: 'each successive implementation...' needs to be better defined
20:11:58 <bcwaldon> markmc: same expectations
20:12:06 <markmc> bcwaldon, that's an old proposal - just point it out for completeness
20:12:07 <bcwaldon> markmc: versioned independently
20:12:08 <heckj> anotherjesse: +1
20:12:09 <vishy> markmc: extensions should be able to add things to requests and response, but I don' tthink they need any other requirements above that
20:12:11 <bcwaldon> markmc: kk
20:12:25 <johnpur> o/
20:12:27 <jaypipes> vishy: what about adding a limit=XXX&marker=XXX post params? that would need API minor version increment, not major version increment, right?
20:12:37 <ttx> The proposal still needs work, at this point we are just saying whether we care
20:12:46 <bcwaldon> we absolutely care
20:12:48 <vishy> jaypipes: sure although we haven't minor versioned any apis yet
20:12:57 <vishy> jaypipes: so why not do it with an extension?
20:12:58 <bcwaldon> for me, its just been an understanding that we all care
20:13:01 <ttx> and if our care extends to extensions
20:13:08 <markmc> yeah, right now it's a question of whether the PPB agrees with the stance here:
20:13:08 <markmc> http://wiki.openstack.org/Governance/Proposed/APIStability
20:13:10 <bcwaldon> I guess we need to explicitly say what we care about?
20:13:18 <bcwaldon> markmc: yes, lets vote
20:13:30 <ttx> I think yes on both accounts is pretty much a given, but the proposals authors would like affirmative vote
20:13:41 * ttx tries to remember how voting works
20:13:44 <markmc> well, not me actually :)
20:13:52 <jaypipes> vishy: is the time when an extension is merged back into core something that is written down somewhere?
20:13:52 * markmc always happy with rough consensus
20:13:57 <markmc> which I figure we had anyway
20:14:04 <bcwaldon> thats fine, nobody has said no
20:14:08 <markmc> awesome
20:14:14 <ttx> #startvote Agreement on proposed API Stability Statement: yes, no
20:14:17 <bcwaldon> voting just makes it obvious and records it in notes
20:14:22 <bcwaldon> #vote yes
20:14:22 <jaypipes> #vote yes
20:14:22 <ttx> hmm
20:14:25 <vishy> #vote yes
20:14:30 <johnpur> #vote yes
20:14:31 <danwent> #vote yes
20:14:31 <ttx> wait the thing didn't work
20:14:32 <anotherjesse> #vote yes
20:14:32 <Ravikumar_hp> #vote yes
20:14:39 <patelna> #vote yes
20:14:39 <anotherjesse> haha
20:14:43 <johnpur> lol
20:14:46 <anotherjesse> #vote petunia
20:14:54 <notmyname> ttx: gotta have the "?"
20:15:07 <ttx> #startvote Agreement on proposed API Stability Statement ? yes, no
20:15:08 <openstack> Begin voting on: Agreement on proposed API Stability Statement ? Valid vote options are yes, no.
20:15:09 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:15:11 <ttx> YEAH
20:15:16 <vishy> #vote yes
20:15:17 <bcwaldon> #vote yes
20:15:19 <jaypipes> #vote yes
20:15:21 <johnpur> #vote yes
20:15:22 <ttx> start again, only PPB members vote please
20:15:28 <ttx> #vote yes
20:15:41 <danwent> #vote yes
20:16:15 <ttx> notmyname, anotherjesse ?
20:16:57 <ttx> heckj?
20:17:24 <anotherjesse> #vote yes
20:17:34 <heckj> #vote yes
20:17:59 <ttx> closing in 30 seconds
20:18:19 <notmyname> #vote yes
20:18:19 <nati_ueno> #vote yes
20:18:31 <ttx> #endvote
20:18:32 <openstack> Voted on "Agreement on proposed API Stability Statement ?" Results are
20:18:33 <openstack> yes (10): anotherjesse, bcwaldon, ttx, notmyname, vishy, heckj, jaypipes, johnpur, danwent, nati_ueno
20:18:42 <jaypipes> wow, contentious.
20:18:46 <ttx> nati_ueno: only PPB members vote, sorry :)
20:18:46 <markmc> thanks
20:18:51 * markmc moves to /Approved
20:18:56 <ttx> markmc: anything more on that subject ?
20:19:08 <bcwaldon> markmc: I would love to work with you on api goals when the time comes
20:19:09 <markmc> ttx, everyone help with the guidelines! :)
20:19:18 <markmc> bcwaldon, cool
20:19:31 <ttx> #topic Supporting projects
20:19:45 <ttx> #link http://wiki.openstack.org/Governance/Proposed/SupportingProjectDefinition
20:20:11 <ttx> So this is a try to align our current structure with the proposed future TC structure
20:20:47 <ttx> Basically we have a number of projects that are considered "OpenStack" with contributors that are relevant technical contributors that should be allowed to vote in TC elections
20:21:11 <ttx> So we need to assert that this category of project exist, and put a number of them in that category
20:21:24 <annegentle> I'd like to voice a concern about leaving openstack-chef and the TryStack project off that list
20:21:39 <ttx> Gives those project contributors the right to vote in directly-elected TC seats election
20:21:40 <annegentle> Those two projects help increase adoption and support documentation efforts by providing real environments.
20:21:52 <annegentle> They're also great bridge projects to operators and cloud users.
20:21:54 <ttx> On the other hand, puts that project under the TC authority
20:22:04 <ttx> so it's a bit of a two-edged sword
20:22:16 <ttx> So first, do we agree about the category ?
20:22:34 <ttx> i.e. Proposal 1 in http://wiki.openstack.org/Governance/Proposed/SupportingProjectDefinition
20:22:47 <ttx> Questions on that part ?
20:23:10 <ttx> annegentle: let's discuss which projects are and aren't considered in that category when we'll discuss Proposal 2
20:23:15 <johnpur> LGTM
20:23:30 <annegentle> ttx: got it
20:23:43 <anotherjesse> ttx: can you give examples in part 1 (in the doc?)
20:23:56 <anotherjesse> err, nevermind
20:24:05 <devcamca-> o/
20:24:19 <ttx> ready to vote on the first part ?
20:24:54 <ttx> #startvote Creating a "supporting" project official category? yes, abstain, no
20:24:55 <openstack> Begin voting on: Creating a "supporting" project official category? Valid vote options are yes, abstain, no.
20:24:56 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:25:04 * ttx is getting better at this startvote thing
20:25:08 <bcwaldon> #vote yes
20:25:10 <johnpur> #vote yes
20:25:15 <ttx> #vote yes
20:25:21 <danwent> #vote yes
20:25:55 <devcamcar> #vote abstain
20:26:09 <bcwaldon> ttx: you might want to expand on what the requirements are to be a supporting project
20:26:15 <vishy> #vote yes
20:26:15 <bcwaldon> ttx: i.e. what you are expected to do
20:27:20 <ttx> bcwaldon: You inherit allthe duties of other openstack official projects, but maybe I could expand on that
20:27:43 <ttx> http://wiki.openstack.org/ProjectTypes
20:27:46 <bcwaldon> sure, or maybe I should just read more
20:27:51 <anotherjesse> #vote yes
20:28:14 <ttx> bcwaldon: there are a few pieces out there that assume the supporting projects already exist ;)
20:28:24 <ttx> vote closes in 30 sec
20:28:31 <heckj> #vote abstain
20:28:54 <notmyname> #vote no
20:29:06 <ttx> #endvote
20:29:07 <openstack> Voted on "Creating a "supporting" project official category?" Results are
20:29:08 <openstack> yes (6): anotherjesse, bcwaldon, ttx, vishy, johnpur, danwent
20:29:09 <openstack> abstain (2): devcamcar, heckj
20:29:10 <openstack> no (1): notmyname
20:29:20 <notmyname> not because it those projects aren't important. but because I don't think it makes them important enough
20:29:52 <ttx> notmyname: as in... less important than core projects because they don't get an aassigned seat on the TC ?
20:29:53 <johnpur> notmyname: what is your alternative?
20:30:37 <vishy> I would be curious to know how many people contribute to these projects that don't also contribute to an official project
20:30:45 <vishy> my thought is that it is close to 0
20:31:05 <heckj> vishy: docs might be an example of a difference, but that's the only one that comes to mind
20:31:12 <notmyname> johnpur: for example, gating + CI + docs together as "one" project with a lead that gets a seat on the PPB/TC
20:31:38 <ttx> notmyname: why not 3 seats then ?
20:32:23 <notmyname> I don't know. why not? :-)
20:32:23 <ttx> you know my position on this.. you can't weigh a project against another, the only way to do it fairly is to have all seats elected in the same way, with proportional rep
20:32:36 <ttx> but that ship has sailed
20:32:43 <ttx> ok, looking into proposal 2
20:33:00 <ttx> which of those projects should actually be considered a supporting project
20:33:13 <ttx> the first on the list are no-brainers in my opinion
20:33:47 <ttx> Anyone objects to the "Official documentation" list of projects ?
20:33:54 <bcwaldon> ttx: you've got my approval on the rest of the proposal
20:34:56 <annegentle> to me, the official documentation list looks correct
20:35:21 <ttx> The only ones I had doubts with are pbr and git-review
20:35:37 <annegentle> sorry, I have to catch a ride back to Austin, but basically I am advocating Supporting project definition that include deployers
20:35:38 <bcwaldon> ttx: both totally necessary
20:35:43 <ttx> The rest is pretty much openstack and openstack-centric
20:36:10 <ttx> annegentle: we can discuss further additions another time anyway
20:36:11 <bcwaldon> ttx: I think putting something in openstack*/* should mean it is some sort of offical openstack project
20:36:19 <annegentle> great, thanks all
20:36:33 <ttx> annegentle: i'll discuss it with you
20:37:03 <ttx> bcwaldon: indeed, the idea would be to remove the ones that are abusively under openstack*/* and should not be considered ours
20:37:21 <ttx> then we can use review.openstack.org/openstack*/* as "the" list
20:37:33 <bcwaldon> ttx: ok, so I could see git-review moving under the stackforge banner
20:37:34 <ttx> and generate active contributors directly from gerrit
20:37:40 <bcwaldon> ttx: and pbr could really exist outside of openstack
20:37:54 <ttx> mtaylor: wanna step up and defend those ?
20:37:55 <bcwaldon> ttx: we should let mtaylor/jeblair argue those points
20:38:07 <ttx> everyone agrees on the rest of the list ?
20:38:35 <ttx> (from openstack/compute-api to openstack-dev/openstack-nose)
20:39:13 <bcwaldon> seems so
20:39:22 <mtaylor> aroo?
20:39:26 <mtaylor> reading
20:39:43 <ttx> wanna make an argument about wht pbr and git-review should be IN ?
20:39:48 <ttx> why*
20:40:01 <mtaylor> same reason as openstack-nose, honestly
20:40:13 <mtaylor> they were written for openstack and are kinda central to what we do
20:40:23 <ttx> mtaylor: openstack-nose has a smarter name :P
20:40:34 <mtaylor> the fact that they were written to be friendly and non-openstack _specific_ is beside the point
20:40:40 <bcwaldon> mtaylor: so I made the opposite decision for warlock
20:40:47 <mtaylor> however, if people want them to move, I don't think it will hurt anything
20:40:50 <bcwaldon> mtaylor: which I wrote for openstack, but it has nothing to do with the domain
20:41:50 <mtaylor> I could see git-review moving to openstack-dev rather than openstack-ci - or honestly just somewhere else
20:42:04 <mtaylor> I'm not wedded to it being in openstack-ci
20:42:07 <bcwaldon> mtaylor: is git-review specific to openstack? Isn't it more of a way to interact with a stackforge cite?
20:42:10 <bcwaldon> site*
20:42:13 <mtaylor> with a gerrit
20:42:16 <ttx> So... no objection to doc and core infra categories, still a bit of discussion around openstack-nose, pbr and git-review
20:42:19 <bcwaldon> sure, even just a gerrit
20:42:28 <mtaylor> it was originally written as a re-write of a shell script we had in our repos
20:42:32 <mtaylor> which is why it's in our system
20:42:42 <mtaylor> same with pbr - which is actually mostly just code from openstack-common
20:42:48 <mtaylor> packaged up to be easier to work with
20:43:12 <mtaylor> both have some openstack assumptions in them (pbr more-so than git-review)
20:43:19 <bcwaldon> mtaylor: right, one thing I don't want to do is to prevent other open source projects from consuming our stuff
20:43:21 <mtaylor> pbr could just as easily be called openstack-setup or something :)
20:43:26 <bcwaldon> mtaylor: and not have to care about openstack
20:43:27 <mtaylor> totally
20:43:27 <ttx> I propose we vote to add the first two categories and let the discussion continue some other day about the others.
20:43:32 <bcwaldon> ttx: sure
20:43:40 <mtaylor> yeah - we can offline pbr and git-review discussion just fine
20:43:57 * mtaylor does noth ave the passionate feelings on this topic - it's a grey area honestly
20:44:00 <johnpur> ttx: +1
20:44:02 <ttx> #startvote Add Official doc and Core Infrastructure projects lists to the "supporting" category? yes, abstain, no
20:44:03 <openstack> Begin voting on: Add Official doc and Core Infrastructure projects lists to the "supporting" category? Valid vote options are yes, abstain, no.
20:44:04 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:44:14 <ttx> I think that roughly covers 100% of contributors anyway
20:44:15 <bcwaldon> #vote yes
20:44:16 <johnpur> #vote yes
20:44:21 <ttx> #vote yes
20:44:31 <ttx> so we can use them to get the right list of people voting
20:44:42 <vishy> #vote yes
20:44:42 <ttx> in the elections next month
20:44:44 <anotherjesse> #vote yes
20:44:44 <heckj> #vote yes
20:44:57 <devcamcar> #vote yes
20:45:09 <danwent> #vote yes
20:45:16 <ttx> 30 seconds more
20:45:25 <notmyname> #vote abstain
20:45:59 <ttx> #endvote
20:46:00 <openstack> Voted on "Add Official doc and Core Infrastructure projects lists to the "supporting" category?" Results are
20:46:01 <openstack> yes (8): anotherjesse, bcwaldon, ttx, vishy, heckj, johnpur, danwent, devcamcar
20:46:02 <openstack> abstain (1): notmyname
20:46:33 <ttx> ok, I think we are done... 14 minute recess before next meeting ?
20:46:57 <bcwaldon> sure
20:46:58 <bcwaldon> thanks, ttx
20:47:09 <ttx> #endmeeting