21:04:37 #startmeeting 21:04:38 Meeting started Tue Sep 14 21:04:37 2010 UTC. The chair is dendrobates. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:04:39 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:04:40 oops 21:04:55 welcome everyone 21:05:20 as usual the agenda is at http://wiki.openstack.org/Meetings 21:05:37 #topic old business 21:05:56 last meetings action items. 21:06:07 * dendrobates find out what license to use for docs] (dendrobates, 21:37:09) ACTION: find out how APL2 affects docs in code (dendrobates, 21:37:32) 21:06:08 Oh, dear. 21:06:17 yes soren? 21:06:31 dendrobates: I think ewan had that answered... 21:06:38 I discussed the matter with RS legal and they are fine with whatever we decide. It does look like the docs pulled out of the source need to be APL2. 21:07:10 Ewan found Apache's policy, that doesn;t have to be ours 21:07:18 dendrobates: gotcha 21:07:19 but it probably should 21:07:34 So my suggestion is that we use APL2 for everything. Any disagreement? 21:07:39 dendrobates: well pretty much everything in OS is Apache2... 21:07:41 #agreed 21:07:50 #agreed 21:07:50 #agreed 21:07:52 #agreed 21:07:52 #agreed 21:07:58 #agreed 21:08:08 #agreed Use APL2 for docs as well as source code 21:08:29 * joshuamckenty thinks that this only works for dendrobates 21:08:45 ok let's consider it closed then. 21:08:48 yep :) 21:08:50 can I propose 21:08:51 yay 21:08:54 I think it works for everyone. 21:08:54 that we dual license with CC0 as well? 21:09:00 just to be annoying? 21:09:16 dendrobates: Does that cause any issues with RS cloud docs being CC licensed? 21:09:18 joshuamckenty: that sounds like extra work. 21:09:26 creiht: I don't believe so, no. 21:09:26 does it give us anything? 21:09:36 <_0x44> dendrobates: Is that extra work for us, or for legal? 21:09:36 then find by me 21:09:36 It sounds like someone volunteering to do extra work, is what I hear. 21:09:42 joshuamckenty: yeah - I don't have permisssion to contribute under other licenses 21:09:43 actually, just to prepare for the fact that, sooner or later, lawyers will realize that docs can't be treated like code, and we need a CC license on the docs 21:09:48 oh, merde 21:09:50 right 21:09:51 nm 21:10:05 if we wanted to use the cc with the non-comercial clause that maybe, but I don;t really want that 21:10:13 KISS. 21:10:17 cc0 is essentially public domain 21:10:18 i say we do 1 for now 21:10:20 APL2 for all. 21:10:23 it makes it easy to excerpt for books 21:10:35 ok topic closed. 21:10:37 the fact that RS cloud docs is CC won't intefere. 21:10:49 #topic summit 21:10:58 The next design summit has been announced http://goo.gl/OD4X 21:11:07 November 9-12 21:11:16 in San Antonio TX 21:11:17 why texas? 21:11:27 yeah, I vote Wisconsin 21:11:34 hah 21:11:35 Tokyo please :) 21:11:37 :D 21:11:40 he 21:11:44 Honolulu, please 21:11:45 heh even. 21:11:47 I second for Tokyo 21:11:52 joshuamckenty: because the kind gentleman that is paying requested it :) 21:11:55 in seriousness, though 21:11:57 I hear Bahamas is nice in November. 21:11:57 Right 21:12:07 can we start a pool for an alternate location for crocus? 21:12:12 ans starts with B 21:12:23 ttx: Oh, right. 21:12:30 i vote for New Orleans, so I can split time between opentstack and rubyconf 21:12:32 montreal 21:12:38 dendrobates: so, the location/date is fixed. shall we make travel and lodging arrangements or will there be some info coming on the hotel? 21:12:38 this is Rackspaces chance to show off our headquarters 21:12:45 yes it is fixed 21:12:55 Please register your attendance on Launchpad at http://goo.gl/nw5G 21:13:02 dendrobates: ah, ok. missed that, sorry. 21:13:13 It is free and open to everyone, but we need to know if your coming. 21:13:20 Info about blueprints and sessions will eventually appear at http://wiki.openstack.org/Summit/Bexar 21:13:25 dendrobates: 21:13:34 pvo: yes 21:13:35 er do RS folks need to register? 21:13:48 yes, it would be helpful for scheduling. 21:13:51 ok 21:14:10 you'll be able to mark yourself as required for certain blueprint discussions 21:14:16 dendrobates: the nasa folks are pushing through the paperwork to go 21:14:34 #action: ALL register for summit if going at http://goo.gl/nw5G 21:14:55 anotherjesse: there may be a chance of sponsorship for key individuals that cannot get funding to attend. 21:15:20 let me know if anyone needs help, but no promises 21:15:42 dendrobates: k, on to orm-refactor? :) 21:16:07 #topic ORM refactoring 21:16:33 So I am guessing most people saw my email to the ml 21:16:42 * jaypipes would like to get resolution on this and get it merged today or tomorroww... 21:16:53 * anotherjesse too 21:16:55 ok so.... 21:16:58 * joshuamckenty also 21:16:58 lots of stuff held up for it right now.. 21:17:04 I propose that we merge it in to austin, and quickly follow with the addition of support for redis, For the reasons I outlined on the ml. We can decide if we want to deprecate redis post austin. 21:17:12 * joshuamckenty concurs 21:17:12 #agreed 21:17:20 #agreed 21:17:22 #agreed 21:17:25 #agreed 21:17:25 <_0x44> #agreed 21:17:27 #agreed 21:17:31 #agreed 21:17:33 * joshuamckenty has deep secret love for redis 21:17:34 #agreed 21:17:35 (and #agreed is an admin only function if you want it to show up in the logs with a summary) 21:17:40 #agreed 21:17:49 #agreed with joshuamckenty's secret love 21:17:50 any dissension 21:17:52 :( 21:17:58 joshuamckenty: So you're doing the Redis backend? :) 21:17:58 so we aren't supposed to do a #agreed to vote? 21:18:01 dendrobates: I will go ahead and create a blueprint for the re-addition of a noSQL adapter. 21:18:03 fine then: #disagreed 21:18:07 dendrobates: if ok with you? 21:18:14 soren, I did it the first time :) 21:18:15 anotherjesse: I think the idea is that the chair uses it to denote what was agreed. 21:18:23 joshuamckenty: So you've got practice. 21:18:25 #action create a blueprint for the re-addition of a noSQL adapter. 21:18:25 anotherjesse: you can use it to vote, but it won't get summarized 21:18:40 soren, good point 21:19:04 jaypipes / dendrobates re-adding redis should be relatively easy - since the models don't escape the api layer as anything more than dicts 21:19:13 anotherjesse: yup. 21:19:19 soren we'll get the voting right next time. 21:19:25 so, I know people want redis, but why exactly if it doesn't make sense for out data set? It seems we wanted to move away from it and use SQL (hence the orm branch). I don't think we need to worry about backwards compatibility yet 21:19:31 anotherjesse: though the fakeldap stuff may be the bigger foobar. 21:19:38 It is not about redis. 21:19:54 i think it's more about shared nothing no spof 21:20:08 it's more about how we drop something from openstack, imho 21:20:09 eday: not redis specifically. could be memcache as far as I care... 21:20:09 jaypipes: the fake ldap eventually needs to be pluggable user system - eg backend to mysql or redis or ldap or ... 21:20:10 <_0x44> eday: It's about going into a release with required dependencies, and then finishing the release with those dependencies just gone without a period of deprecation 21:20:18 anotherjesse: ++ 21:20:26 _0x44: exactly 21:20:30 _0x44: yup. 21:20:55 dendrobates: well, I think we still have the luxery of not having to worry about that until Austin is released :) 21:21:04 <_0x44> eday: It's not a problem now since we didn't have any users before. But it will be in the future, and we don't want to set bad precedent 21:21:21 100% agree we need to deprecate once we have something we say we support, but we've not yet 21:21:25 eday: so you are saying prioritize the fakeldap rework over the re-addition of a noSQL adapter? just trying to understand... 21:21:50 eday: if fakeldap didn't depend on redis, there would be no redis dependency. 21:21:57 jaypipes: I'm saying don't add a nosql adapter just for the sake of having one at this point, especially if we are moving towards a relational model 21:22:06 jaypipes: they are separate - just mentioning it because fakeldap was written at a time when there was no centralized datastore (not even redis) 21:22:31 anotherjesse: I know, what I'm saying is that the fakeldap piece is the last remaining dependency on redis IINM 21:22:52 jaypipes: so we need two patches 21:23:02 one to be off of redis entirely, and one to put it back in 21:23:08 Even though we do not have users, it would surprise casual observers that thought redis was required to find it u nsupported. 21:23:27 joshuamckenty: right, and I believe eday is trying to say it's better to be off redis entirely. right, eday? 21:23:30 Also, if we keep using a relational data model in nova, and have nosql backends, we'll be reinventing an ORM on top of SQLAlchemy and X (whatever it is we support) 21:23:46 joshuamckenty, eday: b/c then we could de-prioritize the re-adding of the nosql driver? 21:24:00 sounds like there are 2 separate things people are talking about: 1) managing deprecation of things that are in the project and 2) should we have non-relational/nosql options at all going forward 21:24:02 then we make a blueprint stating that and discuss it in November and deprecate it. 21:24:33 <_0x44> I think re-adding the nosql driver should still be prioritized because that means that it can be used by the k/v cache for gundlach's rate limiting 21:24:35 jbryce: yes, but I think eday is saying if we remove the nosql dependency before Austin release, #1 will not be a problem :) 21:24:48 _0x44: i disagree with that 21:24:50 #1 is a problem 21:24:59 <_0x44> gundlach: You disagree that it could be used? 21:25:05 because we're not just removing a dependency, we're adding one 21:25:05 <_0x44> gundlach: Or that it should be prioritized? 21:25:14 we're adding a SQL dependency where we didn't have one before 21:25:17 joshuamckenty: is it a problem if there is no more redis-dependent code before Austin release? 21:25:19 no, i disagree that it's a priority. rate limiting works fine for the scale Austin will need, without a separate server 21:25:39 jaypipes: not for us 21:25:53 I think it is a priority and we have a volunteer to do it: jaypipes 21:25:57 anotherjesse: meaning there is not a problem? or there is? 21:25:59 and i've already got a simple, working WSGI app that suffices in case someone did need to 'call out sideways' from multiple API servers to do rate limiting. 21:26:03 it should not affect anyone else 21:26:06 jaypipes: there isn't a problem with not having redis - nebula doesn't use it 21:26:17 anymore 21:26:20 * joshuamckenty sniffs 21:26:23 dendrobates: I'm happy to do it. But what is "it"? :) the removal of redis dependent code or the re-adding of a nosql driver? 21:26:41 re-adding of a nosql driver 21:27:06 jaypipes: vish and I will help 21:27:10 dendrobates: ok. however, I think there is still disagreement on whether we should do that before Austin. eday seems to be making the argument against that. 21:27:17 anotherjesse: cheers :) 21:27:30 eday: correct? 21:27:34 we can then discuss all of this at the summit. I will make the blueprint myself. 21:27:47 dendrobates: so, not for Austin, then... 21:28:02 no, I mean discuss deprecating redis support 21:28:08 ah... 21:28:09 so for austin, re-add a nosql driver; for future release discuss necessity of nosql support 21:28:20 jbryce: exactly 21:28:21 if we are ok dropping redis, what is the technical reason to add some other NoSQL store? 21:28:42 there was no concensus (lazy or otherwise) yet on dropping redis 21:28:43 I don't see any, especially given that we're moving towards a relational model with the ORM branch 21:28:44 proving that we aren't pushing sql assumptions into the data? 21:28:48 there's simply a patch to add SQL support 21:28:49 data layer 21:28:55 jbryce: hmm, ok. I kind of agree with eday, though. If we re-add support in for Austin, we must deprecate stuff if in the future we decide not to support it :) 21:29:15 joshuamckenty: it doesn't just add SQL, it reworks the entire data model and removes redis because fundamental things changed :) 21:29:42 right, but that wasn't the goal of the patch (to remove redis). It was to add an ORM 21:29:44 joshuamckenty: ya, eday is right on that one. 21:29:59 it was to make the data model explicit 21:30:05 I think we should discuss in November if a SQL store will suffice long term (performance numbers) and think about the long term data model, but I see no reason to add a NoSQL interface/store "just because" for Austin 21:30:08 and API interaction with it 21:30:21 there was an earlier (unfinished) effort to make the data model more explicit on top of redis 21:30:30 sorry, but I'm going to agree with eday on this one... 21:30:34 tying it to sql is a pretty big design decision that will have lots of long-term implications. i think it definitely is worthy of a design summit discussion before making a final decision 21:30:35 the my reasons from the ml: 21:30:43 we abandoned that at NASA b/c we had to switch from redis for security reasons 21:30:45 it seems like you will make more people mad if you add a no-sql backing for redis, and then just drop it a release later 21:30:46 * OpenStack should avoid making technical decisions for implementers. 21:30:47 We should only mandate a technology if we have to, for reasons like 21:30:47 uniformity of the code, i.e the twisted debate, or because choice would 21:30:47 be difficult to implement. 21:31:02 creiht: right. 21:31:16 I don't think lack of NoSQL support "ties" it to SQL. It is still pluggable, even if the plugin doesn't exist 21:31:23 i disagree 21:31:37 without two plugins, a plugin architecture is just a myth 21:31:47 joshuamckenty: true. 21:31:50 and if both plugins are SQL-shaped, 21:31:53 then you're tied to SQL 21:31:54 In general, if we are going to drop a major technology choice, we should do it slowly, by deprecating it first. We should never go into a release requiring a technology and end the release with it totally 21:31:54 so write a null plugin :) 21:31:54 unsupported. This is just not fair to our users. We will make choices, but we need to ensure smooth transitions for people that have implemented Openstack. I know it is less of an issue for our first 21:31:54 release, but good policy is good policy. 21:31:56 but the data interface layer has no assumptions about being in sql, its just hashes 21:32:01 or dicts, rather 21:32:01 joshuamckenty: I agree that it would flush it out .. for instance there are some places that do obj.foo instead of obj['foo'] still 21:32:12 Also, nothing is set in stone here. We may throw out ORM and convert to something entirely different in 6 months. But right now we know that Redis won't suffice (security at least), and that we have a huge ORM branch blocking other work. 21:32:21 dendrobates: when was the first release that required redis? :) 21:32:30 dendrobates: yes, you are correct... I'm torn on this decision, like I mentioned on the ML.. :( 21:32:32 eday: everyone already agreed to merge the orm branch 21:32:39 creiht: it was nova 0.6 21:32:48 we should not make security decisions for implementors 21:32:48 dendrobates: and I agree with stable, non-beta products 21:32:51 IIRC 21:33:06 jbryce: right, we're not discussing whether to merge the orm branch, but what to do about nosql driver for the new datastore api... 21:33:17 for example you can compile Apache with -DBIG_SECURITY_HOLE 21:33:41 proposal: since the "pluggable" daat layer is there - we can spent a couple days the first week of oct adding support for redis 21:33:58 it is a "should have" not a "must have" 21:34:03 agreed 21:34:07 +1 21:34:12 jbryce: I thought it sounded like some folks wanted to wait and discuss in November 21:34:41 I like the idea of having it since it can ferret out any assumptions we've made in the api that is wrong 21:34:42 eday: i think the discussion is around long-term inclusion of redis or other nosql rather than blocking the orm branch 21:34:50 anotherjesse: this whole argument is between "should have" and "must have". :) there's a good argument on both sides I think. 21:34:55 eday: we have agreed to merge orm-refactor 21:35:04 jbryce: yup, just thought it had regressed for a second :) 21:35:15 #info we will merge orm refactor for austin 21:35:34 dendrobates: OK, so...why don't we do this... take a vote for "should have" vs. "must have" (for Austin) 21:35:37 jaypipes: I would say it is a "must have" if it wasn't for the time constraints... since having two backends would be nice 21:35:55 anotherjesse: right, but this is all about Austin 21:36:05 #info discussion required at november design summit around long-term inclusion or deprecation of support for redis/nosql datastores 21:36:10 anotherjesse: which has a certain timeframe :) 21:36:12 I think we can get it done. 21:36:12 so we need the same vote for the fakeldap backend 21:36:20 jbryce: yup, good #info. 21:36:24 e.g., getting that off redis as well 21:36:36 joshuamckenty: that would be easy enough... 21:36:45 joshuamckenty: is there a fakeldap branch? 21:36:53 there's a fakeldap module 21:36:59 I don't know if there's a branch 21:37:01 dendrobates: no, it's a module. 21:37:19 so this is work that is not done yet. 21:37:27 and it is only for fakeldap 21:37:38 well, that's what I meant by saying the goal was not redis removal 21:37:45 joshuamckenty, vishy: we could try using dataflake.ldapconnection.tests.fakeldap... 21:38:03 ooh, interesting. Or we could go back to keeper :) 21:38:08 what is the fakeldap branch? 21:38:08 * joshuamckenty ducks 21:38:09 ha! 21:38:22 captcha12: it's a module used in tresting nova. 21:38:26 nothin like serializing json on disk 21:38:57 so vote for "must have"? 21:39:06 #disagree 21:39:11 -1 21:39:15 #disagree 21:39:29 -1 on "must" 21:39:33 so let me see if i've got this: the last remaining question is really do we add redis support back in for austin, potentially pulling it back out in future releases and confusing some people--should have option, or do we just let it disappear out of austin (and updating fakeldap) also potentially confusing some people and then add it back in post november--must have option. 21:39:34 <_0x44> -1 21:39:40 jaypipes: sure, it needs to support very little 21:39:43 #disagree 21:39:55 vishy: not disagreeing with you! ;) 21:40:29 jbryce: I think we've agreed that we "should" put redis support back in for austin. This is whether we "must" do it 21:40:32 jbryce: no, the must have option is to have rediis/nosql support in Austin's relaease 21:40:34 jbryce: um, i thought 'must' vs 'should' were backwards from your descriptions. 21:40:34 hmm...got my must have and should have backwards, didn't i? 21:40:37 #disagree on must have 21:40:38 i almost feel like redis is a solution looking for a problem, does anyone actually want to run on it? 21:40:47 yes 21:40:49 I do 21:40:58 I vote we defer the redis/further data model argument to November summit discussions. We should just sit tight with the ORM branch as is (minus small improvements as needed) 21:41:00 do you want to write it before austin? 21:41:05 i think a day of hacking using the old BasicModel will make it work 21:41:05 OK, so we are #agreed that redis/nosql support is a SHOULD HAVE for Austin. 21:41:17 dude, I'm modelling earthquakes. < xtoddx 21:41:35 joshuamckenty: wanna talk vish into writing it before austin 21:41:40 yup 21:41:53 what about the SHOULD vs MUST for the fakeldap rework? I vote for MUST HAVE. 21:41:56 #info vish will add redis support in using BasicModel, hopefully in time for Austin 21:42:05 hehe 21:42:08 #agreed! 21:42:08 thx josh 21:42:12 #agreed 21:42:32 #disagree, it's only used for testing 21:42:40 <_0x44> Doesn't the outcome of fakeldap depend on whether or not redis is added back? 21:42:50 not really 21:42:56 _0x44: no it is separate from the data model 21:43:04 dendrobates: OK, but recognize that the fakeldap module is the last remaining redis dependent code. 21:43:25 Uh, it's not just used for testing. 21:43:29 I think we're about to spend more time discussing it than the patch will take 21:43:38 I say should have. If it comes down to other features, I say drop it 21:43:43 #agreed joshuamckenty 21:43:48 dendrobates: without the fakeldap redis dependency, we could theoretically release Austin with no Redis dependency. 21:43:53 joshuamckenty: ha 21:44:00 soren: what else is it used for? 21:44:10 #info xtoddx will cherry pick the old (pre-redis) fakeldap forward as a patch 21:44:20 WEll, the fakeldap thing is used if you don't actually want to use ldap for your user backend. This seems common. 21:44:27 soren: fakeldap is used for more than production? 21:44:32 It's the default in the Ubuntu packages, for instance. 21:44:32 er testing 21:44:41 oh 21:45:15 ooh... we could make fakeldap back onto SQL, and use it as a performance test of the DB ;) 21:45:15 Since, what's the point in requiring ANOTHER data store for users if you don't alrady have LDAP set up. It's just more needless complication. 21:45:35 soren: but fakeldap requires redis :) 21:45:46 lol 21:45:55 I love this catch22 ;) 21:46:01 jaypipes: we can get off of redis though, maybe move into the db.api layer 21:46:05 jaypipes: It does, yes. 21:46:10 jaypipes: I never said it didn't :) 21:46:13 it's the code equivalent of a Chinese finger-trap. 21:46:33 yeah, but it's not our fingers we got stuck 21:46:39 soren: well, then your argument above contradicts itself, since it's the only thing using redis, no? 21:46:54 so it's a must have to get fakeldap working without redis if redis is not a must have 21:46:57 soren: so what are you suggesting? 21:47:02 eday: Well, the orm branch hasn't been merged yet :) 21:47:15 jbryce: thus the catch22 ;) 21:47:17 dendrobates: That someone makes the fakeldap thing hook into the ORM. 21:47:23 soren: it will be, that was already decided, and redis is gone for that end :) 21:47:28 jbryce: they are unrelated 21:47:39 dendrobates: I'm suggesting that now. I wasn't suggesting anything before. I was just sayin'. 21:47:45 (well, for now at least) 21:47:58 1) merge orm, 2) move fakeldap into the db layer, 3) make a nosql db layer driver 21:48:00 right? 21:48:05 eday: sorry, I'm having a hard time keeping up :) 21:48:08 xtoddx: correct 21:48:10 eday: this is what I was pointing out earlier, when I explained that ORM change wasn't about removing redis 21:48:23 Or you could use ldap as your data store, and all your problems are solved :) 21:48:26 xtoddx: thank you for your clarity. YES! 21:48:31 easier would be kill fakeldap and just make an AuthDriver that backends to orm 21:48:45 joshuamckenty: yeah, I was thinking about just non-auth before. I knoew auth was still using it for fake 21:48:46 vishy: true 21:48:47 vishy: already done with repoze.what.sql :) 21:48:48 xtoddx: what's the current cacheing layer on auth? 21:49:00 so lets get volunteers for each part and end this. 21:49:05 dendrobates: ++ 21:49:16 talk with your code. 21:49:27 joshuamckenty: the middleware uses the memcached middleware bundled with swift, but nothing durable 21:49:38 jaypipes, so, you have it done and solved? :) 21:49:52 eday: what part? repoze.what.sql? 21:50:10 let's stay on topic. 21:50:20 #action vishy will add redis support in using BasicModel, hopefully in time for Austin 21:50:29 jaypipes: the auth/fake ldap replacement 21:50:35 move fakeldap into the db layer: volunteer? 21:50:41 joshuamckenty also volunteered xtoddx to make fakeldap not depend on redis 21:50:45 i'll do it, it should be quick 21:50:59 #action xtoddx to move fakeldap into db layer 21:51:02 \o/ 21:51:05 i'll kill fakeldap and just make a new auth driver that can be default in ubuntu packages 21:51:10 make a nosql db layer driver: 21:51:22 jaypipes: are you taking that? 21:51:28 xtoddx: please take a looksie at repoze.who and repoze.what. 21:51:34 dendrobates: sure. 21:51:41 jaypipes: links? 21:51:50 dendrobates: but I think vishy already has that? 21:51:56 I believe anotherjesse and vishy offered to play in as well 21:52:13 jaypipes: that's what it said earlier in the chat so i just copied it into an action.... 21:52:15 xtoddx: http://docs.repoze.org/who/1.0/ 21:52:27 ok all can play, but I';ll hold jaypipes responsible. 21:52:35 dendrobates: OK, so vishy, anotherjesse and me. 21:52:39 dendrobates: cool. 21:52:39 (well, technically *I* offered for vishy to play in, but who's counting) 21:52:43 jaypipes: thanks 21:53:09 #action vishy, jaypipes and anotherjesse to make a nosql db layer driver 21:53:25 xtoddx: http://what.repoze.org/docs/1.0/ 21:53:32 so we have agreement 21:53:38 yup 21:53:43 is someone going to take point on getting the orm merge in? 21:54:01 jbryce: I can just go mark as approved right now 21:54:03 jbryce: it's automated. just have to set the merge prop to approve. 21:54:20 eday: do it! get to the chopper! 21:54:25 eday: adding a little patch for networking but i can propose it after 21:54:31 jaypipes, eday: yep...just wanted to make sure it didn't get lost in the shuffle 21:54:34 there will need to be a few things fixed after merge 21:54:35 any objects to landing it now? 21:54:38 jbryce: :) 21:54:46 eday: nope. 21:54:46 Let's make sure we've had the proper review. 21:54:50 err, objections 21:54:55 dendrobates: it's been reviewed a lot. 21:55:08 dendrobates: this discussion was the last "review" 21:55:11 dendrobates: termie and me did a full review as well as eday I believe and soren. 21:55:12 +1 21:55:25 It's good stuff. Merge it :) 21:55:25 jaypipes: thanks, I hadn;t checked 21:55:30 ok, go! 21:55:30 ok, marking it 21:55:33 dendrobates: no worries :) 21:55:51 I smell a broken build email 21:55:56 haha 21:56:01 probably :) 21:56:28 topic closed 21:56:42 #topic meeting time 21:56:43 did we need to discuss xtoddx's auth branch too, or save that for later? 21:56:55 same time next week? 21:57:02 eday: ml 21:57:08 +1 21:57:14 can i make a suggest an hour earlier? 21:57:21 please no :( 21:57:29 i have about 4 branches based on orm which will need review as well :) 21:57:35 zul: you can if you want ninjas from japan to behead you 21:57:47 dendrobates: i would pay to see that 21:58:04 zul: You can't see ninjas. 21:58:13 soren: right 21:58:14 #action everyone do code reviews 21:58:18 zul: look behind you. 21:58:35 #endmeeting