#launchpad-meeting 2006-12-11
<ddaa> MEETING STARTS
<thumper> here :-)
<ddaa> == Agenda ==
<ddaa> Next meeting Monday 18 December, 09:00-09:45 UTC.
<ddaa>  * roll call
<ddaa>  * production status
<ddaa>  * status reports
<ddaa> == Roll call ==
<ddaa> No apology.
<ddaa> lifeless: ping
<ddaa> jamesh: ping
<thumper> lifeless is on leave
<ddaa> SteveA: ping
<jamesh> pong
<ddaa> right
<thumper> good turnout tonight
<spiv> Hello.
<thumper> hi
<ddaa> spiv: welcome
<ddaa> so, lifeless on vac
<spiv> Shouldn't this be on the internal irc server?
<ddaa> poolie late
<ddaa> hu?
<ddaa> I guess it would make more sense
<thumper> spiv: it has always been on the public one before, but I don't mind
<jamesh> spiv: it is notionally public.
<ddaa> yeah
<spiv> jamesh: oh, ok, I assumed otherwise.
<jamesh> spiv: the #launchpad-meeting channel did not move
<spiv> In that case, carry on!
<thumper> anything secret squirrel and we can go sideways
* ddaa carries on
<ddaa> == Production status ==
<ddaa> New rollouts or production problems.
<ddaa> That I know, at least.
<ddaa> Unless anybody has something to report here
<thumper> not from me
<ddaa> like, e.g. the deployment of the supermirror-smart-server :)
<ddaa> I'll carry on
<ddaa> == Status reports ==
<ddaa>  * everybody: read https://blueprints.launchpad.net/distros/ubuntu/+spec/code-review
<ddaa> Did everybody read this spec?
<thumper> readit
* spiv looks
<spiv> No, I haven't yet.
<thumper> I've decided to grab some of the issues hilighted in it
<ddaa> spiv: jamesh: please make sure to read this, it's quite important for the near future of the launchpad-bazaar stuff
<jamesh> I looked over it a bit last week.
<thumper> bugs 58889, 71303 and 73975
<ddaa>  * spiv: supermirror-smart-server.
<ddaa>  * ddaa, _thumper_: look at spec-branches.
<ddaa> I did not look at the spec-branch work.
<thumper> ddaa: note name change
<jamesh> I wonder if we need a search capability for branch listing
<jamesh> in addition to status filtering
<ddaa> thumper: name change?
<thumper> jamesh: searching on what?
<thumper> ddaa: from _thumper_
<jamesh> thumper: branch names and descriptions
<ddaa> jamesh: that would certainly be good
<thumper> sounds like a plan
<ddaa> but not right now
<thumper> braindump it
<thumper> even without a wiki page, just to catch the idea
<ddaa> jamesh: want to look at thumper's work on branch filtering and post a braindump to the ML on how to add fti search?
<spiv> No news from me, as I was at a conference last week, but https://launchpad.canonical.com/SupermirrorSmartServerPlan now exists (as requested at a previous meeting)
<thumper> jamesh: if you don't I will, more karma to me
<jamesh> ddaa: okay.  I had a very brief look at the branch already.  I'll have a more detailed look.
<thumper> ddaa: jamesh has commented already...
<ddaa> I just suggested having a look so the branch searching thing could be thought out in this context.
<jamesh> I was more commenting on issues that had already been brought up
<ddaa> spiv: are you going to have time to focus on it this  week?
<thumper> oh, ok
<ddaa>  * ddaa: pyrex.
<spiv> ddaa: yes, I think so.
<ddaa> Got a quick review from spiv, did not have the time to take any action. Actually, did not have the time to act on any review this week.
<ddaa> spiv: looking forward to having some good news to tell in the next launchpad meeting :)
<spiv> ddaa: me too! :)
<ddaa> at least, some more details in the SupermirrorSmartServerPlan, it's a bit sketchy now
<ddaa> but better if it's more concrete stuff like "wsgi integration tested at spiv's", you see what I mean :)
<ddaa>  * ddaa: progress on motu code-review
<ddaa>  * poolie: bzr-lp features.
<ddaa>  * jamesh: branch browsing, can help?
<jamesh> ddaa: still finishing off the bug import stuff.  Can probably help later on this week.
<ddaa> on motu code-review, commented on the spec, did not get a lot of feedback. Grilled dholbach to get his requirement on branch filtering. Then thumper started implementing it.
<thumper> :)
<ddaa> Also had a round of feedback on the email notification side with thumper. Will try to push the spec forward this week.
<ddaa> jamesh: I'd like if you could tell me when you get started, and if you need anything.
<ddaa> Not that I think you're going to need anything, but it's nice to propose :)
<ddaa> poolie is not here today, so no bzr-lp update
<jamesh> I should talk with poolie about what he thinks it should look like.
<thumper> jamesh: the emails?
<ddaa> the branch browser, I think
<jamesh> thumper: branch browser
<ddaa> jamesh: I think we agreed on "just webserve"
<thumper> ddaa, jamesh: initially, adding features as we want them if they are not there
<ddaa> as a stopgap, we could even run it on the bare id-based filesystem and keep it private
<ddaa> then add the mapping to the virtual filesystem
<jamesh> ddaa: last meeting he mentioned having a talk about it this week
<thumper> ddaa: also suggested by poolie, he is very much in favour of just getting something up quick
<jamesh> which is why I mentioned it.
<SteveA> hi
<ddaa> jamesh: I think we're all in agreement on this. Get something up quick even if it's ugly.
<thumper> although if ugly, keep private
<thumper> initially
<thumper> remember "pretty is a feature"
<ddaa> I think, if it's got the virtual filesystem, it would be pretty enough for the public.
<ddaa> If people want prettier, they would be welcome to hack webserve.
<ddaa> not having a _working_ web UI to showcase is bad for bzr
<ddaa> and geoffredo's site is unusably slow
<ddaa> So, that finishes the agenda.
<ddaa> == Any other business? ==
<ddaa> SteveA: hello, you're late
<thumper> SteveA: getting access to vostok for me
<thumper> can we swing that?
<ddaa> I might not be able to work all day. The heating is off in my appt building, and my fingers are getting cold numb.
<SteveA> yes
<SteveA> I just read the scrollback
<SteveA> ddaa: is there a warm internet cafe near you?
<ddaa> not that I know
<SteveA> or a shop that sells portable heaters?
<thumper> ddaa: why is the heating off?
<ddaa> thumper: no idea
<ddaa> should be back today though
<thumper> ddaa: not even Starbucks?
* thumper ducks
<ddaa> thumper: this is Paris, there are like 3 starbucks in the entire town.
<thumper> ddaa: give it time
<jamesh> there are zero starbucks in Perth
<SteveA> http://www.world66.com/europe/france/paris/cybercafes
<SteveA> spiv: have you found out anything that would update the supermirror SS plan?
* ddaa knew he had some other business to discuss
<spiv> SteveA: not yet.
<SteveA> spiv: finding out whether apache has the hook you need sounds like it needs a small experiment
<SteveA> so describe the experiment and its result in the wiki page
<SteveA> (I wouldn't expect the docs to say this explicitly, and I've found apache docs a bit patchy in describing the interaction of different directives)
<spiv> Yeah, I expect it to involve a hour or two of mucking about.
<ddaa> SteveA: re portable heaters, my appt is too small and crowded to get yet another piece of equipment
<ddaa> SteveA: you read the mail about "software you can get using bzr"?
<thumper> I was wondering about the title
<thumper> isn't it more about bazaar activity?
<thumper> showing what is recent? or explicitly targetting "software you can get with bzr"?
<SteveA> ddaa: no
<ddaa> it's a feature request from sabfdl
<SteveA> ddaa: what's the subject of the email?
<SteveA> I spoke with mark about this on the phone at the end of last week
<SteveA> he specifically wants a page listing product names
<ddaa> Subject: Braindump: Software you can get using bzr
<thumper> SteveA: ok
<SteveA> ddaa: I don't have that email
<ddaa> Date: Fri, 08 Dec 2006 21:10:35 +0100
<thumper> launchpad list
<SteveA> for reasons unknown, I don't have it, and I don't recall having seen it
<thumper> SteveA: forwarded to you now
<SteveA> https://lists.ubuntu.com/mailman/private/launchpad/2006-December/012603.html
<SteveA> ta
<SteveA> ddaa: ok, reading it
<SteveA> Importd does not currently set Productseries.datelastsynced, so we do
<SteveA> not know when was the last successful import. This can be fixed quickly
<SteveA> by a small patch to importd. But this would be a good opportunity to do
<SteveA> more work, and start separating the status reporting from the job runner.
<SteveA> 
<SteveA> this kind of thing worries me
<SteveA> I'll try to explain why
<jamesh> ddaa: weird.  I didn't get that email either
* thumper thinks perhaps it looks like spam
<SteveA> you're appear to be saying "I could make this quick and simple fix, but I won't because I'm worried if I do that, I'll feel less need to do the larger refactoring"
<ddaa> meaning I can hack it in less than an afternoon (tests included), but I'd prefer to start tackling the larger job of separating the job runner (now buildbot) from the status reporting to go incrementally in the directory of improtd-ng. The Plan is to have job-runner -> job-reporter -> cscvs.
<SteveA> ddaa: as far as I can see from reading your mail, that's the only feature we're missing to make the page Mark asked for work
<SteveA> is that correct?
<ddaa> no
<ddaa> "If the last sync was successful, but was not mirrored yet, we do not know how old is the currently published code."
<SteveA> ok
<SteveA> so that too
<thumper> I don't understand what the distinction is between "last sync" and "mirrored"
<SteveA> so, making the import system actually use one field we already have in the database
<thumper> can you enlighten me?
<ddaa> given those two, yes, we can do the page Mark asked for
<SteveA> and adding a new field, and making the import system do that
<SteveA> ddaa: how long do you think doing both those things would take?
<jamesh> thumper: sync == code converted from CVS/Subversion to Bazaar
<spiv> thumper: syncs don't happen directly on the mirror, there's an intermediate holding place.
<ddaa> thumper: importd published stuff to an internal http server, then the branch puller puts this data in the published location
<jamesh> thumper: mirror == code mirrored to http://bazaar.launchpad.net
<thumper> ok, ta
<ddaa> SteveA: All included (coding, review, deployment) it should be about 8 hours of work for me
<SteveA> ok
<ddaa> then there the db patch issue, but it should be cherrypickable
<SteveA> and how long do you think "tackling the larger job of separating the job runner from the status reporting to go incrementally in the directory of improtd-ng"
<SteveA> will take?
<ddaa> not sure... double it at least
<SteveA> double what?
<ddaa> 8 more hours
<ddaa> it's hard to say, it's not complicated work, but it's a bit of new infrastructure, so there's the usual overhead
<ddaa> new script, new test cases, etc.
<SteveA> ok
<SteveA> here's my frustration with what you wrote
<ddaa> 3 mins to go
<SteveA> you wrote that email in response to a request to write a particular feature
<SteveA> and, for very tenuous reasons, you're trying to combine writing that feature
<SteveA> which has a clear bounds
<SteveA> with doing some more open-ended refactoring
<ddaa> sure, I do not have a clear reason for this
<SteveA> then WHY did you do it?
<ddaa> to annoy you? :)
<ddaa> well, because I'm just trying to push this refactoring any way I can
<SteveA> ever heard the phrase "career limiting move" ?
<ddaa> frustrated of not getting around to doing it
<SteveA> we're in a distributed company
<SteveA> communication has an overhead
<SteveA> and a larger overhead than in an "all in one office" company
<SteveA> and I don't like it when you make communication muddy to further a separate agenda than I've asked you about
<SteveA> please think upon this
<SteveA> next time, for example, send me a separate email saying how important you think the refactoring is
<SteveA> but keep the other email to the point
<ddaa> I think you know this issue. I understand it's not smart doing it.
<SteveA> so: stop doing it immedately
<SteveA> that's all.
<ddaa> Anything else you are unhappy about the recent communication spec work I've been doing recently?
<SteveA> non
<SteveA> other than that, the email you wrote about this "bzr products listed on a page" is clear
<ddaa> I've been doing a lot of it, so it feels a bit frustrating that the only feedback I get from you is about this single sentence.
<SteveA> I didn't see that email until today
<ddaa> Oh yes other business:
<ddaa> cscvs has been released, in case people did not notice
<SteveA> cool.  that must feel good, as you've been wanting to do that for a while
<ddaa> the stuff is still lacking some code from hct, I plan to clean that up soon (it's part of the larger "remove dep on pybaz" problem)
<ddaa> and the cmd line is still quite broken
<ddaa> so for the time being I want the release to be low-key
<ddaa> if people express an interest in the code, direct them to it
<jamesh> ddaa: where was the release announced?
<ddaa> It was not announced.
<thumper> not surprising that it passed me by then...
<ddaa> I want to wait until we have ironed out some process to get the code in
<ddaa> I mean code contribution
<ddaa> and until the most blatant breakage in the cmd line is fixed
<ddaa> then we can announce it
<jamesh> would it be worth asking the marketing guys for input on a release announcement?
<ddaa> I expliticitly want this release to stay discreet for now
<ddaa> the tool sucks as a standalone conversion tool as it is
<thumper> perhaps time it with the 1.0 bzr release?
<ddaa> there is a low, but steady, demand for access to this code
<ddaa> I already notified sivang, and he'll talk to janimo about it
<jamesh> okay.  It wouldn't hurt to see if they have any suggestions for the announcement before hand.
<ddaa> so, when we have a patch submission process, and when the most blatant brokeness is fixed, we can announce it. ATM it's just "a dump of broken corporate code"
<ddaa> so, feel free to tell people about it, but I'd rather avoid publicity
<ddaa> the product on launchpad is launchpad-cscvs by the way
<SteveA> ok
<ddaa> BTW, meeting closed
<thumper> yay, sleep
<ddaa> SteveA: I did more than just this email in the past couple of weeks
<SteveA> spiv: I'd like to get some pings from you during the week about progress looking into the smartserver + supermirror
<ddaa> specs about deleted branches, email notification, requirements on branch status filtering
<SteveA> spiv: because I'm interested in seeing how it will come out
<spiv> SteveA: sure.
<SteveA> thanks
<ddaa> actually, I spent pretty much all my time doing help-text, cscvs release, and spec/guidance work.
<SteveA> after the infrastructure for this "page of products"
<SteveA> what would you like to do next?
<ddaa> after?
* ddaa calms down the passive-agressive
<ddaa> continue spec work around launcphad-bazaar, clear out backlog of review replies, spend a little time fixing cscvs, spend a little time improving bzr-svn, and finish the pyrex work.
<ddaa> also, keep spending about one hour a day on small UI improvements to launchpad (currently, spent on help-text)
<SteveA> I'd like to have a call with you later so we can talk over the relative priorities of these things
<SteveA> also, Kiko and I will be introducing a new concept into Launchpad work, starting for each team within Launchpad as soon as the 1.0 work for that team in complete
<SteveA> that is, Fridays will be "work on whatever Launchpad stuff you think needs it" days
<ddaa> mh
<ddaa> too bad there's only one friday a week :)
<SteveA> we're going to start planning Launchpad work based on four day weeks of scheduled work
<SteveA> for completing specs etc.
<SteveA> and on Fridays, you get to set the priorities and activities for that day
<SteveA> formal announcement on Thursday
<ddaa> sounds like a good idea
<ddaa> so we can get to do all those important things that we never get around to
<ddaa> workrave in 2 mins
<lifeless> http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt
<spiv> lifeless: dude, enjoy your holiday! :)
<spiv> What are you doing in a work channel? :)
<ddaa> " Q: How does svnsync deal with parts of the master repository that I'm not    authorized to read? "
<ddaa> mh, that's another cscvs bug in the waiting
<carlos> hi
<kiko> good morning guys
<kiko> how are you
<danilos> I am fine, thanks
<carlos> fine too, thanks
<carlos> and you?
<kiko> pretty good
<kiko> so
<kiko> carlos, what happened last monday?
<carlos> I sent TranslationReview review answer and the modification to allow anonymous browsing was implemented and sent to you
<carlos> for review
<kiko> I saw that
<kiko> but you had said that you would get everything reviewed and landed by monday
<kiko> and you said that in fact you were going to come back in the afternoon
<kiko> so danilo and I waited for you
<carlos> hmm
<carlos> I was, but I didn't connect...
<carlos> was I supposed to connect to IRC?
<kiko> you were supposed to at least tell us the status of your work by end of day monday
<carlos> sorry, I was not aware of that...
<kiko> huh?
<kiko> you said very explicitly that you would be back, and we had spoken on friday about us ensuring that we got things done by monday
<carlos> I said that I will work and handle the merge, but I was not thinking on connecting to IRC, sorry...
<carlos> I sent you a brief report, with copy to danilo 
<kiko> but the merge wasn't done either, was it?
<carlos> with the diff I sent to yoiu
<carlos> you
<carlos> no, because the review required more work
<kiko> and you didn't tell us that either
<kiko> so... hard for us to understand what's going on in valencia.
<kiko> I would like that to sort of thing to be solved 
<carlos> ok, sorry about that. I was not as communicative as I should be...
<kiko> so how are things this week
<kiko> what's snagged on review?
<carlos> kiko: about IRC connection, I usually don't connect when I'm supposed to be on vacations, to be focus on the thing that needs to be done, even on vacations. I will try to connect at least to #canonical next time
<danilos> you've got my weekly reports, and the last thing I did last week was fighting with zipfile module
<danilos> basically, I've done the exports, need to test them thoroughoutly, and add a test (as discussed on Friday)
<kiko> carlos, I don't care. if you say you will merge something and then disappear, I will get upset.
<kiko> so yes, I expect better communication, and this isn't the first time.
<carlos> about the review: I think the review from Salgado should come today and then merged, about TranslationReview, I need to move pagetests from using database code to use BeautifulSoup. I had a meeting today with Bjorn about it, he helped me to figure the best way to check translation form in that way
<kiko> carlos, hmmm. I see. what will beautifulsoup help there?
<kiko> ah, you are querying for results?
<kiko> and bjorn wants you to test the page output?
<carlos> kiko: the fact that active translations are not inside a textarea or input fields, we cannot query them from pagetests, it's just plain html text
<carlos> well, I test the content, but based on what we have in the database
<kiko> right, you'd need to parse with BS indeed
<kiko> yeah, yeah.
<carlos> right
<kiko> how hard is that change?
<carlos> seems much more easy than I expected
<carlos> iterating over html tags
<kiko> okay, good news
<kiko> will you get it done by tomorrrow?
<carlos> yes
<carlos> I hope to get the final review from Bjorn today too
<kiko> ok.
<carlos> but the only remaining issue I think there will be is the BeautifulSoup chnage
<kiko> ok, good news
<kiko> danilos, did you get over the zipfile issue?
<danilos> kiko: well, worked around it as I initially planned: recreated new zipfile in memory instead of trying to modify existing one
<kiko> right.
<kiko> that's the better plan I think too
<danilos> at the moment, I'm trying to get export to work properly
<kiko> danilos, what's stuck there?
<danilos> well, my code is simply not getting called when I run the export cronscript
<danilos> so, I probably missed something, and need to look into it better
<danilos> the thing is that regular po export is using a caching mechanism, which I am not at the moment
<danilos> so, there's probably something missing there
<carlos> danilos: forget about caching at this time
<carlos> it should work without caching support
<danilos> carlos: right
<danilos> basically, this was the last thing I did on Friday, and haven't had a chance to look at it properly
<danilos> the thing is that all the classes are there, but it simply finishes really quickly without exporting anything
<kiko> danilos, add some tracing code
<kiko> to see what its doing
<kiko> or pdb it
<danilos> kiko: right, I'll do that
<kiko> danilos, how's it gone today? 
<danilos> kiko: my plan was to actually find out where it's getting first (using some tracing code), and see where is it failing
<kiko> right, that's pretty sane to me.
<danilos> oh, I've started really late today, so I've got like 6 more hours of work
<danilos> basically, haven't done much
<danilos> but this is the main thing for the rest of the day, anyway
<kiko> okay
<danilos> so, I'll let you know how it goes, and will ping you and others on #launchpad-code if I get stuck
<kiko> carlos, what else came up in your review with carlos?
<kiko> yeah, danilos, please do -- I'm at your service
<carlos> ?
<kiko> err
<kiko> with bjorn
<kiko> my left wrist hurts today, fucks me over
<danilos> kiko, talk with kiko about it :P
<carlos> well
<carlos> most of the changes were related with tests
<carlos> and the way to document it
<kiko> carlos, was he happy with the general design?
<carlos> and also, I did a mistake and with the hurry to deliver the first review, I forgot to review the diff and notice that I miss that I added some kind of documentation that Bjorn told me to change later in the review
<carlos> but that's already solved (or should, I still need his reply)
<kiko> okay.
<carlos> the only complain about the design was related with a behaviour I did on javascript
<kiko> carlos, danilos: what's the  plan for tomorrow?
<kiko> carlos, what JS? the copy stuff?
<danilos> well, I'd rather talk about tommorow later in the day: I want to see how will these things go today first
<carlos> no, the way to handle the 'New suggestion' flag
<carlos> and when you can type in new info to the textarea
<danilos> if I manage to get out of it today, it's up for review tommorow
<carlos> I just followed his advice and implemented it the same way Malone handles it
<danilos> but that's an "if" (no ETA ;)
<kiko> danilos, okay. it sounds like you will still lack tests though, after this.
<kiko> carlos, to auto-select the radiobutton?
<danilos> right, but we've already discussed how I am going to do them
<carlos> kiko: checkbuttons
<danilos> and I'll test such programmed result using local copy of firefox
<carlos> kiko: lack tests?
<carlos> kiko: I don't think so
<carlos> last review was just a review to improve current tests
<kiko> danilos, okay, but likely your reviewer will want tests that are more unit-like
<danilos> carlos: that was about me
<carlos> no code changes (other than renames)
<carlos> oh
<danilos> kiko: ah, so you think more of doctests vs. pagetests, or?
<kiko> carlos, okay. do you need help with the BS changes?
<carlos> ok ;-)
<kiko> danilos, well, you'll need doctests for API you add/modify 
<danilos> kiko: or simply that I should test the new classes I've added as well?
<kiko> pagetests for pages you change
<danilos> kiko: right, and that's best done with doctests, right?
<kiko> and for a complex process like an export
<carlos> kiko: not yet, Bjorn already told me a bunch of hints on that. but I will work on it tomorrow morning
<kiko> carlos, okay. 
<danilos> right, I haven't done those either
<kiko> I'm not sure yet what should be used -- what is used currently to test exports, carlos?
<kiko> danilos, usually it's best to test as you go to avoid the big delay
<danilos> pagetests mostly
<kiko> hmmmm
<kiko> danilos, can you get in a phone call with SteveA to see what's the best strategy for testing the actual export process?
<carlos> for exports?
<kiko> SteveA, ping?
<carlos> doctest
<kiko> yeah
<carlos> poexport*
<carlos> poexport*.txt
<SteveA> kiko: hi
<danilos> kiko: sure
<carlos> mainly
<kiko> SteveA, can you?
<SteveA> can I?
<kiko> yes.
<SteveA> probably.  can I what?
<danilos> SteveA: <kiko> danilos, can you get in a phone call with SteveA to see what's the best strategy for testing the actual export process?
<kiko> SteveA, well, to start off, look up 5 lines or so. 
<SteveA> sure.  after I've had some lunch today is okay.
<SteveA> or tomorrow.
<SteveA> your choice
<kiko> today'd be good
<kiko> better even
<danilos> SteveA: just give me the time, and I'll ping you when it comes
<SteveA> so, that's fine.  I need to go food shopping, as the cupboard is bare
<SteveA> and I have a mouse living under my fridge
<SteveA> I assembled an elaborate trap
<kiko> man perl is so scary
<SteveA> danilos: will you be around in 2 hrs or so?
<carlos> SteveA: ;-)
<danilos> SteveA: if you've got a mouse there, then that's not exactly empty fridge :)
<kiko> it's starving
<danilos> SteveA: yeah, I'll stick around for a while
<kiko> just like SteveA 
<SteveA> kiko: it ate all my food!
<carlos> kiko, danilos: I want to raise another thing
<SteveA> danilos: so, ping me in about 2 hrs.  I should have finished shopping and lunch by then.
<danilos> SteveA: sure, I will
<carlos> kiko, danilos: Are we done with other issues?
<kiko> carlos, yes -- ping bjorn to see if he can expedite your review. we should chat again tomorrow morning
<carlos> Festy translation opening 
<carlos> kiko: ok
<danilos> carlos: right, you mentioned that
<kiko> yeah, I read about that
<carlos> kiko, danilos: From my point of view, we could schedule it to be done right now.
<carlos> but
<carlos> I would like to do a small change in the process, to save resources
<kiko> carlos, it will be high-impact, won't it?
<carlos> kiko: yes
<kiko> hmmmm
<danilos> what worries me is opening it for translation, yet having a lot of entries in the import queue
<carlos> 3-4 hours
<carlos> danilos: the opening will clean the queue a bit
<kiko> carlos, clean, not make worse? how?
<carlos> kiko, danilos: I would like to filter from the copy any template that is disabled in Edgy
<carlos> that's every Debian template or documentation that is not being used as part of language packs
<danilos> carlos: modifying copy-translations stuff?
<carlos> we disabled them a month ago, and it makes no sense to propagate them with every new distro release
<danilos> kiko: it would clean it up by automatically approving those that can be automatically approved
<danilos> but  we would have other entries which would then really need manual handling right away (or pretty soon)
<kiko> danilos, why isn't that happening now? do we have feisty packages already pending?
<carlos> danilos: yes, but just filtering on POTemplate.iscurrent
<carlos> kiko: yes, we get feisty translations in the queue as soon as the first package is uploaded into the buildd
<danilos> kiko: well, because 'opening distrorelease for translation' is basically also copying all the potemplates and pofiles from earlier release first
<danilos> kiko: they cannot get imported until we've got a place to import them to
<carlos> oh, right, kiko, sorry, I didn't see that question...
<carlos> danilos: thanks for handling it
<danilos> basically I don't have a strong opinion on the matter of opening feisty for translation
<kiko> carlos, I see
<carlos> kiko: my proposal, do that change as part of my 1-2 hours slot (and get used to those fast implementations again)
<kiko> I see
<carlos> and schedule that with Stuart for later this week or beginning of next week
<danilos> but facts: it will require 3-4h db downtime, translators/packagers (pitti) will appreciate it
<carlos> and users
<carlos> Feisty lacks any translation for main packages
<kiko> that's a good plan. can it be done with the DB open?
<carlos> open to what?
<carlos> without shutting down launchpad?
<kiko> yeah.
<carlos> no, it cannot
<carlos> at least it cannot as we are used to
<carlos> but
<carlos> perhaps we could do something like what we talked to do the DB schema change
<carlos> use a copy of Person table
<kiko> hmmm.
<carlos> and disable accounts merging
<carlos> and Rosetta, of course
<kiko> yeah, there's that idea.
<carlos> kiko: I will talk with Stuart tomorrow about the options we have for this, and will report to you a summary of the conversation
<kiko> carlos, can you spec out the basics of how that would work as a result of that call? can be a one-page email that we comment and goes into a spec. 
<kiko> carlos, see if stub likes the idea, too.
<carlos> ok
<kiko> cool.
<kiko> okay, let me grab some food
<kiko-fud> see you in an hour
<carlos> kiko-fud: I'm leaving in 30 minutes or so
<carlos> other than asking Bjorn and Salgado for my reviews, is there anything else you need from me today?
<kiko-fud> carlos, okay.
<kiko-fud> no, that's fine.
<kiko-fud> see you tomorrow
<carlos> ok, thanks for the meeting
<carlos> kiko-fud: btw, you owe me a review! ;-)
<carlos> danilos: and you? do you need a hand with firefox exports?
<danilos> carlos: not right now, I'll work on that, and ping you in an hour if I still have the same problem
<carlos> well, I will not be around in one hour ;-)
<carlos> so please, send me an email if that's the case
<danilos> carlos: sure
<carlos> thanks
<kiko-fud> carlos, yeah, will do.
<carlos> kiko-fud: thanks
<SteveA> danilos: hi
<danilos> hi SteveA
<SteveA> danilos: skype?
<danilos> SteveA: so, I am wondering about the best way to test export stuff
<danilos> hum, I don't have skype installed
<SteveA> ok
<SteveA> phone number?
<danilos> I've only got ekiga
<SteveA> or sip number
<danilos> let me check my SIP number
<danilos> it should be 7402
<danilos> sip:7402@canonical.com
<SteveA> do you hear me?
<danilos> I can
<danilos> can you hear me?
<SteveA> are you speaking?
<SteveA> hmm, guess not
<danilos> yeah, guess not
<SteveA> sip:31207173499@budgetphone.nl
<SteveA> try me on that
<danilos> ok
<danilos> you seem to be refusing calls
<danilos> or at least that's what ekiga says for me
<SteveA> hmm
<SteveA> ok, give me a POTS number
<SteveA> oh, wait
<SteveA> try one more thing...
<danilos> +381112103941
<SteveA> sip:0031207173499@budgetphone.nl
<danilos> sure
<danilos> doesn't work for me
<SteveA> ok
<SteveA> I'll call you phone
<danilos> ok
<SteveA> export.xpi
<SteveA> export.xpi
<SteveA> oops
<SteveA> try again
<SteveA> export.xpi
<SteveA> |
<SteveA> +
<danilos> chrome/export.jar
<danilos> install.rdf
<SteveA> 
<SteveA> inside export.jar
<danilos> browser/browser.dtd
<danilos> browser/browser.properties
<danilos> ...
<danilos> <!ENTITY blah "blah">
<danilos> ./browser/help/firefox_welcome.xhtml
<danilos> ./browser/help/download_manager.xhtml
<danilos> ./browser/help/platformStrings.dtd
<danilos> ./browser/help/tabbed_browsing.xhtml
<danilos> ./browser/help/glossary.xhtml
<danilos> ./browser/browser.dtd
<danilos> ./browser/pageInfo.dtd
<danilos> .
<SteveA> foozilla project
<SteveA> translated in this format
<SteveA> with a simple us english xpi
<SteveA> only a few strings
<SteveA> translate into spanish
<SteveA>  canonical/launchpad/scripts/rosetta/ftests/foozilla-sampledata
<SteveA> in there have the expanded .xpi file
<SteveA> and parallel to it
<SteveA> the expended contents of the .jar file
<SteveA> the .xpi file would have no .jar file
<SteveA> the hard part is coming up with decent sample data
<SteveA> 1. create foozilla product in sample data
<SteveA>   sql
<SteveA> 2. create rest of sample data to go along with it
<SteveA> 3. create its en-us xpi file
<SteveA> store the xpi file as files in a directory on the filesystem
<SteveA> check this into RF
<SteveA> don't check in an actual .xpi or .jar file
<SteveA> as this will be unfriendly to developers
<SteveA> to check diff of exported file
<SteveA> 1. you have a list of the files that should have just come from us-en xpi
<SteveA>   so, copy these files (only) from the us-en into a temporary place that is what you compare to
<SteveA> 2. copy the rest of the files to compare to from foozilla-sampledata
<SteveA> 3. diff your export (unzipped) against the temporary place using diff -r
<SteveA> this means you don't store two copies of your en-us.xpi data
<SteveA> and instead you just keep a list of what files are supposed to be duplicated from the en-us file into your output file
<SteveA> and use diff -r to do the comparison -- keep the comparison as simple as possible!
<SteveA> the two important tasks for the test are:
<SteveA>  1. create the temp directory that is what you should have in the export, made up of some things from en-us
<SteveA>    and some things from your foozilla-sampledata
<SteveA> 2. create another temp directory that is the exported file, unzipped (twice)
<SteveA> 3. compare these two using diff -r
#launchpad-meeting 2007-12-11
<jml> waiting on spiv.
<jml> I declare this meeting abandoned.
<spiv> BjornT, jml, jamesh: I'm here now...
<spiv> If you still care :)
<jml> spiv: nope :)
<spiv> I was busily fixing bzr code :)
<jml> spiv: that's a good thing, I think :)
#launchpad-meeting 2007-12-12
<statik> hello, welcome to the reviewer meeting for people who are attending at this time
<mwhudson> hello statik
<statik> barry asked me to help with this meeting as he is away
<statik>     * Roll call
<statik>     * Next meeting
<statik>     * Action items
<statik>     * Queue status
<statik>     * Mentoring update
<statik>     * General Queue allocations (w/salgado and lifeless on vaca)
<statik>     * Review process changes
<statik>           o Tool update
<statik>           o Recruit reviews
<statik> so, who is here (please ping anyone you know should be here)
<intellectronica> me
<gmb> me
<mwhudson> me
<statik> me
<sinzui> me
<BjornT> me
<flacoste> me
<ddaa> me
<flacoste> salgado is on leave
<statik> bac is on leave
<flacoste> barry is at the dentist
<statik> next meeting, same time?
 * ddaa complains about reviewing 1400 lines soyuz diff of doom which appears to consist mostly of pagetests improvement although it seems the branch was intended to fix a bug.
<mwhudson> jtv: here?
<statik> ok, next meeting is at the same time
<statik> action items
 * sinzui recalls the 600 line soyuz diff that inflated to 1600 lines.
<jtv> mwhudson: here
<statik> barry was supposed to edit the wiki about on-call procedures, announce the new 800 line limit on branches, and email launchpad-reviews about adding a joint meeting with asiapac, perhaps once a cycle
<statik> barry told me he would do those things later today
<statik> intellectronica had an action item to work on a cover letter template, how is that going?
<intellectronica> sorry, i'm rubbish. maybe later today? if not then next year
<statik> fantastic, thanks for playing
<sinzui> There was an announcement about the 800 line restriction
<statik> ddaa, sinzui, hopefully the announcement about 800 line limit later today will help prevent your situations
<statik> oh, then I missed it
<statik> queue status!
<statik> has anyone seen the queue?
<statik> I see 3 in the general queue
<statik> intellectronica: how is your load today?
<intellectronica> i'm going through the queue. nearly done with cprov's branch and i hope to take at least another one off the queue
<ddaa> oh, my branch of doom is from cprov too
<sinzui> ddaa: So was mine.
<ddaa> I can see a pattern.
<statik> intellectronica: super. barry suggested that with lifeless and salgado on vacation we need to be careful to do review allocations
<statik> ddaa: if the branch is too big then reject it
<mwhudson> the only old branch in the queue seems to be adeuring/launchpad/parse-hwdb-submissions-step1, assigned to jtv
<jtv> mwhudson: arrived too late for me last night, doing it now
<intellectronica> i can allocate when i'm done for the day
<mwhudson> so i think the queue status is "good"
<ddaa> statik: I'll give it its three hours to see how far I can go.
<statik> intellectronica: great. it would be good if all on-call reviewers can do the same
<statik> ddaa: that sounds like a good balance to strike. I'll remind cprov about the 800 line limit
<statik> next item, mentoring update!
<statik> are the folks who are being mentored getting any branches to review?
<gmb> Yes.
<ddaa> got two
<gmb> And I'm going to share on-call duties with mwhudson tomorrow.
<jtv> mine's a big one
<mwhudson> i think barry assigned a bunch of reviews to mentorees last night
<mwhudson> i was just starting to mentor gmb's reviews when the meeting started
<statik> excellent, sounds like that is going ok then
<statik> final item, review process changes
<statik> or, tool update
<statik> does anyone have anything to say about tools?
<mwhudson> i fixed a couple of the issues in my lpreview plugin this morning
<mwhudson> so update it, please
<statik> I saw mwhudson fixed a lot of stuff ,but I still haven't tried using it yet
<mwhudson> i should add an item to the dev meeting tomorrow about asking if people have used it
<statik> mwhudson: is it going to incorporate intellectronica's cover letter template?
<mwhudson> statik: when he writes it, yes :)
<flacoste> mwhudson: add an item to the agenda
<ddaa> thanks for merging my fix
<flacoste> that's a goo didea
<statik> ok, I guess thats it for tools
<statik> I suggest 3 minutes of random comments from anyone before we adjourn the meeting
 * ddaa raises hand
<statik> have I mentioned how much I like the on-call reviewer process?
<ddaa> after flacoste bothered me yesterday
<statik> go for it ddaa
<ddaa> I wrote a branch to merge all ftests directory into tests directories
<mwhudson> flacoste: done
<ddaa> it's going to conflict with nearly about everything
<ddaa> It already bounced once from pqm because a patch got in before it that added a new ftests file.
<jtv> ddaa: even the test infrastructure stuff?  I like having that slightly separate.
<statik> ddaa: we could probably coordinate with kiko and mthaddon to have your branch land first thing after the rollout
<ddaa> jtv: flacoste said it should move to "testing" directories
<jtv> ah
<ddaa> statik: in the meantime, I'll just keep trying to put it in pqm
<ddaa> but I'm afraid it might cause some branches to miss the end-of-week deadline.
<flacoste> might be better to land it then
<ddaa> statik: but that sounds like a good idea.
<flacoste> then being after the roll-out
<ddaa> ok
<statik> yeah, I see 7 scripts in PQM now, if we know that branch is conflicty then doing it during that quiet period would be better
<mwhudson> it's not really a reviewer meeting item, but pqm runs are getting slower at a depressing rate
<statik> mwhudson: it's all that email that flacoste is sending to the list
<statik> about PQM timing
<ddaa> did not see that
<ddaa> but I want to say
<ddaa> I think the current pqm timing data
<ddaa> is almost useless
<ddaa> it's measuring the wrong thing
<ddaa> you can trivially tweak it by splitting or combining pagetests
<statik> I think it would be worth organizing a separate discussion to talk about PQM timing. would someone here volunteer to organize such a meeting?
<ddaa> what we care about is how much time is spend in the code that's actually called from the pagetests
<statik> ddaa: that is a good point
<BjornT> ddaa: we also care about how fast the test suite runs as a whole, don't we?
<flacoste> i don't understand
<flacoste> ddaa: you are talking about the aggregated time of PageTests or the one of individual test?
<statik> the current emails focus a bit on the slowest tests, I think ddaa was pointing out that the size of an individual test is less important than the overall time
<ddaa> BjornT: the current pqm run summary does to help see how that evolves, and I do not think it was intended for that. Tom's pqm timing graph is good for that.
<ddaa> statik: right
<ddaa> what matters more is "what makes all the tests slow"
<mwhudson> yes, it was https://devpad.canonical.com/~mthaddon/pqm_durations.html that inspired my comment
<flacoste> the email gives an hint to that
<BjornT> ddaa: oh, i thought you were talking about tom's graph
<ddaa> i.e. is there some specific helper function that accounts for 25% of the runtime? We do not know?
<flacoste> 20% is spent in resetting database
<statik> flacoste: since you are sending the current PQM timing mails, I assume you have some plans or ownership of this issue, so if you think we should have a discussion about PQM times and how to make further progress, would you organize it?
<statik> (outside of the reviewer meeting I mean)
<flacoste> statik: i could, but I don't think a meeting is necessary
<statik> flacoste: I trust your judgement completely
<flacoste> somebody need to profile
<flacoste> and then we can talk about solutions
<statik> that's all for this weeks reviewer meeting, I'll do a countdown now because I like the dramatic effect
<statik> 5
<flacoste> without profiling data, everything is guessing
<statik> 4
<statik> 3
<statik> 2
<jtv> "it's going to blow!"
<statik> 1.4
<statik> 0
<statik> thanks everyone!
<jtv> thanks
<flacoste> thanks statik for a short meeting!
<ddaa> mwhudson: that's indeed a depressing sight
<mwhudson> thanks statik
<flacoste> ddaa: you may want to try merging the 3 branches before yours
<flacoste> ddaa: in PQM
<ddaa> flacoste: I tried :)
<flacoste> ddaa: did it work?
<ddaa> no tree shape conflict
<flacoste> ok, so it could work
<ddaa> might be content conflicts through (new references to ftests)
<ddaa> did not check that
<flacoste> right
<ddaa> I did not even check that the full test suite passes in my branch.
<flacoste> if it fails, better than to postpone
<ddaa> ack
<ddaa> flacoste: I believe the db reset cost cannot easily be fixed
<flacoste> probably not
<ddaa> since the test adapter already just do abort if there was no commit
<flacoste> i tried running the test suite under the profiler
<flacoste> it trashed my machine to death
<ddaa> that's usually a good indication that profiling is needed :)
<flacoste> well
<flacoste> the problem is with the profiler
<flacoste> i think it holds all its data structure in memory
<flacoste> so you might guess that with the size of LP test-suite...
<ddaa> which profiler did you use?
<flacoste> ./test.py --profile
<flacoste> which uses hotspot i think
<ddaa> hotshot
<flacoste> right
<ddaa> IIRC, at some point hotshot worked by writing a ton of data on disk
<ddaa> then postprocessing it
<ddaa> if I'm correct, it might be possible to get that behaviour back
<ddaa> it might have been disabled to fit into the old legacy profile api.
<ddaa> it's a strategy for low-impact profiling: externalize the collating of the profiling data so it does not impact the cpu times during profiling.
<mwhudson> there is also lsprof/cProfile
<mwhudson> which is less demented than hotshot in this regard
<mwhudson> ddaa: the problem with hotshot is that _loading the profile data_ takes as long as running the original program under the python profilee
<ddaa> here the problem is not one of time
<ddaa> but one of space
<ddaa> flacoste was just not able to complete the run because of excessive memory use.
<ddaa> so it makes sense to aggressively trade space for time.
<ddaa> my comment about low-impact profiling was to underline that we can expect to find this feature is a number of profilers.
#launchpad-meeting 2007-12-13
<kiko> hello hello
<kiko> am I early?
<mwhudson> two hours early
<kiko> wow!
<gmb> Meeting time?
<jtv> gmb: seems so
<danilos> gmb: it indeed is
<mrevell> gmb: Aye lad
<danilos> me
<danilos> me
<mrevell> moi
<kiko-fud> me
<cprov> me
<danilos> ok, kiko, will you lead the meeting? :)
<kiko> I don't know how, but BjornT can sure do it!
<jtv> danilos: just say "who will chair this meeting" in the middle of a "me" storm.
<barry> me (but waiting for a phone call)
<mthaddon> me
<BjornT> well, since no one else volunteers....
<BjornT> let's start this week's LP developer meeting
<BjornT> who's here?
<gmb> me
<danilos> me
<mwhudson> me
<flacoste> me
<adeuring> me
<sinzui> me
<barry> me
<EdwinGrubbs> me
<statik> me
<mrevell> me
<jtv> me
<schwuk> me
<SteveA> why are we having the meeting here?
<kiko> SteveA, read the mailing list next time, but BjornT is chairing.
<SteveA> I've been on vacation
<kiko> good for you! :)
<danilos> tis a pretty short list of attendees
<jsk> me
<kiko> indeed. cprov?
<BjornT> bac and matsubara are on leave
<kiko> salgado is on vacation too.
<danilos> so is carlos
<BjornT> allenap: ping - meeting time
<cprov> me
<allenap> me
<allenap> BjornT: Thanks.
<BjornT> == Agenda ==
<BjornT>  * Roll call
<BjornT>  * Agenda
<BjornT>  * Next meeting
<BjornT>  * Actions from last meeting
<BjornT>  * Oops report (Matsubara)
<BjornT>  * Critical Bugs (Rinchen)
<BjornT>  * Bug tags
<BjornT>  * Operations report (mthaddon)
<BjornT>  * DBA report (stub)
<BjornT>  * Sysadmin requests (Rinchen)
<BjornT>  * A top user-affecting issue (mrevell)
<BjornT> ----
<BjornT>  * Survey: Are you using lpreview yet? (mwhudson)
<BjornT> ----
<BjornT>  * Blockers
<BjornT> * Next meeting
<BjornT> who knows they will not be here next week?
<danilos> I'm off to vacation next week
<danilos> (back only on January 8th)
<jtv> And carlos will still be away.
<schwuk> I've got holiday planned for next Thurs as well
<ddaa> me
<danilos> so list is getting pretty short, with it being already short enough
<danilos> ddaa: you sticking around for meeting next week?
<ddaa> I should be at work in +=7days
<BjornT> kiko: quite a lot of people will be away next week. still worth having a meeting?
<kiko> BjornT, I think so, because it's post-rollout
<kiko> BjornT, Rinchen will be here and I should be too
<danilos> I'd say one could plan next meeting for next year, but yeah, it's post-rollout
<BjornT> yes, good point.
<BjornT> so, let's have a meeting next week, same time as usual
<BjornT>  * Actions from last meeting
<leonardr> me
<cprov> i will be on vacations (probably), but I will attend the meeting
<BjornT> there were no actions from last week
<kiko> cprov! that's great to hear. :)
<BjornT>  * Oops report (Matsubara)
<kiko> I am standing in for the great chinaman this week
<BjornT> did matsubara send his oops report to anyone?
<BjornT> thanks kiko
<kiko> there are no, and I mean zero, OOPSes of note in the daily report
 * flacoste cheers
<kiko> there is one which is a bit odd, which is the +menudata one
<kiko> here: OOPS-711A312
<ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/711A312
<kiko> flacoste, can someone take a quick look into that? I think it's shallow.
<flacoste> i will
<danilos> we are also getting increased number of timeouts due to ongoing hardy translations opening
<kiko> the significant ones in the lpnet summaries
<kiko> danilos, when is that going to end? I had an ETA of 15h on tuesday :-/
<kiko> as I was saying
<kiko> the significant ones in the lpnet summaries
<kiko> are to do with the sane_description bug limit
<kiko> which is fixed on staging
<danilos> kiko: jtv should be tracking progress on that
<kiko> and a bunch of Unicode* issues
<kiko> danilos, okay. I'm just concerned about it
<danilos> kiko: it's hard to handle it timely with only one admin around
<mrevell_> Sorry, broadband problems. I won't be here next week.
<kiko> jtv, let's talk about this after the meeting.
<jtv> kiko: ok
<BjornT> kiko: are you done?
<kiko> BjornT, well, yeah. I wanted to point out only that a lot of tuesday oopses were related to the database being hammered by rosetta -- we even got some late pingdom alerts
<kiko> timeouts and weird database integrity errors
<jtv> constraint violations?
<kiko> yeah
<kiko> like +filebug crashing because there was no bugmessage there
<kiko> it looks like race conditions right and left
<BjornT> ok. no time to discuss that here, let's do that after the meeting.
<BjornT> thanks kiko. moving on.
<BjornT>  * Critical Bugs (mrevell)
<mrevell> Hello, Joey's on vacation today.
<mrevell> I only see one critical bug and it is marked Fix Committed.
<mrevell> I presume there's nothing to report back to Joey on that. the bug number is
<kiko> because we are a great team that fixes critical problems! :)
<mrevell> 173096
<mrevell> kiko: Yeah! :)
<mrevell> bug 173096
<ubotu> Launchpad bug 173096 in malone "Misleading "Content-Encoding: gzip" header on downloads" [Critical,Fix committed] https://launchpad.net/bugs/173096
<kiko> that's thank to bac
<mrevell> Thanks bac. So, unless there's something to report back to Joey on that, I'l hand back to you BjornT
<BjornT> thanks
<BjornT>  * Bug tags
<BjornT> no new bug tags have been proposed
<BjornT>  * Operations report (mthaddon)
<mthaddon> Staging codehosting is getting close to completion
<mthaddon> Staging update failed again but I believe it's now fixed per email from stub - will be doing a manual update after the meeting
<mthaddon> Copy-missing-translations script still running...
<mthaddon> PQM durations script broken and I'd appreciate if anyone could help me debug it
<mthaddon> That's it unless anyone has questions
<mwhudson> woo staging codehosting
<danilos> mthaddon: cool, just the news I was looking for, thanks for the report
<kiko> staging codehosting! wow!
<BjornT> thanks mthaddon
<kiko> mthaddon, what's left in that work?
<kiko> (BjornT, allow me just that quick question)
<BjornT> sure
<mthaddon> kiko, thumper has a branch that will setup the configs and allow codehosting to be completed
<kiko> mthaddon, will we have it in time for next week's QA
<mwhudson> setting up the syncing of actual branch data i think
<kiko> and are the code team planning on using it?
<mwhudson> kiko: partly, i think
<kiko> what's missing?
<mthaddon> kiko, we need a separate configs directory - bzr-staging
<mthaddon> with a bunch of custom config options
<kiko> mthaddon, I think that's fine by me. flacoste see any problem with it?
<mthaddon> discussed yesterday with thumper - not sure if it's already been submitted
<flacoste> kiko: nope, apart the usual config PITA
<mthaddon> but it just missed last night's update
<kiko> I think that landed today, didn't it?
<mwhudson> kiko: it'll be hard to test stuff to do with mirrored branches, i think
<kiko> mwhudson, hmmm. ok, tell me this after the meeting. thanks!
<mwhudson> yeah, the config branch landed a couple of hours ago
<BjornT> ok, moving on
<BjornT>  * DBA report (stub)
<BjornT> stub is not here. mthaddon, do you have a dba report?
<mthaddon> mwhudson, cool, I can do a manual update and it should be up and running then
<mthaddon> BjornT, fraid not
<BjornT> ok
<kiko> I have some DBA issues that might be worth mentioning
<BjornT> kiko: sure
<kiko> there is a small snag with patch 88-31-0 that is causing staging updates to fail, but it's already good; we'll do a manual rev now and it should work automatically tomorrow. if it doesn't please don't let it go by unnoticed
<kiko> we are considering upgrading the DB server hardware in the near future
<kiko> and stub's been working on the replication stuff which will be a welcome improvement
<kiko> does anyone have any DB patches that still need review or haven't landed yet?
<kiko> there is a small window of opportunity for us if you do need something
<kiko> I remember tom berger had mentioned a change but I've forgotten what it was
<kiko> anyone else?
<mwhudson> i have one change but it's no trivial i doubt it's worth it
<mwhudson> bug 151583
<ubotu> Launchpad bug 151583 in launchpad-bazaar "codeimportresult.date_started should be renamed to date_job_started" [Low,New] https://launchpad.net/bugs/151583
<allenap> I need a correction to security.cfg. Does that count?
<kiko> yes it counts
<BjornT> kiko: tom's patch would be about renaming the janitor. it's that that important, we can do it in the next cycle.
<BjornT> kiko: s/that/not/
<adeuring> I'd like to get lxml install at least for the PQM machine
<adeuring> s/install/installed/
<BjornT> adeuring: that's not a db patch, though! ;)
<kiko> adeuring, that needs an IS RT ticket, and an email to joey CC: launchpad to track it
<kiko> BjornT, okay, no problem.
<adeuring> kiko: I know; I already have a ticket
<kiko> allenap, can I see the diff anywhere? it should be rs=BjornT or something though
<flacoste>  BjornT: renaming the janitor shouldn't need a DB patch?
<allenap> kiko: Not yet, but I'll get it to you asap.
<flacoste> it's only modify production data, no?%
<BjornT> flacoste: right. it's less error prone doing it with a db patch, though.
<kiko> BjornT, I think it was something else that tom wanted IIRC
<flacoste> BjornT: putting a script to run on LaunchpadProductionStatus usually works fine also
<BjornT> kiko: maybe, let's look at that after the meeting.
<kiko> BjornT, hokay
<BjornT> moving on. talk to kiko about db patches, if you have any.
<BjornT>  * Sysadmin requests (mrevell)
<kiko> yes, talk to me. and send me money too
<mrevell> Does anyone have an RT number that they'd like to see chased up?
 * kiko looks at adeuring 
 * kiko looks at barry 
<flacoste> kiko, Rinchen is well aware of those
<jtv> mrevell: after staging is back on track, we'd like a re-run of that statistics script.
<adeuring> Yes... let me look for the number...
<flacoste> i think that elmo is currently taking care of #29298 (mailman on staging)
 * barry sends kiko a meelion dollars
<adeuring> ticket #29558
<mrevell> jtv: Is there an RT number with that?
<jtv> mrevell: mine is #29586.
<mrevell> thanks adeuring
<mrevell> thanks jtv
<kiko> good man adeuring
<statik> mthaddon: our squid setup on staging and production, I'd like to talk with you about that sometime after this meeting
<mthaddon> statik, sure
<kiko> statik, yeah, the feeds cache is important with this release because of announcements
<mrevell> I'll see if I can get a status from the sysadmin chaps on those and will report back. Thanks BjornT
<BjornT> thanks
<kiko> indeed thanks BjornT
<BjornT>  * A top user-affecting issue (mrevell)
<mrevell> Ah me again
<mrevell> For today's user affecting issue, I'd like to raise bug 139495 and an associated problem.
<ubotu> Launchpad bug 139495 in launchpad "Beta testers are redirected even when logged out" [Undecided,Confirmed] https://launchpad.net/bugs/139495
<mrevell> mpt's bug report describes how, although not logged in, he was redirected to edge when following a link from Google. This was because he already had the cookie to say he was a beta tester.
<kiko> hmmmm
<mrevell> The associated problem is reported as when a beta tester logs in at launchpad.net, on a browser without previous LP session cookies, they are redirected to edge.launchpad.net where they are required to log in again.
<kiko> okay. so we should clear that cookie when logging out?
<mrevell> Logging out from edge results in a redirect to launchpad.net where the user is still logged in. Trying to log out from launchpad.net results in a redirect to edge, where the user is already logged out.
<kiko> flacoste, what do you think?
<flacoste> is jamesh around?
<statik> this annoys me every single day
<jtv> sometimes it'd be nice to have a production.launchpad.net
 * flacoste doesn't know the details of that to have an opinion
<statik> well, the logging in twice annoys me. I don't do the logout thing that often
<flacoste> but I know the redirection coed also cause problems in the tests
<flacoste> but that's probably another issue
<mrevell> Perhaps I should raise this on the list and then we can discuss further.
<flacoste> mrevell: i'll look into this
<mrevell> thanks flacoste
<BjornT> thanks mrevell
<BjornT>  * Survey: Are you using lpreview yet? (mwhudson)
<sinzui> me
<statik> not me
<gmb> me
<barry> not me (haven't had a new branch yet)
 * mwhudson hopes the topic is clear, i mailed the list a week ago
<flacoste> not me
<ddaa> yes, lpreview is love
<BjornT> me
<jtv> not me
<EdwinGrubbs> not me
<kiko> thanks guys.
<danilos> not me
<kiko> I haven't tried lpreview yet.
<mwhudson> those who haven't: please try
<jsk> not yet
<allenap> not me
<kiko> so
<mwhudson> those who have: please tell me where it sucks
<BjornT> those of you who answered 'not me', why aren't you using it?
<kiko> by next week
<kiko> those who said "not me"
<kiko> please try it at least once and have feedback to submit
<danilos> kiko: I won't have a chance to do that by next week
<kiko> mwhudson, I will tell you this: I will be really motivated to use it when it has a backend.
<ddaa> got feedback
<kiko> danilos, vacationers are excused.
 * mwhudson points kiko at gmb 
 * barry will try it for his next new branch
<kiko> gmbeeee
<mwhudson> but yeah
<allenap> Is it a replacement for the general queue, or in addition?
<danilos> ok
<mwhudson> allenap: addition at the moment
<flacoste> i asked for a feature that it outputs the thing you can paste on PendingReviews
<ddaa> allenap: ATM it works best with on-call reviewers
<mwhudson> flacoste: yeah, i'll try and do that today
<gmb> kiko: Let me get my bugs work out of the way and I'll make you very happy. In a coding sense.
<allenap> Cool, I'll give it a go :)
<mwhudson> flacoste: can you send a mail to remind me? :)
<kiko> gmb, O K!!
<flacoste> mwhudson: i will
<mwhudson> thanks
<mwhudson> BjornT: enough on this, i think
<BjornT> ok. so those who haven't tried lpreview yet, please do so until next week
<BjornT> moving on
<BjornT>  * Blockers
<BjornT> Bugs team: not blocked
<flacoste> Foundations Team: Blocked on MailMan setup on staging (RT #29298)
<jtv> Translations team: not blocked
<statik> lpcomm team: not blocked
<kiko> I know I am blocking: bjorn on comment imports and reviewing the bugzilla spec
<cprov> Soyuz team: not blocked (cprov-only this week)
<mrevell> Releases team: Not blocked.
<schwuk> HWDB: No
<kiko> schwuk and adeuring on some hwdb org updates
<ddaa> Code team: not blocket
<kiko> and maybe cprov needs to look over soyuz 1.1.12 final?
<schwuk> kiko: True, but on the current work, no
<BjornT> anyone from SC here?
<kiko> I think they are boycotting this channel <wink>
<BjornT> ok, except for SC, it should be all
<cprov> kiko:  sure, I'm dealing with the last trivial bugs (some wip will slip for 1.2.1, for sure)
<BjornT> thanks guys
<BjornT> MEETING ENDED
<jtv> BjornT: thanks for running the show again :)
<kiko> cprov, no problemo. let's chat tonight.
<mwhudson> BjornT: thanks
<cprov> kiko: ta
<kiko> BjornT, you're good at this! but I would like flacoste to run the next one, if he could
<mrevell> thanks BjornT
<flacoste> kiko: sure
<BjornT> kiko: sure, i don't mind someone else doing it :)
<kiko> thanks francis
<kiko> you are a good volunteer
<flacoste> kiko: i'm especially good at being volunteered ;-)
<kiko> not surprised at that. :)
<kiko-phone> danilos, you want to get your hostmask fixed, yeah?
<danilos> kiko-phone: yeah
<kiko-phone> and you're identified?
<danilos> kiko-phone: yes
<kiko-phone> okay. let's get an admin
<danilos> kiko-phone: basically, "danilo" has mine, and I am "danilos" on freenode :)
<kiko-phone> oh!
<danilos> kiko-phone: yeah, tell that to mako who spent some time trying to convince "danilo" how he should remember him :)
<kiko-phone> lol
<danilos> kiko-phone: I'll have to go out now, will be back later: do you need me for this?
<kiko-phone> danilos, I don't think so. I'm still waiting for a response on #freenode
<danilos> kiko-phone: ok, cool, thanks a lot
<kiko-phone> thanks to you
#launchpad-meeting 2008-12-08
<sinzui> EdwinGrubbs: standup in two minutes. You are not on #launchpad...did you client not like the new cert.
#launchpad-meeting 2008-12-09
<barry> #startmeeting
<MootBot> Meeting started at 21:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everyone and welcome to this week's asiapac reviewers meeting.  who's here today?
<barry> mwhudson_, jml, thumper ?
<jml> barry: !
<thumper> hi
<mwhudson_> hellooo
<barry> hi!
<barry> how is everyone today?
<thumper> frustrated
<barry> thumper: dang, what's up?
<thumper> barry: [testfix] annoyances, and the way most of the email processing is hardcoded to malone
<barry> on the first, i feel your pain
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Printing strings in doctests (barry)
<barry>  * Gavin's `pretty()` function (allenap)
<barry>  * Sabbaticals? (barry)
<barry>  * Do we need a standard cover letter template for merge proposals? (barry)
<barry>    * [[attachment:cover.txt]]
<barry>  * If there's time, the old boring script
<jml> barry: I'm well. Busy and getting things done, but frustrated by the slow speed of almost all of our technologies and by the way that Launchpad still doesn't make it easier for my work to flow.
<barry>    * Next meeting
<barry>    * Action items
<barry>    * Mentoring update
<barry>    * Queue status
<barry> wow, there must be something in the air down there today :/
<mwhudson> i'm just generically grumpy, i don't think there's any particular reason
 * barry thinks we should sprint for two weeks on *that*
<mwhudson> so maybe you're right!
<mwhudson> (also it's not sunny today)
<thumper> I haven't had enough coffee
<thumper> and I'm all out of beans
<jml> thumper: :(
 * sinzui has cans of emergency espresso
<jml> anyway, we are all here, right?
 * thumper laughs at sinzui
<mwhudson> sinzui: i had emergency coffee in a can from a vending machine in tokyo.  it was a strange experience :)
<barry> well, let's jump right in and get this over with ;)
<jml> barry: yes, let's :)
<barry> [TOPIC]  * Printing strings in doctests (barry)
<MootBot> New Topic:   * Printing strings in doctests (barry)
<barry> so, in a couple of recent reviews, we've talked about doctests, and print strings instead of just returning them
<jml> wherefore?
<barry> this is useful if you don't care whether you're getting a unicode or 8-bit, and because nobody cares about quotes
<thumper> barry: I normally print strings
<barry> thumper: excellent
<thumper> barry: if I feel the need to write doctests
<sinzui> returning them shows if they are unicode or ascii
<thumper> barry: which I normally don't
<barry> thumper: right :)
<barry> sinzui: right.  you rarely care
 * sinzui does not like print strings in translations and answer tests
 * thumper doesn't care
<jml> barry: ok. so this is just heads up on another review checklist item?
<barry> jml: yep
<jml> barry: where *does* that review checklist live?
<barry> jml: it's still in the old wiki, but i think i know what i might spend my hour of wiki gardening on :)
<jml> heh heh.
<barry> though, that's not the canonical wiki, but still
<barry> now, i just have to clear that with my team leader
<barry> that's all i have on this topic anyway
<jml> cool.
<barry> [TOPIC]  * Gavin's `pretty()` function (allenap)
<MootBot> New Topic:   * Gavin's `pretty()` function (allenap)
<barry> so, just another heads up.  allenap landed a nice addition in a recent branch
<barry> pretty() is just the global binding for python 2.5's pprint function
<barry> which fixes dictionary ordering
<barry> yay!
<barry> so it's something that we as reviewers can encourage devs to use when the opportunity comes up
<thumper> are we using python 2.5?
<jml> 2.4 has pprint
<jml> (2.3 has pprint, even)
<barry> thumper: nope.  he just installed 2.5's pprint module in a special place
<barry> jml: yep, but < 2.5 has a bug in dictionary printing where order is not guaranteed
<jml> I guess that's a bug if you love doctests :)
<barry> lol
<mwhudson> pprint appeared in 1.2 or something :)
<barry> or review them... <wink>
<barry> anyway...
<barry> [TOPIC]  * Sabbaticals? (barry)
<MootBot> New Topic:   * Sabbaticals? (barry)
<thumper> you going somewhere?
<thumper> oh
<thumper> I know
<barry> thumper: yep.  fridays/west :)
<thumper> you want to come to the code team
<thumper> :)
<barry> thumper: well, i gotta give BHO a chance first
<jml> what's all this about?
<jml> bho?
<barry> okay!
<thumper> Obama
<barry> so, intellectronica asked for a break from reviewing, so we really just came up with a (very loose) policy on that
<thumper> barry: we'd have you even if you stayed where you are
<barry> basically we have enough reviewers so people can take short breaks
<barry> the policy is that you have to clear it with me first.  i promise i won't charge you much
<barry> thumper: whatever happened to that cross-team training?
<thumper> barry: it didn't take too well
<jml> barry: Launchpad 2.0 partly
<barry> unfortunately, i don't know how much this affects you guys becuase of the timezones, but i wanted to communicate the decision to you anyway
<jml> barry: thanks.
<thumper> barry: I think people get stuck with what they're into
<sinzui> I thought the new policy was to move people every 12 months
<thumper> sinzui: there is a policy?
<jml> barry: I think the summary is that we don't really need to take sabbaticals because the load is pretty low, and there are so few of us that sabbaticals would leave a shortage of reviewers.
<mwhudson> jml: +1
<barry> jml: cool
<sinzui> In September we decide where priorities lie and juggle people.
<barry> sinzui: that's an interesting idea.  i think some people would be up for trying new things and others like it where they are
 * sinzui was on 4 teams in 18 months
<jml> next item?
<barry> [TOPIC] Do we need a standard cover letter template for merge proposals? (barry)
<MootBot> New Topic:  Do we need a standard cover letter template for merge proposals? (barry)
<barry> i proposed a rough draft at last week's ameu meeting.  i have a more fleshed out example:
<thumper> I think we should have one
<barry> https://dev.launchpad.net/ReviewerMeetingAgenda?action=AttachFile&do=view&target=cover.txt
<barry> it's probably too much to read right now.  i'll send an email
<mwhudson> barry: it's certainly pretty long
<barry> i've been using it for my last several branches.  i try to start writing it before i start hacking
<barry> mwhudson: mostly because it has examples
<barry> mwhudson: the headings are really the only useful bits
<mwhudson> ok
<barry> jml, mwhudson do you think it would be useful to have a standard (even if this one isn't it)?
<jml> barry: yes, but I think it's more useful as a tool than as a mandatory form, if you catch my drift?
<mwhudson> barry: yes, especially if we can have a tool to write chunks of it
<barry> jml: as part of a tool?  e.g. resurrect that bzr plugin perhaps?
<jml> barry: I mean, the culture around it should be "use it as much as it helps", not "you must fill in each field"
<barry> jml: gotcha.  i agree
<thumper> jml: +1 on that
<barry> thanks.  good feedback
<barry> [TOPIC]  * Peanut gallery (anything not on the agenda)
<MootBot> New Topic:   * Peanut gallery (anything not on the agenda)
<barry> that's it from me.  do y'all have anything for me or the ameus?
 * jml thinks
<jml> an idea that's only tangentially related...
<jml> Twisted has this thing where information about the tests for a module live in comments (as emacs variables) in that module
<jml> That could gradually replace "run <foo> to test these changes"
<jml> that's out of scope for this meeting though.
<jml> ignore me.
<barry> jml: i'm interested in hearing more, but perhaps on the ml?
<sinzui> jml: that sounds like allenap's branch that runs the tests from the code coverage report.
<jml> barry: *nod*
<jml> sinzui: yeah, this is just less magic & more explicit.
<mwhudson> it also coincides a little with my rant about "tests should be in directories called 'tests'"
<sinzui> +1
<jml> mwhudson: :)
<barry> +1
<barry> sinzui: sounds like we have enough material for at least 2 2-week hackathons :)
<sinzui> Happy holidays
<barry> :-D
 * sinzui is planning the death of blueprints
<barry> forced vacations == +1
<jml> sinzui: heh heh
<barry> on that note.  anything else from you guys?
<jml> barry: meeting next week?
<thumper> sinzui: I'd like to see that plan
<barry> jml: same time and place?
<jml> cool.
<jml> I'm done
<sinzui> thumper: When I can fit it on one page, the plan is ready for publishing
<thumper> barry: sounds good to me
<barry> jml: i think we have one or twomore left for the year.  i'll leave it up to you if we do the 23rd or not
<barry> you == y'all
 * jml nods
<barry> i probably will /not/ have an ameu meeting on the 24th
 * thumper plans to be away on the 23rd
<barry> k
<barry> with that...
<barry> #endmeeting
<MootBot> Meeting finished at 21:29.
<barry> thanks guys
<jml> barry: thanks
#launchpad-meeting 2008-12-10
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello and welcome to this week's ameu reviewers meeting.  who's here today?
<rockstar> me
<EdwinGrubbs> me
<adeuring> me
<flacoste> me
<rockstar> That's it?
<barry> wow, light attendance today <wink>
<barry> allenap: ping
<allenap> me
<barry> bac_uds: hopeful ping
<barry> bigjools: ping
<barry> BjornT: ping
<barry> cprov: ping
<bigjools> me
<barry> gmb: ping?
<barry> intellectronica: ping
<barry> mars: ping
<barry> salgado: ping
<bigjools> it's 7 in the morning for cprov at UDS
<intellectronica> me
<BjornT> me
<barry> bigjools: what's his cell #?  let's wake him up :)
 * barry is not sure who's at uds
<rockstar> Ooh, that's bad...
<bigjools> 1-800-EAT-SHIT
<rockstar> !
 * barry dials
<mars> me
<barry> bigjools: hey, waiiittt a minute!
<bigjools> :)
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Printing strings in doctests (barry)
<barry>  * Gavin's `pretty()` function (allenap)
<barry>  * Do we need a standard cover letter template for merge proposals? (barry)
<barry>    * [[attachment:cover-quick.txt]]
<barry>    * [[attachment:cover.txt]]
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  * If there's time, the old boring script
<barry>    * Next meeting
<barry>    * Action items
<barry>    * Mentoring update
<barry>    * Queue status
<barry> [TOPIC]  * Printing strings in doctests (barry)
<MootBot> New Topic:   * Printing strings in doctests (barry)
<barry> so, i mentioned this in a couple of reviews as well as in the asiapac meeting, with some positive feedback
<barry> the idea is that in docstrings, you should (usually) be printing the value of strings instead of returning them
<sinzui> me
<barry> the advantage of that is that you usually don't care if its unicode or str, and you're not saddled with extraneous noise like u' and '
<barry> e.g.
<barry> instead of
<barry> >>> foo['key']
<barry> u'baz'
<barry> you'd do
<barry> >>> print foo['key']
<barry> baz
<barry> thoughts?
<salgado> me!
<salgado> sorry, I'm late
<intellectronica> yes, i also prefer printing
<bigjools> barry: +1
<sinzui> Unless we fix/hack the the testrunner, translations and answers tests will fail
<barry> sinzui: right.  hence the "usually" :)
<rockstar> barry, +1
<barry> so, as reviewers just be aware of that in code you review and suggest conversion to printing strings
<barry> any objections?
<adeuring> none, just a questin:
<barry> adeuring: go4it
<EdwinGrubbs> I think that the bug really needs to be fixed in the testrunner, since it doesn't tell you which line the error is on when you try printing out a unicode character, the whole doctest just fails, so you end up commenting out half your test  to find the offending line.
<adeuring> what, if we want to test, if we want to check that we have for eaxmpale a string object, but not a unicode object?
<adeuring> print repr(foo)
<rockstar> EdwinGrubbs, +1
<barry> EdwinGrubbs: totally agree.  it's not like we don't actually have proposed fixes either :)  iirc it's a bug in zope upstream
<adeuring> I mean, whould we use explicity the print statment,
<barry> adeuring: in that case you can either return the value and show the u''
<adeuring> or should we allow the simple >>> foo
<barry> adeuring: or, use isinstance(foo, unicode)
<barry> adeuring: or even print foo.encode('utf-8')
<rockstar> I'd prefer the second choice.
<barry> rockstar: for a pure type test, i agree
<rockstar> barry, yea' and if you want the value, you'd use print.
<adeuring> barry: OK, though explicit encoding can make things more difficult to read
<barry> rockstar: right
<barry> adeuring: yep.  if we had a fixed testrunner we could just print it
<barry> flacoste: can we ask gary to look into fixing this upstream for us?
<adeuring> barry: ...or use repr(u'Ã¤Ã¼Ã¶')
<flacoste> barry: gary doesn't have on the testrunner
<adeuring> slightly better to read than the encoded string
<flacoste> barry: but he can send emails
<flacoste> barry: but anyway, we are way behind upstream here
<flacoste> barry: so we should just fix our stuff for now
<rockstar> flacoste, +1
<barry> flacoste: maybe when we move to 2.6 :)
<barry> and zc.buildout :)
<flacoste> 2.6 is crack!
<barry> :-D
<barry> anyway for now, just be aware of this in reviews and make friendly suggestions
<barry> [TOPIC]  * Gavin's `pretty()` function (allenap)
<MootBot> New Topic:   * Gavin's `pretty()` function (allenap)
<barry> allenap landed a branch with a nice pretty() function in doctest globals
<flacoste> don't use it for API tests btw!
<barry> although i've since heard that lazr has something similar, right flacoste ?
<sinzui> zope.testing.doctest:1486
<sinzui>     sys.stdout = self._fakeout
<sinzui> Becomes
<sinzui>     from codecs import EncodedFile
<sinzui>     sys.stdout = EncodedFile(self._fakeout, "ascii", "utf-8")
<allenap> flacoste: too late.
<barry> flacoste: why?
<barry> sinzui: yes, excactly
<flacoste> because there is pprint_entry and pprint_collection
<flacoste> that does that + other stuff
<barry> flacoste: ah
<flacoste> for example, it omits the etag key
<flacoste> so pretty() is fine for non-API stuff
<barry> flacoste: do we need a dev/reviewer style guide for apis?
<flacoste> yeah, we probably do
<allenap> flacoste: Yeah, agreed, the pprint_* functions are better for API. I'll clean up my API stuff that uses pretty().
<flacoste> salgado started something if i recall
<flacoste> or maybe it was for the coder perspective
<flacoste> but yes, i'll do a API reviewer cheatsheet
<barry> [ACTION] flacoste to do an API reviewer cheatsheet
<MootBot> ACTION received:  flacoste to do an API reviewer cheatsheet
<barry> flacoste: thanks!
<flacoste> or add a section to the reviewer cheet sheet
<barry> btw, rs=barry for any cleanup that consolidates pretty() and lazr's pretty printer
<salgado> flacoste, barry, https://launchpad.canonical.com/API/StyleGuide is what I wrote
<barry> salgado: nice, thanks
<barry> [TOPIC]  * Do we need a standard cover letter template for merge proposals? (barry)
<MootBot> New Topic:   * Do we need a standard cover letter template for merge proposals? (barry)
<barry> i mentioned this last week.  this week i have two examples.  one a quick outline and the other more detailed, with examples
<barry> https://dev.launchpad.net/ReviewerMeetingAgenda?action=AttachFile&do=view&target=cover-quick.txt
<barry> https://dev.launchpad.net/ReviewerMeetingAgenda?action=AttachFile&do=view&target=cover.txt
<barry> putting aside the issue of tool support for this, what do you think about encouraging devs to use this in mps?
<barry> the thing i like about it is that everything's in one comment
<barry> so when you get the mp email, you've already got the description, the lint, and the diff
<barry> and it makes it very easy to respond in email
<barry> i really hate it when i have to review a branch, but it's spread out over several emails
<rockstar> barry, I don't like that either.
<rockstar> I usually try and consolidate it into one reply.
<barry> rockstar: right, which isn't always easy depending on your mua :)
<rockstar> Yea.
<rockstar> (vim ftw)
<barry> rockstar: claws + emacs + emacsclient :)
<bigjools> jeez, copy and paste ffs :)
<barry> anyway.  +1, -1  for the cover standard?
<bigjools> +0
<rockstar> barry, which one is would be the standard?
<barry> rockstar: they're the same except for the explanatory text and examples in the long one
<barry> rockstar: so cover-quick.txt is the template most people would use
<bigjools> how much of the stuff in the template should we / can we put in the MP form?
 * sinzui has been pasting it all
<barry> sinzui: right.  the idea is that you begin filling out the form right when you start working on the branch.  lots will be empty, but you fill it in as you think about the fix, get a pre-imp, hack the code, etc
<barry> when you're ready for the mp, you paste the whole thing
<rockstar> barry, why do we need bug XXXXXX section?
<barry> rockstar: as the longer example says, it's to translate the bug description into human
<sinzui> barry: correct. I do,
<barry> from the native "user" :)
<rockstar> Hm.  I think if I read the bug itself, and then read the solution, I could deduce the issues myself.
<barry> rockstar: remember, we're trying to make things fast and easy for reviewers
<bigjools> doesn't the branch link to the bug if you say --fixes?
<barry> rockstar: so the dev should do more work upfront (imo)
<rockstar> bigjools, yes
<barry> rockstar: the idea is.  i'm going to review your branch in 5 minutes.  i should have everything i need right there in that one email
<rockstar> barry, I'm all for people making the reviewer's life easier.
<barry> rockstar: don't make me go looking around the world unless i want to
<bigjools> I think that doing that and having the reviewer follow a link is better than the dev re-writing the bug description
<barry> bigjools: the problem is that many bug have poor descriptions, or long conversational threads
<barry> bigjools: i think it's the dev's resposibility to boil it down to: "Bug XYZ describes this very specific problem"
<rockstar> barry, so why can't that translation to human be in the bug.
<bigjools> barry: so I would rather the root cause was fixed then - lets update the bug
<barry> i guess the point is that i don't want to have to hunt around in the bug.  i want to read my email, do my review and be done with it
<rockstar> barry, maybe that would make sense as a sentence in the pre-implementation of implementation section.
<bigjools> I hear we've got this funky tool called Launchpad that stores all this stuff for us ;)
<barry> i should try to find a real-world example to show you what i mean.  it's really just a 2 sentence summary
<barry> and you can just cut-n-paste the bug description if it's in human readable form
<rockstar> If there's good information about the bug itself, I feel it really belongs in the bug, not the merge proposal.
<barry> but if it's not, or the bug has a long conversational thread that eventually gets around to the real bug, then 2 sentences, boom you're done, and you've helped reduce reviewer friction
<rockstar> It may be just two lines, but it's still segmentation of information.
<bigjools> let me propose this:  if the bug's description was included in the branch page (is it already?) and the email, and the description was updated if it's inaccurate, would that suffice?
<barry> rockstar: this isn't a big detailed thing, it's a summary.  the cover can always say there are important details in the tracker issue
<rockstar> QA might not know to go look at the merge proposal for the actual explanation.
<sinzui> rockstar: I summarize the bug because I don't want to make you spend 20 minutes reading all the comments that were not relevant to diagnosing the root cause
<barry> bigjools: sure.  if it were included in the email that would help
<barry> sinzui: exactly
<rockstar> sinzui, I understand that, and I agree it's helpful.  I just think that we have all these buckets where certain types of information go.
<bigjools> barry: great - I just hate the idea of re-writing the bug description and not including it in the bug report!
<barry> this is all about reducing reviewer friction
<rockstar> barry, and I agree it needs to happen.
<rockstar> I also like to make sure that the branch is linked to the appropriate bugs it fixes.
<sinzui> rockstar: secondly, I may land five branches to fix a bug, each branch focuses on an aspect of the bug that is strictly scoped so that I have small branches
<barry> bigjools: i have no problem if the workflow is: dev updates the bug description to accurately reflect the root cause of the problem being reported, then cut-and-pastes that into his cover letter :)
<BjornT> i think we should rename 'Bug XXX' to 'Summary', and concentrate on describing what the branch contains, rather than what the bug was.
<barry> sinzui: excellent point!
<rockstar> BjornT, +1
<intellectronica> +1, and we already have that in the submission form, so the only thing is to make sure that it's displayed conveniently both on the web and in email
<bigjools> BjornT: again, I think that should be recorded in LP, with the branch.  It can be sent with the email.
<barry> BjornT: Summary of Bug XXXXX and i'm on board with that
<bigjools> barry: not all branches are bug fixes though
<barry> bigjools: hmm. okay
<BjornT> barry: well, as sinzui said, he might land five branches to fx
<barry> but they should be, right? :)
<BjornT> fix a single bug
<bigjools> barry: blueprints? :)
<rockstar> barry, two lines in of the faur line Summary can be devoted to it.
<BjornT> barry: should he include the same bug description in all five merge proposals?
<rockstar> s/faur/four
<barry> bigjools: i've heard it's a great way to increase your karma
<bigjools> barry: you get more for blueprints! :)
<barry> BjornT: when i've done that, the first sentence is the same, but then the rest of that summary section goes on to explain the sub-issue this branch is addressing
<barry> but i'm okay with Summary
<BjornT> barry: right. in that case you're not summarizing the bug report; you're summarizing your branch
<barry> as long as i don't have to guess which bug it's addressing
<barry> BjornT: cool, i'm convinced.  Summary sounds good
<barry> i'll make that change and take it to the ml
<BjornT> i do agree that the summary should explain in words what issue was fixed, rather than just saying 'fixes bug xxx'.
<barry> btw, i really appreciate all the good feedback.  ultimately this is about making things easier for us reviewers!
<barry> you should work harder when your dev hat is on :)
<barry> BjornT: +1
<bigjools> as someone once said to me, we're being worked like camels already :)
<barry> bigjools: :)  reducing dev friction is a whole 'nuther topic
<barry> but not for today :)
<bigjools> 5 mins left!
<barry> [TOPIC] # Peanut gallery (anything not on the agenda)
<MootBot> New Topic:  # Peanut gallery (anything not on the agenda)
<barry> bigjools: what a great straight man you are!
<barry> so, the floor is open.  do you have anything not on the agenda?
<rockstar> How are merge proposals going?
<rockstar> We're fixing bugs to get things easier to use.
<bigjools> I think they're great, but I think they could prompt us for the info that barry wants :)
<rockstar> Is anyone noticing?
<flacoste> bigjools: honestly, i don't think so
<flacoste> form filling is boring
<barry> rockstar: you had me at "PendingReviews is dead".  i think they're great
<bigjools> flacoste: you'd rather copy & paste a template?
<sinzui> flacoste: but note taking is safe and satisfying.
<rockstar> barry, Hurray!
<flacoste> yeah, free form text FTW!
<barry> tool support would definitely make it easier
<barry> rockstar: plus i want a button to re-send me the mp email :)
<bigjools> I like being reminded of things, I'm not getting any younger!
<BjornT> flacoste: +1
<barry> flacoste, rockstar how much of the mp stuff is exposed in the api?
<BjornT> bigjools: you should be able to use 'bzr send' and have the template come up in your text editor.
<bigjools> BjornT: bzr send creates MPs?
<rockstar> barry, the basic read only stuff landed last week.
<barry> BjornT: though of course, you've already started the template when you began to think about the bug, had your pre-impl, etc. <wink>
<BjornT> bigjools: well, somehow you should be able to submit MPs from bzr
<rockstar> bigjools, it will, as soon as abentley gets back from UDS.
<barry> BjornT: big +1 there
<rockstar> BjornT, yea, that's the idea.
<bigjools> BjornT: agree
<bigjools> rockstar: that would be very cool!
<intellectronica> personally, i would rather have web forms (and perhaps the ability to bypass them using the API)
<intellectronica> and i think they would be very good for are users too
<bigjools> well both - choice is good
<rockstar> So diffs and bzr send are the big ones for mp right now then?
<barry> rockstar: i think so
<barry> oops, look at the clock.  we're the time go?
<rockstar> Cool.  I'll bring that up in the meeting.  I know the code has been landing, just don't know the specifics.
<barry> anything else before we break?
<barry> 5
<BjornT> rockstar: especially the possiblity to attach diffs (rather than having them generated automatically, which is also nice of course)
<barry> 4
<barry> 3
<rockstar> BjornT, agreed
<barry> 2
<barry> 1
<rockstar> Break!
<barry> #endmeeting
<MootBot> Meeting finished at 09:47.
<barry> thanks everyone!
<allenap> Thanks barry.
<rockstar> BjornT, technically, bzr send uses attachments to send the diff.  Is that what you're saying?
<BjornT> rockstar: kind of. what i want is to have the diff attached to the outgoing e-mail notification (not appended as normal text). this is for both new merge proposals, and for replies, where the coder is attaching a diff of his changes.
<rockstar> Ah, so when you receive a mp email, the diff is an attachment?
<BjornT> rockstar: yes, that is what i want. that way it's easy to get to the diff. it's easier to go to the next attachment, rather than paging through the comment to find the beginning of the diff.
<rockstar> BjornT, okay, noted.  I'll see what I can do.
<BjornT> rockstar: cool, thanks.
#launchpad-meeting 2008-12-11
<matsubara> #startmeeting
<MootBot> Meeting started at 09:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<henninge> me
<intellectronica> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<herb> me
<Ursinha> me
<stub> me
<matsubara> sinzui, flacoste?
<rockstar> me
<flacoste> me
<matsubara> bigjools: ?
<bigjools> meeeeeeee
<sinzui> m,e
<sinzui> me
<matsubara> all right, everyone is here
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
 * sinzui hates windows that steal focus
<matsubara>  * Next meeting
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs
<matsubara>  * QA pending items
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (DBA contact)
<matsubara> [TOPIC] * Next meeting
<MootBot> New Topic:  * Next meeting
<matsubara> same time next week?
<matsubara> I'll be on vacation, so Ursinha will take over
 * bigjools is out for 3 weeks
<Ursinha> o/
<matsubara> [action] matsubara to add himself and bigjools to the apologies list
<MootBot> ACTION received:  matsubara to add himself and bigjools to the apologies list
<matsubara> bigjools: can you arrange for someone in soyuz to cover for you?
<bigjools> matsubara: yep
<matsubara> bigjools: thanks
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>  * matsubara email stub asking for the DBA report
<matsubara>  * matsubara to talk with gmb and add sql to hide bug 2-9-7-3-8-8 as a fix for bug 300324
<matsubara>  * rockstar to talk with code team about their pending QA items
<matsubara>  * henninge  to talk with translation team about their pending QA items
<matsubara>  * Ursinha to talk with bigjools about one account on dogfood machine to do some testing
<ubottu> Error: Launchpad bug 2 could not be found
<matsubara>  * rockstar to handle bug 271879 today (12-04)
<matsubara>  * Ursinha to watch timeouts in the next days to see if they continue to happen this often
<ubottu> Launchpad bug 300324 in malone "Bug 297388 OOPSing because had its 0 comment deleted" [High,Triaged] https://launchpad.net/bugs/300324
<matsubara>  * rockstar to manage having something reported on bug 118625 and bug 156453
<matsubara>  * Ursinha to watch for strange OOPSes on edge in the next days
<ubottu> Bug 271879 on http://launchpad.net/bugs/271879 is private
<ubottu> Launchpad bug 118625 in launchpad-bazaar "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/118625
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,In progress] https://launchpad.net/bugs/156453
<Ursinha> oh yeah
<Ursinha> I've opened a RT to get access to mawson
<rockstar> matsubara, first item is talked about everyday now.
<matsubara> I did both of mine and gmb added the query to the the LPPS page effectively hiding the problematic bug
<Ursinha> matsubara, great
<Ursinha> I've watched for the oopses and nothing that bizarre came up
<rockstar> matsubara, the fix for the timeout bug is approved, but we need to do some query testing.
<matsubara> thanks rockstar. Is the daily nagging helping QA testing?
<rockstar> matsubara, my team doesn't like nagging, but they're getting to it.
<matsubara> Ursinha: anything unusual about the strange OOPS and timeouts?
<Ursinha> matsubara, nothing that's not reported and being taken care of
<matsubara> henninge: how's the daily nagging about pending QA items going? is it helping your team?
<henninge> matsubara: Well, currently all items have been tested that could have been.
<henninge> matsubara: danilo is at UDS right now and jtv doesn't have anything else to test.
<matsubara> great. thanks henninge
<henninge> matsubara: we'll keep reminding ourselves ...
<matsubara> cool
<matsubara> moving on
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<Ursinha> okay
<matsubara> Ursinha: do you want me to do it?
<matsubara> all right, go ahead
<Ursinha> matsubara, just saw sinzui was talking to salgado about bug 304113
<ubottu> Launchpad bug 304113 in launchpad-registry "Milestone:+index page timing out" [High,Triaged] https://launchpad.net/bugs/304113
<Ursinha> oops, this wasn't for you matsubara, sorry :)
<sinzui> Ursinha: we will start working on it in a few hours
<Ursinha> sinzui, great, thanks
<Ursinha> henninge, can you ask someone on translations to set priority and importance on bug 302798, please?
<ubottu> Launchpad bug 302798 in rosetta "Timeout on +translate page" [Undecided,New] https://launchpad.net/bugs/302798
<henninge> Ursinha: yes
<Ursinha> henninge, thank you :)
<matsubara> priority and importance ?
<Ursinha> erm
<matsubara> we have only importance :-)
<henninge> status and importance
<Ursinha> status and importance, sorry :)
<henninge> Ursinha: I knew what you meant ... ;)
<matsubara> anything else Ursinha ?
<Ursinha> rockstar, you
<rockstar> Me?!
<Ursinha> rockstar, do you know anything about bug 305367
<ubottu> Bug 305367 on http://launchpad.net/bugs/305367 is private
<Ursinha> ?
<Ursinha> grrr
<Ursinha> it's a critical one
<Ursinha> the only one we have
<Ursinha> it's really critical?
<rockstar> Ursinha, I don't think they are critical.
<rockstar> activereviews is for your own code.
<Ursinha> rockstar, stub marked it critical
<rockstar> I'm working on the pages to generate a list of reviews you need to vote on.
<Ursinha> rockstar, right.
<rockstar> I'm going to bring it down from critical, anh talk with stub.
<stub> I marked it critical because I couldn't see a work around and might lose things. Feel free to point me at a work around :)
<Ursinha> rockstar, thank you very much
<rockstar> stub, no work around.
<rockstar> stub, I think your people should be contacting you to tell you about them.
<Ursinha> I'm done after that
<rockstar> That should be the workaround right now.
<stub> rockstar: Not really an option with the db review windows - I'll use a wiki page next cycle.
<rockstar> stub, next cycle you'll have the page you're looking for.  I'm working on it now.
<rockstar> But activereviews is for seeing the code you've proposed for review and its status.
<stub> Ok.
<matsubara> all right, moving on.
<matsubara> thanks everyone
<Ursinha> thanks guys
<matsubara> [TOPIC] * QA pending items
<MootBot> New Topic:  * QA pending items
<Ursinha> right
<Ursinha> so we have a lot of items to be tested
<rockstar> We have too many still, and the ones that are getting done aren't getting recorded.
<rockstar> :/
<matsubara> why not?
<Ursinha> rockstar, this is a problem
<rockstar> Ursinha, I'll talk with thumper about it.
<Ursinha> rockstar, you'll lost yourselves with that
<Ursinha> rockstar, okay. I'm on my late shift today, will talk to thumper as weel
<Ursinha> *well
<matsubara> rockstar: what's the issue about recording what's been tested?
<rockstar> matsubara, no idea.  I know some of these things have been tested.
<matsubara> rockstar: right, so it's just a matter of updating the wiki page or something else?
<rockstar> matsubara, wiki page.
<matsubara> I see. if the process to update the test plan page is too troublesome we need to find a better way. suggestions welcome.
<rockstar> matsubara, also, this week has been abnormally busy with the ec2 stuff.  It might be that recording it isn't at the front of their minds.
<rockstar> matsubara, I need to think about that.
<intellectronica> fwiw there's quite a lot of talk about using launchpad itself to track qa. if anyone has good ideas please let them be known
<Ursinha> rockstar, thanks.
<Ursinha> intellectronica, indeed
<rockstar> intellectronica, yea, I was going to think about that.
<rockstar> The Ubuntu guys might be happy to have qa handled in Lanuchpad.
<rockstar> also, Launchpad.
<intellectronica> so i hear, yes
<Ursinha> any suggestions/ideas are very welcome
<matsubara> that's probably something that will happen in the future, until we get to the pojnt we can use LP to track QA, we should be updating the wiki page
<intellectronica> of course
<matsubara> I know that's far from perfect but don't let that stop the QA.
<matsubara> one thing you could do is email Ursinha and I all items tested and we'll take care of updating the test plan
<Ursinha> and I'm going to repeat myself again, but, please, ping us if we can do something
<Ursinha> like that matsubara said
<bigjools> Ursinha: halp
<matsubara> until we find a better way to deal with this
<matsubara> thanks
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<Ursinha> bigjools, as soon as a have access to mawson, will be glad too. but if there's something I could do now, let me know
<herb> * 2008-12-10 - Cherry picked r7386 enabling replication to production and cherry picked r7419 to edge.
<Ursinha> s/as a/as I/
<herb> * Bugs #118625 and #156453 continue to be a problem despite a patch and the addition of the pyrex package.
<herb> * Had an issue with the branch scanner where a user's subscription to a particularly large branch was causing the branchscanner to hang. See bug #242807
<ubottu> Launchpad bug 118625 in launchpad-bazaar "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/118625
<herb> * Had to kill off a bunch of old processes on the code hosting server. This seems to be happening a bit more often than once a week now. See bug #260171
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,In progress] https://launchpad.net/bugs/156453
<ubottu> Launchpad bug 242807 in ubuntu "my ipod nano is not showing up when plugged in" [Low,Invalid] https://launchpad.net/bugs/242807
<ubottu> Bug 260171 on http://launchpad.net/bugs/260171 is private
<herb> hmm
<matsubara> ipod nano?
<matsubara> hehe
<Ursinha> lol
<rockstar> 242807 doesn't seem to correlate.
<herb> something tells me I typoed at least one of those.
<herb> should be bug #252807
<ubottu> Bug 252807 on http://launchpad.net/bugs/252807 is private
<rockstar> herb, there are many folken at UDS right now trying to figure out why loggerhead sucks.
<matsubara> herb: btw, did you find out why staging is down?
<rockstar> It's disappointing that it's still having issues.
<matsubara> hmm it's not down anymore, so why staging was down? :-)
<herb> matsubara: the old lp process didn't exit and so the new process couldn't bind to the port after the restore.
<Ursinha> herb, iirc it was the second time this week
<matsubara> herb: ok. thanks for chasing
<Ursinha> the other time happened for the same reason?
<herb> Ursinha: 3rd or 4th time in the last 10 days.
<herb> Ursinha: different reasons the last couple of times. it had been hanging in the middle of startup.
<Ursinha> hm, right.
<rockstar> herb, was it the librarian?
<herb> rockstar: running.  but didn't really look at it in too much detail.
<matsubara> herb: if it happens again, could you file a bug about it please and let me know?
<rockstar> herb, I've noticed the librarian doesn't close cleanly on my dev machine.
<herb> matsubara: sure. I can't provide much detail on the problems I've seen over and over though.  stracing the startup just shows a wait call.
<herb> :(
<matsubara> thanks herb
<matsubara> [TOPIC] * DBA report (DBA contact)
<MootBot> New Topic:  * DBA report (DBA contact)
<stub> The losas altered the production appserver configs so they start talking to the production replica where possible. This is working well... possibly too well.
<stub> Most of the load is now on the slave, with the production box pretty much idling. We can push some of the
<stub> load back to the main box by reverting a few of the appserver configs, but we should probably leave it be until we have the reverse web proxy caching anonymous requests to see how this affects the load distribution.
<stub> I will be running the script to open Jaunty translations with Jeroen tomorrow. This should be the last time it is a heavy weight operation, as translation inheritence is scheduled to be implemented before the next opening. No ETAs on the run time completion yet - I don't fully trust them given the extra overhead we have now on inserts thanks to replication.
<stub> DB patches for this cycle are all either landed or rejected, except for the per language translation policies link with is blocked on discussions upstairs.
<stub> (^-^)
<bigjools> stub: did Celso's get accepted or rejected?
<stub> Which one?
<bigjools> the licensing meta-data one
<stub> Oh... licencing sourcepackagereleae. Rejected. Needs mucho discussion.
<bigjools> blah
<matsubara> all right, anything else for stub?
<matsubara> thanks stub
<matsubara> anything else before I close?
<matsubara> 5
<matsubara> 4
<matsubara> 3
<matsubara> 2
<matsubara> 1
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<Ursinha> lol
<matsubara> #endmeeting
<MootBot> Meeting finished at 09:37.
<Ursinha> thanks matsubara
<intellectronica> thanks matsubara
#launchpad-meeting 2009-12-09
<abentley> meep
<gary_poster> danilo, hey.  were we supposed to have a meeting?
<gary_poster> or am I confused?
<gary_poster> danilos, I meant; and reviewer meeting, I meant
<danilos> gary_poster, I think we were supposed to, but barry, the usual instigator, seems not to be around
<gary_poster> danilos: oh for some reason I thought you were reviewer man in his absence.  Just giving you extra responsibilities for the fun of it, I guess. :-)
<danilos> gary_poster, that was also 1h ago
<danilos> gary_poster, heh, thanks :)
#launchpad-meeting 2009-12-10
<matsubara> #startmeeting
<MootBot> Meeting started at 10:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<gary_poster> me
<rockstar> ni! ni!
<danilos> me
<allenap> me
<sinzui> me
<matsubara> Chex, bigjools, hi
<bigjools> me
<Chex> Chex: hello
<matsubara> ok, everyone is here.
<Chex> .. /o\ err, hi
<matsubara> apologies from Ursinha and stub
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara>  * DBA report (stub)
<matsubara>  * Proposed items
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> * Ursinha to send one email to lp list explaining the qa-tags experiment
<matsubara> * Chex to follow up with thumper about the multiple git import failures on the importd
<matsubara> * matsubara to file a high/critical bug for OOPS-1430F2574
<matsubara> * matsubara to email tim about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1427EA45
<matsubara> * matsubara to email tim about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1426EC1536
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1430F2574
<matsubara>     * emailed Tim about it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1427EA45
<matsubara> * matsubara to talk to TL about not having the LP production meeting anymore or change its format
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1426EC1536
<matsubara> * matsubara to email QA contacts about next LP prod. meeting at 16UTC
<matsubara>     * emailed the list and QA contacts about this :-)
<matsubara> * matsubara to email losas about their weekly report
<matsubara>     * emailed them requesting that the operation report be sent to the list
<matsubara> I talked to salgado about OOPS-1430F2574 and it wasn't necessary to file a bug for that one. it was a one off problem and I'm keeping an eye on oops reports if it shows up again
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1430F2574
<matsubara> danilos sent the email about the qa-tags experiment
<danilos> matsubara, Ursula is on vacation, I'd like her to give us her PoV as well
<matsubara> Chex, did you sort out the failures in the git import with thumper?
<danilos> matsubara, though, that will likely happen as part of the discussion on the list, so we can probably take the action item off
<matsubara> danilos, right. thanks for starting the discussion
<Chex> matsubara: I followed up with him briefly, but was not able to resolve anything, I need to talk to him again, sorry about that
<danilos> np, it was way overdue
<matsubara> Chex, shall I re-add the action item to the list?
<Chex> matsubara: yes please do
<matsubara> [action] * Chex to follow up with thumper about the multiple git import failures on the importd
<MootBot> ACTION received:  * Chex to follow up with thumper about the multiple git import failures on the importd
<matsubara> ok, thanks Chex
<matsubara> let's move on
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> bigjools,  https://bugs.edge.launchpad.net/soyuz/+bug/493703
<ubottu> Ubuntu bug 493703 in soyuz "LocationError raised in build page and distribution arch series binary package page" [High,Triaged]
<matsubara> it's targeted to .12, currently not assigned and the cycle will end tomorrow. Any chance of have that one fixed before the holidays? it's generating > 1K OOPS a day (most of them from robots but it's pretty importante nonetheless)
<bigjools> matsubara: zero chance
<matsubara> s/importante/important/ sorry for the portuguese leakage there :-)
<bigjools> heh I am used to it from working with cprov :)
<matsubara> bigjools, :-(
<matsubara> the sad smile is for the zero chance comment btw
<bigjools> yeah, there's another serious problem that is taking precedence.  If by some miracle I get that fixed then we can look at the oopses
<matsubara> hmm that's the top OOPS we have
<bigjools> gar sorry
<bigjools> when will the pain end this week
<matsubara> oh, the retry dep thingie?
<bigjools> yep
<matsubara> right. ok then
<matsubara> gary_poster, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/403618
<ubottu> Ubuntu bug 403618 in launchpad-foundations "Launchpad should return a 404 instead of ForbiddenAttribute OOPS" [High,Triaged]
<matsubara> gary_poster, same thing, that one is happening quite frequently. any chance of landing a fix before the holidays?
<gary_poster> matsubara: holidays, yes, next release, no
<gary_poster> where yes is "any chance" :-)
<gary_poster> I suppose it can be an RC then
<gary_poster> I mean CP
<matsubara> gary_poster, all right. as long as they disappear from the OOPS summaries, it's good :-)
<gary_poster> :-) understood
<matsubara> gary_poster, could you take a look at https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1439EB784 ?
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1439EB784
<matsubara> it's a timeout error on the api
<matsubara> I'm not sure if it's just regular timeouts, if they do, then I'd need to update oops-tools to handle those just like any other timeouts
<matsubara> currently they show up in the exceptions section
<gary_poster> matsubara: yes, it's another timeout
<matsubara> rockstar, OOPS-1438EA844
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1438EA844
<matsubara> gary_poster, so just a matter of moving that kind of exception to the right section in the summaries?
 * rockstar looks
<gary_poster> matsubara: i.e., this is something that should be addressed by bugs, notfoundatons/leonardr
<matsubara> gary_poster, ok, looks like a time out using the dupe finder
<matsubara> but using the API
<matsubara> so, I'll talk to the bugs team about it and sort it out (and file a bug to have oops-tools updated to handle it appropriately)
<gary_poster> matsubara: right.  the problem probably needs to be addressed in lp.bugs.model.bugtask, line 571, in findSimilarBugs
<matsubara> sinzui, https://bugs.edge.launchpad.net/launchpad-registry/+bug/495051
<ubottu> Ubuntu bug 495051 in launchpad-registry "UnboundLocalError editing proposed team membership" [High,In progress]
<sinzui> 'nough said
<matsubara> allenap, I have a few timeout OOPSes on +filebug. are you interested in those? I know gmb just landed code to make it async so maybe it's just a matter of waiting for that and see how things will behave
<matsubara> sinzui, indeed! thanks dude!
<danilos> matsubara, how common is eg. bug 493703 in OOPSes? it looks reasonably simple to solve that somebody outside soyuz can fix it? bigjools, is my assessment wrong?
<ubottu> Launchpad bug 493703 in soyuz "LocationError raised in build page and distribution arch series binary package page" [High,Triaged] https://launchpad.net/bugs/493703
<allenap> matsubara: gmb's async stuff probably won't make the timeouts any different, it's just that the user won't be so affected.
<bigjools> danilos: noodles is going to look into it
<matsubara> [action] matsubara to talk to bugs team about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1439EB784 and file a bug on oops-tools to handle LaunchpadTimeoutError correctly
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1439EB784
<MootBot> ACTION received:  matsubara to talk to bugs team about https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1439EB784 and file a bug on oops-tools to handle LaunchpadTimeoutError correctly
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1439EB784
<allenap> matsubara: The URL will change slightly, to +filebug-inline-form. Timeouts for this page are far less important.
<danilos> bigjools, ok, if you need help finding someone to work on it (though, looking into it might be most of the work anyway), I'd be happy to give a hand tomorrow (in looking for someone, not doing it :)
<bigjools> danilos: ok thanks :)
<matsubara> danilos, thanks. we have around 1K of those a day (mostly from bots triggering it)
<danilos> matsubara, right, thanks
<matsubara> allenap, all right. yesterday bigkev was trying to file some bugs and couldn't due to timeouts. I wonder if you need more OOPSes to help investigate the issue
<allenap> matsubara: He should be able to file bugs today, because the async dupe-finder is there now. But more OOPS reports are useful, if you have a bug to attach them to?
<matsubara> allenap, cool. I'll add those to the bug report then
<allenap> matsubara: Thanks :)
<matsubara> [action] matsubara to add +filebug timeout oopses to the bug report
<MootBot> ACTION received:  matsubara to add +filebug timeout oopses to the bug report
<matsubara> rockstar, that SQLObjectNotFound oops is quite strange
<matsubara> rockstar, have you seen it before? looks like it happened only twice
<rockstar> matsubara, yeah, I'm looking at it.  It probably should have 404'd - Not sure though.
<matsubara> and I was unable to reproduce
<rockstar> I have not seen it before.  It's probably some corrupted bmp somewhere.
<danilos> matsubara, that strikes me as replication-related, but I am no expert :)
<matsubara> rockstar, worth a bug rpeort for that one?
<rockstar> danilos, yeah, that's what I thought.
<rockstar> matsubara, not sure.  I'll look into it, and file one if need be.
<matsubara> danilos, rockstar  yeah, same thought here
<matsubara> rockstar, cool. thanks! I'll let you know if it happens again
<matsubara> we had some script failures since last week
<matsubara> Scripts failed to run: loganberry:allocate-revision-karma, loganberry:flag-expired-memberships
<matsubara> sinzui, ^ I think that one is yours?
<matsubara> the retry depwait script failure is being worked on by bigjools
<sinzui> matsubara: We have had intermittent timing issues because of long processes
<bigjools> floundering on
<sinzui> matsubara: there are no errors and the script do run when they get their turn
<matsubara> sinzui, ok, so that means that the failures on mizuho:librarian-gc and loganberry:karma-update, loganberry:allocate-revision-karma, loganberry:launchpad-stats, loganberry:expire-questions, loganberry:productreleasefinder, loganberry:update-cache, loganberry:launchpad-targetnamecacheupdate are probably related to that?
<matsubara> I guess so, since the last failures for those were 2 days ago
<matsubara> we have only one critical bug which bigjools is on it.
<sinzui> matsubara: right. I do not investigate a failure to run for 24 hours after the notice because ANOTHER process is responsible for that. When all scripts fail, I might investigate withing 24 hours
<matsubara> I see. all right then. thanks sinzui
<matsubara> and thanks everyone. let's move on
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<sinzui> matsubara: and i check if we changed production code in the last 24 hours
<Chex> hello everyone, a rport focused on the LP rollout:
<matsubara> Chex, ?
<matsubara> wow, nice timing :-)
<Chex> - The LP 3.1.11 rollout was last week, and there is a upcoming 'short' LP rollout next week.
<Chex> - 3.1.11 roll-out took 2 days, due to some problems with the rollout
<Chex>           process. We are working to address these issues for next time.
<Chex>     Steps we are taking to improve the process are:
<Chex>         : moving to build centrally before pushing code out to speed up pushing and building of code
<Chex>         : investigating less error prone ways (and quicker ways) of switching to read-only mode
<Chex>         : ensuring we're not interrupted by other DB jobs on other servers in the cluster that block the DB upgrade
<Chex> and thats all for this week, questions/comments, anyone??
<matsubara> Chex, thanks
<Chex> matsubara: your welcome
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<danilos> Chex, yes, are we getting any of this for 3.1.12?
<matsubara> oops, sorry, go ahead danilos
<matsubara> [action] matsubara to email stub about the DBA report
<MootBot> ACTION received:  matsubara to email stub about the DBA report
<Chex> danilos: yes, most of those items I listed should make it into the 3.1.12 release, I believe
<danilos> Chex, ok, cool, that sounds great then, but there's always potential for failure with new features like that; I'll try to keep an eye on that :)
<Chex> danilos: ok, great, we appreciate all and any eyeballs on the process
<danilos> Chex, fwiw, I'll be doing a release manager rotation, it's not that I don't trust our lovely LOSA team :)
<danilos> bigjools, (add a link to the image :)
<bigjools> http://people.canonical.com/~ed/losa-team.png
<MootBot> LINK received:  http://people.canonical.com/~ed/losa-team.png
<matsubara> LOL
<danilos> thank you, we can move on :)
<matsubara> sorry, got very distracted by that picture hehe
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> there's no new proposed items
<matsubara> the new meeting time seems to work fine for everyone
<matsubara> anything else before I close?
<danilos> And if anyone has any issues that may need tracking, please ping me as the release manager for 3.1.12. Thank you.
<bigjools> danilos, my hero
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:37.
<danilos> cheers
#launchpad-meeting 2010-12-15
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<jelmer> me
<bac> hello, who is here today?
<abentley> me
<bigjools> me
<sinzui> me
<jcsackett> me
<benji> me
<mrevell> me
<deryck> me
<EdwinGrubbs> me
<henninge> me
<flacoste> me
 * benji things it should be "I" :P
<mars> me
<mars> benji, "moo" is always fun
<benji> heh
<salgado> me
<gary_poster> me
<danilos> me
<gmb> Me
<allenap> me
<danilos> oh, capital "Me" is here as well
<bac> great, let's start.  pretty light agenda today
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * Mentat update.
<bac>    * Salgado (ui)
<bac>    * StevenK (code)
<bac>    * MRevell (ui)
<bac>  * New items
<bac>    * Should reviewers expect the review template to be used? - abentley
<bac>    * Integrating test timing into reviews, recap.  -bac
<bac>  * Peanut gallery
<bac> [topic] mentat update
<MootBot> New Topic:  mentat update
<bac> salgado, getting any more UI reviews?
<gary_poster> bac, benji should be in mentat update
<salgado> nope
<bac> mrevell, getting any?
<bac> thanks, gary_poster
<mrevell> bac, No.
<salgado> haven't done any in a long while
<jelmer> I will have one tomorrow
<jcsackett> bac: i'm in the mentoring process as well.
<danilos> I've also asked henninge to be my UI mentor as well, so I'll be starting as UI reviewer one of these days as well
<sinzui> salgado, me too
<bac>  sorry benji and jcsackett.  updated on the wiki now
<benji> np
<danilos> perhaps there's no need for UI reviewers anymore
<flacoste> danilos: why?
<sinzui> salgado, may be should agree that mentoring ui <= 3 month
<danilos> flacoste, why would I want to be, or why there might not be a need?
<sinzui> salgado, maybe you should graduate next week because you have all the experience you are ever going to get
<danilos> flacoste, it's just that people haven't been getting any UI branches for review
<abentley> danilos, there's certainly a need for UI review, but maybe not one so frequent as to demand specialized reviewers.
<bac> sinzui: +1
<EdwinGrubbs> benji has been doing a good job, but we haven't been getting very many requests for reviews on Wednesday
<salgado> sinzui, well, I'm not sure a time limit is a good idea as in some periods (like now) we may stay a long time without doing any reviews
<danilos> flacoste, i.e. mrevell and salgado hasn't gotten any in a week, so I am wondering if it's smart to try to achieve that specialization with unused workforce we've got
<jcsackett> EdwinGrubbs: i've found the same thing on thursdays--i think maybe it's an end of year slow down?
<flacoste> jcsackett: probably is
<henninge> I have not had that many, either.
<bac> jcsackett, flacoste: but with the BugJam on perhaps it'll pick up?
<salgado> danilos, fwiw, I was doing 3 or so reviews a week when I started.  just lately there doesn't seem to have been many people working on UI
<abentley> fwiw, monday OCR is rarely busy.
<flacoste> bac: number of reviews should yes
<flacoste> salgado, danilos: yeah, UI reviews usually come in burst
<flacoste> when a new feature is developped
<danilos> salgado, right, thanks; I don't want to become a mentat as well and thus distribute the low UI activity over more people
<bac> danilos: perhaps you have a point that we don't need new UI reviewers in the pipeline if we can't get enough to get the current mentats trained.
<danilos> bac, right, that was my point
<jcsackett> bac: maybe get a queue of people willing to be UI and phase them in when the next feature rush begins?
<abentley> danilos, Sorry, I thought you meant the whole concept was outdated.
<bac> abentley: yeah, me too
<danilos> abentley, oh no, sorry for confusing you guys :)
<bac> [topic] Should reviewers expect the review template to be used? - abentley
<MootBot> New Topic:  Should reviewers expect the review template to be used? - abentley
<abentley> Back when I  started, there was a template that was expected to be used for code review.
<abentley> It's basically preserved in the lpreview_body plugin.
<abentley> It expects a summary, pre-implementation notes, implementation details, lint, etc.
<abentley> I use it, but I find that basically no one else does.
<bac> abentley: i always use it and really like it when others do.
<abentley> Okay, maybe that's too strong.
<jcsackett> abentley: that template was provided to me when i started. i've seen it from a few others (though sometimes not with all sections).
<bigjools> I use it sometimes.  It's massive overkill for simple branches.
<abentley> There are a bunch of people not using it.
<bac> personally i like it because i'm both lazy and forgetful.  it helps with both.
<deryck> I don't use it.  there I owned up to it. ;)
 * deryck looks around at the rest of the room
<deryck> I feel it's too prescriptive.
<bac> bigjools: the sections that are overkill are easily deleted or marked 'n/a'
<abentley> bac, +1
<jcsackett> deryck: could you unpack that a bit? not sure what you mean.
<bigjools> that's extra hassle, particularly if I use the web ui
<flacoste> actually, web ui is the major problem there
<bac> bigjools: oh.  i *never* use the web ui...
<flacoste> i most often use the web ui to submit branches
<flacoste> (ok, i don't submit that many anymore...)
<jcsackett> i use the web ui, and find that pasting in the template as a starting point isn't that big a deal.
<gary_poster> more people may be using it soon, if the switch to using tarmac is successful
<flacoste> i'd use the template
<gary_poster> it == the web
<flacoste> if it was easy to get at
<abentley> gary_poster, why?
<flacoste> gary_poster: why?
<bigjools> if the branch is cleaning up, or a trivial bug, I find that template too prescriptive, annoying to edit and a waste of time.
<gary_poster> because you'll be able to submit without using a commandline if you want
<bigjools> however, it's useful for a more complex change
<abentley> gary_poster, I think you are talking about lp-land, not lp-propose.
<jelmer> It'd be nice if it the template was available in the web interface as well, not just in "bzr send".
<gary_poster> oh, you are right, abentley.  thanks, sorry
<jelmer> I'm also guilty of not using the template now that I've switched to using the web interface primarily for proposing merges.
<abentley> jelmer, it's not just in bzr send, it's also in lp-propose, and that's preferred.
<gary_poster> not using template: me too.
<abentley> jelmer, I don't see how the web site is going to run lint on your local machine :-)
<bigjools> I stopped using lint when it kept coming up with a million* false positives
<abentley> Personally, I think it's a useful reminder of key things.
<abentley> Like who the pre-implementation call was with.
<abentley> I agree it's overkill for trivial bugs.
<bigjools> pre-imp details are the most useful thing on that template
<abentley> bigjools, it's pretty good for me now.
<abentley> bigjools, lint is pretty good for me, I mean.
<benji> abentley: indeed; I use it as a checklist; I make sure that I've considered every item on the template, even if I don't include it
<bigjools> ok I'll try it again, thanks
<bac> i guess the bigger issue is whether reviewers think the merge proposals are providing all of the expected information, whether people use the available tools, or not.
<flacoste> abentley: does lp-propose submit the template on the web UI?
<abentley> bac, also, if we're going to include test execution times, it would be sensible to add them to the template.
 * flacoste doesn't know about lp-propose
<bigjools> s/expected/useful and pertinent/
<bac> those that i see that use the template tend to cover all of the bases.  doesn't do a thing about the quality of the prose, though.
<abentley> flacoste, it opens up your editor to edit the description, then loads the proposal in the browser when it's done.
<flacoste> bac: dev writes in code :-p
<flacoste> abentley: then I should be using that!
<jcsackett> abentley: that sounds like the coolest thing ever.
<flacoste> i think it might just be that people don't know about lp-propose
<danilos> I find it's hard to find out about it
 * jcsackett never heard about it.
<deryck> bac: that's part of my issue with the template, sometime those who use it, just list a bunch of info, rather than writing a couple paragraphs explaining what is happening in the code, which is often more useful to me.
<danilos> I used to have one of previous submit plugins with the template, but now I type most of the relevant sections out of my head
<bac> abentley: i think part of the problem is new people don't know how to use your plug-in and some experienced folks forgot.  could you send out a reminder email or a pointer to the wiki?
<jelmer> I was vaguely aware of it, but didn't know it was the proper way to propose merges instead of the web UI.
<danilos> it's simply hard to find what the latest and best way to submit MPs is (i.e. appropriate plugin and such: I knew nothing about lp-propose either)
<flacoste> jelmer: it sounds like it's a wrapper around the uI, which is exactly what we need
<abentley> jelmer, I meant that it's preferred over "bzr send", not necessarily the web UI.
<mars> danilos, yes, that is odd - we used to do that just fine (years ago, when I joined)
<abentley> danilos, it ships as part of bzr :-P
<jelmer> abentley: don't you still need lpreview_body to actually get the template though?
<abentley> jelmer, yes, you do.
<danilos> abentley, heh, right, that's probably why it's harder for people to find out about it: if you are not actively looking for it and you've been using something like lpreview_body or whatever in the past, you wonder why it doesn't work as well anymore
<abentley> jelmer, since it's packaged, we could add it to lp-developer-dependencies, if it's not already.
<danilos> (and I was actually stuck on whatever was before lpreview_body with my "lpsend" as the alias)
<jelmer> abentley: I think that's a good idea
<bac> abentley: can you send that reminder email and pursue getting it added to lp-d-d?
<abentley> danilos, I bear some blame, since I wrote it and didn't promote it.
<abentley> bac, Sure.
<bac> abentley: thanks for bringing up the topic...and for writing the tool.
<bac> moving on
<bac> [topic]  Integrating test timing into reviews.  --bac
<MootBot> New Topic:   Integrating test timing into reviews.  --bac
<bac> last week we started the discussion about paying attention to test timing.  we've had a lot of discussioin on the mailing list about what that means.
<bac> has anyone tried and have successes or failures to report?
<mars> Aaron added two tests yesterday, timing was 2 seconds
<bigjools> timing info on its own means nothing to me
<mars> TBH, I didn't know how far to pursue it - how much was setup, how much existing tests, what it ok?
<mars> 'what is ok'
<flacoste> bac: given that we are planning on rewriting the persistence layer and that there is controversy on the metrics side
<flacoste> why don't we move on to another aspect?
<flacoste> and revisit this later, once the story around persistence and tests is more clear
<bac> francis, sure we can do that
<flacoste> well, that's not an edict!
<flacoste> just proposing
<bac> i unwisely thought this would be an easy one to start with
<bigjools> I concur :)
<bac> i'll propose something next week
<bac> [topic] peanuts
<MootBot> New Topic:  peanuts
<bigjools> o/
<bac> yes bigjools?
<abentley> Who's seen A Charlie Brown Christmas this year? :-)
<bac> are you really left handed?
<bigjools> ...
<danilos> bac, that was him with his back turned on us
<gary_poster> :-)
 * bigjools is speechless for the first time in ages
<bigjools> anyway
<danilos> but he's also a slow typist (especially with only one hand)
 * gary_poster laughs
 * bigjools sees the gutter approaching
<mars> lol
<bigjools> I want to talk about the mailing list thread that jelmer brought up
<bigjools> regarding api only functions in model classes
<jelmer> bigjools: thanks, I forgot about that
<bigjools> I think it's a good idea to prepend api_ in front of any method that's only used in the api
 * danilos is still behind on his mail
<bigjools> anyone got any comments?
<abentley> bigjools, I think it's a good idea.
<bigjools> (with liberal use of export_as of course)
<danilos> other than that we should have made API a separate layer in the first place? no :)
<bigjools> I assume that's coming
<danilos> anyway, "api_" as the prefix for API-only methods is probably good
<bigjools> this is a stopgap
<abentley> bigjools, it makes me sad that the API has the zope naming convetion, though.
<jelmer> abentley: is that documented somewhere?
<bigjools> we should change that *now* if we can
<bigjools> but it might be too late
<abentley> jelmer, Not as a special thing.  All our code has the zope naming convention.
<mars> danilos, makes sense: model -> views (HTML), model -> api-layer (JSON)
<jelmer> abentley: I found a couple of methods which explicitly used "export_method_as" and used names with underscores and lowercase characters.
<gary_poster> I think it's too late myself
<leonardr> bigjools: a while ago we decided it was too late
<gary_poster> consistency is more valuable IMO
<leonardr> and now it's even later
<bigjools> :(
<abentley> gary_poster, definitely too late for 1.0 :-(
<gary_poster> yup
<bigjools> maybe on the next version bump?
<bigjools> then we can make everything consistent
<bigjools> it's a bit of a mess right now
<danilos> E_TOOMUCHWORK
<danilos> at least imo
 * gary_poster thinks that the webservice will get attention separately
<bigjools> I think it's valuable work - we don't have anyone looking at our whole api, other than the people who use it
<danilos> of course, we can choose when the next version bump will be
<gary_poster> i.e., this is the worng forum
<danilos> gary_poster, +1
<jcsackett> gary_poster + 1
<gary_poster> looking at the whole api: that was to have been what leonardr did soon :-)
<bac> gary_poster: yep
<bigjools> anyway, votes for api_ ?
<abentley> bigjools, +1
<danilos> bigjools, +1
<gary_poster> sure, _1
<bac> +1
<gary_poster> heh
<deryck> +1
<gary_poster> +
<jcsackett> +1
<danilos> :)
<jelmer> +1
<deryck> is underbar 1 even less than -1? ;)
<bigjools> it's a wunderbar
<benji> +1
<gary_poster> heh, yeah, maybe so :-)
<leonardr> +0
<bac> bigjools: looks like you have a winner
<bigjools> motion carried
<bac> bigjools: will you update the style guide?
<bigjools> if I can remember where it is
<bigjools> :)
<jelmer> Alternatively, I'd be happy to update it
<danilos> bigjools, I am guessing dev.launchpad.net/StyleGuide :)
<danilos> nope, but it does give useful hints :)
<bigjools> what!  it's in an obvious place?  I'd never have thought to look there.
<bac> any other topics?
<bac> i'll look at the list of people who will be around next wednesday and cancel this meeting if it looks too low.
<bac> thanks for coming everyone
<flacoste> thanks bac
<bac> #endmeeting
<MootBot> Meeting finished at 09:37.
<danilos> cheers bac
<mars> thanks bac
<bigjools> cheers
<gary_poster> thank you
<gmb> Ta
<abentley> thanks, bac.
<jcsackett> thanks, bac.
<benji> leonardr: your "and now it's even later" comment made me think of TMBG's "Older" (http://www.youtube.com/watch?v=2ltJ8kK4G90&feature=related)
#launchpad-meeting 2010-12-16
<bac> #startmeeting
<MootBot> Meeting started at 18:01. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> who's here?  anyone?
 * wallyworld lurking
<bac> mwhudson: you around?  thumper?
<wallyworld> might be a very short meeting if no one else is here :-)
<bac> wallyworld: indeed.  that combined with the fact my dinner is ready...
<wallyworld> thumper is on leave this afternoon so he may already have EOD
<bac> ah, ok.
<bac> well, what say we try again next week...or next month/year?
<bac> #endmeeting
<MootBot> Meeting finished at 18:02.
<mwhudson> hi
<wallyworld> sounds good. enjoy your dinner
<mwhudson> enjoy dinner
<mwhudson> bac: are you back in the US?
<wgrant> StevenK and I are back now.
<wgrant> Sorry, forgot about the meeting.
<thumper> hmm
<thumper> my calendar said 00:30 UTC
<thumper> I have finished for the day thoug
<thumper> h
