=== salgado-afk is now known as salgado === mrevell is now known as mrevell-lunch [15:00] #startmeeting [15:00] Meeting started at 09:00. The chair is barry. [15:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:00] hello everyone and welcome to this week's ameu reviewers meeting. who's here today? [15:00] me [15:00] me [15:01] me [15:01] me [15:01] me [15:02] me [15:02] gary_poster leonardr bigjools salgado sinzui BjornT ping [15:02] me [15:02] me [15:02] me and hiya [15:02] * sinzui is still having problems with that cat [15:02] me [15:02] [TOPIC] agenda [15:02] New Topic: agenda [15:02] * Roll call [15:02] * Action items [15:02] * UI review call update [15:02] * ''Adding a check for pop-up help to reviews [mrevell]'' [15:02] * Test dependencies in setup.py [gary] [15:02] * "Have you added pop-up help? If not, why not?" [mrevell, barry] [15:03] * Peanut gallery (anything not on the agenda) [15:03] [15:03] [TOPIC] * Action items [15:03] New Topic: * Action items [15:03] * barry to get with mrevell on guidelines migration from old wiki to new [15:03] me [15:03] i have not done that, but i've pinged mrevell-lunch about it so maybe we'll actually chat about it today ;) [15:03] * intellectronica and barry to draft guidelines for drive-by cleanups [15:03] also not done, but i have a little more information [15:04] so i've been trying to use bzr-pipelines, which seem pretty cool (in a similar way as looms, but better). i do think they can help with drive-bys [15:05] but they aren't a perfect solution, mostly because diff'ing sometimes gets things wrong-ish [15:05] or at least not quite what you want [15:05] i was working on a branch, then realized i had some drive byes i should get independently reviewed [15:06] i created a lower pipe and merge -i 'd the changes into that branch [15:06] then i got the main branch reviewed and ask for a look at the drive byes in the same mp [15:06] this seemed to work well, except... [15:07] sometimes chunks produced by merge -i contained both drive by and substantive differences [15:07] in that case i just left them in the main branch [15:07] EOT. any thoughts, comments? [15:08] +1 on pipeline [15:08] gary_poster: have you used them? [15:08] +1 on getting the pipeline tweaked for what we need [15:08] Oh, that was an unfortunate time to walk in. Guess I'll read the notes. [15:08] abentley: hi. i was just relating my experience with pipelines wrt drive-byes [15:08] I've read about them. I've used looms. pipelines look good. I like abentley. ;-) [15:09] :-D [15:09] abentley: out of context, but... sometimes chunks produced by merge -i contained both drive by and [15:09] substantive differences [15:09] abentley: i don't know what if anything can be done about that [15:10] merge -i into something already containing the drive-bys? [15:10] abentley: no, sorry. merging into a new pipe [15:11] abentley: i'll try to post this to the mailing list, it's fine to respond there instead [15:11] barry: So this is just wanting better than per-hunk granularity. I have a branch for that. [15:11] abentley: oh! yes, and once again, you rock [15:11] see? :-) [15:12] :-D [15:12] abentley: thanks. let's move on then... [15:12] * ''Adding a check for pop-up help to reviews [mrevell]'' [15:12] mrevell-lunch: are you around? [15:13] i guess not [15:13] anyway, my understanding of this is that mrevell-lunch wants us to ask about adding pop-up help when reviewing a branch [15:13] he says it's easy to add [15:14] i'll leave this on the agenda for now though in case he wants to say more [15:14] * Test dependencies in setup.py [gary] [15:14] gary_poster: you're up [15:14] I sent an email Oct 8 about "test what you fly, fly what you test". The subject was "Including test dependencies in our package releases," sent to the launchpad-dev list. It only started getting replies yesterday (thanks barry!). [15:14] I won't repeat it here unless someone requests it. It would be nice to have a consensus that what I proposed is our expected/desired approach for our standalone libraries. [15:14] I'm hopeful it is not contentious, since the only concrete reply was Barry's, which seemed to agree with me. Maybe we can agree now, or maybe we can give the email another week for replies, and then declare it policy. [15:14] Thoughts? [15:15] * barry only thought is that gary_poster types fast [15:15] :-) [15:15] gary_poster: In the absence of a recognized test-dependencies concept, I'm all for it. [15:16] me too [15:16] abentley, we can do that. setuptools and/or distutils has that support. So perhaps there's room for contention afterall. [15:16] after all [15:16] In my latest release for another project, is did this because the user are willing to provide good debugging information if you remove the barriers [15:16] +1 to more contention. [15:16] heh [15:16] * jml relurks [15:16] s/is/I/ [15:16] gary_poster: So, it worries me that we might depend on something without having deliberately chosen to. [15:17] gary_poster: But it's more of a theoretical thing. === mrevell-lunch is now known as mrevell [15:18] abentley: "we" the user of the library, or "we" the creator of the library? Not quite sure I understand [15:18] gary_poster: We the user of the library. [15:18] gary_poster: I think the problem here is the dependency can be large, or complex. In my case, I had to use fakes to make the test deps portable. I do not think we want to do this. (but man, is the test fast!) [15:18] gary_poster: For example, I'd be scared if Mocker was a real dependency of Launchpad. [15:19] gary_poster: But if it was a test dependency, that would be fine. [15:19] abentley: how would that work in practical terms? when would the dependencies get pulled in? [15:20] abentley: I can understand that from a theoretical perspective. From a practical perspective, if we regard automated tests as our primary tool for quality (as opposed to, say, manual QA) then I don't see a way around it [15:20] that is [15:20] I don't see a reasonable way to guarantee that Mocker is a test dependency and not a "real" dependency [15:21] barry: Sorry, I didn't even know setuptools supported test dependecies. I certainly don't know how they work. [15:21] You said "But it's more of a theoretical thing," so does that mean we are on at least similar pages? [15:22] gary_poster: Yes, it's more of a niggle than a real concern. [15:22] cool [15:22] and understood [15:23] gary_poster, abentley thanks. for now, i think we're agreed including the test dependency (in the usual case) is about the best we can do [15:23] cool [15:23] mrevell: is !away. mrevell do you want to have a word about pop-up help? [15:24] Hi barry, sorry I had to run out. Yes, I'd love to please if that's okay. [15:24] My apologies. [15:24] mrevell: no worries, and the floor is yours [15:24] I'd like to propose that a check for in-line help be added to code reviews. Maybe it should be ui reviews. [15:25] I think that when we add a new [15:25] feature/page we should consider whether everything on that page is self-evident to our less-experienced users. [15:25] If not, we should consider adding in-line help using the pop-up system. I'd be more than happy to write that help or review any help. [15:25] Any thoughts? [15:26] mrevell: +1 [15:26] Great :) Heh. [15:26] mrevell: i had a review last week (maybe bac's branch?) where i asked for a popup help. mrevell tell them how easy it is to add such help [15:27] barry: Ah yes, it is very easy indeed. [15:27] All you have to do is add an HTML file in the right place (there's a template and there are instructions at [15:27] https://dev.launchpad.net/PopUpHelp) [15:27] and then place a link in your page with a target of "help" [15:28] that automatically brings in the JS to create the pop-up and call in your help page in that pop-up. [15:28] So, I'd like to say that I see this as a real priority for my time so if you need my help or review or whatever when producing pop-up help, please do ask me. [15:28] I have used this. It is very easy to create help [15:28] Or suggest that the person whose branch you're reviewing contact me. [15:29] mrevell: how would you like to flesh out https://dev.launchpad.net/DeveloperDocumentation/UserInterfaceChecklist which is linked off of https://dev.launchpad.net/StyleGuides but empty? [15:29] barry: I'll do that! Thanks very much everyone. [15:30] mrevell: thanks! [15:30] [ACTION] mrevell to flesh out UserInterfaceChecklist [15:30] ACTION received: mrevell to flesh out UserInterfaceChecklist [15:30] [TOPIC] peanut gallery [15:30] New Topic: peanut gallery [15:30] that's all i have for today. do you have anything on your mind? [15:31] Does anyone else find they're creating a lot of HTML fragment URLs? [15:31] yeah [15:31] well, i did in the past, but there's plans for more of them [15:32] I think it would be nice if we could retrieve particular IDs as HTML, or maybe address views directly. [15:32] By particular ids, I mean HTML IDs. [15:32] abentley: what do you mean by 'retrieve particular IDs'? [15:32] mrevell: there might be some overlap between that UI checklist page above and https://dev.launchpad.net/UI/Reviews [15:32] ah, you mean addressing an element within a page on the server? [15:33] So where you have