19:01:07 <mfer> #startmeeting openstack-sdk-php
19:01:07 <openstack> Meeting started Wed Apr  9 19:01:07 2014 UTC and is due to finish in 60 minutes.  The chair is mfer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:11 <openstack> The meeting name has been set to 'openstack_sdk_php'
19:01:26 <mfer> #topic State of repo
19:01:40 <mfer> Can everyone state your names and associations if there is one.
19:01:43 <mfer> Matt Farina, HP
19:01:53 <jamie_h> Jamie Hannaford, Rackspace
19:02:15 <ycombinator> Shaunak Kashyap, Rackspace
19:02:19 <samchoi> Sam Choi, HP
19:02:54 <mfer> This meeting is to discuss the state of the repo...
19:02:56 <glenc> Glen Campbell, Rackspace
19:03:21 <jamie_h> shall we start where we left off?
19:03:47 <mfer> to restate the starting point from earlier....
19:03:50 <mfer> "We have an SDK that we contributed to stackforge and altered to be OpenStack rather than HP Cloud. We have a larder codebase than we released because we went all in on OpenStack rather than continuing to drive our own. We wanted to make the needed changes for OpenStack before we added service...."
19:03:59 <mfer> "For example, there are things like multiple api version support that needed to happen."
19:04:20 <mfer> that's copied and pasted from the earlier meeting
19:04:59 <ycombinator> also: "from a general contributor perspective, wouldn't it be easier to start from an empty repo, though?"
19:05:06 <ycombinator> that was me
19:05:20 <ycombinator> and "<jamie_h> yes. no legacy decisions, cleaner code, and it allows members to be included from the very beginning"
19:05:28 <ycombinator> and " <mfer> i'm curious to know why? many folks prefer to join into an architecture that's already there so add to it or work on needed tasks."
19:06:07 <mfer> and then we ran out of time
19:06:15 <ycombinator> yup
19:06:20 <ycombinator> so I'll put forth my take
19:06:25 <ycombinator> to kick us off
19:07:10 <samchoi> sure, would be good to clear up each individual's thoughts as it's unclear. And we can go over pros/cons of each approach as you noted.
19:07:59 <ycombinator> starting with a set of use cases -> blueprints -> reviews against a blank repo seems like the right way to approach the project
19:08:21 <ycombinator> as opposed to modifying existing code
19:09:00 <ycombinator> I'd be quite happy if parts of the existing code were "imported" into a blank project as long as a) they matched a blueprint and b) they were reviewed by all of us
19:09:27 <mfer> ycombinator fyi, i'm waiting to ask questions until you've let me know your complete thought
19:09:34 <ycombinator> yeah - almost done :)
19:10:26 <ycombinator> right now, I confess it feels like I'm having to learn an existing codebase just to have to revise parts of it
19:10:41 <ycombinator> okay, I'll step down with that for Q&A and for someone else to go
19:11:50 <jamie_h> no questions, but i agree with the import idea
19:12:02 <mfer> ycombinator starting with a blank repo you need to have a base architecture. where does that fit into your use cases -> blueprints -> reviews picture?
19:12:17 <jamie_h> mfer what do you mean by "base architecture"?
19:12:27 <jamie_h> as in directory structure?
19:12:36 <ycombinator> if my understanding of blueprints are correct, I think thats where it would happen
19:12:37 <mfer> the software architecture for the codebase. it's more than directories
19:12:47 <ycombinator> blueprints + wiki, perhaps
19:13:05 <jamie_h> there's a blueprint for the workspace (directory structure). each service's design is discussed separately
19:13:12 <ycombinator> (someone please feel free to direct me to how architecture type decisions are made in openstack)
19:13:15 <mfer> also, what we already have started with the use cases -> tickets -> review process internally. how does resetting the codebase to do that over come into account?
19:13:52 <jamie_h> because forcing people to use an existing codebase, which has not been reviewed by others, does not match the standard review process
19:13:55 <mfer> i do appologize that the current blueprints don't reflect that kind of detail
19:14:15 <ycombinator> no need mfer, we are all supposed to bear that burden
19:14:16 <edleafe> ycombinator: Generally blueprint+wiki for each proposed design, followed by discussion in email or IRC
19:14:39 <mfer> if I understand it, most openstack project were contributed projects not reviewed by others. then others came in to be part of the development process
19:14:51 <edleafe> …or discussion at a Design Summit ;-)
19:15:10 <edleafe> mfer: that was probably only true of Swift
19:15:27 <edleafe> …since that was already code in production when OpenStack was created
19:15:42 <jamie_h> i also think we need to make this decision based on the pros and cons, and arrive at a decision best for the project. not based on what other projects did in the past
19:15:43 <edleafe> Nova went through a *lot* of design reviews
19:16:05 <edleafe> jamie_h: Agreed; just letting you in on some history
19:16:19 <edleafe> that's what us old-timers are good for  ;-)
19:16:32 <jamie_h> ha
19:16:35 <mfer> edleafe so, Nova was contributed to openstack and then went though reviews? Were the reviews during incubation or at other point in time?
19:17:14 <glenc> There were a ton of reviews and a lot of revisions in 2011 when it was getting off the ground
19:17:16 <edleafe> Nova was originally the nebula project at NASA - lots of good ideas, but written for a particular use case
19:17:33 <edleafe> e.g., instances were not designed to persist
19:17:33 <mfer> was it contributed before or after the changes?
19:17:50 <edleafe> it was used more as a strawman
19:17:52 <mfer> and was it changed or rewritten from scratch?
19:18:04 <glenc> (I was on the Nova team at that time). The nebula code was pre-existing, but it wasn't nearly ready. My guess is that very little was kept; most was replaced.
19:18:04 <edleafe> mostly written from scratch
19:18:29 <edleafe> it was too hard to fit into a broader use case that the various parties needed
19:18:30 <glenc> Sort of used as a template, but much of it wouldn't scale well.
19:18:54 <mfer> edleafe if it didn't have those issues would so much of it have been rewritten?
19:19:34 <edleafe> mfer: well, that was the point. The issues existed because it was written for a single use case
19:19:44 <jamie_h> we have those issues with the current codebase too...
19:19:58 <edleafe> to make it something that could be the basis of OpenStack Nova, we largely started from scratch
19:20:00 <jamie_h> it doesn't reflect at all our plans for the transport or service layer, so it really does warrant new code
19:20:11 <mfer> not exactly, with a minimal amout of work we can change the existing codebase to not have those issues
19:20:19 <jamie_h> i disagree
19:20:36 <jamie_h> it will require more effort and time than writing fresh code
19:20:50 <jamie_h> and it will probably cause more bugs in the future than a clean slate
19:21:14 <jamie_h> plus, you'd have to completely rewrite your tests - which is a nightmare for existing projects
19:21:15 <edleafe> The general rule is that code talks. If you think something can work, code it and let everyone review it
19:21:33 <mfer> that's an interesting persepctive. it would likely be more time for you to write the code because you aren't intimately familiar with the existing codebase. i'm already quite familiar with the codebase and coding up the needed changes
19:21:50 <samchoi> jamie_h: so let's discuss the short term road map. https://wiki.openstack.org/wiki/OpenStack-SDK-PHP
19:22:03 <samchoi> Which requirement(s) would be difficult to fulfill?
19:22:11 <samchoi> With the current repo
19:22:27 <mfer> edleafe we have a plan to get where we'd planned on going with tweaks to the existing codebase to meet the wider needs. things i've discussed with others like Jesse Noller, Dean Troyer and other. we've been coding to go there
19:22:46 <mfer> i'll admit that more of the details could use documentation
19:22:59 <mfer> earlier today I volunteered to do more of that
19:23:06 <edleafe> mfer: OK, sounds good. But yeah, docs would be a huge help
19:24:18 <edleafe> If others don't think the current path will get us there, I would encourage them to likewise document a different approach
19:24:18 <samchoi> From the road map, I feel that 3, 7, and 8 are quite trivial requirements so maybe out of the other 5 there are issues you all see?
19:24:24 <mfer> in an email earlier this week I suggested two reasons to start with a fresh repo. 1) There was a technologically superior solution. Something measurable or very obvious that we'd need a clean repo to do. 2) we could get to a release faster while meeting all the requirements.
19:24:59 <jamie_h> samchoi Mainly the transport and service layer. If you'd like me to draw up a detailed analysis of what will be particularly difficult to implement, I can do so. but the general point still stands: asking 3 people to rewrite your code will take longer, and considerably more effort, than a fresh start
19:25:39 <mfer> edleafe note, this dicussion isn't around changing the architecture. it's about wiping the codebase and starting from scratch. we are updating the architecture and actively discussing changes.
19:25:41 <jamie_h> plus the existing codebase is not PSR-2 compliant, there's a reliance on singletons, etc.
19:25:51 <samchoi> thanks for clarifying
19:26:03 <edleafe> mfer: Understood
19:26:08 <ycombinator> in general, its going to take anyone not familiar with the existing codebase longer than those who are
19:26:22 <jamie_h> and inclusivity is one of our most important goals
19:26:26 <mfer> jamie_h there is a task for be PSR-2 and and tool to automate that change.... thanks to fabpot. the singleton left has a blueprint to remove which is fairly straight forward
19:26:28 <jamie_h> reduce barriers for entry, not raise them
19:26:31 <ycombinator> if we wipe clean and start with blueprints first we ensure that there is an shared understanding as we submit reviews
19:26:51 <jamie_h> mfer these are two, i agree, incidental points. but it's endemic of the wider issue
19:27:23 <ycombinator> again, I think its perfectly okay to "import" existing code so as not to lose existing work - as long as its conforms to agreed-upon blueprints which will give all of us a shared understanding of what to expect from the code
19:27:28 <mfer> jamie_h i've thought a lot about the service layer. i think it's a great idea. i've even mentally worked out how to alter the existing codebase to get things there. i was waiting to see what you'd come up with after our last chat on it.
19:28:05 <mfer> ycombinator if we start with a new codebase then no one will be familiar with the codebase
19:28:05 <jamie_h> i agree completely with what shaunak said: i'm not against any existing piece of code, we can re-import so long as everyone gets a fair say over the design
19:28:18 <jamie_h> mfer but it puts people on level footing
19:28:29 <jamie_h> and we can quickly iterate over new designs or re-import existing code
19:28:35 <jamie_h> but there needs to be a fair process
19:28:36 <mfer> and how does that help progress the project?
19:28:43 <ycombinator> mfer: what jamie_h said + we would all be agreeing to designs first, which I think is an important step
19:28:45 <mfer> the goal is to produce a PHP SDK for end users
19:28:48 <samchoi> I also don't see how that helps with progress
19:28:54 <jamie_h> it's important for the community and it will make non-HP workflow faster
19:29:10 <mfer> that's saying that it's for an HP workflow now
19:29:19 <mfer> and that the current path continues that trend
19:29:33 <jamie_h> all i'm saying is that you're familiar with the codebase and we're not
19:30:00 <mfer> lots of codebases start that way. i've been doing open source a long time. when i approach an existing codebase i always have stuff to learn
19:30:16 <mfer> i'm not sure how that helps move this along at a good pace
19:30:20 <edleafe> mfer: True, but OpenStack is a different beast
19:30:24 <jamie_h> but this is not any other codebase. this is our chance to make a great openstack project
19:30:40 <mfer> i agree
19:30:53 <jamie_h> mfer i guarantee you that with a fresh codebase, i'll be committing every single day and we'll gain rapid pace
19:31:01 <edleafe> I've had to scrap a bunch of working existing code in order to get a community around the Python SDK
19:31:27 <mfer> edleafe i understand that. i've been spending a lot of time trying to understand the way the community operates
19:31:31 <mfer> and how to work well in it
19:32:16 <edleafe> mfer: yeah, it's not easy. I just want to say "HERE THIS STUFF WORKS! USE IT!", but that wouldn't help in the long run
19:32:37 <jamie_h> i really wouldn't suggest a fresh repo if i didn't think it had a lot of positive advantages (for workflow + community engagement)
19:33:02 <mfer> it's more like, here's the stuff, it works well, we have a path to make some changes, and we're actively working to get it out to people
19:33:21 <mfer> jamie_h break that down. how does starting new help the workflow?
19:33:41 <mfer> put aside the community engagement for a moment
19:34:23 <glenc> I think there's a frustration that people aren't able to contribute significantly because they essentially have a learn a new codebase, and one that does not match the target.
19:34:30 <jamie_h> it speedens up the workflow for every single developer who isn't intimate with the codebase. which, right now, is everybody except HP
19:34:56 <samchoi> The story behind the initial code that's in stackforge right now is that mfer and another senior engineer created the initial php sdk. I was brought on board in 2012 to add additional services. It took me 2-3 days to understand the code base without much PHP experience at the time. So I don't think what's in stackforge at the moment is too complex for most.
19:35:04 <edleafe> mfer: I'm approaching it like a new product, but since I've written an SDK before, I know how to avoid lots of the dead ends, and where there be dragons.
19:35:06 <mfer> a fresh codebase would run the problem of everyone having to learn all of it while we discuss the foundation for it.
19:35:23 <jamie_h> we're not learning anything with a new codebase. we're creating it.
19:35:32 <jamie_h> creating it with an approved process of review
19:35:41 <mfer> we're all laerning what's being created by others
19:35:57 <jamie_h> but that's the nature of a collaborative project
19:36:32 <jamie_h> right now, there's an entire codebase which has not been scrutinised by the openstack community. all i'm saying is that it needs to be.
19:36:50 <ycombinator> this is a community issue: we would feel much more comfortable starting on level ground with everyone else on the project
19:37:06 <ycombinator> and right now, thats not the case
19:37:15 <mfer> i've worked on many collaborative projects. i think the difference here is we asked folks to come collaborate with us on where we are going and actively contributing to. the suggestion is to burn down the village so that everyone can work together to architect and build it.
19:37:34 <jamie_h> that's your personal choice of metaphor
19:38:17 <jamie_h> openstack is about full transparency and equality. having a new codebase does that: it opens everything up for review and puts people on a level footing
19:38:30 <jamie_h> this is a new, community-driven project: not the continuation of a private codebase.
19:38:55 <mfer> i'll go back to something edleafe said. he noted that code talks. there have been some good ideas for you fine folks. we've gone and coded them.
19:39:17 <mfer> and in understand. you don't want to get involved if it's not coded from scratch
19:39:43 <jamie_h> this is not an argument of principle, there are strong arguments at stake here
19:39:45 <mfer> i've not seen how this applies to technical problem in teh codebase that cant' be easily overcome
19:40:17 <mfer> it seems it's a matter of start clean or you're not going to get started
19:40:34 <mfer> which is quite different from the nova disucssion/example earlier
19:40:46 <jamie_h> the technical reason is that a fresh slate offer significantly more freedom to implement agreed-upon designs
19:41:02 <jamie_h> you're not constrained by legacy (unapproved) decisions
19:41:22 <ycombinator> its a matter of making everyone feel equally involved from the start
19:41:24 <glenc> I see the issues are more political than technical. As you said, we can all eventually learn an existing codebase. In the past, companies like Rackspace have gotten trashed for "contributing" a bunch of existing code without involving the community; this is why Solum and the python SDK started off clean, even though we had existing code.
19:42:08 <ycombinator> right now, by virtue of there being a pre-existing, not-approved-by-all codebase, we are not all equally involved from the start
19:42:45 <glenc> I suppose we could always go through the existing codebase and submit changes for stuff that doesn't match the desired end state, even to the extent of removing it. That would go through the approval process. Still seems inefficient, but it could work.
19:43:10 <jamie_h> i don't mind using any of the existing codebase so long as it goes through gerrit first
19:43:16 <jamie_h> and we all have a say
19:43:19 <ycombinator> right, that's my "import" suggestion
19:43:22 <jamie_h> yeah
19:43:31 <mfer> for me this isn't political but pragmatic. openstack needs some solid SDKs and we're actively working to produce a PHP one. if there is a more technically sound way to do that or a way to get it out there quicker I'm happy so look at that. This is pragmantic to meet the needs of the end users
19:44:58 <samchoi> ycombinator: jamie_h so that main argument is that you both need to be equally involved from the start, right? After a few weeks, we would have a codebase similar in size to what's in stackforge right now since it's fairly small. Newer contributors may also come along, but it wouldn't be prudent for them to ask us to scrap the codebase without pragmatic reasons.
19:45:23 <ycombinator> samchoi: the difference is that by then we'll have a set of blueprints to go with the codebase
19:45:26 <jamie_h> it's primarily a political and community issue, which can't really be trumped by the premise that going down the "existing codebase" avenue will save us a few hours
19:45:27 <ycombinator> right now we don't have that
19:45:39 <mfer> ycombinator we already have a set of blueprints to go with the codebase
19:46:36 <samchoi> jamie_h: considering where the python sdk is at today, probably more than a few hours ;)
19:46:51 <jamie_h> samchoi: this is a bigger issue than me and shaunak. it's symbol of a wider need for equality and inclusivity
19:47:39 <mfer> everyone is equally invited to get involved.
19:47:45 <mfer> this is different from that
19:47:50 <jamie_h> not when half of the code has not been reviewed by others
19:48:01 <jamie_h> sorry, all of the code
19:48:22 <mfer> others have not taken the time to review the code. they are welcome to come in, file bugs, use it, etc.
19:48:44 <jamie_h> because the basic premise is flawed: there is extant code in the repo which has not been officially reviewed
19:48:56 <mfer> why does the openstack infra team have an explicit way to import code for a new project if that's not something that should be done?
19:49:40 <mfer> you point the tool at the existing repo and it pulls it in
19:50:28 <mfer> since this is being described as a community process issue, I need to do follow-up from outside this group.
19:50:59 <mfer> if it's not been articulated enough please feel free to add more details
19:51:15 <edleafe> mfer: Good idea. Talk to Jesse and Dean about the discussions on these lines we've had on the Python SDK side
19:52:07 <jamie_h> so, from my perspective, the follow up strategy needs to be: wipe the codebase and mass import the existing features we want
19:52:15 <jamie_h> which will go through gerrit and be merged back in the library
19:52:18 <ycombinator> I'll summarize my thoughts one more time for external follow up
19:53:08 <ycombinator> we have an opportunity to start with designing in the open (using blueprints) and submitting reviews against these blueprints (which could be imports of existing code) to let all contributors have an equal say from the start
19:55:38 <jamie_h> so mfer and samchoi, where do you stand? are you up for having a try at what shaunak suggested?
19:56:45 <mfer> my stance is i need to do some external follow-up before i have any further stance
19:57:00 <ycombinator> I think that's fair mfer
19:57:18 <mfer> is there anything else?
19:57:22 <ycombinator> could you include us on those follow up conversations as well, please?
19:57:28 <samchoi> that's fine, will need follow up in any case
19:57:54 <jamie_h> mfer also, what exactly are you following up?
19:58:04 <jamie_h> the process of importing?
19:58:06 <mfer> ycombinator where appropriate i will. some of this is personal mentors and direction in the community type stuff
19:58:17 <ycombinator> mfer: understood
19:58:18 <ycombinator> thanks
19:58:32 <mfer> if not before, next week we'll continue this at the normal meeting time. for meeting things that is
19:58:49 <mfer> emails and side discussions may happen in between.
19:58:53 <mfer> sound good?
19:58:54 <jamie_h> i had a question above
19:59:08 <mfer> you mean on what i'm following up on?
19:59:16 <jamie_h> yeah, i wasn't 100% sure, sorry
19:59:30 <mfer> to understand community processes, history, decision making, project context, etc
19:59:51 <mfer> lots of background on the community angle to this discussion
20:00:39 <jamie_h> sure, okay. perhaps we could reach out to folks in the openstack community too
20:00:53 <jamie_h> so next wednesday is good for everyone?
20:00:55 <samchoi> Btw, jamie_h ycombinator what are you primary considerations for choosing one approach over another? I can be convinced either way but want to see what everyone's thought process is and their rationale
20:01:03 <mfer> that's one of the things i'm going to do and have been doing since i released this codebase to the community
20:01:31 <jamie_h> awesome, it's definitely an important step before we release any more code
20:01:47 <ycombinator> jamie_h I think the wednesday 1530 UTC meeting in openstack-meeting-3 is set for good now
20:02:12 <samchoi> I think one of the issues is that each individual's criteria for choosing a starting approach is quite different
20:02:17 <jamie_h> samchoi: i can follow up over e-mail if you'd like. is that okay with you?
20:02:27 <samchoi> oh certainly, I forgot it's quite late for you
20:02:30 <samchoi> my apologies jamie_h
20:02:31 <jamie_h> :)
20:04:18 <mfer> the hour is up. i'm not sure if aother meeting is coming in here.
20:04:28 <mfer> don't want to step on anyone elses toes atain
20:04:33 <mfer> s/atain/again
20:04:48 <mfer> if there's nothing else I'll end the meeting to respect everyones time
20:05:06 <jamie_h> sure, i have nothing else
20:05:14 <glenc> ok
20:05:39 <mfer> #endmeeting