20:02:19 #startmeeting tc 20:02:19 Meeting started Tue Sep 15 20:02:19 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:24 The meeting name has been set to 'tc' 20:02:32 Agenda for this Technical committee meeting at: 20:02:37 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:55 #topic OpenStack programming languages resolution 20:03:01 #link https://review.openstack.org/217710 20:03:10 The latest version tweaks the wording to be clearer, as suggested by annegentle and sdague 20:03:20 This now has enough votes to pass. I'll approve it now unless someone screams 20:03:36 lgtm! 20:04:07 lgtm and it addressed sdague's comments 20:04:11 * ttx leaves 30 more seconds for jeblair to re-register his +1 20:04:31 ttx: i think i just did? 20:04:37 ah, refreshed 20:04:52 #topic Cross-project track workgroup: collecting topics 20:05:05 Since we don't have that much on the agenda, I figured we could use some time to discuss the cross-project track, since so many TC members are interested in helping there 20:05:11 Two weeks ago a number of people signed up to help there: 20:05:18 (dhellmann, sdague, mordred, flaper87, lifeless and me on the TC side + thingee & Rockyg) 20:05:25 A few data points first... 20:05:26 * dims_ lurks 20:05:33 Number of slots: We have seven 40-min time slots, and we can use 2 or 3 parallel rooms 20:05:43 (in Vancouver we only used 2 parallel rooms, for a total of 14 slots) 20:05:53 We have a time slot (at 2pm) where the Ops have nothing scheduled, so we can have devs+ops sessions in the track 20:06:22 ttx: when you say 7 slots, is that total or is that 7 times the number of parallel rooms we decide to use? 20:06:29 Also late afternoon the Ops track is in workgroup sessions so we can have more ops-oriented topics then as well 20:06:36 ttx: when you say 2 or 3, do you mean we can adjust as necessary, or do we need to decide on 14 or 21 sessions? 20:06:40 7 times * number of parallel rooms 20:06:48 +1 for dev+ops session 20:06:54 +1 20:07:04 we have 3 rooms available -- whether we use all of them all the time is up to us 20:07:13 mmh, I wonder if 21 slotes would make it really difficult for folks that need/want to attend several 20:07:17 we have 9 top level items on https://etherpad.openstack.org/p/mitaka-cross-project-session-planning so far 20:07:17 ttx: gotcha 20:07:27 flaper87: ++ 20:07:37 How do you want to handle the track contents ? Should we take suggestions, or just decide what the content should be ? 20:07:40 Lets see how many topics we have but I'm afraid 21 will be too many 20:07:50 that etherpad was not communicated that wi 20:07:52 dely yet 20:08:16 flaper87: if i'm following, we just leave rooms empty for some sessions to the degree we want to handle that. 20:08:17 I'd like to see what we can come up with as a group, and then fill in with community suggestions. 20:08:25 i'd suggest putting owner/session-lead names beside each proposal 20:08:28 before it gets too far 20:08:32 dhellmann: sounds good 20:08:35 russellb: ++ 20:08:36 bcause that's a pain to chase down later 20:08:38 In the past, we've tended to have proposals for sessions that included just 2 projects at a time, though maybe folks understand the intent better now. 20:09:24 jeblair: yup 20:09:33 I don't see cross-project communication on the list, does anyone know if anne was going to propose a session for it? 20:09:55 anteaya: no idea here 20:10:12 anteaya: that's a good one, why don't you start and you and annegentle can cooperate? 20:10:33 I can put it on the list since anne isn't here and let her decide how she wants to proceed 20:10:40 ++ 20:10:41 anteaya: ttx just signed up for it 20:10:41 happy to help if anne wishes 20:10:45 ah great 20:10:48 ttx: thanks 20:11:02 anteaya: at least, something very very similar i think :) 20:11:18 line 34 looks close enough to me 20:11:47 ttx: it might be interesting to get some input from some of the working groups like API and UX, too 20:11:51 anteaya, +1 20:12:04 One thing lifeless said on the Glance thread made me think -- "goals you've identified are well within our [all OpenStack contributors] power to address during the next cycle" 20:12:13 Wondering whether we should define a few cross-project goals on a given cycle 20:12:24 ttx we can try and see what happens 20:12:28 dhellmann, Yeah. the API group should have a session that pretty much involves all projects 20:12:31 and use the cross-project track to discuss them 20:12:39 ttx: well - thats what I did with the constraints thing 20:13:05 ttx: it wasn't something that needed lots of people pushing on it, but affects /everyone/ 20:13:36 would a config session be worthwhile? Getting consistency across configuration would help ops temendously 20:13:51 there are some, bigger ones, that have cross-prokject impact and needs some care. User facing notifications, for instance. 20:14:07 I believe there's a cross-project spec for that 20:14:23 flaper87: is someone signed up to do that work? we've talked about it in the past, but the follow-through hasn't been great 20:14:35 flaper87: and you have enough to do, so don't volunteer ;-) 20:14:45 How about we close that brainstorming at the TC meeting next week, and decide if we need to open a CFP for more cross-project topics then ? 20:14:49 dhellmann: LOOL 20:14:53 ttx: ++ 20:15:02 dhellmann: I know Angus was writing the spec but then no one followed up as you said 20:15:02 ttx: I think we should ask for inputs now 20:15:13 but I kinda think it's important 20:15:22 ttx: there's no benefit I can see to waiting 20:15:24 lifeless: I'd like to see what we can come up with as a group, and then fill in with community suggestions. 20:15:32 Rockyg: if not in a session, it'd be worth mentioning it in the dev+ops session 20:15:34 ttx: yes, I saw that. I'm disagreeing :) 20:15:39 ok, flight! 20:15:42 or fight! 20:15:47 Adrenaline? 20:15:56 Last cycle we used a Google form to take suggestions 20:16:23 I'm fine either way. I agree that there is no harm in taking suggestions anyway 20:16:25 I liked the google form, it allowed to comment etc 20:16:27 flaper87, notifications definitely are hot -- and how/when they should be logged. jaypipes was also really on that for a while 20:16:34 for the lines that are just the title of a working group, like API working group, can we get a sense of the burning issue taht what to discuss or is just giving them a room to see each other sufficient? 20:16:36 flaper87: it did not allow everyone to comment 20:16:44 jeblair: oh, mh :( 20:16:48 anyone up for creating the form ? Or should I just copy the old one and start it ? 20:16:59 didn't we use to have a nice web app just for this? :) 20:17:05 ttx: Than you for volunteering :) 20:17:15 *Thank* 20:17:26 * russellb was fond of the web app, personally 20:17:37 russellb: me too 20:17:42 it didn't have features for commenting, did it? 20:17:50 * dhellmann only vaguely remembers 20:17:54 google apps don't get China dev input -- they're blocked 20:18:19 dhellmann: i think it did ... 20:18:44 I remember comments 20:18:52 ok, cool 20:18:56 * ttx doesn't look forward resurrecting that code 20:19:02 heh, that's fine 20:19:04 it's sort of short notice 20:19:30 Rockyg: maybe we can redirect Chinese users to human proxies that will create entries for them ? 20:19:36 I guess it'll be etherpad to allow for everyone to chime in 20:19:59 dhellmann: do you agree with opening up the suggestions pandora box asap ? 20:20:05 I have no concerns about giving folk the etherpad url 20:20:05 i'd love to be able to comment this time. i was unable to do so last time. 20:20:39 etherpad would work. 20:20:43 ttx: if we really want to, that's fine. Using an etherpad failed at this scale in the past, which is why we used the google form, but if that's an issue for parts of the community we can sort through whatever comes into the etherpad 20:20:51 etherpad is such a mess when we used it for large-scale collection 20:20:57 Any way to enforce identification with a color or typed line? 20:21:10 Rockyg: you can't enforce anything with etherpad 20:21:21 ttx: want to try a mailing list thread? 20:21:29 Rockyg: trust me, that etherpad we used two cycles ago was a mess 20:21:45 yeah.. 20:21:50 dhellmann: can be hard to tell what's a suggestiojn and what's not, but I guess we don't need to precisely count anyway 20:21:53 ml would be cause a lot of traffic, but it would also refine the topics 20:21:54 Then I'd say google form and ask people to send emails if they can't access it 20:21:59 https://etherpad.openstack.org/p/kilo-crossproject-summit-topics 20:22:31 i wish we could lead by example here and use a tool that's accessible to everyone in our community 20:22:50 jeblair: we can certainly be prepared for the next summit 20:23:08 * dhellmann hesitates suggesting a git repo 20:23:16 jeblair: ++ 20:23:24 https://www.zoho.com/forms/ ? (similar to google stuff?) 20:23:28 flaper87: we've had since the last one. :( 20:23:29 jeblair: do you have anything in mind that is feasible to do now? 20:23:30 yaml2summitsched 20:23:30 dhellmann: well gerrit can figure out comments 20:23:40 anteaya: if all you have is a hammer... 20:23:43 dhellmann, would be just like etherpad if you think about it, but with names attached at least 20:23:48 dhellmann: it is handy 20:23:50 jeblair: suggestions? 20:24:12 * jgriffith despises etherpads FWIW (probably not much) 20:24:13 jgriffith: it seems the only objection to the previous summit app is cobwebs? 20:24:27 jeblair: ahh... fair point 20:24:47 i'm moving house right now, so maybe i'm just used to clearing them out :) 20:24:50 jgriffith, ++ 20:24:51 jeblair: I personally thought the "old app" worked fine 20:25:11 jeblair: you clearly never had to clear out cobwebs from code I wrote 20:25:23 if we're going to move back to that app, it sounds like ttx wants a volunteer to clean up the code and get it running again 20:25:27 LOL 20:25:41 :P 20:25:44 dhellmann: it's not difficult, it's just a lot of manual pain 20:25:49 ttx: i think i actually did have to figure out how to modify track leads while you were on vacation once :) 20:25:51 I'd volunteer if I had a clue what i was getting int ot :) 20:25:55 since we never got round to properly puppetize it 20:26:06 ttx: maybe that's something for the next summit, then 20:26:08 s/ot/to/ 20:26:14 ttx: i will put money where my mouth is and help, but could not do it alone 20:26:33 is the source in gerrit at least, or does it need importing? 20:26:40 jeblair: if you help me and fasttrack any infra hoop, we might be able to pull it off quickly together 20:26:48 fungi: all in gerrit 20:27:04 ttx: deal 20:27:08 * flaper87 volunteers ttx jeblair for this job 20:27:11 sold 20:27:24 jeblair: I can offer up some assitance, but not a ton of time to promise 20:27:24 and if memory serves, the server itself exists and has a mostly empty placeholder in our puppet 20:27:26 #action jeblair and ttx to resurrect odsreg 20:27:47 whew, ttx remembers the name. that's a good start. :) 20:27:54 (and will save me some time) 20:28:07 It's just that we need to ignore a lot of what it used to do, like sched.org scheduling 20:28:31 * jeblair is excellent at commenting out code 20:28:52 ttx: ping if I can provide any django assistance 20:29:07 I think I resurrected it once already, but used commenting out heavily to do so, rather than build the config options that would allow to run a light version 20:29:13 what does the sched.org stuff now? 20:29:13 * anteaya pats david-lyle on the back 20:29:15 manual? 20:29:21 ttx: jeblair I mentioned as well I'm happy to help out if/where I can 20:29:22 it's the incredible cheddar 20:29:27 russellb: ^ 20:29:29 oic 20:29:32 HenryG, kevinbenton: what's the long-term plan with db deadlocks? those retry decorators are stinky cheese. 20:29:48 OOPS, sorry. :) 20:29:49 which is like 10 times better than odsreg ever was, but does not do collection at all 20:30:06 it's stateless and could even run in a container. That's how awesome it is 20:30:12 dougwig: nice! cheddar to stinky cheese in 5 seconds! 20:30:18 dougwig: timing was interesting 20:30:31 wow, that's awesome for not even reading the channel. 20:30:40 hahah 20:31:15 OK, so let me summarize... We continue to brainstorm on the etherpad, we find a way to start up odsreg for cross-project session collection before end of week, and we discuss it again next week. 20:31:22 dougwig https://aphyr.com/posts/327-call-me-maybe-mariadb-galera-cluster was a good read 20:31:23 ttx: and there's a mongodb joke in there somewhere 20:31:33 'In this post, we’ll see MariaDB Galera Cluster allow transactions to read partially committed state.' (oops) 20:32:11 #topic Communications workgroup report 20:32:17 annegentle, flaper87: o/ 20:32:25 o/ 20:32:44 The last blog post came out before our lsat week's meeting 20:32:54 I don't think we need another one this week 20:33:02 but I'll sync w/ annegentle 20:33:45 * flaper87 silently goes back to his desk 20:34:20 #topic Other workgroups 20:34:27 Any other workgroup with a report ? 20:34:50 I guess not 20:34:58 #topic Open discussion 20:35:05 Lots of things to discuss in Open discussion this week ! 20:35:26 cpallares wanted to mention something about CoC, but is not around currently 20:35:42 let me find what she told me 20:36:19 "I have merged the Code of Conduct here https://etherpad.openstack.org/p/CoC" 20:36:30 comments welcome ^ 20:36:33 awesome 20:36:36 * flaper87 clicks 20:36:38 #link https://etherpad.openstack.org/p/CoC 20:36:53 * Glance priorities for Mitaka (http://lists.openstack.org/pipermail/openstack-dev/2015-September/074360.html) 20:37:02 dhellmann came up with target priorities for the Glance team, from the perspective of the rest of the OpenStack community 20:37:03 thanks to everyone who has joined in that conversation 20:37:21 I think that's great work atht we should do more often 20:37:28 dhellmann: ++ 20:37:45 Bravo! 20:37:46 it was great discussion, and helped to clear up some misconceptions that I had also 20:38:03 i think it's really good and like the conversations that have come out of it 20:38:22 and especially the information 20:38:31 Yeah, at the very least that helps clearing things up, and ideally that would steer the PTL election discussion and the Mitaka cycle in the direction most of the community want Glance to take 20:38:46 From a community perspective, I believe this leaves me with: 1) We need to look after other projects more often 2) We gotta improve our communication and make sure concerns and doubts are properly communicated 20:38:50 yeah, the confusion seems in large part to be a communication issue, so I'm glad folks are talking more now 20:38:52 i feel like a lot of people have a clue what's going on now and what people are talking about. and we're learning real things about how glance is used and not just speculating. :) 20:39:16 Many misconceptions people had about Glance were communicated late or to other folks that probably weren't familiar enough with the API. 20:39:19 as the local defcore/interop rep, there's some relevance to capabilities outside of nova that we're working on, particularly with regards to glance, cinder, neutron, and keystone, all of which have cross-project concerns 20:39:30 Just to be clear, this is not a complain but an observation for us as a community 20:39:30 would a cross-project session be worthwhile for Glance talking to the rest of OpenStack? 20:39:37 I take it as a bit of a reality check, more than as a top-down edict 20:39:40 We can't let situations like this to go thus far 20:40:01 and it may cut both ways 20:40:19 hogepodge: I'm going to be pushing for us to improve communication between contributors and defcore over the next cycle, going both directions. 20:40:39 Rockyg: I'd probably recommend people to attend Glance sessions about what will happen in Mitaka 20:40:50 to that end, there are a bunch of iterop reviews in openstack/defcore that it would be nice for the community to review. I can post to the mailing list. 20:40:58 not sure what could be said in a cross-project session of Glance folks talking to the rest 20:41:02 hogepodge: yes, please start a thread 20:41:17 flaper87, the only problem with that is when the other projects' important sessions conflict... 20:41:18 hogepodge: ++ 20:42:05 Rockyg: yup, that's unfortunate 20:42:34 ok, another topic I wanted to discuss now is: 20:42:37 * Convergence on common deprecation policy 20:42:45 I wanted to quickly discuss convergence on a common deprecation base policy, following the thread at: 20:42:46 or just have consistent API's and missions 20:42:46 Rockyg, flaper87 : as long as we get the nova/glance and cinder/glance sessions we need, that should be good for right now 20:42:47 AKA don't break crap 20:42:56 #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html 20:43:03 we also discussed it at the cross-project meeting last week 20:43:10 As I posted recently on the thread, it looks like there is convergence on: 20:43:20 "config options and features will have to be marked deprecated for a minimum of one stable release branch and a minimum of 3 months" 20:43:22 dhellmann, ++ 20:43:27 yeah 20:43:30 with some language to encourage major features to be marked deprecated for at least two stable release branches 20:43:39 so I want to call out in particular that libs and clients have had different rules 20:43:42 So I'll post a new patchset to https://review.openstack.org/207467 along those lines 20:43:50 ttx: have you compared the API deprecation timelines proposed against what defcore expects? we might need to call out defcore explicitly in that document 20:44:16 dhellmann: good q 20:44:21 perhaps hogepodge can look at it and comment 20:44:31 dhellmann: will do 20:44:52 dhellmann: well, the doc says you need to do a survey before deciding on the deprecation timeframe 20:44:52 lifeless: that's one reason for the time-based components 20:44:53 we should be fine to use a shorter time frame for something that isn't used by defcore, but we need to make sure we know how to tell what is/isn't 20:44:55 specifically clients for a long time didn't break anything ever 20:45:11 that changed with the branching stuff relatively recently 20:45:16 so somethign that is part of a defcore capability would certainly have a longer deprecation time to account for that 20:45:25 ttx: I'd like for there to be explicit language mentioning defcore, since we've identified that as a thing projects don't know enough about 20:45:27 libs have been somewhat unclear about what they can and can't do 20:45:50 dhellmann: we have two active standards at any time, which can cover different versions but still fit in a deprecation window, but we should make sure everything matches up and makes sense 20:45:51 dtroyer: yes 20:46:01 lifeless: should we say that the proposed rule is for services ? 20:46:03 hogepodge: we need a way to say that clearly 20:46:04 dtroyer: I'm advocating discussion around not branching clients or libs this summit 20:46:11 dhellmann: agree 20:46:11 and keep the discussion opened for libs ? 20:46:24 lifeless: ++ 20:46:32 dhellmann: we also need to make sure that deprecation takes into account cross project concerns 20:46:47 hogepodge: ++ 20:46:54 hogepodge: the rule is just one of the things the tag mandates 20:47:10 See https://review.openstack.org/207467 20:47:10 ttx: I don't want to exclude clients and libs from backwards compat - its important there. I think though that the expression may be different 20:47:45 ttx: I'm still working up the discussion - as long as we can revisit the tag I think its fine today 20:47:46 lifeless: would you care to propose something on that ML thread ? 20:47:51 ttx: nope :) 20:48:02 lifeless: mmh, if we're following semver in libraries, shouldn't we just stick to that ? 20:48:06 lifeless: part of the issue with the client-libraries is that they're both application developer/api user client implementations and also cross-service communication libraries between openstack server components, and those use cases have clashed spectacularly in the past 20:48:10 ttx: in that - I don't think I've got a cogent holistic case to present yet 20:48:16 fungi: yes, I get that 20:48:18 ok, I'll make the poilicy service-specific and say something is cooking for libs 20:48:35 flaper87: this is orthogonal to semver 20:48:46 flaper87: we should totally still be following semver 20:48:47 ttx: ++, we can amend the policy to add lib stuff when we work out the details 20:48:51 ttx: ++ 20:49:09 lifeless: sorry, I probably just missed the context of what you were saying 20:49:10 lifeless: so the client libraries didn't actually avoid breaking anything ever, they just avoided user-facing breakage (and basically changed anything they wanted for server-to-server communication) 20:49:28 fungi: by user I think you mean CLI 20:49:39 fungi: anyhow, I'm familiar with the debate 20:49:44 cli and "cloud application development" 20:50:09 §b dmacpher-afk 20:50:19 * dhellmann squints at EmilienM 20:50:49 OK, last thing I wanted to mention is: 20:50:53 * No/Low/Danger-diversity tag name bikeshedding (https://review.openstack.org/218725) 20:51:07 dhellmann: sorry 20:51:10 PUce! 20:51:10 Another WIP tag, the one to signal fragile affiliation diversity, which has turned into a name bikeshedding contest 20:51:22 The argument is not really about the tag itself or how it was defined, but mostly on how much negative the name should be 20:51:22 fungi: dhellmann: and thers - started a etherpad at https://etherpad.openstack.org/p/branchless-clients-and-libs : I haven't put content in yet but will be doing so today 20:51:23 EmilienM: np, I just couldn't make out what that was, my client didn't like some of the unicode :-) 20:51:31 feel fre to weigh in, it's fun 20:51:58 ttx: (?) 20:52:04 ttx: I do not think you know what fun means :) 20:52:24 * dhellmann hands ttx a teddy bear 20:52:42 personally I think it's ok to be slightly negative, but apparently YMMV 20:53:11 ttx: small teams can be nimble and quick 20:53:14 anyway, that one is driven by jogo, to whom I extend my encouragements and thanks 20:53:15 i've been thinking about it a lot, and coming around to the thinking that negative tags may be more harmful than helpful 20:53:15 ttx: but yeah 20:53:48 annegentle: this is not a question of small, or fast. It's a question about the risk of not being there at all tomorrow. 20:54:02 russellb: +1 20:54:08 mostly because i want to be a more friendly and welcoming community, not one where you show up and get a set of "you're bad" labels 20:54:09 russellb: sorry, I mean -(-1) 20:54:12 heh 20:54:18 Those projects can be killed by the will of a single person, and it's not fair to expose our users to that risk without a warning sign 20:54:32 all projects are safe, but some are safer than others :) 20:54:37 ttx: hang on 20:54:49 ttx: Not all our users are equally sophisticated 20:54:58 ttx: Not all our users use things from git etc 20:55:12 edleafe: ++ 20:55:15 ttx: we have distributors and vendors who have direct relations with a huge fraction of our users 20:55:17 * jeblair wonders which person has this power... 20:55:18 russellb: I think welcoming also means taking on the challenge of us openly acknowledging a team is danger without making it too difficult to dig out of the hole we created by labeling them as at risk 20:55:49 I have osdreg up and breathing 20:55:50 jeblair: the CEO of the company who owns 99% development of a project can kill it. It happened before and will happen again 20:55:51 ttx: right, right 20:56:03 ttx: a very diverse project with deprecation periods stable releases and puppet guides may still be a bad choice for a user 20:56:09 "killed" is used liberally here. the project ceases to have development resources, but can be picked up by new contributors as soon as anyone cares 20:56:19 lifeless: but not for that reason 20:56:24 lifeless: it's not the only warning sigh. It's just "a sign" 20:56:28 anteaya, you go, grrl! 20:56:45 anteaya: nicely timed, btw :) 20:56:49 fungi: is anyone picking up MagnetoDB ? 20:56:54 lifeless: this is just another data point for them to evaluate 20:56:56 i think the projects which die because of a change in availability of development resources also had little to no user community 20:57:05 if that project did not have diversity before, it's unlikely to get it once it's killed ? 20:57:08 edleafe: so, I'm not debating *that* 20:57:10 anteaya: will resurrect any important dead projects 20:57:13 is it like guns don't kill people people kill people fungi ttx? 20:57:22 ttx: projects have had diversity and lost it 20:57:24 well, users don't necessarily means devs 20:57:25 jeblair: not sure about that 20:57:28 ttx: I've been involved in one such... 20:57:40 fungi: so how about a "lack-of-community-support" tag? :) 20:57:41 outside openstack, at least, it's not unusual for some company to stop development on an open source application and then the community forks or resumes development on it themselves 20:57:44 here's a suggestion 20:57:45 lifeless: not to the point of getting that tag, right ? 20:57:45 that's less negative 20:58:12 the brought-to-you-by sponsorship tag? 20:58:20 david-lyle: ha! 20:58:26 ttx: I have't checked the stats, but suspect its due to a couple of the spin-out tools keeping diversity, not the $project 20:58:28 flaper87: any sufficiently advanced free software user is indistinguishable from a developer ;) 20:58:41 The issue AIUI is that we want to say 'has not earnt tag X' 20:58:44 and make that discoverable 20:58:55 fungi: lol 20:59:08 no matter how you wrap it, it's a negative condition 20:59:12 I know, the rule for 'danger' was going to be lower than the rule for 'diverse' - but fundamentally we want to surface that there is a badge they haven't earnt. 20:59:15 so why don't we do that 20:59:18 lifeless: I don't think so. There is a space where the project is not diverse and still is not in danger 20:59:20 in the UI 20:59:28 ttx: I agree 20:59:30 those are different questions 20:59:32 show earnt and unearnt badges 20:59:32 1 minute warning 20:59:38 I kinda feel what we're discussing here is how to make it less negative when the condition itself is just bad 20:59:44 not necessarily the project's fault 20:59:44 I don't think its bad 20:59:45 edleafe: exactly, and recognizing that should be ok 20:59:50 I think its the starting point for things 20:59:54 start small and ramp up 21:00:32 anyway, more on that review! 21:00:35 lifeless: no one is arguing about that but rather that as lon as you're small, we need to commuicate that 21:00:37 time is up 21:00:44 * flaper87 hugs everyone 21:00:46 #endmeeting