#launchpad-meeting 2007-04-29 <lifeless> SteveA: is this channel still used ? <SteveA> apparently not * Starting logfile irclogs/launchpad-meeting.log * mode/#launchpad-meeting [+nt] by ubuntulog #launchpad-meeting 2008-04-01 <barry> #startmeeting <MootBot> Meeting started at 05:01. The chair is barry. <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] <barry> hi everybody and welcome to this week's asiapac reviewers meeting <barry> who's here today? <sinzui> me <thumper> me (kind of) <sinzui> Well this is looking embarrassing. <spiv> I'm here. <barry> sinzui: i was going to say, if it was just you and me, we should do it when the sun is up :) <jml> hi <barry> jml: hi <barry> spiv, thumper hi <barry> mwhudson: are you around? <jml> thumper is unwell and is off <barry> thumper: :( <barry> [TOPIC] agenda <MootBot> New Topic: agenda <jml> mwhudson last said "afk for a little while" 4 minutes ago <barry> jml: okay thanks, oh well <barry> * Roll call <barry> * Next meeting <barry> * Action items <barry> * Queue status <barry> * Mentoring update <barry> * Review process <barry> * '''Pre-imp calls are falling by the wayside''' (gmb) <barry> [TOPIC] next meeting <MootBot> New Topic: next meeting <barry> so, is this a good time for y'all? <jml> for me, yes. <thumper> normally, but I'm somewhat uncommunicative right now <spiv> This is fine for me too (same timezone as jml). <barry> thumper: no worries. anybody know if this is a good time for jamesh? <jml> but I'd be equally with something up to four hours earlier or two hours later, if things need rescheduling. <jml> barry: it's 11am in WA right now. <jml> barry: it *ought* to be a good time for him :) <barry> :) <jml> (the WA that's on the west coast of Australia, not the one on the west coast) <barry> jml, naw, i was thinking maybe 1 hour earlier, but this works just fine for me too. in daylight saving's its 11pm, and i fake-tivo the daily show so it's all good <jml> :) <barry> cool, let's keep 0300utc then <jml> +1 <barry> [TOPIC] action items <MootBot> New Topic: action items <barry> * (continued) thumper to report on pending-reviews killer in LP <thumper> barry: sorry, it's coming <thumper> but nothing else to report right now <barry> thumper: no worries, we'll just keep continuing it if you want <thumper> yeah <barry> thumper: just want to be sure you don't want to ditch the whole thing :) <barry> jamesh: hi! <jamesh> hi <thumper> barry: not just yet <lifeless> boo! <barry> cool * barry is frightened <barry> just for completeness, here are the ameu action items: <barry> * gmb to hack review-submit to enforce 800 line limit. <barry> * schwuk to work with mwhudson to get instructions for running loggerhead onto the wiki <barry> any comments or should we just move on? <jml> barry: I don't think enforcing the 800 limit is a good idea. <jml> barry: unless that means "show a warning" <thumper> me neither <sinzui> jml: 800 + shame <barry> yeah, it's mostly so you have a warning <barry> i really think the option to override should be --isuck <lifeless> rather than say enforce <lifeless> say 'warn' perhaps ? <sinzui> jml: the 800 line flag really means you need to send with the -r switch (have a review lined up) <lifeless> if you mean warn :> * barry speaks as someone who sucks often <jml> sinzui: perhaps. <barry> yes, the point is you really need to arrange things with a reviewer if your >800 lines <jml> I think that's fair enough. I still think you should be able to override whatever policy the tool has by default. <barry> i'm happy to reword this action item to be clearer about it, but i think gmb knows what we mean <barry> jml: definitely <jml> anyway, review-submit will be an addon to send eventually. <jml> barry: cool. now I know what gmb means, I'm happy :) <barry> cool! <barry> [TOPIC] queue status <MootBot> New Topic: queue status <barry> some bonehead's got two branch's in the general queue <jml> :) <barry> :-D <jml> just to be clear <jml> are we supposed to send emails *and* hack wiki? <barry> jml: i don't know anymore. i do, but that's just me <jml> hah! <jml> ok :) <barry> i fully intend to ask tomorrow's on-caller to review these branches though <lifeless> someone should patch submit-review to edit the wiki <jml> there's also at least one email sent that's not on the wiki page and has no assigned reviewer <jml> lifeless: yes. it's getting close to that already. <barry> jml: it's still the responsibility of the dev to get his branches reviewed <jml> *nod* * barry still likes the pending-reviews page tho <barry> it tells me we have 5 pink branches <barry> i know about stub's two <barry> jml: what's up with your use-inmemory-proxies branch? <jml> barry: shelved, for the time being. <barry> jml: should we move that to wip? <jml> barry: yeah, probably. <barry> jml: i'll let you do that :) <jml> ok <barry> thanks <barry> any other queue-related comments? <jml> none from me <barry> [TOPIC] mentoring update <MootBot> New Topic: mentoring update <barry> i don't think there are any asiapac mentors or mentorees <barry> are there any of you guys who /aren't/ already reviewers? <sinzui> That was to requirement for mwhudson to emigrate. <jml> barry: all australasian LP hackers are reviewers <jml> we even have a non-LP hacker who's a reviewer :) <barry> jml: excellent! <jml> a veritable superabundance of reviewers. <barry> you need to hire more grunts <barry> [TOPIC] review process <MootBot> New Topic: review process <barry> * '''Pre-imp calls are falling by the wayside''' (gmb) <jml> What does that mean? <barry> people 'round here slacking on pre-impl calls <barry> have you noticed that? is it a problem? and if so what do we do about it? <barry> here's specifically what gmb says: <barry> * '''Pre-imp calls are falling by the wayside''' (gmb). Since we've adopted the on-call review process I've noticed that less and less people (including myself) have been having pre-imp calls before they start work. Partly, I figure that this is because the on-call process allows the developer to talk about their implementation decisions with the reviewer and so helps to substitute for a pre-imp in a lot of ways. However, I've had one <barry> branch land this cycle that happily had r= from the reviewer but which, had there been a pre-imp, might not have landed in the form it did (which would have avoided me needing to ask for an RC). Should we be enforcing the requirement to have pre-imp calls, or at least be more scrutinous of those branches that don't? <mwhudson> oopsie <jml> I've observed that people aren't rigorous about calling someone before they begin work on a branch. <jml> I don't think that's a problem. <jamesh> I think I've done only two pre-impl calls with people in the last month (and only one was actually voice) <barry> let me ask: how have the quality of branches been lately when first submitted for review? has it been getting better, worse, or about the same? <jml> the way we'd measure it being a problem is if reviewers were asking for branches to be re-implemented :) <jml> barry: that's hard to discern. The code I get to review is generally very clear. <barry> i'm curious about the rate of needs-reply branches. <jml> the sample is limited, because we are increasing the size of the review team. <barry> jml: many of the branches i've reviewed lately have been merge-* right off the bat (i.e. very good quality) <mwhudson> something that's definitely happening is that i'm basically only reviewing things from the code team <jml> needs-reply doesn't always mean lower quality <mwhudson> and occasionally jamesh <barry> jml: no, you're right, but it's an indicator that the branch maybe wasn't quite ready to code yet <jml> I often flag things needs-reply because I don't understand a part of the problem domain. <barry> mwhudson: interesting <jml> yeah, I'd agree w/ mwhudson on that. <barry> is that basically geography? <jml> I also almost always get code or bzr ppl to do my pre-impl calls <jamesh> well, it isn't that surprising that NZ reviewers mainly have overlap with NZ and AU coders <mwhudson> indeed <barry> jamesh: yep <jamesh> for pre-implementation calls, it is even more of an issue <jamesh> since that's real time when reviewing might not be <barry> cool, so basically you don't feel that the current rate of pre-impl's is a problem? <jml> no :) <mwhudson> i don't know how much of a problem this is, it reduces the cross-team spread of knowledge a bit <mwhudson> barry: no <barry> mwhudson: good point. <jamesh> while there might not be as many formal pre-impl calls as there once were, people do consult others on IRC about implementation issues <jamesh> (at least in this time zone) <barry> if it's not a problem, i'm definitely not going to try to "fix" it then :) <barry> thanks, this has been good feedback <barry> so... that's it from me. we have 15 minutes if anybody has anything not on the agenda, or messages to convey to ameu * jml has nothing on topic <barry> cool. time for the colbert report then :) <mwhudson> :) <barry> #endmeeting <MootBot> Meeting finished at 05:31. <barry> thanks everyone! g'night :) <mwhudson> thanks barry <jml> thanks barry <mwhudson> (and sorry for being late) <barry> mwhudson: no worries. talk to you guys soon... #launchpad-meeting 2008-04-02 <flacoste> #startmeeting <flacoste> Welcome to this weeks' reviewers meeting <flacoste> mootboot seems not to be available, so we'll do without <flacoste> so who's here today? <allenap> me <sinzui> me <intellectronica> me <bac> me <schwuk> me <gmb> me <flacoste> (btw, i'm chairing in lieu of barry) <BjornT_> me <flacoste> (who is out sick) <schwuk> bigjools said he might not be around. <flacoste> salgado: ping <salgado> me <flacoste> danilos: ping <danilos> flacoste: sorry, on a sprint, will miss the meeting <flacoste> danilos: ok <flacoste> intellectronica: also sent his apologies <flacoste> == Agenda == <intellectronica> i'm here but will have to leave around 14:30 <flacoste> * Roll call <flacoste> * Next meeting <flacoste> * Action items <flacoste> * Queue status <flacoste> * Mentoring update <flacoste> * Review process <flacoste> * '''Pre-imp calls are falling by the wayside''' (gmb) <flacoste> '''pending-reviews is missing branches listed on PendingReviews''' <flacoste> '''Is there a policy on private name mangling?''' <flacoste> Topic: Next meeting <flacoste> Same time, same place? <flacoste> anybody knows they can't make it? <flacoste> 5 <flacoste> 4 <flacoste> 3 <flacoste> 2 <flacoste> 1 <flacoste> great, same time, same place, everybody should be there! <flacoste> TOPIC: Action items <flacoste> * gmb to hack review-submit to enforce 800 line limit. <gmb> This is done <gmb> Hurrah <flacoste> awesome! <gmb> I've sent the patch to mwh to look at. <flacoste> i guess people have to upgrade their plugin to have it? <flacoste> ah, it's not landed yet <flacoste> anyway, that's still cool! <flacoste> thanks gmb <flacoste> * schwuk to work with mwhudson to get instructions for running loggerhead onto the wiki <allenap> gmb: Is there an --override option, for when we're agreed in advance with a reviewer? <sinzui> --isuk? <schwuk> flacoste: that was finished a couple of weeks ago when gmb chaired <gmb> allenap: Yes. <allenap> gmb: Cool :) And thanks sinzui :) <schwuk> flacoste: https://launchpad.canonical.com/RunningLoggerhead * gmb forgot to update the agenda after that last minute chairing. <flacoste> ok <flacoste> any other actions i'm not aware of? <flacoste> i guess not <flacoste> Topic: Queue status <flacoste> according to the QueueStatus, there are two stub's branch needing a review <flacoste> one branch that has the wrong status (that's my fault) <flacoste> and another branch which is 7 days old but not marked over SLA? <flacoste> salgado, that's the abel's branch, what's the status there? <salgado> it's merge-approved, IIRC <salgado> let me check <salgado> yeah, I approved it <flacoste> ok * salgado updates the status <flacoste> i guess the two stub's branch are the ASIAPAC meeting responsibility <flacoste> anything else to add on queue status? <sinzui> It's not showing all branches <flacoste> sinzui: i think we have another item to discuss that <flacoste> or is this something eles? <sinzui> flacoste: we do :) <flacoste> ok, moving on then <flacoste> Topic: Mentoring update <flacoste> who's it going? schwuk, allenap? <flacoste> bigjools and danilos are two other mentees being absent (or maybe their mentor have something to say) <flacoste> hmm, bigjools mentor's is sick <sinzui> schwuk: Are you going to take an on-call slot? <schwuk> Last week fell apart for me with my father, so I got no reviews done. I'm on call this Friday so I can overlap with sinzui. <bac> gavin and did our first on-call yesterday and it went really well <allenap> Going well, did a couple of reviews on call yesterday, which bac mostly thought were good. * schwuk remembers to update the schedule * gmb cheers at the idea of having even more people to throw branches at on a Friday <flacoste> who is mentoring danilos? <bac> allenap: they were quite good! <gmb> flacoste: danilos graduated last cycle. <allenap> bac: Thanks :) <sinzui> danilos: graduated <flacoste> oops :-) <flacoste> no offense meant <flacoste> so we only have three mentees? * flacoste will take that for a yes <flacoste> anything else to add on the topic? <flacoste> 5 <flacoste> 4 <flacoste> 3 <flacoste> 2 <flacoste> 1 <flacoste> * Review process <flacoste> we have 3 items for discussion on the process <flacoste> first one: <flacoste> * '''Pre-imp calls are falling by the wayside''' (gmb) <gmb> flacoste: Was that not covered last week? <flacoste> TOPIC: 'Pre-imp calls are falling by the wayside (gmb) * gmb was on vacation <flacoste> i guess <sinzui> I was covered here and in asiapac <flacoste> there was an action about "barry to remind lp devs to do pre-impl calls " <flacoste> did that occured? * flacoste can't remember * gmb didn't see anything <flacoste> i guess not then <flacoste> ACTION: barry to remind lp devs to do pre-impl calls (repost) <flacoste> so let's move on <flacoste> TOPIC: pending-reviews is missing branches listed on PendingReviews (sinzui) * flacoste hands the mic to sinzui <sinzui> I noticed that the two of jtv's branches I reviewed are not on pending-reviews <flacoste> sinzui: is it because they are not on PendingReviews, or because of a bug? <sinzui> I also noticed that one of cprov's branches that was marked merge-approved several days ago still states it was need-reply <sinzui> The branchs were/are on PendingReviews. All came from the general queue to my queue <sinzui> I removed cprovs branch because I saw the commit message. <flacoste> jtv's branch are still missing though <sinzui> right <flacoste> i guess there is a bug in the script <flacoste> jamesh maintains that <flacoste> sinzui: can you email jamesh about the problem? <flacoste> cc list <sinzui> I will <flacoste> ACTION: sinzui to email jamesh about some branches not being picked up by pending-reviews <flacoste> anything else to add here? <flacoste> 5 <flacoste> 4 <flacoste> 3 <flacoste> 2 <flacoste> 1 <flacoste> TOPIC: Is there a policy on private name mangling? (allenap) <flacoste> allenap has the floor * allenap starts copying and pasting frantically. <allenap> A branch I reviewed yesterday had a _pseudo_private method on a mix-in class. Not that it's a big danger, but this seems like a sensible place to use __private_name_mangling. Or is mangling frowned upon, or deprecated? <flacoste> allenap: what's your opinion <allenap> I'm all for it, but I wanted other's opinions. <intellectronica> i don't think we should do this unless it's really dangerous for a consumer to touch an attribute <allenap> But, even in this case, it didn't matter too much. I wanted to see if there were good reasons for or against. <intellectronica> you never know, for example, when you might need to monkeypatch <gmb> I'm with intellectronica here. <gmb> Not that I'm advocating monkeypatching ;) <gmb> But I don't think we'd gain too much from using mangling. <flacoste> the problem with mangling is that it makes it very hard to work with the attribute <flacoste> in the debugger <flacoste> or in subclass <flacoste> so i usually prefer _pseudo_private to __mangling <flacoste> but this all might be because I'm an ex-perl hacker and I live by the motto 'we rather you don't come in our living room because you weren't invited, not because I have a shotgun' <gmb> flacoste: There's also the Python motto "We kind of expect you to know what you're doing; on your head be it if you don't." <gmb> Which is less snappy but... <BjornT_> +1 for _pseudo_private <allenap> I don't really see name mangling as a way to prevent access, more as a way to avoid shooting self in foot. <gmb> allenap: True, but the test suite *should* pick up on foot-shooting anyway. <allenap> Okay, consensus seems to be for _singles, so I'll add that to the guidelines on the wiki. <intellectronica> allenap: you see, if you didn't have a shotgun, you wouldn't have the problem of shooting yourself in the foot ;) <allenap> Perl hackers and their shotguns, heh. <allenap> flacoste: Back to you I think. <intellectronica> anyway, gotta go now. my apologies again <flacoste> ACTION: allenap to update Reviewers' guidelines with _pseudo_private policy <flacoste> that's it for the items on the agenda <flacoste> we have some time left <flacoste> anybody has a topic to propose? <flacoste> 5 <flacoste> 4 <flacoste> 3 <flacoste> 2 <flacoste> 1 <flacoste> Then we are done <flacoste> Meeting Ends <flacoste> thanks a lot everyone <gmb> Thanks flacoste #launchpad-meeting 2008-04-03 <Rinchen> hello MootBot <bigjools> Rinchen: is there a meeting <bigjools> ? <gmb> Rinchen, bigjools: The calendar says it's at 18:00 UTC... <bigjools> wtf <bigjools> 7pm - will definitely not be making that then <sinzui> We really need to move this meeting next week <cprov> +1 <sinzui> I may be the only North American that supports that. <Rinchen> On the 6th I think is when NZ does their timezone change <sinzui> The argument would be in the European favour too if it wasn't for all us cheap Americans. <Rinchen> sinzui, spoken like a true Canadian * sinzui gets out the visa <Rinchen> and the mastercard <Rinchen> lol <bigjools> badumtish <Rinchen> :-) <bigjools> I'VE ALWAYS LOVED CANADA <Rinchen> at the very least we can go to 17:00 next week. That should be 7am for thumper <sinzui> I still hold Canada responsible for global warming <sinzui> And Brian Adams <bigjools> and maple syrup <bigjools> wait...that's nice! * sinzui likes maple syrup <bigjools> preferably doused on some pancakes <sinzui> bigjools: There is a fashion in the US to lace sausages and bacon with it. <bigjools> ewww gross <bigjools> there's only one thing to have with bacon <sinzui> bigjools: the first bite is fine, it's the second bite that you think 'ewww gross' <bigjools> more bacon <sinzui> bigjools: I think I agree with you <bigjools> except if it's Jono <bigjools> lol <sinzui> There ca be only one <Rinchen> mmm bacon. You're making me hungry for lunch <barry> bacon <Rinchen> jsk! <sinzui> jsk? <sinzui> jsk: translations is hiring <Rinchen> jtv... did you notice the similarities between SKJ and jsk ? :-) <jtv> jsk: come back, all is forgiven! <jtv> Rinchen: for that reason alone we must have him back. :-) <mwhudson> hnnnnnnnnnnngh <jtv> Rinchen: ah, and the K in SKJ became a GTF Contributor today. * gmb hands mwhudson a large coffee. <Rinchen> jtv, well, add JJS = Joseph James Stanford (joey) and you can add me <Rinchen> too <danilos> Rinchen: no, that sucks :) <jtv> Rinchen: you're already in the GCP, no? <Rinchen> lol <Rinchen> jtv, no idea <jtv> Rinchen: but you're in the GTF now, right above Journal of Japanese Studies. <Rinchen> lol <Rinchen> domo <thumper> mwhudson: I feel the same way <Rinchen> morning thumper <thumper> Rinchen: morning <kiko> ahoy hoy * flacoste cheers kiko <Rinchen> ahoy me matey <Rinchen> 45 seconds on the atomic clock <intellectronica> i say, free supply of meth to the down under participants if they agree to hold the meeting an hour earlier * Rinchen laughs. <thumper> Hmm.. my clock must be out <Rinchen> intellectronica, I don't think Thumper needs meth <gmb> T - 5 <Rinchen> and on that note..... <Rinchen> #startmeeting <MootBot> Meeting started at 20:00. The chair is Rinchen. <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] <Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development. <Rinchen> [TOPIC] Roll Call <MootBot> New Topic: Roll Call <Rinchen> me! <bac> me <statik> me <mars> me <mthaddon> me <intellectronica> me <gmb> me <jtv> me <danilos> me <abentley> me <carlos> me <flacoste> me <thumper> me <BjornT> me <matsubara> me <bigjools> me for 30 mins <herb> me <EdwinGrubbs> me <salgado> me <sinzui> me <adeuring> me <cprov> me <Rinchen> mrevell, mpt ? <kiko> me <mrevell> me <stub> me <flacoste> barry is still sick< <Rinchen> apologies from allenap <mwhudson> me <schwuk> me <kiko> I'm sick too <mrevell> Rinchen: mpt said somethng about going to the other side of the world earlier, so maybe he's on a flight. <leonardr> me <Rinchen> anyone missing from your teams flacoste, statik ? <statik> nope <Rinchen> SteveA? <statik> all present and me'd <flacoste> Rinchen: apart barry, no one <Rinchen> cool thanks <Rinchen> [TOPIC] Agenda <MootBot> New Topic: Agenda <flacoste> Rinchen: besides i'd love to have statik on my team, but he got one of his own :-) <Rinchen> * Next meeting <Rinchen> * Actions from last meeting <Rinchen> * Oops report (Matsubara) <Rinchen> * Critical Bugs (Rinchen) <Rinchen> * Bug tags <Rinchen> * Operations report (mthaddon/herb) <Rinchen> * DBA report (stub) <Rinchen> * Sysadmin requests (Rinchen) <Rinchen> * New packages required (salgado) <Rinchen> * A top user-affecting issue (mrevell) <Rinchen> * Doc Team report (mrevell) <Rinchen> * Blockers <Rinchen> [TOPIC] Next meeting <MootBot> New Topic: Next meeting <Rinchen> There was some rather vocal pre-meeting discussion about how the 18:00 UTC meeting time no longer works for the European team members now that the Northern Hemisphere is on DST. <Rinchen> DST ends in NZ on the 6th which would mean that next week could start the meeting at 17:00 UTC and this would restore the meeting time to the usual hour. I understand this is still not convenient for the eastern Europeans but it would be 7am in NZ allowing those folks to participate. <thumper> ah, 17:00 UTC is 5am <jtv> Or midnight for me <gmb> Even *I* think that would be harsh... <Rinchen> hmm I must have misread timeanddate.com then <thumper> for NZ take UTC and add 12 hours <thumper> I could do 6am <thumper> but 5am is a little harsh <Rinchen> yeah, indeed <Rinchen> we could move the meeting up <Rinchen> but even at 14:00 it'll be 2am <barry> me <danilos> vote? <thumper> votes suck <thumper> :-) <flacoste> yeah, the antipodeans are underpresented <Rinchen> because they are mostly asleep still <danilos> thumper: we can vote on that too :) <carlos> let's open a Launchpad poll!! <gmb> flacoste: I think you mean under*rep*resented. * carlos hides <Rinchen> kiko, opinions <gmb> Unless they're sartorially shoddy... <flacoste> gmb: that also ;-) <bigjools> it's going to suck for *someone* whatever we do <kiko> I think we shouldn't change the date, as much as it pains northerners <kiko> or the time <SteveA> me <Rinchen> yeah, even the meeting spreadsheet doesn't help us due to our diversity <intellectronica> how about rotation, so it only sucks some of the time? <kiko> this meeting time is totally geared towards tim -- if we change it to be one hour closer to death from him, we've failed <thumper> my only suggestion would be to have rotation <thumper> intellectronica: exactly <kiko> a lot of people would miss meetings, I suspect <kiko> rotations are really confusing <kiko> well, here's my proposal <schwuk> they are <bigjools> thumper: just move back to London :) <Rinchen> I agree because they wouldn't know when the meeting would be <sinzui> The sparsest population is San Francisco and Denver. Should we move the meeting to 13:00 <adeuring> an email reminder can help <kiko> thumper decides whether it's 18:00 or 17:00 UTC <kiko> and we try a rotation for the team leads meeting for 2 weeks <kiko> if it works for that smaller group we can try it for the larger group <Rinchen> (which starts on Monday) <thumper> 18:00 <kiko> is that workable for the next 2 weeks? <Rinchen> ok by me but I'm not affected <Rinchen> anyone deeply opposed? <danilos> any chance to get a more relaxed excuses for missing meetings then? <Rinchen> I'd say take that discussion up with your manager. <jtv> ...who is sitting right next to him <Rinchen> I have no problem with it so long as it's not a regular occurrence and someone covers for you <Rinchen> covers and provides feedback about the meeting of course <kiko> danilos, it's only one meeting a week -- it's not like you don't get a lot of flexibility otherwise. <stub> Is this meeting still considered essential for everyone now the teams have grown and been reorganized? (assuming yes, but I don't know if this has been discussed) <kiko> I can see that if it's after 10pm or before 7am it's nasty <kiko> I think the meeting is one thing that helps ensure people are on the same page in a number of things <danilos> kiko: that's true, but see stub <kiko> danilos, I'm really sympathetic to stub, jtv and thumper for that reason <intellectronica> let's discuss this again after you've experimented with rotation for for the team leads meeting. no point going on about this for hours here and how <kiko> okay <kiko> fair enough. thanks <barry> kiko: i don't care what you do, just be sure to send a very clear email to the list stating when the next meeting is ;) <kiko> barry, in what timezone? :) <kiko> heh <Rinchen> [AGREED] try rotating the team leads meeting to see how well that works for everyone. If it works well we'll consider rotating the larger LP meetings. <MootBot> AGREED received: try rotating the team leads meeting to see how well that works for everyone. If it works well we'll consider rotating the larger LP meetings. <kiko> [AGREED] keep meeting at 18:00 for the next 2 weeks <barry> kiko: us eastern of course <wink> * kiko kicks fucking MootBot <Rinchen> [AGREED] keep meeting at 18:00 for the next 2 weeks <MootBot> AGREED received: keep meeting at 18:00 for the next 2 weeks <Rinchen> [TOPIC] Actions from last meeting <MootBot> New Topic: Actions from last meeting <Rinchen> both have been worked on <Rinchen> flacoste, any commentary on the librarian? <Rinchen> none is ok <flacoste> Rinchen: kiko and I had a call, and it seems that the issue is similar to the app server <flacoste> Rinchen: so i'm investigating that first <Rinchen> k, thanks. We'll come to that topic shortly <Rinchen> [TOPIC] Oops report (Matsubara) <MootBot> New Topic: Oops report (Matsubara) <matsubara> Today's oops report is about bugs 209892, 211394, 211423 <ubotu> Launchpad bug 209892 in launchpad-bazaar "LaunchpadValidationError raised while registering a branch using the xmlrpc interface" [Undecided,New] https://launchpad.net/bugs/209892 <ubotu> Launchpad bug 211394 in launchpad-bazaar "OOPS deleting a branch" [Undecided,New] https://launchpad.net/bugs/211394 <ubotu> Launchpad bug 211423 in malone "OOPS in the email interface when inactive account tried to file a new bug" [Undecided,New] https://launchpad.net/bugs/211423 <matsubara> mwhudson, since you commented on #209892, and wrote that code, can you take it? <matsubara> thumper, who from your team should take 211394? <matsubara> intellectronica, can you take 211423? <mwhudson> matsubara: oh right yes <thumper> matsubara: I'll work with abentley on 211394 <intellectronica> matsubara: i can take a look at 211423, since i'm doing emaily stuff anyways <matsubara> that was smooth! thanks guys <matsubara> I'm done Rinchen. back to you <Rinchen> [AGREED] mwh to work on bug 209892 <MootBot> AGREED received: mwh to work on bug 209892 <Rinchen> [AGREED] intellectronica to look at bug 211423 <MootBot> AGREED received: intellectronica to look at bug 211423 <ubotu> Launchpad bug 211423 in malone "OOPS in the email interface when inactive account tried to file a new bug" [Undecided,New] https://launchpad.net/bugs/211423 <Rinchen> I'm trying to do more of these per feedback from the Ozzies <Rinchen> [AGREED] Thumper and abentley to look at bug 211394 <MootBot> AGREED received: Thumper and abentley to look at bug 211394 <Rinchen> [TOPIC] Critical Bugs (Rinchen) <MootBot> New Topic: Critical Bugs (Rinchen) <ubotu> Launchpad bug 211394 in launchpad-bazaar "OOPS deleting a branch" [Undecided,New] https://launchpad.net/bugs/211394 <Rinchen> two for today <mwhudson> Rinchen: +1 <Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/206654 <Rinchen> This is the memory issue. flacoste, SteveA - is there anything anyone else can do to help? <MootBot> LINK received: https://bugs.edge.launchpad.net/launchpad/+bug/206654 <kiko> Rinchen, SteveA and flacoste have a good plan <kiko> Rinchen, flacoste's working hard on some diagnostic code -- let's wait to see that deployed. <Rinchen> good deal. I didn't think there was much we could add <Rinchen> [LINK] https://bugs.edge.launchpad.net/rosetta/+bug/209859 <Rinchen> jtv, what's your plan for your popularity issue? <MootBot> LINK received: https://bugs.edge.launchpad.net/rosetta/+bug/209859 <jtv> Rinchen: ? <jtv> Rinchen: ah, that. <jtv> Rinchen: memory errors are fixed now, so it's not quite as urgent anymore. <jtv> Rinchen: so will look into that in more detail later. <Rinchen> jtv, should it be high rather than critical? <kiko> yes <jtv> Rinchen: now, yes. <mthaddon> jtv, have we confirmed the memory error fix works as expected? <Rinchen> jtv, would you do the honours? <jtv> mthaddon: yes, thanks for the quick rollout * jtv does honours <Rinchen> [AGREED] downgraded bug 209859 to high as it's not as much of an issue now <MootBot> AGREED received: downgraded bug 209859 to high as it's not as much of an issue now <ubotu> Bug 209859 on http://launchpad.net/bugs/209859 is private <ubotu> Bug 209859 on http://launchpad.net/bugs/209859 is private <Rinchen> heh <Rinchen> thanks <Rinchen> [TOPIC] Bug tags <MootBot> New Topic: Bug tags <Rinchen> we have 1 <Rinchen> intellectronica, javascript * kiko snickers as he fixed his! <Rinchen> https://help.launchpad.net/TaggingLaunchpadBugs <kiko> I approve javascript <thumper> +1 <matsubara> +1 <sinzui> +2 <Rinchen> Any objections? <intellectronica> sounds like a consensus to me <kiko> no <cprov> no <Rinchen> [AGREED] javascript bug tag approved, intellectronica to update the wiki <MootBot> AGREED received: javascript bug tag approved, intellectronica to update the wiki <Rinchen> [TOPIC] Operations report (mthaddon/herb) <MootBot> New Topic: Operations report (mthaddon/herb) <herb> 2008-03-31 - edge2 died. nothing in nohup.out. restarted. <herb> 2008-03-31 - Cherry pick 5977 <herb> 2008-04-02 - edge3 died, no coredump. restarted. <herb> 2008-04-02 - Cherry pick 5992 <herb> 2008-04-02 - edge1 died during logrotate. restarted. <herb> We're going to be testing a new staging update script which might cause staging update errors over the next couple of days. Tom and I will be watching closely. <herb> Cherry pick 5992 had issues due to the new config format. <herb> Multiple restarts of both edge and production app servers daily due to memory leaks. <mthaddon> I'd also like to bring up the issue of rocketfuel-built inconsistencies that I'd mailed to the list <kiko> herb, what's the issue with the staging update script? <mthaddon> kiko, we're adding an option to allow non DB-import version <herb> kiko, no issue, just a change in the way we deploy the code. <mthaddon> kiko, at the moment, non-DB import on staging is manual - we're adding it as an option to the script so it can be consistent and quicker in the future <kiko> gotcha <kiko> nice job! <Rinchen> Anything else for herb or mthaddon ? <mthaddon> thx, rocketfuel-built inconsistencies, anyone? <kiko> the deaths of edge due to links? <Rinchen> ah yes <kiko> mthaddon, you got a reply on list about that? <kiko> it's something to take up with lifeless afaik <kiko> err <mthaddon> kiko, yeah, but wasn't very revealing - okay, will take up with lifeless <kiko> the deaths of edge due to leaks? <herb> kiko, most likely. <LarstiQ> leaks make a lot more sense than links :) <kiko> mthaddon, the inconsistencies were pretty minor, right -- just perms? <kiko> LarstiQ, talking on the phone at the same time ruins me :-/ <mthaddon> kiko, yeah, just perms, but creates noise on a new production code checking script we're putting in place <Rinchen> further discussion? <mthaddon> but anyway, that's it from me <kiko> gotcha <kiko> thanks <Rinchen> [TOPIC] DBA report (stub) <MootBot> New Topic: DBA report (stub) <stub> Currently our full text indexes are only indexing the first 2.5k of text for a row. This is screwing up package searchi (Bug 207969). I'll be landing a patch that turns off this limit so we can test on staging to see if anything blows up. I think the limit is left over from limitations on earlier PG versions. <stub> I want to have the auth/person split finalized next week and implementation started. I need to go over the options and recommendations with Mark first. <stub> I've been seeing more idle open transactions being killed by our transaction reaper - fiera and poexport I think. These should be obvious in the OOPS report (server closed connection). If this is a problem and can't be fixed in the short term let me know and we can discuss increasing the timeouts. <ubotu> Launchpad bug 207969 in soyuz "ppa search fail to return expected results on some cases" [High,Fix committed] https://launchpad.net/bugs/207969 <stub> We have two options for migrating to PG 8.3. Do it whenever while the data centre machines are running dapper and take around a 3.5 hour downtime hit, or wait until the DC machines are running hardy and we can run Slony-I. This will allow us to do the migration with a few minutes of downtime. I'm thinking waiting for Hardy unless elmo wants to delay DC upgrades for some reason. <stub> All for now. <danilos> stub: fyi, those 'poexport' leftovers could be from manual killings of poexport script to solve some problems <kiko> stub, I'm hoping for hardy soon, too <kiko> let's see what the release looks like <stub> Ok. I can't tell from my end. * stub nods <Rinchen> Thanks stub <Rinchen> anything further for stub? <Rinchen> [TOPIC] Sysadmin requests (Rinchen) <MootBot> New Topic: Sysadmin requests (Rinchen) <Rinchen> Hi! Is anyone blocked on an RT or have any that are becoming urgent? <Rinchen> I know about the usual suspects from last week <kiko> Rinchen, BjornT will be wanting to talk to elmo about setting up a debbugs instance <jtv> Rinchen: #30384 is pretty important to us. <jtv> But it's brand-new. <BjornT> kiko: we'll be having a call about it tomorrow <kiko> BjornT, owwsom <Rinchen> BjornT, let me know how it goes. <Rinchen> jtv, got it <Rinchen> any others? <bigjools> Rinchen: any eta for mine? <Rinchen> bigjools, none, or kiko's either. IS is working on several things, many to prep for hardy as I understand <kiko> yeah <Rinchen> but I'll keep after them <Rinchen> [TOPIC] New packages required (salgado) <MootBot> New Topic: New packages required (salgado) <mthaddon> jtv, isn't that just setting up launchpad_langpack? <salgado> if any of the branches you're working on right now depends on any library which is not part of the launchpad-dependencies package, come talk to me ASAP. <kiko> salgado, there is a big hardy shakeout happening eh? <jtv> mthaddon: basically, though no longer as standby for production <kiko> will that affect lp-devel-deps <mthaddon> I thought we'd agreed to use launchpad_staging for that? <salgado> kiko, hardy shakeout? <Rinchen> yeah, what should we do about python-xml? <kiko> well, the upgrade causing issues left and right with our dependencies <jtv> mthaddon: we feel like messing with the schema. <carlos> mthaddon: it's just for a big branch we are working on <carlos> mthaddon: in general stating is enough <mthaddon> jtv: well that didn't last long... :( <jtv> s/stating/staging/ <carlos> s/stating/staging/ <salgado> I think in the long term we should replace python-xml with something else <kiko> mthaddon, hey, this is software engineering! :) <Rinchen> I'm currently running and older copy per salgado's email <jtv> engineering is blowing stuff up. <flacoste> salgado: i suggest the ElementTree API <stub> (which means we make it up as we go along) <kiko> what flacoste said <salgado> jtv, carlos, danilos, is that feasible? * intellectronica blows his nose <kiko> stub, (you and me think alike) <flacoste> salgado: several libraries provide that interface (lxml, cElementTree, ElementTree, there is even a BeautifulSOupwrapper for it) <kiko> flacoste, ah, there's a wrapper you tell me now!! <danilos> salgado: would need investigation, we are parsing DTD, not XML <Rinchen> we also use py xml for new branch creation when running make schema <flacoste> kiko: not the way we need for our pagetests though <kiko> flacoste, </3 <flacoste> kiko: it to use the ELementTree API with BeautifulSoup <mwhudson> Rinchen: eh, really? is that not something that just gets imported by the by? <kiko> mwhudson? <Rinchen> make-dummy-hosted-branches <Rinchen> mwhudson, I haven't checked it in detail though <kiko> I am concerned that the hardy upgrade will cause big shakeouts in lp-deps and we are skewed further from production <kiko> but I guess we'll just need to keep a special eye out for version upgrades <kiko> and file bugs against ubuntu <kiko> btw <kiko> please escalate ubuntu packaging bugs to joey <kiko> and I'll work with him to make sure they are fixed <Rinchen> deal <kiko> before hardy releases <salgado> kiko, I don't see what is your concern. the only problem we've seen so far is with python-xml and python-pkg-resources <kiko> this is really important, because otherwise we're at a distro blind spot just filing bugs <carlos> Rinchen: https://bugs.edge.launchpad.net/bzr/+bug/208418 <ubotu> Launchpad bug 208418 in bzr "ValueError when trying to pull/merge from a remote repository" [Critical,Confirmed] <kiko> salgado, that's two packages already <salgado> the latter not being in lp-deps so not really a problem <kiko> and counting <kiko> well.. so yes, this problem goes beyond deps, salgado <kiko> what's your point? should we not worry? :) <salgado> we should <kiko> okay! :) <salgado> I just don't expect it to be a big deal <salgado> maybe I'm just too optimist <kiko> well, it's a big deal if we need to pin or downgrade packages past the hardy release <kiko> let's make sure we get these fixed before that. <kiko> over and out! send bugs to Rinchen <Rinchen> [AGREED] there is concern that hardy will affect our dependencies. e.g. python-xml no longer contains a module we need. Devs to provide bugs of this sort to Rinchen for follow up <MootBot> AGREED received: there is concern that hardy will affect our dependencies. e.g. python-xml no longer contains a module we need. Devs to provide bugs of this sort to Rinchen for follow up <Rinchen> [TOPIC] A top user-affecting issue (mrevell) <MootBot> New Topic: A top user-affecting issue (mrevell) <mrevell> Yo. <kiko> Yo! <mrevell> other than the POT export failure, which the Translations guys are dealing with, I haven't seen any major issues this week. However, in the launchpad-users thread on bug noise, Bruce Cowan links to a fascinating blog post and comment discussion on karma hunting (http://www.sourcecode.de/content/dealing-with-bugs-no-karma-hunting). The suggestion is that some people edit bugs in an unhelpful manner simply to boost their karma. It <mrevell> makes interesting reading, even if just to see views on how karma influences people's actions in LP. <kiko> I should read that, I have lots of karma <Rinchen> We've had amazing OpenID feedback since we launched too..... amazing as in a lot of it <mrevell> I would be interested to hear from anyone else who has seen a user-affecting issue that they'd like to discuss, though. <stub> The fact I still get Bug #1 spam (and other bugs too) bugs me <kiko> stub, is that bug invalidated for Launchpad? <mwhudson> yes <kiko> I was looking at https://bugs.edge.launchpad.net/malone/+bug/83488 <ubotu> Launchpad bug 83488 in malone "Implicitly unsubscribe bug contact when bug is Invalid" [Undecided,Confirmed] <kiko> today <stub> So invalid targets shouldn't get mail any more? Cool. <kiko> I wish it weren't so controversial <mwhudson> (there's a bug about this problem too, i think) <kiko> yes <kiko> there is <statik> I was really pleased to note yesterday that zed shaw started using bazaar and launchpad http://www.zedshaw.com/projects/vellum/ <kiko> that's very cool <kiko> I've been seeing lots of people request project groups <mrevell> statik: nice hat <kiko> so <statik> ah, that reminds me! <statik> user affecting issue <statik> when people start using launchpad <statik> they almost ALWAYS forget to link their bazaar branch to the trunk series <abentley> kiko: I think that unsubscribing from the bug is wrong. There should be a way to delete the BugTask. <statik> which means that bzr get lp:project doesn't work <abentley> There are *lots* of annoying things about the continued existence of invalid bugtasks. <thumper> statik: I tried to make that a bit more obvious on the project code page <thumper> st <thumper> statik: perhaps we need to work out a better way <thumper> statik: mdz suggested making "bzr push lp:project" autolink <statik> thumper: yeah, I've just realized over the last week that almost every new project i saw in launchpad I had to email them and tell them to hook up their branch to trunk <thumper> statik: which requires api's to work as a privledged user <thumper> but would be cool <barry> statik: happens to me all the time, and i /know/ i have to do that <mwhudson> thumper: something for the branch/+new page too? <kiko> abentley, well.. deleting bugtasks is a possibility, too. it's just nastier and gives off a different impression than invalidation. <mwhudson> if user is owner and there is no trunk.user_branch then ... <thumper> mwhudson: perhaps... <kiko> good call mwhudson <thumper> mwhudson: best to talk with poolie, but he might agree <mwhudson> doesn't help if the user doesn't use the +new page <mwhudson> thumper: right * Rinchen glances at the clock. <Rinchen> I'm going to move on then.... <Rinchen> thanks for the discussion <Rinchen> [TOPIC] Doc Team report (mrevell) <MootBot> New Topic: Doc Team report (mrevell) <mrevell> Howdy. I've published the new Help wiki home page, along with the YourAccount, Teams and Projects sections of the new user guide. In the mean time, while waiting for the new user guide sections, I've linked to existing material in the "user guide" section of the new front page. <mrevell> Following on from last week's meeting, we've had a positive response to the idea of a frequent update detailing changes on edge. We seem to have a split, right now, between those who'd prefer a feed and those who are happy with email. I'd say using the beta testers team's mailing list for these updates would be the least-effort option right now. <mrevell> However it's presented, beta team members seem keen to get this information, as it'll enable them to actively test things we haven't announce in some other way, rather than stumble across them. <mrevell> The only real time-drag I can see, in actually producing the report, is finding if the feature/fix has made it to edge. <mrevell> thanks Rinchenator <gmb> mrevell: Can we not create a script for you that would do the hard work? <kiko> mrevell, we should probably just stick this on edge itself.. <mrevell> kiko: In the way poolie suggested? <gmb> That sounded more subservient than I'd intended... <kiko> i.e. in a hideable element present overlayed <Rinchen> I rather liked poolies NEWS idea <kiko> yeah <mwhudson> mrevell: doesn't the "build 6002" thing in the footer help with that? <Rinchen> but it's an extra step to do news * mwhudson has unpleasant thoughts about conflicts <mrevell> mwhudson: Yeah, it would, although commit 6001 might not be on edge because a db change <abentley> Let everyone create a description of their feature. One per file, so you don't get conflicts. Require it in reviews. <mwhudson> mrevell: uh <thumper> abentley: ah, a news.d directory <mwhudson> mrevell: either you or i are confused here :) <mrevell> mwhudson: Or am I confused? <mrevell> mwhudson: Most likely me :) <abentley> thumper: Pretty much. <mwhudson> mrevell: lets take this elsewhere <mrevell> mwhudson: k <Rinchen> The advantage of a news.d directory or similar is that we can feed that automagically <Rinchen> rather than mrevell having to sift through commits to produce something <thumper> and no conflicts <thumper> (with suitable naming scheme) <kiko> I'm not opposed to it <kiko> would engineers be discliplined enough about it, though? <Rinchen> yeah. I'm happy to try to automate something else but the key for me is that it be automated...and not time consuming. <kiko> Rinchen, hold a vote? <thumper> how about a directory called "edge-news"? <kiko> well, it's not really just edge news <mrevell> I'd always be available to help write or review these news snippets. <kiko> if we do it that way <statik> that's interesting, as the news entry would then be part of the code review <thumper> kiko: they only need to write something if they want explicit testing <kiko> it's news.d really <kiko> thumper, explicit announcement, I hope you mean? <mrevell> thumper: Yeah, simple bug fixes or whatever wouldn't need it. <thumper> well, yea <danilos> warning: we are over time already ;) <kiko> this isn't just for testing <mrevell> I'll open a thread on the ML <kiko> it's for communicating to people what we're doing <stub> News on edge is different to News on production ('Please beta test this new feature' vs. 'here is this cool new feature') <kiko> agreed <kiko> though one is a batched and subsetted form of another if you provide a full changelog <kiko> I'm not sure -- just musing * sinzui rescues children from state institution. <kiko> anyway, good plan with mrevell opening a thread, let's just not drop it <abentley> So tragic to be institutionalized so young. <kiko> moveing on <Rinchen> mrevell, let's chat about this when you have time <kiko> movieing on <mrevell> Rinchen: sho thang <Rinchen> it's that time again... <Rinchen> [TOPIC] Blockers <MootBot> New Topic: Blockers <jtv> Translations: more Kiko please! <flacoste> Foundations: not blocked <cprov> Soyuz Team: not blocked <BjornT> Bugs: not blocked <Rinchen> Releases Team: Not blocked too badly. :-) <thumper> Code: not blocked <kiko> jtv, now with added 99% more kiko <adeuring> hwdb: not blocked <jtv> kiko: yummy <cprov> Soyuz team: P3A RT from bigjools (correction) <Rinchen> [AGREED] soyuz team blocked on the RT <MootBot> AGREED received: soyuz team blocked on the RT <Rinchen> statik? <Rinchen> SteveA? <statik> lopcomm: not blocked <statik> lpcomm even <kiko> SteveA's out <Rinchen> very well then <Rinchen> Shazam! <Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs. <Rinchen> #endmeeting <MootBot> Meeting finished at 20:55. <kiko> thanks joeyey <thumper> thanks Rinchen <kiko> it's great when the meeting overruns! <intellectronica> thanks Rinchen, great meeting <mrevell> Thanks rinchen, thanks everybody. <Rinchen> Thanks gents <statik> thanks everyone for a very informative meeting (especially those at odd timezomens) <abentley> Thanks everybunny <mwhudson> thanks all * mwhudson goes for more caffeine <schwuk> Thanks Rinchen <carlos> thanks * <mrevell> Right, I'm off to drink a flat pint of brown beer, eat jellied eels and wallow in some other stereotypes. #launchpad-meeting 2008-04-04 <jsk> Rinchen, jtv: yo <jsk> Rinchen, jtv: :) #launchpad-meeting 2008-04-08 <barry> #startmeeting <MootBot> Meeting started at 05:00. The chair is barry. <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] <barry> hi everybody and welcome to this week's asiapac reviewer's meeting. who's here today? <mwhudson> good grief <mwhudson> i am here <barry> jeebus, i'm going to bed <mwhudson> jml, thumper, spiv <barry> thumper told me he might not make it <barry> so mwhudson how the hell are ya? <mwhudson> i think the other two should be around <mwhudson> barry: i am ok! <barry> :) <mwhudson> slogging away at code imports for the most part <mwhudson> barry: how are you? <barry> getting over being sick for a week :( <mwhudson> :( <barry> jamesh: hi! <jamesh> hi <barry> we can wait a minute or so to see if jml and spiv show up <barry> sinzui, ol' eastern timezone buddy, ol' pal <barry> [TOPIC] agenda <MootBot> New Topic: agenda <barry> * Roll call <barry> * Next meeting <barry> * Action items <barry> * Queue status <barry> * Mentoring update <barry> * Review process <barry> [TOPIC] next meeting <MootBot> New Topic: next meeting <barry> same time and place? <jml> back <jml> yes <barry> jml: hi <jml> sorry, dst confusion <barry> no worries <barry> okay. same time and place next week <barry> [TOPIC] action items <MootBot> New Topic: action items <barry> * (continued) thumper to report on pending-reviews killer in LP <barry> i guess we'll just continue this one on since thumper's not here <barry> [TOPIC] queue status <MootBot> New Topic: queue status <jml> actually, this is likely to be a bad time for thumper. <jml> I'll ask him about timing preferences after the meeting. <jml> back to queue status. <barry> jml: please do. i'm happy to move it one hour earlier, but probably don't want to go much later <jml> *nod* <barry> queue looks fine to me. still have one of stub's long running test branches <barry> not much in PR <jamesh> I'll get to that. <barry> jamesh: cool, thanks <barry> jamesh: looks like it has a conflict <barry> any feedback on the queue from you guys? <jamesh> barry: it is in .bzrignore, so doesn't obscure the meat of the branch. <barry> jml: i reviewed your branch. i'm really sorry it took so long to get that reviewed <barry> jamesh: cool <jml> barry: np. thanks for the review, I'll aim to reply today. <mwhudson_> pff! <barry> jml: k <barry> anything else? <jml> nope. <barry> [TOPIC] mentoring update <MootBot> New Topic:
{'channel': 'launchpad-meeting', 'month': 4}