=== lifeless_ [n=robertc@dsl-28.7.240.220.rns01-kent-syd.dsl.comindico.com.au] has joined #launchpad-meeting === SteveA [n=steve@195.182.78.95] has joined #launchpad-meeting === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad-meeting [11:57] Meeting in two minutes === jamesh [n=james@203-59-208-190.dyn.iinet.net.au] has joined #launchpad-meeting [12:00] MEETING STARTS [12:00] Luckily there's no .it in this meeting. [12:00] * roll call [12:00] * SFTP and knit advertising [12:00] * vcs-import knits [12:00] * branch scanner latency [12:00] * cscvs/bzr-native [12:00] * supermirror branch browser [12:00] * private branches [12:00] * critical bugs [12:00] * pending sysadmin tasks [12:00] * any other business [12:00] Hu [12:00] That is the Bazaar meeting, for all things Launchpad and Bazaar, of course. [12:01] Hu [12:01] * Roll call! [12:01] hi [12:01] jamesh: lifeless: spiv: ping [12:01] mpool: #launchpad-meeting [12:01] argh [12:02] Sorry, the infra guys are late. [12:02] we're almost done with the infrastructure meeting [12:02] so don't wait [12:03] I'm here [12:03] Okay, so 'vrybuddy's here except mpool. [12:03] here [12:03] * SFTP and knit advertising [12:03] After the initial blog entry, I planned to blog about [12:03] - team shared branches [12:03] - using checkouts (aka bound branches) [12:03] I have no time for that, I'd like somebody to write a blog about that, and I'll link from ddaa.net. === mpool [n=mbp@ozlabs.org] has joined #launchpad-meeting [12:04] hi there [12:04] Anybody volunteers for blogging about team-shared branches on launchpad.net and using heavy checkouts on them? [12:05] ddaa: did you tell jdub about your initial blog entry? [12:05] Not personally, I think. But I posted to the warthogs@ mailing list. [12:05] ddaa: do contact jdub personally [12:05] I mentioned your first blog entry in my blog [12:06] although it is good that you also mailed warthogs [12:06] ddaa: is there a plan to do anything else about it beyond blogging? [12:06] ACTION: ddaa to tell jdub [12:07] mpool: mh... that's a good question. Probably, when we have something good we could put that on launchpad.net/bazaar [12:08] but ATM blogging seems like a good way to get the stuff written in the first place [12:08] I could write an article about team shared branches if no one else is [12:08] jamesh: that would be most cool [12:09] jamesh: I think you win that one :) [12:09] I'll send a draft through to the list before hand [12:09] we should make sure to get at least something small and more formal onto the site [12:09] even if it's just "branches can be hosted here, see ddaa's blog" [12:09] I dont think formal matters [12:09] mpool: https://launchpad.net/bazaar [12:09] I think discoverable matters [12:10] agree [12:10] whereever there is a 'branch' there should be a emblem for help or something, which if followed will educate [12:10] ddaa, that looks good [12:11] There is work to link to that branch from interesting bug pages in one of my bazaar-ui branches. [12:12] ddaa: just land it! [12:12] But it's part of the "controversial" stuff that I never got around comitting. And that frankly I'd rather not dust off right now (largely because of context switching). [12:12] then give it to someone else to land [12:12] don't just sit on it [12:12] it is wasted work in that case [12:12] why do you say "controversial" ? [12:13] mpt had comments, I thought they were good comments, but you asked me to postpone acting on it for two weeks, about two months ago [12:13] good UI takes time [12:13] that we lack [12:14] we had a meeting [12:14] we also agreed that with UI stuff, just fucking land it [12:14] of review team [12:14] and then lp team [12:14] https://chinstrap.ubuntu.com/~jamesh/pending-reviews/david/launchpad/bazaar-ui/full-diff [12:14] where we said 'ui stuff LAND first, review SECOND' [12:15] as in, code review only, not ui review. [12:16] if it doesn't land, it has wasted your time in doing the code, and the reviewers' time in reviewing UI and code [12:16] it's conflicted, some of mpt comments still need addressing, it's unfinished work dangit [12:16] mpt's comments can be addressed later, and lifeless and I have just said [12:16] lifeless more eloquently than I [12:16] but I win the award for the most creative use of the word "fuck" in a serious launchpad meeting [12:16] fuck you [12:17] :) [12:17] So, somebody please merge david/launchpad/bazaar-ui [12:18] spiv: do you have time to do this? [12:18] I think so. [12:18] It doesn't look outrageously large... [12:18] I'll let you know if I don't :) [12:19] ddaa: add mpt's comments to a todo list [12:19] mpool: you mean a bug? [12:19] either a bug, or just your personal list of things to do [12:19] spiv: ta [12:20] ACTION: spiv to try landing david/launchpad/bazaar-ui/ [12:20] ACTION: ddaa to file a bug with mpt comments about ui [12:20] pff [12:20] cat comments > /dev/null :( [12:20] Moving on. [12:20] * vcs-imports knits [12:20] https://launchpad.net/products/launchpad-bazaar/+bug/49449 [12:20] Rolled out new bzrlib to importd. Will process some outstanding VCS import request [12:20] https://launchpad.net/products/launchpad-bazaar/+bug/52313 [12:20] that will hopefully allow me to check that new importd branches are indeed published in knits. [12:20] I think conversion of existing branches could be done by importd, before pushing to escudero. Plan to do sometimes after finishing bzr-native. [12:20] ACTION: ddaa to file bug about converting existing vcs-import branches to knits. [12:21] If you think that converting vcs-imports to knits is very important and urgent, please scream now. [12:21] I sent you a summary of which vcs-imports branches were being used, to give an idea of which ones would be a priority [12:22] jamesh: AFAICT, that means the use of system is near-zero [12:22] except for Kamion and a couple other ubuntu guys [12:22] well, we don't exactly advertise it [12:22] which is find, since it is not exactly painless [12:23] the idea was just to put the branches people are using at the head of the conversion queue [12:24] jamesh: considering the level of use the system is seeing, I think having a separate conversion process is too much work. [12:24] better to get the thing churn conversions for one week and be done with it [12:25] ddaa: I wasn't suggesting a separate process -- the suggestion was to tweak the ordering [12:25] that infra will also be useful for future conversions, hopefully at that point we'll have better system and we'll be able to just plug in more slave for this sort of load peaks. [12:26] focus please [12:26] conversions are not the most important thing to do [12:26] (given the usage stats) [12:26] right, so let's move on [12:26] new branches are knits already. So lets move on. [12:26] * branch scanner latency [12:26] Jamesh has merged out a patch to let the branch puller record more information, and let the branch scanner use it to save uncessary work. However, it broke the branch scanner on rollout. [12:26] Jamesh has a branch in review to fix the breakage, and move the bzrsync code and tests out of lib/importd. So it will use the normal test runner and get proper Zope utility setup. [12:26] No other comment there, jamesh appears to be on top of the situation. Thanks. [12:27] * cscvs/bzr-native [12:27] ddaa will put a branch for review that uses bzr in all CVS-based tests. Still need one (subversion tests) or two (shell tests?) more iterations of test refactoring after that. [12:27] No other comment there, either. [12:27] * supermirror branch browser [spiv] [12:27] https://launchpad.net/products/launchpad-bazaar/+bug/49991 [12:27] Hi spiv. How is that going? Anything blocking you? [12:27] I think the shell tests can be nuked now [12:28] lifeless: okay, I'll check whether they do something more than the unittests (which have less than complete coverage for some cvs stuff) [12:28] ddaa: no progress at all, I've got a note to talk to Steve about it, but until today he was at EP. [12:29] cool, hopefully you'll get some of SteveA's time soon :) [12:29] spiv: what do you need from me? [12:30] SteveA: I can't recall what I had in mind originally, to be honest. Basically a pre-impl call, though. [12:31] spiv: okay. today or tomorrow is good for me. [12:31] * private branches [12:31] In an unexpected move, lifeless specced out private branches [12:31] https://launchpad.net/products/launchpad-bazaar/+spec/private-branches [12:31] I am still supposed to review that. Will try to do Tuesday or Wednesday. [12:31] ACTION: ddaa ro reviews spec/private-branches [12:31] SteveA: I may ping you after review team meeting, depending on when I make dinner, otherwise tomorrow. [12:31] everybody else here more than welcome to review it too [12:31] spiv: ok [12:32] Is it acceptable to put feedback on the end of the wiki page, or is there a facility in the spec system I should use? [12:32] private branches are important so that we can get launchpad and other internal projects using "The Bazaar" features in launchpad [12:32] wiki page - reviewer questions area [12:32] spiv: put it in the wiki page at the end [12:33] Ok. [12:33] it should be "reviewer comments" [12:33] Anybody else interested in reviewing and not having a review request already? [12:33] okay, moving on [12:33] i'll read it [12:33] * critical bugs [12:33] Four critical bugs on launcpad-bazaar: [12:33] - bug 31308: Cannot set branch associated to a product series. https://launchpad.net/products/launchpad-bazaar/+bug/31308 [12:33] Talked about that in Vilnius. Three states for a productseries: nothing, vcs import, native branch. That requires a spec to define the behaviour for all the possible transitions. Lifeless said he would do it. [12:33] lifeless are you still hot? [12:33] but i was present during its conception [12:34] It doesn't look outrageously large... === ddaa pokes lifeless with a stick [12:35] it looks lifeless... [12:36] sorry [12:36] ELYNNE [12:36] There's nobody else I think is familiar enough with the corner cases of that issue. [12:36] yes, Iw ill be doing the spec for that [12:37] ACTION: lifeless to spec for bug 37897 [12:37] - bug 37897: renaming project, product or series breaks vcs imports https://launchpad.net/products/launchpad-bazaar/+bug/37897 [12:37] Talked about that in Vilnius. Will add importd_slave column in ProductSeries to record which importd system currently own the persistent data. Existing records will be inited using the current job-name-hashing logic. New records will be given to slave with the least jobs. Simple interim measure. [12:37] ACTION: ddaa to spec short term and long term fix for that bug in excruciating detail [12:37] I still need hands to implement that in the short term. [12:38] Want to do it since it's overlaps with the bzr-native and importd-ng roadmaps. [12:38] (which I reckon are only in my head, and somewhat fuzzy) [12:38] Thought lifeless certainly has some very strong opinions on that too :) [12:39] - bug 51130: cannot use +admin on a branch I own https://launchpad.net/products/launchpad-bazaar/+bug/51130 [12:39] I suggest: [12:39] + edit Branch.name and Branch.product on branch/+edit [12:39] + edit Branch.owner on branch/+reassign (like product), call the action link "Change Owner" or something, but _not_ "Change Maintainer" as it is currently on the product page. [12:39] If you like that, I'll comment on the bug and try to get somebody to do it. That should be fairly easy. [12:40] Does everybody like that plan? [12:40] The rational for +reassign, is that it's something the user cannot undo, and that it is a very rare operation. It should be hard to do by mistake. [12:41] (lookng) [12:41] Should be a good place to make team-shared branches discoverable, too. [12:42] ddaa: that sounds reasonable [12:42] is there any decision on changing the url, or is that a different bug? [12:42] changing what url? [12:42] or does that remain under +admin [12:43] changing the real url of the branch [12:43] that's currently under +edit AFAIK [12:43] I think all the fields the user can edit should be in +edit [12:43] no bug here that I'm aware of [12:43] and admin only fields in +admin [12:43] ok [12:43] lifeless: sure, branch/+admin will go away too. [12:43] but this is nikeshedding [12:44] okay [12:44] * pending sysadmin tasks? [12:44] lifeless: not reebokshedding? ;) [12:44] what matters is letting users change fields they should be able to. [12:44] lifeless: the way we present that functionality matters a lot too. [12:45] Nobody is blocked on sysadmining? [12:45] I have a new item for end of meeting [12:45] Cool [12:45] * Any other business? [12:45] I've got the cscvs support for Subversion symlinks up for review [12:46] so that should fix some imports once landed [12:46] mh [12:46] I'm on vacation from tuesday to monday [12:46] So I'll likely look at it and roll it out next week. [12:47] It hasn't been reviewed yet, but I can delay landing it til you look over it if you'd prefer. [12:47] jamesh: please get it reviewed [12:47] I just want to sanity check the code for logic holes [12:47] but I trust that I will find nothing to complain about. [12:47] ddaa: I wasn't planning on taking it off the queue. Just asking if you wanted me to delay landing it after review [12:48] i'm planning to write some braindump specs for [12:48] jamesh: nope please land it ASAP [12:48] branch viewing, review on launchpad and so on [12:48] jamesh: thank you for asking [12:48] ddaa: okay. [12:48] just to start making plans for future features and so we can prioritise them [12:49] should have something for folks to read in the next week or two [12:49] just an advance warning [12:49] sounds useful, along with private branches that will make a useful roadmap [12:50] mpool: if you feel like it, I'd love a spec about email subscription to branches [12:51] that's a cool feature we've been promising forever [12:51] ok guys. [12:51] this meeting is now late. and I have another in 9 minutes [12:51] lifeless: you said you had something to add [12:51] I'm going to jump in now with my new item [12:52] which is, these meetings should be about decisions not planning [12:52] ddaa: that'd be good [12:53] I'd really like to see us move discussion about solutions, about whether things are right or wrong, to the usual channels: specs, the lp mailing list, bugs. [12:53] lifeless: ok - and do what here? [12:54] mpool: Status of tasks; assignment of tasks; [12:54] changes in policy; changes in priority that needs dispersement ot the team. [12:54] ACTION: mpool to braindump specs for branch viewing, reviews, email subscription, and so on [12:55] ACTION: jamesh get svn-symlinks reviewed and landed [12:55] ACTION: ddaa to sanity check svn-symlinks and roll out [12:55] the reason being that we can literally spend 2 hours talking over a feature, holding 6 people here, when in fact, its fine grained ui tweaks best discussed in a small group with mpt. Or best mocked up and tested. [12:56] etc etc [12:56] sure [12:56] ACTION: ddaa, to set up a wiki page for this meeting's agenda [12:56] and write the agenda on it [12:56] that gives other an opportunity to comment whether the agenda is actually appropriate for everyone [12:56] lifeless: okay, I'll refrain from "does everybody agree" sort of question in the future [12:57] ddaa: if it needs consensus, then perhaps do this: [12:57] 1) assign everyone a task to review the 'thing' [12:57] SteveA: well, the agenda is usually carried over from one week to the next with only minor changes [12:57] 2) the next week, the thing is reviewed, or not and it continues on. [12:57] ddaa: good. then the wiki page will require little maintenance [12:58] SteveA: okay, I see what you mean. [12:58] lifeless: okay [12:58] 5 [12:58] 4 [12:58] ddaa: A wiki page also gives a place to register apologies, e.g. if someone is on leave. [12:58] 3 [12:58] 2 [12:58] 1 [12:58] MEETING ENDS [12:59] thank you everybody, sorry for being late [12:59] you can now run to the reviewers meeting === ddaa [n=ddaa@nor75-18-82-241-238-155.fbx.proxad.net] has joined #launchpad-meeting === danilos [n=danilo@147.91.15.54] has joined #launchpad-meeting [05:32] hi danilos === carlos_ [n=carlos@222.Red-88-9-27.dynamicIP.rima-tde.net] has joined #launchpad-meeting [05:33] hi [05:33] hi SteveA, carlos_ [05:34] hi carlos [05:34] okay, let's go [05:34] I was away at a conference last week [05:34] so I'm a little behind the times [05:34] ok [05:34] so, first of all, carlos, please say a few things about what you've been working on this past week or so [05:35] and what's coming up next [05:35] danilos: how long do you have here? [05:35] SteveA: well, 20 minutes or so: don't want to be late since it takes me at least 30 minutes to get to the embassy [05:36] Last week I did some work on translation migrations from breezy to dapper and edgy opening to be translated [05:38] (I'm going to play a little dumb... will explain why shortly) [05:38] carlos: so, what's the benefit of that? [05:39] well, that will make us to have all translations from breezy applied to dapper [05:39] and also, get edgy open to translate with exactly the same status we have in dapper [05:39] (a guess: to help me get a feel for what is it I am actually going to be working on? :) [05:39] is that done on a string-by-string basis? [05:39] yes [05:39] okay, cool [05:40] so, what happens to the new messages in a POT? [05:40] (that's one reason. another is that we should all be always ready to explain *why* we're doing a particular piece of work. and to explain it clearly.) [05:40] if we got a new translation for dapper, we don't change that translation, we only change the ones that are still using the translations from upstream [05:40] or empty ones [05:41] (and carlos is doing a pretty good job at that here.) [05:41] ok [05:41] that's a workaround until we implement the TranslationReviews and MulticastTranslations specs [05:42] is the migration all done? [05:42] or is there still more work to do on it? [05:42] (ok, sounds perfectly reasonable) [05:42] as Andrew already stated with the preimplementation call report [05:42] i'm behind on reading that email [05:43] SteveA: I did most of the migration already. I had a small problem with duplicate rows, but that's already fixed (talking about edgy opening) [05:43] SteveA: the breezy -> dapper path is only started atm [05:43] SteveA: yeah. [05:44] are you continuing with this migration work? [05:44] yes [05:44] ok [05:44] so, for stuff that danilo can do, I can think of three options [05:44] can I chip in with some questions, or should I hold them for later? [05:44] 1. danilo can help you out with this [05:44] 2. danilo can work on some other feature [05:44] 3. danilo can choose some outstanding rosetta bugs to work on [05:44] ah, ok, there you go in involving me as well [05:44] I propose 3 for now [05:45] I think 3. is also a good start [05:45] sounds fine to me as well [05:45] ok. [05:45] do we have time to pick off some bugs now? [05:45] like, to choose them from the list [05:45] we have a lot of small bugs/features to implement that could help you to understand a bit better how launchpad/rosetta works [05:45] I think so [05:45] https://launchpad.net/products/rosetta/+bugs [05:46] that's the list of bugs on Rosetta [05:46] was just heading there; though, my request for account hasn't been responded to yet [05:46] what kind of account? [05:46] chinstrap? [05:47] yup [05:47] what's the RT number? [05:47] and email alias (not that it's that important) [05:47] hum, haven't received anything: maybe my email setup is broken [05:47] did you mail RT? [05:47] you should get a confirmation email [05:48] yup, as outlined on https://wiki.canonical.com/NewStaffTasks [05:48] but, no need for chinstrap access to get started [05:48] all you need is the bzr branch data [05:48] I could provide you a copy [05:48] also, none of my mailing list subscriptions got approved yet [05:48] for example, carlos could tar up rocketfuel-built [05:48] ah, ok, great [05:49] and stick it on chinstrap's public_html [05:49] yeah, and I've already installed launchpad-dependencies [05:49] for you to download [05:49] sure, that's no problem then [05:49] but do check out your email configuration [05:49] I think this bug would be a good start. It's quite trivial: https://launchpad.net/products/rosetta/+bug/1788 [05:50] you can put bug fix diffs into a pastebing [05:50] pastebin [05:50] on chinstrap [05:50] and add that to the pending reviews page [05:50] until you have a chinstrap accoiunt [05:50] danilos: do you know the pastebin url on chinstrap? [05:50] danilos: https://chinstrap.ubuntu.com/~dsilvers/paste/ [05:51] hum, I am not yet sure what "pastebin" is? [05:51] danilos: it's a kind of clipboard using the web [05:52] yeah, already looking at the link [05:52] so you can 'paste' something there and will get a URL to paste on IRC so other people can see the information you want to share [05:52] that one on chinstrap is protected with a password so we can use it for confidential data [05:53] ok [05:54] I think we're sorted. Danilo, ask on irc about anything you need in the code. [05:54] yeah, ok, so "pastebin" it is [05:54] We'll talk tomorrow and see how things are going. [05:54] check that you have an RT request in for the chinstrap account [05:54] no problem, I'll work with carlos and #launchpad [05:54] danilos: I will prepare now a tarball of rocketfuel and send you the URL to download it [05:54] when I have the RT number, I can check how that's going with the admins [05:54] btw, #launchpad-dev seems to be empty even if it's mentioned in the wiki? [05:54] that is out of date [05:54] please update the wiki page you found that on [05:55] danilos: we just use #launchpad [05:55] RT ID #13702 (just resent it now) [05:55] danilos: you mean you send a new request [05:56] and got back that RT number? [05:56] yup [05:56] the previous ones ended up without response [05:56] but I changed my mail set-up, maybe that caused the problem [05:58] ok, I'll be updating https://wiki.canonical.com/MessagingSystems and removing references to #launchpad-dev; I'll also remove the "users" bit describing "#launchpad" if that's correct? [05:58] woops, I guess #launchpad is actually for users as well, and no password? [05:58] and carlos, please recommend 8 bugs for danilo to do [05:58] danilos: #launchpad is for users and developers, yes [05:59] SteveA: ok [05:59] carlos: can you also prepare a tarball for me to download once I get back from embassy? [05:59] or in the morning at the latest [06:00] karl said your account will be sorted pretty soon. i expect in the next day or so. [06:00] SteveA: ok, thanks [06:00] danilos: I'm doing it atm [06:01] cool. let's talk tomorrow and see how things are going. [06:01] good luck at the embassy, danilo [06:01] ok, great; I am off to the embassy now, just email me to danilo@kvota.net whatever needs emailing for the time being :) [06:01] yeah, good luck! [06:01] thanks SteveA === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has joined #launchpad-meeting [06:06] hi [06:06] hi [06:06] so, I read the spec [06:07] and these are good thoughts of refactoring [06:07] kiko and you spoke of caveats? [06:07] I would point out that IDistribution shouldn't extend ITicketTarget [06:08] but, according to our current conventions, Distribution should implement both ITicketTarget and IDistribution [06:09] that's a minor point [06:09] on to the other general issues [06:10] launchpad started off using lots of components, like this [06:10] and until recently, we were using this pattern in rosetta for IRosettaStats [06:10] you're talking about adapters? [06:11] to experienced zope people such as you and me, using a bunch of components like this is easy to understand [06:11] yes, an adapter is a kind of component [06:12] but to some of the more junior developers, and to Mark, it was confusing -- the functionality for a particular thing was split across many files, many places to look, much to understand to maintain things [06:12] so, Mark refactored the code into much larger classes / units of functionality [06:12] this had a good effect, and a bad effect [06:13] interesting, this is exactly the problems I mentioned in my spec... [06:13] the good effect was that more of the developers on launchpad got to understand more of the code, so better shared ownership of all the code [06:13] right -- see, complexity and amount of things to look at can be seen in different ways [06:13] indeed [06:14] number of components / amount of responsibility per component / amount of "glue" binding the components / amount of explicit vs implicit glue [06:14] so, this brings us to the situation today [06:14] I think we went too far in the "big clumps of things" direction [06:14] so I want us to go back in the other direction a bit [06:15] but before we do so, I want to fix a number of things about how we use Zope and the component architecture [06:15] to do with defining interfaces and adapters, and hooking these things up [06:15] this is consistent with the direction of zope3 [06:15] but I want us to get there earlier than zope3 will [06:15] what are those number of things? [06:16] when we have less overhead in the "glue" and in registering adapters, and defining interfaces, and doing security [06:16] then there will be less cost in dividing things into smaller units [06:16] so we'll be able to afford slightly smaller units [06:16] and so get some of those benefits, without the costs we'd pay today [06:17] i'm not familiar with the way security is hooked in launchpad, so I guess i'm not yet able to evaluate the cost of this glue [06:19] things like, for making a change in distribution: [06:19] - edit interface [06:19] - edit tests [06:19] - edit zcml perhaps [06:19] - edit security adapters perhaps [06:20] or, to write a new content object [06:20] - write interface [06:20] - write tests [06:20] - write implementation [06:20] - write zcml [06:20] - write security [06:21] these things don't sound like much, but they use up too many of the "working memory slots" a person has [06:21] some people have more than others -- some people are accustomed to keeping many things on the go at once [06:21] others work much better with fewer things to keep in mind [06:21] how could this list be really shortened? [06:22] - write tests [06:22] - write implementation [06:22] and the security, interface and zcml is done unobtrusively and elegantly in the implementation [06:23] with a kind of declarative API? [06:23] now, we don't need to get all the way there to make better use of adapters or better patterns for xxxxTarget stuff [06:23] we have spec targets, bug targets, support targets [06:23] it is a common pattern [06:24] as you point out in that spec [06:25] and I think we will refactor launchpad like that [06:25] but not today. [06:25] ok, message received :-) [06:25] I'd like you to help me with experiments in this direction in about two weeks [06:25] I have a mgt meeting in 1 week [06:25] that would be my pleasure! [06:25] then the week after that a rosetta/bzr sprint [06:25] then a week in vilnius [06:25] then the lazr sprint [06:26] in the week in vilnius, if there's time, we should look at this issue again [06:26] and work it into the lazr plans... if I have time [06:26] if not, it'l lhave to wait until after the lazr sprint [06:26] great! I'll refresh your memory on the 24th :-) [06:26] ok, cool [06:27] it's been a learning experience for me. on launchpad, seeing the different ways people think about components [06:27] and what different people find easier to maintain and understand [06:28] yes, I'm quite aware that simplicity and complexity is really a function of one's background [06:29] thanks for the background perspective === flacoste [n=francis@modemcable207.210-200-24.mc.videotron.ca] has left #launchpad-meeting ["Bye"] === jamesh [n=james@203-59-20-109.dyn.iinet.net.au] has joined #launchpad-meeting