19:01:07 #startmeeting openstack-sdk-php 19:01:07 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:11 The meeting name has been set to 'openstack_sdk_php' 19:01:26 #topic State of repo 19:01:40 Can everyone state your names and associations if there is one. 19:01:43 Matt Farina, HP 19:01:53 Jamie Hannaford, Rackspace 19:02:15 Shaunak Kashyap, Rackspace 19:02:19 Sam Choi, HP 19:02:54 This meeting is to discuss the state of the repo... 19:02:56 Glen Campbell, Rackspace 19:03:21 shall we start where we left off? 19:03:47 to restate the starting point from earlier.... 19:03:50 "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 "For example, there are things like multiple api version support that needed to happen." 19:04:20 that's copied and pasted from the earlier meeting 19:04:59 also: "from a general contributor perspective, wouldn't it be easier to start from an empty repo, though?" 19:05:06 that was me 19:05:20 and " yes. no legacy decisions, cleaner code, and it allows members to be included from the very beginning" 19:05:28 and " 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 and then we ran out of time 19:06:15 yup 19:06:20 so I'll put forth my take 19:06:25 to kick us off 19:07:10 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 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 as opposed to modifying existing code 19:09:00 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 ycombinator fyi, i'm waiting to ask questions until you've let me know your complete thought 19:09:34 yeah - almost done :) 19:10:26 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 okay, I'll step down with that for Q&A and for someone else to go 19:11:50 no questions, but i agree with the import idea 19:12:02 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 mfer what do you mean by "base architecture"? 19:12:27 as in directory structure? 19:12:36 if my understanding of blueprints are correct, I think thats where it would happen 19:12:37 the software architecture for the codebase. it's more than directories 19:12:47 blueprints + wiki, perhaps 19:13:05 there's a blueprint for the workspace (directory structure). each service's design is discussed separately 19:13:12 (someone please feel free to direct me to how architecture type decisions are made in openstack) 19:13:15 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 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 i do appologize that the current blueprints don't reflect that kind of detail 19:14:15 no need mfer, we are all supposed to bear that burden 19:14:16 ycombinator: Generally blueprint+wiki for each proposed design, followed by discussion in email or IRC 19:14:39 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 …or discussion at a Design Summit ;-) 19:15:10 mfer: that was probably only true of Swift 19:15:27 …since that was already code in production when OpenStack was created 19:15:42 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 Nova went through a *lot* of design reviews 19:16:05 jamie_h: Agreed; just letting you in on some history 19:16:19 that's what us old-timers are good for ;-) 19:16:32 ha 19:16:35 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 There were a ton of reviews and a lot of revisions in 2011 when it was getting off the ground 19:17:16 Nova was originally the nebula project at NASA - lots of good ideas, but written for a particular use case 19:17:33 e.g., instances were not designed to persist 19:17:33 was it contributed before or after the changes? 19:17:50 it was used more as a strawman 19:17:52 and was it changed or rewritten from scratch? 19:18:04 (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 mostly written from scratch 19:18:29 it was too hard to fit into a broader use case that the various parties needed 19:18:30 Sort of used as a template, but much of it wouldn't scale well. 19:18:54 edleafe if it didn't have those issues would so much of it have been rewritten? 19:19:34 mfer: well, that was the point. The issues existed because it was written for a single use case 19:19:44 we have those issues with the current codebase too... 19:19:58 to make it something that could be the basis of OpenStack Nova, we largely started from scratch 19:20:00 it doesn't reflect at all our plans for the transport or service layer, so it really does warrant new code 19:20:11 not exactly, with a minimal amout of work we can change the existing codebase to not have those issues 19:20:19 i disagree 19:20:36 it will require more effort and time than writing fresh code 19:20:50 and it will probably cause more bugs in the future than a clean slate 19:21:14 plus, you'd have to completely rewrite your tests - which is a nightmare for existing projects 19:21:15 The general rule is that code talks. If you think something can work, code it and let everyone review it 19:21:33 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 jamie_h: so let's discuss the short term road map. https://wiki.openstack.org/wiki/OpenStack-SDK-PHP 19:22:03 Which requirement(s) would be difficult to fulfill? 19:22:11 With the current repo 19:22:27 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 i'll admit that more of the details could use documentation 19:22:59 earlier today I volunteered to do more of that 19:23:06 mfer: OK, sounds good. But yeah, docs would be a huge help 19:24:18 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 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 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 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 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 plus the existing codebase is not PSR-2 compliant, there's a reliance on singletons, etc. 19:25:51 thanks for clarifying 19:26:03 mfer: Understood 19:26:08 in general, its going to take anyone not familiar with the existing codebase longer than those who are 19:26:22 and inclusivity is one of our most important goals 19:26:26 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 reduce barriers for entry, not raise them 19:26:31 if we wipe clean and start with blueprints first we ensure that there is an shared understanding as we submit reviews 19:26:51 mfer these are two, i agree, incidental points. but it's endemic of the wider issue 19:27:23 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 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 ycombinator if we start with a new codebase then no one will be familiar with the codebase 19:28:05 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 mfer but it puts people on level footing 19:28:29 and we can quickly iterate over new designs or re-import existing code 19:28:35 but there needs to be a fair process 19:28:36 and how does that help progress the project? 19:28:43 mfer: what jamie_h said + we would all be agreeing to designs first, which I think is an important step 19:28:45 the goal is to produce a PHP SDK for end users 19:28:48 I also don't see how that helps with progress 19:28:54 it's important for the community and it will make non-HP workflow faster 19:29:10 that's saying that it's for an HP workflow now 19:29:19 and that the current path continues that trend 19:29:33 all i'm saying is that you're familiar with the codebase and we're not 19:30:00 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 i'm not sure how that helps move this along at a good pace 19:30:20 mfer: True, but OpenStack is a different beast 19:30:24 but this is not any other codebase. this is our chance to make a great openstack project 19:30:40 i agree 19:30:53 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 I've had to scrap a bunch of working existing code in order to get a community around the Python SDK 19:31:27 edleafe i understand that. i've been spending a lot of time trying to understand the way the community operates 19:31:31 and how to work well in it 19:32:16 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 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 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 jamie_h break that down. how does starting new help the workflow? 19:33:41 put aside the community engagement for a moment 19:34:23 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 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 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 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 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 we're not learning anything with a new codebase. we're creating it. 19:35:32 creating it with an approved process of review 19:35:41 we're all laerning what's being created by others 19:35:57 but that's the nature of a collaborative project 19:36:32 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 this is a community issue: we would feel much more comfortable starting on level ground with everyone else on the project 19:37:06 and right now, thats not the case 19:37:15 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 that's your personal choice of metaphor 19:38:17 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 this is a new, community-driven project: not the continuation of a private codebase. 19:38:55 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 and in understand. you don't want to get involved if it's not coded from scratch 19:39:43 this is not an argument of principle, there are strong arguments at stake here 19:39:45 i've not seen how this applies to technical problem in teh codebase that cant' be easily overcome 19:40:17 it seems it's a matter of start clean or you're not going to get started 19:40:34 which is quite different from the nova disucssion/example earlier 19:40:46 the technical reason is that a fresh slate offer significantly more freedom to implement agreed-upon designs 19:41:02 you're not constrained by legacy (unapproved) decisions 19:41:22 its a matter of making everyone feel equally involved from the start 19:41:24 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 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 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 i don't mind using any of the existing codebase so long as it goes through gerrit first 19:43:16 and we all have a say 19:43:19 right, that's my "import" suggestion 19:43:22 yeah 19:43:31 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 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 samchoi: the difference is that by then we'll have a set of blueprints to go with the codebase 19:45:26 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 right now we don't have that 19:45:39 ycombinator we already have a set of blueprints to go with the codebase 19:46:36 jamie_h: considering where the python sdk is at today, probably more than a few hours ;) 19:46:51 samchoi: this is a bigger issue than me and shaunak. it's symbol of a wider need for equality and inclusivity 19:47:39 everyone is equally invited to get involved. 19:47:45 this is different from that 19:47:50 not when half of the code has not been reviewed by others 19:48:01 sorry, all of the code 19:48:22 others have not taken the time to review the code. they are welcome to come in, file bugs, use it, etc. 19:48:44 because the basic premise is flawed: there is extant code in the repo which has not been officially reviewed 19:48:56 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 you point the tool at the existing repo and it pulls it in 19:50:28 since this is being described as a community process issue, I need to do follow-up from outside this group. 19:50:59 if it's not been articulated enough please feel free to add more details 19:51:15 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 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 which will go through gerrit and be merged back in the library 19:52:18 I'll summarize my thoughts one more time for external follow up 19:53:08 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 so mfer and samchoi, where do you stand? are you up for having a try at what shaunak suggested? 19:56:45 my stance is i need to do some external follow-up before i have any further stance 19:57:00 I think that's fair mfer 19:57:18 is there anything else? 19:57:22 could you include us on those follow up conversations as well, please? 19:57:28 that's fine, will need follow up in any case 19:57:54 mfer also, what exactly are you following up? 19:58:04 the process of importing? 19:58:06 ycombinator where appropriate i will. some of this is personal mentors and direction in the community type stuff 19:58:17 mfer: understood 19:58:18 thanks 19:58:32 if not before, next week we'll continue this at the normal meeting time. for meeting things that is 19:58:49 emails and side discussions may happen in between. 19:58:53 sound good? 19:58:54 i had a question above 19:59:08 you mean on what i'm following up on? 19:59:16 yeah, i wasn't 100% sure, sorry 19:59:30 to understand community processes, history, decision making, project context, etc 19:59:51 lots of background on the community angle to this discussion 20:00:39 sure, okay. perhaps we could reach out to folks in the openstack community too 20:00:53 so next wednesday is good for everyone? 20:00:55 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 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 awesome, it's definitely an important step before we release any more code 20:01:47 jamie_h I think the wednesday 1530 UTC meeting in openstack-meeting-3 is set for good now 20:02:12 I think one of the issues is that each individual's criteria for choosing a starting approach is quite different 20:02:17 samchoi: i can follow up over e-mail if you'd like. is that okay with you? 20:02:27 oh certainly, I forgot it's quite late for you 20:02:30 my apologies jamie_h 20:02:31 :) 20:04:18 the hour is up. i'm not sure if aother meeting is coming in here. 20:04:28 don't want to step on anyone elses toes atain 20:04:33 s/atain/again 20:04:48 if there's nothing else I'll end the meeting to respect everyones time 20:05:06 sure, i have nothing else 20:05:14 ok 20:05:39 #endmeeting