= ReviewerMeeting20091014 = == summary == * bzr pipelines are cool and we love abentley for making them cooler all the time (more granularity for merge -i) * except in extreme cases, we'll include test dependencies in the packages we release * when doing ui reviews, see if popup help would improve things. they're easy to add * mrevell to flesh out UserInterfaceChecklist about popup help == logs == === ameu === {{{ 10:00:09 > barry: #startmeeting 10:00:11 < MootBot: Meeting started at 09:00. The chair is barry. 10:00:11 < MootBot: Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] 10:00:24 > barry: hello everyone and welcome to this week's ameu reviewers meeting. who's here today? 10:00:33 < allenap: me 10:00:34 < noodles775: me 10:01:22 < EdwinGrubbs: me 10:01:22 < gmb: me 10:01:40 < intellectronica: me 10:01:55 < bac: me 10:02:04 > barry: gary_poster leonardr bigjools salgado sinzui BjornT ping 10:02:12 < sinzui: me 10:02:14 < salgado: me 10:02:17 < gary_poster: me and hiya 10:02:26 < * sinzui!n=sinzui@pool-71-163-158-16.washdc.fios.verizon.net is still having problems with that cat 10:02:35 < leonardr: me 10:02:41 > barry: [TOPIC] agenda 10:02:43 < MootBot: New Topic: agenda 10:02:45 > barry: * Roll call 10:02:45 > barry: * Action items 10:02:45 > barry: * UI review call update 10:02:45 > barry: * ''Adding a check for pop-up help to reviews [mrevell]'' 10:02:48 > barry: * Test dependencies in setup.py [gary] 10:02:51 > barry: * "Have you added pop-up help? If not, why not?" [mrevell, barry] 10:02:54 > barry: * Peanut gallery (anything not on the agenda) 10:02:58 > barry: 10:03:02 > barry: [TOPIC] * Action items 10:03:03 < MootBot: New Topic: * Action items 10:03:06 > barry: * barry to get with mrevell on guidelines migration from old wiki to new 10:03:10 < adeuring: me 10:03:29 > barry: i have not done that, but i've pinged mrevell-lunch about it so maybe we'll actually chat about it today ;) 10:03:37 > barry: * intellectronica and barry to draft guidelines for drive-by cleanups 10:03:47 > barry: also not done, but i have a little more information 10:04:42 > barry: 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 10:05:06 -!- andrea-bs!n=andrea@ubuntu/member/beeseek.developer.andrea-bs has quit [Remote closed the connection] 10:05:09 > barry: but they aren't a perfect solution, mostly because diff'ing sometimes gets things wrong-ish 10:05:19 > barry: or at least not quite what you want 10:05:38 > barry: i was working on a branch, then realized i had some drive byes i should get independently reviewed 10:06:02 > barry: i created a lower pipe and merge -i 'd the changes into that branch 10:06:24 > barry: then i got the main branch reviewed and ask for a look at the drive byes in the same mp 10:06:32 > barry: this seemed to work well, except... 10:06:57 > barry: sometimes chunks produced by merge -i contained both drive by and substantive differences 10:07:06 > barry: in that case i just left them in the main branch 10:07:12 > barry: EOT. any thoughts, comments? 10:08:08 < gary_poster: +1 on pipeline 10:08:17 -!- abentley!n=abentley@CPE001a7046c8f9-CM001e6b233d5a.cpe.net.cable.rogers.com has joined #launchpad-meeting 10:08:19 > barry: gary_poster: have you used them? 10:08:20 < gary_poster: +1 on getting the pipeline tweaked for what we need 10:08:41 < abentley: Oh, that was an unfortunate time to walk in. Guess I'll read the notes. 10:08:53 > barry: abentley: hi. i was just relating my experience with pipelines wrt drive-byes 10:08:54 < gary_poster: I've read about them. I've used looms. pipelines look good. I like abentley. ;-) 10:09:01 > barry: :-D 10:09:18 > barry: abentley: out of context, but... sometimes chunks produced by merge -i contained both drive by and 10:09:18 > barry: substantive differences 10:09:41 > barry: abentley: i don't know what if anything can be done about that 10:10:23 < abentley: merge -i into something already containing the drive-bys? 10:10:46 > barry: abentley: no, sorry. merging into a new pipe 10:11:08 > barry: abentley: i'll try to post this to the mailing list, it's fine to respond there instead 10:11:25 < abentley: barry: So this is just wanting better than per-hunk granularity. I have a branch for that. 10:11:40 > barry: abentley: oh! yes, and once again, you rock 10:11:48 < gary_poster: see? :-) 10:11:55 > barry: :-D 10:12:03 > barry: abentley: thanks. let's move on then... 10:12:09 > barry: * ''Adding a check for pop-up help to reviews [mrevell]'' 10:12:14 > barry: mrevell-lunch: are you around? 10:12:54 > barry: i guess not 10:13:23 > barry: anyway, my understanding of this is that mrevell-lunch wants us to ask about adding pop-up help when reviewing a branch 10:13:30 > barry: he says it's easy to add 10:14:21 > barry: i'll leave this on the agenda for now though in case he wants to say more 10:14:29 > barry: * Test dependencies in setup.py [gary] 10:14:34 > barry: gary_poster: you're up 10:14:35 < gary_poster: 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!). 10:14:36 < gary_poster: 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. 10:14:36 < gary_poster: 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. 10:14:36 < gary_poster: Thoughts? 10:15:18 > * barry only thought is that gary_poster types fast 10:15:23 < gary_poster: :-) 10:15:32 < abentley: gary_poster: In the absence of a recognized test-dependencies concept, I'm all for it. 10:16:13 > barry: me too 10:16:20 < gary_poster: abentley, we can do that. setuptools and/or distutils has that support. So perhaps there's room for contention afterall. 10:16:21 < gary_poster: after all 10:16:25 < sinzui: 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 10:16:32 < jml: +1 to more contention. 10:16:36 < gary_poster: heh 10:16:36 < * jml!n=jml@canonical/launchpad/jml relurks 10:16:40 < sinzui: s/is/I/ 10:16:49 < abentley: gary_poster: So, it worries me that we might depend on something without having deliberately chosen to. 10:17:10 < abentley: gary_poster: But it's more of a theoretical thing. 10:17:17 -!- mrevell-lunch is now known as mrevell 10:17:56 < gary_poster: abentley: "we" the user of the library, or "we" the creator of the library? Not quite sure I understand 10:18:12 < abentley: gary_poster: We the user of the library. 10:18:41 < sinzui: 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!) 10:18:50 < abentley: gary_poster: For example, I'd be scared if Mocker was a real dependency of Launchpad. 10:19:08 < abentley: gary_poster: But if it was a test dependency, that would be fine. 10:19:43 > barry: abentley: how would that work in practical terms? when would the dependencies get pulled in? 10:20:11 < gary_poster: 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 10:20:15 < gary_poster: that is 10:20:43 < gary_poster: I don't see a reasonable way to guarantee that Mocker is a test dependency and not a "real" dependency 10:21:41 < abentley: barry: Sorry, I didn't even know setuptools supported test dependecies. I certainly don't know how they work. 10:21:45 < gary_poster: You said "But it's more of a theoretical thing," so does that mean we are on at least similar pages? 10:22:08 < abentley: gary_poster: Yes, it's more of a niggle than a real concern. 10:22:12 < gary_poster: cool 10:22:16 < gary_poster: and understood 10:23:01 > barry: 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 10:23:12 < gary_poster: cool 10:23:31 > barry: mrevell: is !away. mrevell do you want to have a word about pop-up help? 10:24:09 < mrevell: Hi barry, sorry I had to run out. Yes, I'd love to please if that's okay. 10:24:13 < mrevell: My apologies. 10:24:20 > barry: mrevell: no worries, and the floor is yours 10:24:52 < mrevell: I'd like to propose that a check for in-line help be added to code reviews. Maybe it should be ui reviews. 10:25:09 < mrevell: I think that when we add a new 10:25:33 < mrevell: feature/page we should consider whether everything on that page is self-evident to our less-experienced users. 10:25:51 < mrevell: 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. 10:25:54 < mrevell: Any thoughts? 10:26:24 > barry: mrevell: +1 10:26:50 < mrevell: Great :) Heh. 10:26:52 > barry: 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 10:27:06 < mrevell: barry: Ah yes, it is very easy indeed. 10:27:24 < mrevell: All you have to do is add an HTML file in the right place (there's a template and there are instructions at 10:27:34 < mrevell: https://dev.launchpad.net/PopUpHelp) 10:27:49 < mrevell: and then place a link in your page with a target of "help" 10:28:10 < mrevell: that automatically brings in the JS to create the pop-up and call in your help page in that pop-up. 10:28:37 < mrevell: 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. 10:28:39 < sinzui: I have used this. It is very easy to create help 10:28:47 < mrevell: Or suggest that the person whose branch you're reviewing contact me. 10:29:36 > barry: 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? 10:29:53 < mrevell: barry: I'll do that! Thanks very much everyone. 10:30:02 > barry: mrevell: thanks! 10:30:12 > barry: [ACTION] mrevell to flesh out UserInterfaceChecklist 10:30:13 < MootBot: ACTION received: mrevell to flesh out UserInterfaceChecklist 10:30:26 > barry: [TOPIC] peanut gallery 10:30:27 < MootBot: New Topic: peanut gallery 10:30:36 > barry: that's all i have for today. do you have anything on your mind? 10:31:11 < abentley: Does anyone else find they're creating a lot of HTML fragment URLs? 10:31:36 < intellectronica: yeah 10:31:48 < intellectronica: well, i did in the past, but there's plans for more of them 10:32:07 < abentley: I think it would be nice if we could retrieve particular IDs as HTML, or maybe address views directly. 10:32:28 < abentley: By particular ids, I mean HTML IDs. 10:32:30 < intellectronica: abentley: what do you mean by 'retrieve particular IDs'? 10:32:43 < noodles775: mrevell: there might be some overlap between that UI checklist page above and https://dev.launchpad.net/UI/Reviews 10:32:54 < intellectronica: ah, you mean addressing an element within a page on the server? 10:32:58 < abentley: So where you have