20:06:43 <jbryce> #startmeeting
20:06:44 <openstack> Meeting started Tue Jun 28 20:06:43 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:06:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:06:51 <jbryce> http://wiki.openstack.org/Governance/PPB - agenda at the bottom
20:07:21 <jmckenty_> jbryce: can I suggest structured discussion on the project autonomy question?
20:07:34 <jbryce> jmckenty_: sure
20:07:36 <jmckenty_> e.g., one person to present for, one to present against, and then discussion?
20:08:05 <jbryce> any volunteers for either side?
20:08:12 <jmckenty_> Maybe using #info for relevant factoids
20:08:18 <jmckenty_> I'll present against autonomy
20:08:25 <jmckenty_> if no one else grabs it
20:08:26 <notmyname> I'll volunteer for autonomy
20:08:30 <ttx> jmckenty: I can help you with that.
20:08:33 <notmyname> heh
20:08:38 <jbryce> one thing to keep in mind to is that autonomy is kind of a gradient as well....
20:08:44 <jbryce> there are levels of autonomy
20:08:46 <notmyname> of course
20:08:48 <jmckenty_> true enough, I think if we argue the extremes,
20:08:50 <jbryce> but we can start with a flat for and against
20:08:52 <ttx> yes, not sure it's a binary decision
20:08:59 <jmckenty_> we'll end up identifying an ideal mid-position
20:09:07 <jbryce> notmyname: want to get it started since it was your topic?
20:09:09 <ttx> (in fact, I'm wearing grey today)
20:09:14 <jbryce> #topic Project autonomy
20:09:14 <notmyname> sure
20:09:19 <notmyname> my thoughts, so as not to spam the channel: https://gist.github.com/1052036 (click the "raw" link to get nicely wrapped lines)
20:09:24 <notmyname> it's short
20:09:52 <jbryce> https://gist.github.com/1052036 - notmyname's summary of his position on project autonomy
20:09:54 <ttx> "raw" doesn't work for me :)
20:10:10 <notmyname> we've made several decisions already that have tended towards autonomy. I'd like to continue that and allow each project to choose their own tools for their own work
20:10:24 <notmyname> ttx: https://raw.github.com/gist/1052036/33a6df89a37e6d29210806f61365c097a4b2e64b/gistfile1.txt
20:10:49 <ttx> notmyname: firefox displays that in very long lines. But I can handle it.
20:10:59 <jmckenty_> So it seems like there are some buckets of "autonomy":
20:10:59 <jmckenty_> - Language
20:10:59 <jmckenty_> - Tools
20:11:00 <jmckenty_> - Release Cycle
20:11:00 <jmckenty_> - Philosophy
20:11:00 <jmckenty_> - Governance / Mgmt
20:11:06 <jmckenty_> Did I miss anything substantive?
20:11:11 <notmyname> I see the project management (openstack packaging/release) as a separate project and should choose their tools too
20:11:28 <notmyname> jmckenty_: Philosophy kinda answers most of the others
20:11:50 <jmckenty_> Not really - I'm using philosophy to mean "Project goals", e.g. scale and strong opinions
20:12:03 <jmckenty_> aka who OpenStack will be useful for
20:12:16 <jmckenty_> useful == designed for == ideal for
20:13:04 <jmckenty_> There are actually a LOT of unique descriptions of openstack floating around now
20:13:19 <jmckenty_> the launchpad.net one, the openstack.org one, the original novacc.org one
20:13:36 <jmckenty_> Plus various things that have been said in the press (The operating system of the cloud, etc)
20:13:52 <jmckenty_> Launchpad says "simple to implement "
20:14:01 <ttx> Note that our best project autonomy definition so far is what we agreed at: http://wiki.openstack.org/ProjectTypes
20:14:51 <jmckenty_> I agree with "so far",
20:15:07 <jmckenty_> since we dodged the question of language, of philosophy, and of tools
20:15:27 <jmckenty_> My strong (opinionated) position is this:
20:15:44 <jmckenty_> Rackspace and NASA partnered on OpenStack originally, in large part, because we both had written in python
20:16:03 <jmckenty_> A lot of the community engagement around OpenStack as a *unified* set of projects has been because of the language consistency
20:16:36 <jmckenty_> Community portability (e.g., the ability for developers to move easily from nova to swift to glance, etc) will rest on common coding standards, including language
20:16:51 <jmckenty_> And I think making that STRONGER rather than weaker will only help
20:17:11 <jmckenty_> We've already agreed on unified governance (according to the project types doc)
20:17:23 <jmckenty_> we *seem* to be converging on unified philosophy
20:17:32 <jmckenty_> we've agreed on unified release cycles and packaging
20:17:38 <notmyname> *
20:18:03 <jmckenty_> If we agree on unified language, I'm happy to allow projects to have tool autonomyu
20:18:12 <jmckenty_> provided we can agree on QUALITY gates
20:18:29 <jmckenty_> e.g., everyone needs CI, everyone needs revision control, everyone needs review automation
20:18:43 <jmckenty_> everyone needs measurement of unit test coverage
20:18:58 <ttx> i don't really see the point of having autonomous projects calling themselves OpenStack, I guess. "OpenStack" must mean something, and that something is what we have in common.
20:19:28 <ttx> not just "being included in the release announcement"
20:19:30 <jmckenty_> Right, we're just clarifying what the common ground is
20:20:01 <jmckenty_> I have a selfish reason, of course
20:20:04 <ttx> I think it's one thing to diverge on code hosting... but for example differing on issue tracking (a user-facing tool) makes OpenStack look like a weird patchwork of separate pieces.
20:20:15 <jbryce> on things like tools, i think it's important to consider the total audience of a specific tool
20:20:19 <jmckenty_> I'm trying to make nova, swift and glance work together in much closer ways
20:20:33 <jmckenty_> and having those three projects in different RCS makes it hard for me
20:20:41 <notmyname> issue tracking is central to a dev workflow and should be chosen by those who use it (ie the devs for the project)
20:21:06 <jbryce> something like the revision control system has a relatively small audience of the developers who are submitting code compared to issue-tracking/blueprints/release tracking which has developers, users, external tool builders
20:21:13 <jbryce> issue tracking is not just a dev tool
20:21:13 <notmyname> I agree with jmckenty_ about the quality gates, as long as they are descriptive guidelines rather than prescriptive requirements for projects
20:21:20 <jbryce> it's used by many more people than just devs
20:21:35 <ttx> jbryce: +1
20:21:48 <dendrobates> I would say that issue tracking is a qa tool used by multiple groups
20:22:09 <johnpur> my view is that the dev community can drive the tools decision, but we need a *common* solution across openstack projects
20:22:13 <notmyname> we only currently have unified release cycles and packaging in the sense of the 6-month releases
20:22:16 <ewanmellor> notmyname: Sorry, I disagree.  That's true as long as you're never expecting bugs that lie across components, but I fully expect bugs that need to move between Swift or Glance, or Nova and Quantum, or whatever.
20:22:25 <jbryce> there are a lot of people who enter and consume information from the bug reports and blueprints who are not submitting code
20:22:35 <jbryce> i'd rather that all be centralized in one place that we can point everyone too
20:22:40 <ttx> ewanmellor: and accidentally, that's where Launchpad bugs really shine.
20:23:04 <jmckenty_> ttx: let's avoid specific recommendations for the moment, if possible
20:23:07 <jbryce> they want to know what's going on in "openstack" not have to track down the information from an arbitrary number of authoritative sources
20:23:32 <ttx> jmckenty: sure -- was just pointing out what we already had.
20:23:42 <jmckenty_> jbryce: I think this is true, but also a major problem on the documentation and forums side as well
20:23:58 <creiht> https://wiki.ubuntu.com/Bugs/Watches#Watching%20Another%20Project
20:24:39 <jmckenty_> notmyname: are you all right with all of us using the same system if it's github?
20:24:53 <jmckenty_> b/c that's certainly the ideal for me
20:25:00 <notmyname> jmckenty_: I think it raises the bar to entry for new projects
20:25:10 <jmckenty_> nova was born on github, and I think it would be great to go back there
20:25:27 <notmyname> I prefer github for my own project(s) but I think those who actually contribute to the projects shouldbe the ones to make that choice
20:25:27 <jbryce> jmckenty_: what happened to avoiding specific recommendations for now?
20:25:34 <jmckenty_> :p
20:25:40 <jmckenty_> ttx threw a gaunlet
20:25:53 <ttx> jmckenty: we are drifting away from "autonomy" into the next topic :)
20:26:18 <jmckenty_> no, I think notmyname brought up autonomy originally only in the context of the github move, if I'm not mistaken
20:26:34 <notmyname> yes, but it affects much more than code hosting or issues
20:26:41 <jmckenty_> can we agree that there's no sense in projects having autonomous philosophy or language?
20:27:03 <jmckenty_> e.g., if a project wants to be part of openstack, it needs to be cloud, and it needs to be simple to implement and massively scalable
20:27:08 <jmckenty_> and it needs to be in python
20:27:16 <ttx> jmckenty: is "philosophy" what is described in http://wiki.openstack.org/ProjectTypes ?
20:27:16 <notmyname> except for the last part, I like that
20:27:18 <jbryce> i can agree on philosophy. i think that is the foundation that binds openstack together.
20:27:38 <dendrobates> notmyname: which last part?
20:27:38 <jmckenty_> great. So what we're talking about is autonomy of TOOLS
20:27:44 <notmyname> dendrobates: python
20:27:57 <jbryce> but how long is openstack going to last and grow? i hope for years maybe decades....i don't want to commit to 1 language forever
20:28:04 <ttx> jmckenty: Openness, Transparency, Commonality, Integration, Respect of release deadlines, Facilitation of downstream distribution ?
20:28:11 <notmyname> jmckenty_: to be part of openstack, a project should subscribe to the openstack philosophy
20:28:12 <ttx> or a subset thereof ?
20:28:27 <jmckenty_> ttx: I think the last is dangerous
20:28:38 <jmckenty_> e.g., WHICH downstream?
20:28:46 <jmckenty_> or how MANY downstreams
20:29:03 <jmckenty_> jbryce: why not?
20:29:27 <ttx> jmckenty: read that as "when contacted, the project devs should make their best to help downstream distributors" ?
20:29:50 <jmckenty_> fair enough, though
20:29:56 <jmckenty_> ttx: fair enough
20:30:05 <jmckenty_> dendrobates: do you have a position on language?
20:30:05 <ttx> i.e. if slackware comes knocking at our door, we should try to help them as much as we reasonably can.
20:30:09 <notmyname> is openstack a single thing with subsystems or a collection of independent projects that work together for some level of integration and releases? I think the second
20:30:21 <jmckenty_> ttx: so you're saying linux distros are the only downstreams?
20:30:22 <ttx> I think the first.
20:30:32 <dendrobates> jmckenty: I think python is good enough for almost all situations
20:30:33 <jmckenty_> What if someone wants to put openstack on an ASIC?
20:30:35 <ttx> jmckenty: no, that was just an example :)
20:30:50 <ttx> jmckenty: Puppet/Chef could also be considered downstreams.
20:30:54 <jmckenty_> notmyname and ttx: I think the first as well
20:31:16 <jbryce> i think somewhere in the middle. it's a collection of projects that can be used independently, but that will benefit from commonality.
20:31:29 <jbryce> i'm wearing my grey shirt today, too. = )
20:31:37 <ttx> jbryce: but that make sense as a whole, right ?
20:31:48 <jmckenty_> can we each think of a comparable package?
20:32:01 <jmckenty_> e.g., ubuntu would be the second, right?
20:32:09 <notmyname> I see the packaging of openstack as another openstack project (meta project?). so I think that they should be able to choose tools they want. and the other projects should do what's possible to integrate (bug watches, code mirroring, etc)
20:32:44 <jmckenty_> notmyname: My goal is to have it much more tightly integrated
20:32:55 <jmckenty_> I think it's the primary differentiator of OpenStack from other attempts
20:33:21 <vishy> notmyname: we could just fork all three projects and put them into a new project called openstack
20:33:25 <dendrobates> jmckenty: +1
20:33:37 <jmckenty_> vishy: I don't think you're allowed to use the spoon word
20:33:42 <vishy> notmyname: but i think the idea is collaboration
20:34:07 <jmckenty_> notmyname: is there a project that you think of as a comparable?
20:34:08 <notmyname> vishy: I think collaboration is they key
20:34:49 <notmyname> jmckenty_: I don't like trying to relate to other projects (it's like X except for Y) because we all have different perspectives on what X actually is. let's say what we want, not what we want it to be like
20:34:49 <jbryce> when people want to get involved, it's much easier if there's more commonality rather than having to track their way around 10 projects that are using 100 combinations of revision control, issue tracking, roadmap tracking, release management. it's about much more than just the wishes of the few developers we have today.
20:34:56 <ttx> jmckenty: I'd say something like "Linux kernel subsystems with slightly more independence for subsystem maintainers"
20:35:12 <jmckenty_> I just find it easier to understand people's perspectives with an example
20:35:22 <ttx> jmckenty: but as notmyname says, the metaphor is always bad
20:35:42 <gholt> If you have one set of "rules" you may have a lot fewer than 10 projects. ;)
20:35:46 <heckj> or too subjective to be ultimately useful
20:36:47 <jmckenty_> dendrobates et al: the thinking on a single language, aside from the cross-community aspects I mentioned earlier, it also keeps system dependencies down (and attendant security issues), coding conventions stronger, etc.
20:37:08 <ttx> So we have two options, #1 is "openstack is a single product made aof a lot of independent, but cooperating, components" and #2 is "a collection of independent projects that work together for some level of integration and releases"
20:37:20 <jmckenty_> But I agree we have the potential need for C / Erlang / etc. for very low-level performance concerns, which is why we dodged this before
20:37:25 <dendrobates> jmckenty: I agree.  That was one of the original reasons
20:37:28 <jbryce> gholt: raw quantity of projects is not a specific goal of mine...with that said, i would propose something similar to what we already agreed on for revision control
20:37:48 <ttx> we saw with the Burrow/erlang discussion that there is a lot of value in keeping the dev community around a single language
20:37:52 <jbryce> in the different categories of tools we have options that projects can choose from that tie in well with the processes and overall systems to manage releases and information
20:38:27 <jbryce> e.g. revision control can be bzr or git, issues can be launchpad or something that ties into launchpad mirroring (with the onus of making the mirroring work on the project team that wants to use the other tool), etc
20:38:30 <eday> ttx: that switch back was more for lack of performance gains :)
20:38:32 <creiht> ttx: How many people are actively developing on burrow?
20:38:47 <eday> creiht: just me so far! and one patch form some other guy
20:38:57 <ttx> creiht: I actually plan to help ;)
20:39:06 * eday is getting lonely
20:39:31 <ttx> There is always somethign else to do though -- my point is that if I had to learn Erlang that remote possibility would even be less likely
20:39:34 <eday> so, we started some of this discussions after the last summit, http://etherpad.openstack.org/PQ7dy5in2B, if we want to add autonomy specifics there
20:39:42 <creiht> ttx: big community there ;)
20:39:51 <jmckenty_> jbryce: did I miss some previous decision on git issues v2.0, or has it not come up yet?
20:39:53 <gholt> So, say Swift was it's own non-OpenStack project, but considered needed by OpenStack as a whole. How would it be incorporated?
20:39:54 <eday> at the time I though we had decided more integrated/less autonomous
20:40:18 <jmckenty_> eday: this ended up being http://wiki.openstack.org/ProjectTypes right?
20:40:21 <jmckenty_> which we ratified
20:40:23 <ttx> jmckenty: at ODS we said we'd consider issue tracking once/when/if code hosting is migrated
20:40:26 <notmyname> I don't subscribe to the idea of developer portability. in practice, having devs that move between projects is exceedingly rare and there will always be learning curves, even if tooling is identical
20:40:34 <eday> (not saying I necessarily agree, just stating what was previously "decided")
20:40:44 <ttx> notmyname: Glance being an exception rater than the rule ?
20:40:51 <jmckenty_> ttx: that's how I remembered it
20:41:04 <creiht> I'll offer the opinion that if you make too strict of rules, you may miss out from contributions from the broader community as a whole, including projects
20:41:09 <ttx> jmckenty: so in Boston in October.
20:41:13 <jmckenty_> notmyname: I respectfully disagree.
20:41:30 <jmckenty_> notmyname: maybe on a day-by-day basis, but I've seen a TON of long-term migration between projects
20:41:35 <eday> jmckenty_: ahh, yes. so it did
20:41:49 <jmckenty_> creiht: if that's a trade-off for a quality bar, I'm okay with it
20:42:08 <creiht> the problem is, programming language != quality
20:42:21 <gholt> It's more a trade off for "not how I want it" bar. :)
20:42:23 <creiht> we are all for high quality projects
20:42:44 <jmckenty_> sure, but <n> X language ~= low quality, in general
20:42:45 <dendrobates> creiht: no but familiarity with the language helps spot quality problems
20:42:56 <jmckenty_> you end up with a shallow review group
20:43:11 <jmckenty_> a shallower set of tools
20:43:12 <ttx> jbryce: vote/decision/action ? 15min left.
20:43:14 <creiht> and most programming languages have the tools that help meet high quality standards, including the standards you summarized at the beginning
20:43:27 <creiht> dendrobates: that is quite the strawman
20:43:38 <jmckenty_> creiht: can you name a multi-language project that has high quality?
20:43:51 <creiht> I'm not talking about a multi-language project
20:43:56 <creiht> gets back to philosophy
20:43:56 <jmckenty_> and if you say Eucalyptus, I'm going to vote to have you ejected from the PPB :P
20:44:04 <dendrobates> creiht: just poorly typed.  see jmckenty's comment instead
20:44:11 <notmyname> jmckenty_: if openstack recommends something, like python or bzr or launchpad, but allows projects to choose, that's fine. it's up to the projects to do the extra work required to integrate well
20:44:13 <creiht> I've already been ejected from the PPB :{
20:44:14 <creiht> :P
20:44:25 <notmyname> jmckenty_: re: CI and code quality sutff
20:44:41 <jmckenty_> right, that was the context that I brought it up in - 1 project, 1 language, a reasonably *minimal* set of tools
20:44:53 <creiht> I would argue that most projects are going to have a core team that focus on that specific project
20:45:00 <ttx> Did we lose our chair ?
20:45:04 <jmckenty_> which can include multiple choices when necessary for dev workflow
20:45:06 <creiht> jmckenty_: how much cross-polination is there between nova and swift now?
20:45:06 <jbryce> ttx: no
20:45:09 <ttx> ah!
20:45:11 <creiht> almost none
20:45:20 <jmckenty_> creiht: I don't want to be a dick, but if you're not on the PPB, you're kind of out of turn
20:45:31 <creiht> I believe this is an open meeting
20:45:53 <gholt> Oh, is this only for representatives?
20:45:54 <jmckenty_> ah, my bad.
20:45:59 <creiht> but you don't have to listen to me, just offering my opinion
20:46:01 <jbryce> jmckenty_: we've allowed external input in other meetings
20:46:09 <creiht> indeed
20:46:10 <jbryce> i'm not sure where the vote would be on this
20:46:18 <jmckenty_> k, I have a hard time keeping track of the ppb members
20:46:20 <jbryce> we have different definitions of autonomy
20:46:36 <jbryce> jmckenty_: http://wiki.openstack.org/Governance/PPB - all listed there
20:46:37 <notmyname> I'm not sure that we even have soemthing that can be voted on
20:46:41 <jbryce> right
20:46:44 <creiht> jmckenty_: They are listed on a wiki page somewhere :)
20:46:46 <heckj> swift and nova never cross polinated much, but glance is a bit different in that respect
20:46:50 <ttx> jbryce: #1 is "openstack is a single product made aof a lot of independent, but cooperating, components" and #2 is "a collection of independent projects that work together for some level of integration and releases" ?
20:47:03 <creiht> glance is also a very simple project
20:47:07 <creiht> imho
20:47:11 <jmckenty_> heckj: I'm working on some crazy swift things right now,
20:47:14 <jmckenty_> and I'm a nova dev
20:47:18 <creiht> not at the same level as nova or swift
20:47:20 <heckj> creight: no argument there
20:47:24 <jmckenty_> ditto for 0x44
20:47:36 <gholt> jmckenty_: Really? Care to share with the Swift guys? :)
20:47:39 <creiht> jmckenty_: it would be nice if that was done in the open ;)
20:47:42 <ttx> jbryce: I think the question of "single product" vs. "collection of independent projects" is the central one
20:47:51 <jbryce> ok
20:47:52 <jmckenty_> creiht: it's on github
20:47:55 <jmckenty_> ;)
20:47:56 <creiht> you know since we are supposed to  be a community and all
20:47:56 <gholt> hahahahhaha
20:48:06 <jbryce> can we pause the discussion for a minute
20:48:08 <heckj> I would posit that you'd get more benefit longer term from more cross pollination, so encouraging that is useful/beneficial to the project
20:48:12 <jmckenty_> sure
20:48:24 <jmckenty_> jbryce: sure
20:48:42 <jbryce> let's take a vote on the options ttx laid out in terms of a general philosophy on autonomy
20:49:01 <jmckenty_> +1 for #1
20:49:07 <ttx> +1 for #1
20:49:11 <jbryce> #topic VOTE: #1 is "member:openstack is a single product made aof a lot of independent, but cooperating, components" and #2 is "a collection of independent projects that work together for some level of integration and releases"
20:49:16 <jbryce> +1 for #1
20:49:22 <jmckenty_> +1 for #1
20:49:35 <johnpur> +1 for #1
20:49:35 <notmyname> +1 for #2
20:49:37 <ttx> +1 for #1 (for the record)
20:49:53 <jmckenty_> dendrobates: ?
20:49:56 <eday> +1 for #2
20:49:59 <jmckenty_> ewanmellor: ?
20:50:09 <dendrobates> +1 for 1
20:50:16 <jmckenty_> vishy: ?
20:50:16 <ewanmellor> +1 for #1
20:50:37 * vishy is thinking
20:50:46 * jmckenty_ smacks vishy in his thinking-hole
20:50:59 <vishy> I don't like forcing people to collaborate via policy
20:51:11 <vishy> because it leads to ill-will
20:51:28 <jmckenty_> the doukhobors did it
20:51:36 <ttx> vishy: it's not about forcing... it's about openstack being a single product or a collection of indep projects.
20:51:41 <vishy> it is though
20:51:45 <jmckenty_> they designed their villages to force people to run into each other on a daily basis
20:51:54 <vishy> we're forcing detractors to take on our model of how things should work
20:51:55 <jmckenty_> it kept conflict from festering
20:52:09 <jbryce> the policies can be flexible and include multiple viable options
20:52:10 <vishy> I would prefer if we convince them to change their view
20:52:31 <jmckenty_> vishy: the irony to me is that we moved nova to launchpad so that swift and nova would be on a common platform
20:52:31 <vishy> my personal view is #1 is more valuable
20:52:44 <jbryce> but the tools need to roll into an integrated view and experience for all the audiences
20:52:57 <heckj> jbryce: +1
20:52:58 <vishy> so +1 for #1
20:53:06 <notmyname> jmckenty_: we were both on git to start with! neither one of us wanted LP
20:53:18 <vishy> anotherjesse says +1 for #1
20:53:27 <jmckenty_> There's some crazy crack-rock there that we should sort out at some point
20:53:31 <jmckenty_> anyway
20:53:33 <jbryce> #info philosophy is "openstack is a single product made aof a lot of independent, but cooperating, components" - vote 7-2
20:53:40 <vishy> I'll make a caveat that I don't think we should be heavy-handed on our plicies
20:53:45 <jbryce> vishy: +1
20:53:47 <vishy> * policies
20:53:51 <dendrobates> vishy: I appreciate your concerns.  We do not want to be too pedantic
20:54:02 <jmckenty_> jbryce: shall we vote on supporting multiple sets of tools (minimal sets) with equivalent function and strong integration?
20:54:06 <jmckenty_> or is that a given?
20:54:18 <jbryce> well, that's item 3 on the agenda
20:54:23 <jmckenty_> ah, right
20:54:24 <jbryce> #topic Possibility for core projects to choose their own code hosting (free choice, no choice, or set of options vetted by PPB ?)
20:54:28 <jmckenty_> and we still have 6 minutes left
20:54:30 <jbryce> we've got 5 minutes
20:54:38 <jmckenty_> +1 for set of vetted options
20:54:38 <ttx> ok, I can explain the options
20:54:41 <notmyname> jmckenty_: one project implies single code hosting and single toolset?
20:54:54 <jmckenty_> no, I think it implies that as an ideal
20:54:59 <jbryce> i'm for a vetted set of options
20:55:02 <jmckenty_> but I think dev productivity trumps that
20:55:25 <jmckenty_> I would make it a target to have everything in single hosting and toolset by the end of next year,
20:55:37 <jmckenty_> since it may involve writing the damn hosting platform to not suck
20:55:41 <ttx> basically "free choice" means the project choose and the integration tools must catch up, "no choice" is a bit out of fashion nowadays... and "set of options" allow to check for integration feasibility
20:55:53 <ttx> ...beforehand.
20:56:04 <ttx> I obviously vote for "vetted set of options"
20:56:20 <dendrobates> I like a vetted set of options
20:56:28 <ttx> since neither of the extreme positions sound like a good idea to me
20:56:44 <jbryce> let's do an actual vote on it before we run out of time
20:57:05 <jmckenty_> #topic VOTE on integration tools
20:57:10 <jmckenty_> +1 for vetted set
20:57:18 <ttx> +1 for vetted set
20:57:34 <jbryce> +1 for vetted set
20:57:48 <vishy> +1
20:58:01 <dendrobates> +1 vetted set
20:58:02 <eday> +1 for no choice - if we're going to be a "single project", lets not fragment. (we can still change the set, but keep it consistent)
20:58:24 <ttx> (so, currently LP is the only option, but github should soon be an option, if mtaylor and termie work on it this week :)
20:58:25 <jbryce> vishy: +1 for which?
20:58:55 <mtaylor> ttx: I'm not sure we're going to be doing much work this week - but it's coming real soon now
20:59:02 <jmckenty_> ttx: I'd suggest that PPB / jbryce should make that more important than anything else they're doing
20:59:07 <vishy> vetted
20:59:29 <jbryce> so 5 for vetted, 1 for no choice
20:59:34 <jmckenty_> notmyname: ?
20:59:36 <ewanmellor> +1 for no choice -- I don't want to have to train my devs on git and bzr
20:59:56 <ttx> ewanmellor: note that we can actually turn "vetted" into "no choice" when we consider adding github to the set.
20:59:57 <notmyname> +1 for no choice to be consistent with the previous vote (but I disagree with that ;-) )
21:00:11 <jbryce> ok...we're out of time
21:00:28 <creiht> well that was convenient
21:00:30 * jaypipes is a sad puppy for missing this...
21:00:31 <jbryce> #info vetted set wins with 5 votes, no choice received 3 votes
21:00:37 <dendrobates> I change my vote to no choice. I agree with Ewan
21:01:07 <jbryce> that ties it up. we can discuss further next meeting. we've got to hand the room over for the larger team
21:01:19 <jbryce> #info no final result
21:01:23 <jmckenty_> I'll change to no choice if it's github
21:01:23 <jbryce> #endmeeting