#launchpad-meeting 2006-06-27 * Starting logfile irclogs/launchpad-meeting.log (fabbione/#launchpad-meeting) test * Starting logfile irclogs/launchpad-meeting.log #launchpad-meeting 2006-06-29 <SteveA> https://launchpad.canonical.com/PrivateBranches * ..[topic/#launchpad-meeting:SteveA] : public launchpad meeting channel <stub> Waaaay offtopic <stub> Porno name for 'Launchpad' <spiv> Raunchpad? <lifeless> Raucnh Pad <lifeless> need the second syllable <stub> Blewpint.launchpad.net <jamesh> I just lost my connection. Could you invite me again? <jamesh> SteveA: ^^ ? <SteveA> ok <jamesh> thanks <jamesh> select * from pg_locks where pid = pg_backend_pid(); <spiv> SteveA: that was fast <lifeless> SteveA: dyson needs some small love. Is it possible that the infrastructure team can do that ? <lifeless> https://launchpad.net/products/launchpad/+bug/51168 <SteveA> james has agreed to do this <SteveA> stub mentioned that dyson should be made more robust <lifeless> agreed and agreed. thanks jamesh <SteveA> stub: on pagetests... <SteveA> i wonder if we can do a GET vs POST thing, and use a r/o connection for GETs <SteveA> then we could always rollback in the publisher on a GET <SteveA> and then not need to do fancy shit when pagetesting <stub> Thats a thought <SteveA> need to be a bit careful about not rolling back session changes <stub> Hmm... but we want to make GET requests use a read only database connection anyway, so we know no changes are made using that. <SteveA> yes <SteveA> but i wouldn't want to rely on that convention for the pagetests <SteveA> i would prefer to rely on "no commits have been made" <SteveA> although i suppose session stuff screws that a bit <SteveA> although resetting the session DB should be cheaper than resetting the main DB <stub> We don't care about updates to the session database <SteveA> if you insist <SteveA> sounds a tad dodgy <SteveA> we just don't use sessions much in pagetests <SteveA> it's almost all basic auth <stub> We do for cookie auth and notifications, many of which are tested for. <stub> However, I decided that we will never worry about resetting the session database in the tests because if you care, you are using sessions incorrectly. <SteveA> ok. i hope that assumption exists somewhere more concrete than this irc channel and your head <stub> I think there are comments to that effect in the guts of the database reset code ;) * stub doesn't check, just in case ;) <SteveA> i'd expect some garish ascii-art on server start-up <spiv> SteveA: be careful what you wish for... <lifeless> aacows <SteveA> stub, spiv, jamesh: I mailed a call summary to the list. You have Action Items. <SteveA> http://www.fatalexception.org/action_item.html #launchpad-meeting 2008-06-02 <mrevell> orning #launchpad-meeting 2008-06-03 <barry> hello everybody and welcome to this weeks asiapac reviewers meeting <barry> who's here today? <jml> hi! <mwhudson> hi! <mwhudson> wow, i am _actually here_! <barry> :) <jml> also, I really need to make my IRC ident like yours barry <thumper> hi <barry> jml: use your time machine and sign up at freenode 12 years ago :) <thumper> hmm, mine used to be like barry's <jml> barry: I'm dead certain you weren't working at Canonical 12 years ago. <jml> barry: and it was called openprojects back then anyway :) <barry> oh that! ask kiko i think :) <barry> anyway... <barry> == Agenda == <barry> * Roll call <barry> * Next meeting <barry> * Action items <barry> * Queue status <barry> * Mentoring update <barry> * Review process <barry> * Help people learn how big branches can be split up (BjornT) <barry> * (Julian) Since I seem to be finding it hard to get my Soyuz comrades to follow our own informal coding standards, when reviewing Soyuz code please make sure you don't let code of the form: ` if archive.purpose == ArchivePurpose.PPA:` land, instead it should be the simpler: `if archive.is_ppa:` which not only encapsulates the decision in IArchive, it should remove an import of the DBEnum. <barry> * Next meeting <barry> week += 1? <jml> +1 <thumper> yeha <jml> I mean, r=jml * thumper ment yeah <barry> :) <thumper> not cowboy mode <mwhudson> sure <barry> thumper: that would be yee haw <barry> cool <barry> * Action items <barry> actually, i forgot to remove thumper's ai, so there really is nothing <mwhudson> hooray <barry> * Queue status <barry> 3 on PR * jml looks <barry> 6 pinks (tho we won't count stubs branch) <barry> jml: your branch got rejected? * mwhudson tries to remember if jml asked him to look at the stacking puller <jml> barry: because the bzr branch it depends on is unfetchable. <barry> jml: ! <jml> barry: I need to fix it up. <jml> I've had other things to do, I'm afraid. <barry> ah well * barry didn't get to nearly as many branches as he'd hoped today <jml> it's not an immediate concern because we aren't going to land it until the bazaar changes we need are in trunk. <jml> the review process doesn't have a clear place for this sort of thing. <barry> jml: not a WIP? <jml> barry: the Launchpad part of the code is done. <barry> jml: no biggie if the branch'll be ready soon. if not, just remove it from PR and add it back when you're ready <jml> ok. <barry> anything else on the queue? <jml> I'm not sure I understand the question * thumper doesn't look very often any more <barry> er, sorry. any other queue related comments? <jml> no :) <barry> i'll skip mentoring <jml> good good. <barry> i don't think i have anything else to say about bjorn's item, except that i think he was going to take it to the ml <barry> * (Julian) Since I seem to be finding it hard to get my Soyuz comrades to follow our own informal coding standards, when reviewing Soyuz code please make sure you don't let code of the form: ` if archive.purpose == ArchivePurpose.PPA:` land, instead it should be the simpler: `if archive.is_ppa:` which not only encapsulates the decision in IArchive, it should remove an import of the DBEnum. <barry> bigjools was going to start a page for product-specific coding guidelines <jml> hmm. <barry> e.g. what should soyuz devs and reviewers look for <barry> etc. <thumper> hah <thumper> I'm thinking of a bzrlp specific guidelines <thumper> * use unit tests <thumper> :-) <jml> barry: I'm not sure that this is such a good idea. <barry> jml: why not? <mwhudson> thumper: as opposed to doctests you mean? <jml> * are they really unit-y? no? go back and try again. <thumper> mwhudson: yeah <jml> barry: a couple of reasons <mwhudson> 'read xunit test patterns' <jml> barry: the example that Julian gives could probably be enforced in code, rather than by review, by making 'purpose' a private attribute <jml> or protected or however zope spells it. <jml> barry: also, it feels kind of a roundabout way of getting the soyuz team clear on their own abstractions. <barry> jml: it's also to get reviewers who aren't as familiar with the internal conventions, to know what to look for <jml> barry: I'm not strongly opposed to the idea, but... <barry> jml: i think what you're saying is that there should be one obvious way to do it, even if you're not dutch <jml> barry: yeah, that's kind of what I'm saying. <barry> it's a good point <jml> barry: in fact, that's very much what I'm saying :) * barry chants the zop <jml> barry: I think there's a stronger case for having review guidelines split by service types rather than by team. <barry> jml: i'll communicate that on to the ameus <mwhudson> jml: 'service types' ? <barry> jml: what do you mean? <jml> barry: webapp, package builder, codehosting etc. <jml> because they are actually quite different areas and hard to navigate if you aren't familiar <jml> but then the guidelines wouldn't be so much "Use the provided interface" as brief tours <barry> hard too to remember if you're not deep in it every day <jml> so maybe forget I said anything. <jml> or rather, I think it's a good idea, but it's heading off topic <barry> well, i agree that it would be good to have better roadmaps for functional areas. this would especially help new devs <jml> the sort of thing that fits on to one A3 page. <barry> yeah <barry> anyway, that's all i have for today. anything more from y'all? * jml thinks <jml> barry: nope. <barry> alrighty then, have a great week. g'night :) <mwhudson> g'night bazza <jml> barry: g'night. <jml> mwhudson: heh. <Rinchen> yay! <Rinchen> Mootbot works! #launchpad-meeting 2008-06-04 * ToyKeeper wonders how to get relatively small feature requests pushed through the launchpad development process <jml> ToyKeeper: filing a bug works pretty well, as does mentioning it on the #launchpad channel. <ToyKeeper> Bug 161187 has been idle since November, and seems like it'd be a pretty quick, low-risk enhancement. <ubottu> Launchpad bug 161187 in launchpad "not obvious how to add a download file for a new release" [Medium,Confirmed] https://launchpad.net/bugs/161187 <ToyKeeper> Oops, this is -meeting. Xchat cuts off the tab titles. :0 <mrevell> g <barry> hello everyone and welcome to this week's ameu reviewers meeting. who's here today? <sinzui> me <bigjools> me <schwuk> me <bac> me <allenap> me <intellectronica> me <flacoste> me <salgado> me <barry> BjornT: ping <barry> danilos: ping <barry> EdwinGrubbs: ping <barry> gmb: ping <intellectronica> barry: gmb had to leave urgently earlier today, so he probably won't be participating in the meeting <BjornT> me <EdwinGrubbs> me <barry> intellectronica: okay thanks (hope all is okay) <barry> statik: ping <barry> i think that's everyone <statik> me! <barry> == Agenda == <barry> * Roll call <barry> * Next meeting <barry> * Action items <barry> * Queue status <barry> * Mentoring update <barry> * Review process <barry> * domain-specific cheat sheets: there should be only one way to do it <barry> * (intellectronica) What should our policy be for the formatting of destructuring assingments? <barry> * Next meeting <barry> everyone good for next week, same time & place <barry> we'll take that as "yes" :) <barry> * Action items <barry> * barry to start discussion of big branch rejection policy on ml * barry sucks <barry> * bigjools to start domain specific cheat sheets * bigjools sucks too <barry> * flacoste to add `safe_hasattr()` to `lazr.utils` <bigjools> tbh I won't start that until after 2.0 <barry> flacoste: does NOT suck! <flacoste> done! <barry> bigjools: okay, should we leave it on there or axe it? <bigjools> barry: it might be better to axe it until we can all agree on a good format for each project <barry> bigjools: done <bigjools> common format, I mean <barry> * bjorn to add recommendation to test style guide saying don't use asserts in doctests <barry> BjornT: ^^ <BjornT> that's done <barry> BjornT: excellent, thanks! <barry> * Queue status <barry> jml was going to remove his rejected branch from the general queue <intellectronica> there are quite a few branches on the general queue. i suggest allocating to reviewers at the end of allenap's shift and mine if we didn't finish <barry> other than that, how are things going? <barry> intellectronica: +1 <barry> intellectronica: favor mentorees if you can <intellectronica> ah good idea, wouldn't have thought about that * bigjools does not need any more this week! <intellectronica> bigjools: noted. but you can always reject if you're overloaded <bigjools> just saving wasted effort ... <barry> any other queue related comments? <barry> * Mentoring update <barry> if you have graduations or suggestions for recruits, send 'em to me <barry> that's all i have <flacoste> that was shor1 <barry> wait, just on mentoring... <barry> * Review process <barry> * domain-specific cheat sheets: there should be only one way to do it <intellectronica> yeah, you should _always_ cheat <barry> bigjools: something was suggested in the asiapac meeting, regarding the soyuz suggestion you made. jml thought that the code should express there's only one way to do it <bigjools> barry: that would be quite hard <bigjools> but I understand the ethos <barry> bigjools: make it a private attribute? <barry> bigjools: or, er non-public <barry> but in general, yes, that's what we should be doing <bigjools> it needs lots of drive-by fixing before that can happen, but yes I agree <bigjools> encapsulation is the way forwards <bigjools> ;) <barry> bigjools: cool :) <barry> btw intellectronica :) <barry> * (intellectronica) What should our policy be for the formatting of destructuring assingments? <barry> intellectronica: the floor is yours <intellectronica> well, the question is pretty self explenatory <intellectronica> a) (item1, item2) = multival_func() <intellectronica> b) [item1, item2] = multival_func() <intellectronica> c) item1, item2 = multival_func() <intellectronica> which one should it be? <intellectronica> i used to write c, today i reviewed b, and got convinced that it should probably be a * barry prefers (c) unless there's only one item * bigjools votes (a) or (b) but not (c) <bigjools> and kiko preferred that too * sinzui lists c * bac prefers c * allenap prefers c <salgado> yeah, I prefer (c) too <kiko> what are the dangers with c) <barry> bigjools: kiko prefers (c)? * EdwinGrubbs thinks "item1 = func()[0]" looks cleaner for a single value * sinzui likes c <kiko> ? <barry> EdwinGrubbs: i agree, but there's been disagreement over that one. SteveA prefers: <intellectronica> kiko: you mentioned problems when refactoring. one could get confused when cut-and-pasting code, i suppose <barry> [item] = func() * flacoste voes c <barry> and i've tended to let those go in reviews these days, though i was much stickier about them at one time <flacoste> that's because it's easy to miss the trailing comma <barry> flacoste: yes, definite this would suck: foo, = func() <flacoste> or because that makes sure that you are really expecting only one items <flacoste> [item] = func() vs item func()[0] <barry> SteveA: things the latter looks "magical" <barry> er, s/things/thinks * allenap prefers tuple literals: (item,) = func() <intellectronica> i think the format for two items should be identical to the format for one item, for simplicity <sinzui> barry: the latter is obtuse <EdwinGrubbs> (foo,) = func() would also look ugly <barry> i.e. it's not clear that you're expecting func() to return a sequence of exactly one item <EdwinGrubbs> [foo] = func() is cleaner <barry> intellectronica: well, unfortunately, python has this syntactic wart, so i'm not in favor of consistency here <salgado> I think we should use "[item] = singleval_func()" and "item1, item2 = multival_func()". the reason being that in the first case that makes it clear that the return value is expected to have a single value and the brackets makes it more visually distinctive than a single trailing comma (e.g. "item, = func()") <barry> salgado: +1 <allenap> functions always returning a 1-tuple are probably broken anyway. <intellectronica> barry: we could always use square brackets. i also like omitting them, but kiko's argument was convincing <bac> and if you're only interested in the nth value? is 'item = func()[n]' acceptable then? <bigjools> hmmm it smacks of inconsistency to me <flacoste> i think so <barry> allenap: i've seen them mostly in tests, where func() returns "some sequence" which for a test case happens to have exactly 1 item <kiko> yes <kiko> I personally feel that <kiko> a, b = x <kiko> is kinda error prone <salgado> bac, in that case I usually unpack all items and then use only the one I want <kiko> (a, b) = x <kiko> I think that <allenap> barry: ah, true. <kiko> a = x, y <kiko> is even more error prone <kiko> and we should definitely always do <flacoste> kiko: why is it error prone? <kiko> a = (x, y) <sinzui> I like to see all the items unpacked...the identifier names act as documentation even when one one item is used. <flacoste> no, a, b = y <intellectronica> i agree with kiko. i think we should have `(x,) = func()` and `(x, y) = func()` <kiko> flacoste, because it's easy to miss the comma in long statements <barry> bac: i personally have no problem with that <salgado> bac, the reason why I do that is explained by sinzui above. :) <kiko> I've lost time tracking down this sort of sillyness <flacoste> (x,) = func() is error prone <intellectronica> sinzui: but won't lint error on that? <flacoste> that's easy to miss the comma there and do <flacoste> (x) = func() <flacoste> which isn't the same thing <sinzui> intellectronica: pylint sucks! <flacoste> i'm -1 on (x,) <kiko> flacoste, agreed. if you have a comma, we should have multiple items <kiko> I'm -1 on (x,) as well <kiko> I am +1 on (x, dummy) <kiko> that's what I mean. <kiko> no implicit tuples I think? <intellectronica> but if you return a 1-tuple? <flacoste> and why (x, dummy) over x, dummy? <kiko> anyway, just my 2c <flacoste> intellectronica: x = func() <kiko> flacoste, because it's easy to miss the comma. <kiko> as I said above? :) <flacoste> and use x as a tuple <flacoste> how would you miss the ocmma? <barry> btw, this pertains to record-type tuple unpacking, not list-type sequence unpacking. i.e. if you really are interested in the 7th item in a 7-string list, use mystrings[7] <flacoste> you xdummy? <flacoste> you read xdummy? <kiko> flacoste, it is trickier when there's other punctuation or long words. <barry> kiko: i only find them hard to miss when they are trailing commas, but that's just me <kiko> but as I said, it was just a suggestion, I will keep on being explicit in code I write :) <intellectronica> ok, if 1-tuples are not relevant to the discussion, then i think (x, y) = is the best option <salgado> why aren't 1-tuples relevant? <sinzui> intellectronica: the pylint warning is an edge case. I have added disabled the warning. We could have a rule that identifiers ending in a trailing _ are to be ignored. <intellectronica> salgado: because they only happen when you return a sequence, not when you return a structure <sinzui> intellectronica: ignore that middle-would-be-sentence <barry> do we need a guideline here, or can we accept both "x, y =" and "(x, y) = "? <BjornT> intellectronica: tests do unpacking of sequences quite often, where the length of the sequence is well-known <barry> BjornT: in tests, i think [foo] = func() is fine <intellectronica> BjornT: sure, but they could still make an exception for 1-tuples <barry> though i still prefer foo = func()[0] <bigjools> [0] is a magic number though <BjornT> barry: i kind of agree with you. in tests i prefer [foo] = func(), but in real code i prefer foo = func()[0], together with an assert len(func()) == 1 <sinzui> barry wont get that past me in a review <BjornT> if you use an assert, the 0 isn't very magical <barry> BjornT: +1 <barry> BjornT: i definitely prefer the much more explicit length assertion <flacoste> verbose <barry> [foo] = func() seems passive agressive to me :) <flacoste> consise <flacoste> concise <bigjools> I must admit, I've got to prefer the short form for its conciseness <salgado> we seem to have only two occurrences of that in non-test code <salgado> database/queue.py: [source] = self.sources <salgado> webapp/dynmenu.py: [name] = self.names <intellectronica> anyway, [foo] is a slightly degenerate case that should only happen in tests, so we should decide on the multiple value, and allow for exceptions if we only have one value <salgado> and a third one <salgado> scripts/ftpmaster.py: [action] = self.args <barry> intellectronica: agreed, okay, here's the vote: <barry> (a) foo, bar = func(); (b) (foo, bar) = func() <barry> what say ye: a or b <intellectronica> b <flacoste> a <barry> a <bigjools> b <salgado> a <BjornT> a <bac> a <sinzui> a <allenap> a <statik> a <barry> okay, unless the australian superdelegates steal the election, we'll go with (a) <intellectronica> bigjools: you see, you thoght convincing me would save you some work, but now you'll have to change it :) <bigjools> intellectronica: too late! <barry> anyway, that's all i have. we have 9 minutes for anything not on the agenda. anybody have anything else? <bigjools> I think it's inconsistent between one and many values now, but hey ho <mpt> barry, judging by the "baa baaaaa", it looks like they already have ;-) <sinzui> I propose that we end unused identifiers with an underscores (ot 2 underscores). It makes it a clearer which as really needed. I can add a pylint rule to never warn that they are unused. * barry will update the style guide and send an email <barry> sinzui: ? <bigjools> for tests? * sinzui asks fore better typing for his birthday <barry> sinzui: i don't understand the suggestion <salgado> (thing_i_want, thing_I_dont_want_) = foo() ? <sinzui> barry: I want a naming convention for variables that are unpacked and unused by the code. <sinzui> We can also tell pylint to ignore them. <barry> sinzui: oh, i use 'ignore' <bigjools> I quite often do dummy = func() in doctests when func produces unwanted output <barry> as in: ignore, ignore, supergoodness, ignore, ignore = func() <sinzui> barry: what is ignore? a port, a day? <salgado> I use dummy, but that doesn't tell me what data it's supposed to hold <barry> sinzui: who cares? <bigjools> if you're ignoring it who cares <sinzui> barry: I care! <sinzui> barry: I'm an idiot. I want to know what the ignored variable is. I may want to use it <barry> sinzui: then it's really not unused is it? <sinzui> barry: then I rename it <barry> sinzui: i don't see how you can have a naming convention for items you don't care about if you really want to know what they are :) <sinzui> barry: The code may not use them, but what they are is self-documentation <barry> sinzui: so then, what naming convention are you proposing? <sinzui> ending the dummy variables with an underscore (or 2 of them) <allenap> scheme_, netloc_, path, query, fragment_ = urlparse.urlsplit(...) <sinzui> barry: pylint will complain about unused variables. I have seen a number of meaningful names in an unpack statement changed to dummy. <barry> allenap: oh, i don't think i've seen that. yeah, that's ugly <sinzui> allenap: right <barry> some of those will go away in python 2.5 anyway, y'know <sinzui> allenap: in py 2.5 you can use their names <barry> sinzui: exactly <barry> named tuples rule <allenap> Do you mean 2.6? <barry> anyway, we're out of time. sinzui take it to the ml? <sinzui> ok <barry> allenap: nope, 2.5 <allenap> Really, I didn't know. Cool :) <barry> thanks everyone, that's it. have a good week! <barry> #endmeeting * barry looks to the sky and yells: moooootbooootttttt! <intellectronica> thanks barry #launchpad-meeting 2008-06-05 <Rinchen> hello MootBot! <statik> is mootbot back? <Rinchen> it is <Rinchen> it was working yesterday <Rinchen> so we shall see today <statik> very cool <Rinchen> the re-write from eggdrop to ubottu hasn't happened yet but it planned <statik> mwhudson_: I'm loving the new import system, I get email notifications as new revisions come in! <kiko-fud> meee <Rinchen> yep, his ntp server is fixed * Rinchen crosses his fingers <Rinchen> #startmeeting <MootBot> Meeting started at 13:01. The chair is Rinchen. <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] <Rinchen> woot! <Rinchen> [TOPIC] Roll Call <MootBot> New Topic: Roll Call <Rinchen> me <gmb> me <schwuk> me <abentley> me <matsubara> me <herb> me <mpt> me <barry> me <stub> me <statik> me <salgado> me <bac> me <adeuring> me <sinzui> me <intellectronica> me <allenap> me <jtv> me <danilos> me <Rinchen> mrevell ? <mrevell> me <cprov> me <vednis> me <EdwinGrubbs> me <Rinchen> thumper? <salgado> flacoste, leonardr? <kiko-fud> meeee <flacoste> me <leonardr> me <BjornT> me <mars> me again <kiko-fud> me <flacoste> Rinchen: foundations is complete <kiko> I'm the most me a me can be <Rinchen> thanks flacoste, releases is here too <Rinchen> allenap? <allenap> me <statik> Rinchen: lpcomm is all here <thumper> me <Rinchen> great thanks <allenap> abel is missing. <BjornT> no, he's not <intellectronica> no, he's adeuring, i think <adeuring> no, I'm here <bigjools> me <allenap> oh yeah, sorry :) <Rinchen> bigjools? <Rinchen> ah gotcha <Rinchen> thanks <Rinchen> ok. <Rinchen> [TOPIC] Agenda <MootBot> New Topic: Agenda <rockstar> me <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) <mthaddon> me <Rinchen> * Doc Team report (mrevell) <Rinchen> [TOPIC] Next meeting <MootBot> New Topic: Next meeting <Rinchen> btw apologies received from SteveA <Rinchen> same time same day next week? <Rinchen> anyone know they will not be able to attend? <statik> I won't be here for the meeting next week <Rinchen> [AGREED] same time next week. Apologies from statik <MootBot> AGREED received: same time next week. Apologies from statik <Rinchen> [TOPIC] Actions from last meeting <MootBot> New Topic: Actions from last meeting <Rinchen> one, and it was completed <Rinchen> [TOPIC] Oops report (Matsubara) <MootBot> New Topic: Oops report (Matsubara) <matsubara> Today's oops report is about bugs 236425, 228307 <ubottu> matsubara: Bug 236425 on http://launchpad.net/bugs/236425 is private <matsubara> sinzui, how's #236425 fix coming? <matsubara> schwuk, any news about 228307? <sinzui> matsubara: it is in PQM <matsubara> flacost, I've seen a couple of CyclicalTeamMembershipError. isn't that one fixed? <schwuk> matsubara: not yet <matsubara> cool. thanks sinzui <sinzui> matsubara: about 18 hours form landing :( <schwuk> matsubara: but the hwdb oops are continuing <Rinchen> it must be coming from New Zealand <salgado> matsubara, CyclicalTeamMembershipError? where did you see them? <matsubara> schwuk: yeah, I wonder if the UploadFailed errors are related <matsubara> salgado: https://devpad.canonical.com/~matsubara/oops.cgi/2008-05-31/F1254 <salgado> oh, when reassigning? <schwuk> matsubara: most likely <matsubara> schwuk: hmm I'll add those errors to the timeout report then. thanks <salgado> matsubara, hadn't seen that one, but I was expecting them to show up <matsubara> salgado: +editproposedmember, I'll follow up with you after the meeting then <matsubara> Rinchen: I'm done. Thanks <salgado> ok <matsubara> thanks everyone <Rinchen> thanks matsubara <Rinchen> [TOPIC] Critical Bugs (Rinchen) <MootBot> New Topic: Critical Bugs (Rinchen) <Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/237086 <Rinchen> Stale PID - mars, how are you coming with this? <MootBot> LINK received: https://bugs.edge.launchpad.net/launchpad/+bug/237086 <ubottu> Rinchen: Error: This bug is private <ubottu> MootBot: Error: This bug is private <mars> Rinchen, the fix should be running right now <Rinchen> excellente <Rinchen> thanks <Rinchen> [TOPIC] Bug tags <MootBot> New Topic: Bug tags <Rinchen> we have no new requests <Rinchen> [TOPIC] Operations report (mthaddon/herb) <MootBot> New Topic: Operations report (mthaddon/herb) <herb> Friday (2008-05-30) we did the re-roll. Since then, we've had one CP for r6407 on Monday (2008-06-02). We have one CP, r6410, waiting for approval. <herb> A branch with configs for the restricted librarian is in the queue at the moment. The directory has been set up on the server. We're just waiting for the branch to land. <herb> We've started work on the Debian import machine. <herb> We had an issue occur Tuesday (2008-06-02). A spike in load on the production DB server caused performance problems with LP. The site became so slow it was virtually unresponsive. Seems similar to the bug filed back in April: Bug #224623. <ubottu> herb: Bug 224623 on http://launchpad.net/bugs/224623 is private <Rinchen> [LINK] http://launchpad.net/bugs/224623 <MootBot> LINK received: http://launchpad.net/bugs/224623 <ubottu> Rinchen: Error: This bug is private <ubottu> MootBot: Error: This bug is private <herb> that's it from Tom and me unless there are questions. <Rinchen> herb, was there any more data from Tuesday that can be added to the bug report? <Rinchen> herb, without more definition I don't think stub can narrow it down <herb> Rinchen: there are the debug logs that we typically get. I can throw them in there. <Rinchen> herb, ok, please do. stub can evaluate if it need further detail after he views them <herb> I'm happy to try to collect more info if the problem occurs again. Just would need some direction as to what would be helpful. <Rinchen> btw, herb and mthaddon, I really like the format you use for your report. <Rinchen> stub, any words of wisdom here? <stub> No - I haven't found where the debug logs are yet. <Rinchen> ok. thanks <cprov> herb: thanks for start working on the gina-machine. <herb> stub: I'll attach it to the bug above. <mthaddon> stub, on hackberry in ~postgres/logs <Rinchen> Any questions for herb and mthaddon? <herb> cprov: thank mthaddon, he's been heading that up. <Rinchen> thanks herb <cprov> mthaddon: thanks ;) <Rinchen> [TOPIC] DBA report (stub) <MootBot> New Topic: DBA report (stub) <cprov> what about the restricted librarian ? <mthaddon> cprov, see above <cprov> mthaddon: duh, sorry, I missed that. <mthaddon> :) <stub> https://bugs.edge.launchpad.net/ubuntu/+source/slony1/+bug/236749 is blocking me testing a low downtime PG 8.3 upgrade procedure. If we can't get a package built, we either need to do a manual install (with the crappy workarounds for hardy mentioned in the bug report) or take the downtime hit. <stub> Both Abel and Danilo are having similar Unicode issues at the moment, where the DB is running in the C locale so lower() doesn't always give correct results. <ubottu> Launchpad bug 236749 in slony1 "No PostgreSQL 8.2 (or earlier) packages" [Undecided,New] <Rinchen> [LINK] https://bugs.edge.launchpad.net/ubuntu/+source/slony1/+bug/236749 <MootBot> LINK received: https://bugs.edge.launchpad.net/ubuntu/+source/slony1/+bug/236749 <stub> I need to investigate if there are still functional index bugs in PostgreSQL that will stop us using them as the solution to their problems. <kiko> stub, why don't we use slony on 8.3? <stub> Because that doesn't help us migrating from 8.2 -> 8.3. <kiko> stub, how much time is the upgrade going to take if we do it cold turkey? <stub> PG 8.2 needs stored procedures built and installed for it, and so does PG 8.3 to do the migration between versions <stub> 3 or 4 hours <stub> But we will have the same issue next major release too probably, and by then we will have high availability systems. <kiko> stub, sure, but we /will/ have slony for 8.3 right? <stub> I suppose. <kiko> stub, I will talk to pitti and doko and see if either of them can help. if not, we should just take the downtime. <kiko> it's no use waiting for too long on this. <stub> I'm thinking for the 8.3->8.4 migration. We need slony for two versions of PG installed to do the migration. <kiko> sure <kiko> once you have 8.3 running, you can install slony for it <stub> Yes - it isn't blocking the migration. Just blocking being able to do it without much downtime. <kiko> stub, if we do decide to upgrade postgresql without slony, why don't we do it at the same time mthaddon and herb schedule the upgrade of our systems to hardy? <stub> We already have PG 8.3 with slony installed. <kiko> cool <mthaddon> kiko, that's a lot of moving parts, but a possibility... <kiko> mthaddon, herb: any news on the hardy updates, btw? that just rang a bell! <stub> That timing would be fine. The main DB server is already running hardy. <mthaddon> kiko, we're working through the low impact ones, and once we're ready to move ahead with the others will get a schedule together <kiko> mthaddon, well, yes, but moving parts that are pretty distinct -- i.e. no LP code will change, just the DB and the frontends <mthaddon> true <stub> Just more to debug if it all falls in a heap ;) <kiko> that is true <stub> But that would never happen <Rinchen> anything else for stub? <kiko> mthaddon, so, any ETA at all for that downtime? <kiko> stub, yes! <kiko> person-auth-split, for 1.2.6, yes/no? <mthaddon> kiko, not yet - I'll try and get you something by the end of the week (a time scheduled, I mean) <stub> gone through review and ready to land. yes. <kiko> stub, I'm asking you because I think you're not aware of our likely post-1.2.6-rollout process <kiko> neither is anyone else outside of people on yesterday's call of course <stub> Its only the first section though - the whole thing has huge scope. But the data model will all be in place. <kiko> but we're unlikely to do any DB patches for 1.2.7 <kiko> that's cool and what I was hoping for <kiko> thanks stub <Rinchen> anything else for stub? <kiko> mthaddon, thanks. it needs to be within the next 3 weekends I guess <Rinchen> popular guy today <kiko> mthaddon, or then only in august <mthaddon> kiko, yep <kiko> nah <kiko> toda <Rinchen> [TOPIC] Sysadmin requests (Rinchen) <Rinchen> Is anyone blocked on an RT or have any that are becoming urgent? <MootBot> New Topic: Sysadmin requests (Rinchen) <kiko> Rinchen, I reminded RT of one to remove some old bazaar repos still public <kiko> it's an old one poolie asked for <kiko> thumper, will we need any RTs for upgrading bzr? <thumper> kiko: I think it is just a normal rollout for LP, or are you referring to other machines? <Rinchen> I saw the thread. If you get no reply to it soon I'll go make myself more visible to IS <cprov> both soyuz-related requests are in-progress (restricted-librarian and gina), thank you. <Rinchen> we have 1 RT for the bzr-beta already <kiko> thumper, both <thumper> kiko: as Rinchen says, there is one for bzr-beta already, and I don't think we'll need one for LP <kiko> okay, thanks. <Rinchen> nifty. Anything else for this topic? <Rinchen> [TOPIC] New packages required (salgado) <MootBot> New Topic: New packages required (salgado) <salgado> anything to add this week? <kiko> salgado, maybe something to remove. do we currently depend on bzrtools? <salgado> isn't shelf in bzrtools? <Rinchen> kiko, thumper submitted an rt to remove that <Rinchen> iirc <thumper> I don't think we do depend on it <thumper> but many have it installed <salgado> there's no launchpad-d* packages which depend on it, btw <Rinchen> (remove from source that is) <mpt> I have launchpad-developer-dependencies but not bzrtools <kiko> salgado, yes, it can be part of -developer-dependencies, but not of -dependencies, because it has a bug in the shelf test suite <stub> PG8.3 has been done now, which is good. <kiko> okay, cool <kiko> thumper, is there a bug filed for the bzrtools bug, btw? would be nice to get that fixed for intrepid.. <thumper> kiko: abentley is aware, but not sure if there is a bug filed <Rinchen> anything else for salgado? <abentley> kiko: A fix has already been committed to trunk. <statik> abentley, like the rest of the bzr team, fixes things almost before we notice them! <kiko> heh <kiko> Rinchen, no, thanks <Rinchen> ok, I think it's time for us to kick off the Matt Revell show....staring... mrevell <Rinchen> [TOPIC] A top user-affecting issue (mrevell) <MootBot> New Topic: A top user-affecting issue (mrevell) <mrevell> heh :) <mrevell> On Sunday, there was an issue with Bazaar branch hosting for branches using the knit format. <mrevell> This led to a discussion about the best way to communicate service-affecting issues to people who use and rely on Launchpad. <mrevell> The outcome is that we have set up a launchpad-announce list. This will be very low volume - service-affecting issues and release announcements only. All mail to the list is held for moderation and only appropriate messages will get through. <mrevell> I shall be announcing the, err, announcements list shortly. <jtv> launchpad-meta-announce? <mrevell> If you have something that must be announced to our users please ping me or, in my absence, RInchen <kiko> mrevell, we should make it so /everybody technical/ at canonical subscribes <kiko> mrevell, I'll talk to mdz about this <mrevell> kiko: Okay, thanks. <Rinchen> a bit taboo but we could subscribe the distro-team list :-) <mrevell> Rinchen: You'd wanna get some flame-retardent gear on first :) <kiko> eww <mrevell> Rinchen: Unless anybody has a comment on that, or the Bazaar hosting outage itself, that's that for me. <Rinchen> thanks mrevell <Rinchen> [TOPIC] Doc Team report (mrevell) <MootBot> New Topic: Doc Team report (mrevell) <mrevell> And the limelight calls again <mrevell> I'm pleased to say that community contributions to the doc team and growing slowly in number. We have a couple of community members who are now actively filing bugs for things they find in the help wiki and who are diving right in and making changes themselves. <mrevell> s/and growing/are growing <mrevell> Other docs news: tour is progressing and I have another meeting with Mark and the designers next week. I have mailed team leads to ask for confirmation of the items I've selected for 1.2.6 what's new and release announcement. Thanks to those who've already responded. <mrevell> Thanks Rinchen <kiko> awesome <kiko> woo! <Rinchen> good stuff, thanks mrevell <mpt> When is the tour due to land? <mrevell> mpt: it might be easier to answer that after my meeting with SEM and Mark on Wednesday <mpt> ok <Rinchen> we have a recent addition to the agenda.... <Rinchen> [TOPIC] Storm Integration <MootBot> New Topic: Storm Integration <Rinchen> kiko! <kiko> heh <kiko> first, I want to thank BjornT for knocking off 100 minutes from PQM test run times <mpt> (otherwise known as "the gathering storm") <kiko> (nothing to do with storm of course) * Rinchen cheers. <kiko> err <kiko> extra zero there, and then some <thumper> 100? <kiko> but YKWIM <kiko> a lot <kiko> https://devpad.canonical.com/~mthaddon/pqm-durations.png <kiko> etc <jtv> Hurray for BjornT! <Rinchen> Yeah, it now takes PQM -20 minutes to run. <mthaddon> nice drop off :) <kiko> thumper, funny you speak up, because I wanted to ask you if you are getting rid of buildbot anytime soon -- it currently is tested against launchpad because it adds lib/ to its path <thumper> kiko: yes we are <kiko> thumper, alternatively, do you know if we can avoid running buildbot tests when LP lands? <flacoste> BjornT: what happened, you turned off all bugs tests? <flacoste> oh <flacoste> the sourcecode dependancy... <flacoste> that took 20mins, amazing... <Rinchen> 10 mins... <Rinchen> my joke missed the audience <thumper> Rinchen: I got it <kiko> thumper, well, ok. when you remove that we'll knock a few minutes off, so that's great to hear. <kiko> flacoste didn't :) <kiko> okay <kiko> now for the real storm topic <kiko> thumper, flacoste, jtv, statik: did you guys ack that list I sent out? <flacoste> kiko: seems sane to me <jtv> kiko: didn't ack it yet, will do when I wake up <thumper> already knocked quite a few off <kiko> I haven't seen any email back on that topic so I want to make sure something is happening <kiko> thumper, you are the man <stub> There where some pillarname ones I would have thought I would have, but if statik wants them he is welcome to them :) <statik> kiko: yep, edwin started looking at it already. funny, i get a lot more tests failing locally than in the report, but we're diggin ito it <thumper> there is a test dependancy issue thought <kiko> jtv, please have a call with jamesh when you get up to sort yours out, I'm unhappy you didn't start on that today <statik> stub: we might send you mail later :) <thumper> many run fine by themselves <kiko> statik, very cool, thanks so much <thumper> but fail when run with everything <thumper> something is stomping on the db configs <kiko> thumper, yeah, need to isolate which one is fscking us over! * thumper looks at sinzui for some strange reason <flacoste> hey, sinzui isn't responsible for all the config problems <flacoste> just the API <sinzui> thumper: et al. mutating the config is bad for testing <kiko> thumper, the problem is tests that write to the configs don't reset them <thumper> yeah, I know <stub> We have an API for config problems? <kiko> heh <flacoste> we have APIs for everything <kiko> okay <kiko> jtv, ack? <sinzui> I think we need to switch to the push() and pop() form of the config and raise an error when someone tries to create a new attribute on the conifg. <jtv> kiko: sure <stub> pickle the config in the layer testSetUp, pickle it in the layer testTearDown and compare. <kiko> thanks vm <flacoste> sinzui: i think that's a little drastic change for our schedule <flacoste> i say only plug the hole, not redo the whole plumbing * sinzui checks the weekend schedule. <flacoste> lol <kiko> what flacoste says, sinzui -- don't get carried away!! :) <kiko> okay, that was all <kiko> Rinchen, take over before it's too late! <Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. <flacoste> sinzui: did they open that crystal meth lab in you 'hood lately? <Rinchen> #endmeeting <MootBot> Meeting finished at 13:43. <thumper> thanks Rinchen <kiko> the crystal <gmb> thanks Rinchen <abentley> tx Rinchen <Rinchen> hehe <sinzui> flacoste: It went up in smoke when the try knocked out the power lines on my street yeterday <flacoste> Rinchen: thank for another one on time <Rinchen> now i Just need to find out where mootbot put the logs :-) <sinzui> I am relying on an infant to keep me awake <flacoste> sinzui, that's probably a little healthier <mwhudson_> statik: oh good :) #launchpad-meeting 2008-06-10 <jml> barry: hi <barry> jml: hi <barry> #startmeeting <MootBot> Meeting started at 21:02. The chair is barry. <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] <barry> yay! <barry> welcome to this week's asiapac reviewer's meeting. who's here today? * jml is reminded to file a bug on Python <jml> barry: I am. <barry> thumper: ping? <barry> mwhudson: ping * barry guesses thumper knows barry will rant at him about pqm :) <thumper> hi <thumper> barry: now why would you rant about pqm? <barry> thumper: i'd like it to vanish more of my branches please! :) <barry> [TOPIC] agenda <MootBot> New Topic: agenda <thumper> barry: I could delete them for you? <barry> * Roll call <barry> * Next meeting <barry> * Action items <barry> * Queue status <barry> * Mentoring update <barry> * Review process <barry> * make pqm not broken <barry> thumper: then i could just stop working on branches too! excellent <thumper> slacking FTW! <barry> [TOPIC] * Next meeting <MootBot> New Topic: * Next meeting <barry> everyone okay with today += week(1) <thumper> +1 <barry> jml: i know you are too :) <jml> :) <barry> [TOPIC] * Action items <MootBot> New Topic: * Action items <barry> nothing on asiapac iirc <barry> [TOPIC] * Queue status <MootBot> New Topic: * Queue status <mwhudson> ah, as traditional, i missed the start of the meeting, sorry * jml files http://bugs.python.org/issue3071 <barry> mwhudson: no problem! i was just about to assign all the GQ branches to you! <mwhudson> heh heh <barry> jml: cool <jml> barry: I've been griping about Python's default exception messages for ages now. <jml> barry: time to do so productively :) <barry> jml: especially with the first betas going out on wednesday! (perhaps) <barry> i don't have much on the queue status <barry> i'm going to assign the 4 GQ branches after this meeting, but other than that, things look okay <barry> i had test failures in the one adeuring branch i started today <mwhudson> oh hey, i got assigned a branch <sinzui> not from me <mwhudson> i totally didn't notice <barry> mwhudson: you should run bac's script! <mwhudson> barry: we should fix launchpad! <mwhudson> etc etc <barry> that too :) * jml notices Python 2.5 actually does a lot better at error messages than 2.4. <barry> jml: 2.5 rocks. we really need to switch to it <barry> anything on the queue from y'all? <jml> barry: damn straight. I want to use defgen :) <sinzui> mwhudson: hmm. I think I did make a mistake. that branch looks familiar. I think I meant to assign it to bigjools * barry wants with statements! <thumper> FWIW abentley is working on the branch that will email the reviewer when nominated for a review <mwhudson> will the zope upgrade get us any close to being ready to use 2.5 ? <barry> thumper: how long before you think we'll be able to do all our reviews in lp? <sinzui> barry: start debugging the zope 3.4 branch. It works except for that giant hole I putting in importfacsist. <thumper> hacky ones in about 3 or 4 weeks <thumper> with shiney happy people, probably about 8 <barry> sinzui: fred drake tells me they (zc) runs zope all the time on py2.5 <barry> thumper: that will rock <mwhudson> sinzui: ok, are you going to move that branch out of my queue? <sinzui> barry: I bet. but importfascists and zope 3.4 conflict. I sacrificed the former for zope <sinzui> mwhudson: I will <mwhudson> sinzui: thanks <barry> sinzui: dang. where's the branch? <barry> anyway. moving on... <barry> [TOPIC] * Mentoring update <MootBot> New Topic: * Mentoring update <barry> skipped as usual... <mwhudson> n/a <barry> [TOPIC] * Review process <MootBot> New Topic: * Review process <barry> * make pqm not broken <barry> so... thumper i'm told you're pqm-man now! :) <thumper> hah <jml> what's the PQM break? <jml> looks just fine to me. <jml> or at least as good as it's ever been :) <barry> there are several problems, but the most severe symptom is that branches are getting disappeared all the time <barry> they fail and nobody gets notified <jml> ahh ok. <jml> that *is* pretty bad. <sinzui> Isn't that directly cause by the make check change from 60 minutes to 15 minutes? <barry> jml: it's doubly bad because grepping through the logs is PAINFUL <barry> since the logs don't include branch information unless they succeed :( <thumper> barry: where are the logs? <barry> sinzui: yes, that's what flacoste thinks <mwhudson> this sounds like something that needs help from an OSA <jml> I see. <mwhudson> not us <barry> thumper: devpad <thumper> barry: where on devpad? <mwhudson> sinzui: i don't see the connection instantly <barry> thumper: /srv/lp-pqm-logs <thumper> barry: thanks <jml> barry: do we know that this is a bug in PQM itself? <barry> francis and i talked about a few things: first, if merges get killed, we should still see notifications, which i think today we don't <barry> jml: we don't, but that's the suspicion <barry> second issue is figuring out why sometimes you get no output for 15+ minutes <mwhudson> but the vicious killing after 15 minutes isn't anything to do with pqm <mwhudson> it's something test.py or shh.py or something does <barry> mwhudson: aren't the logs maintained and sent by pqm? <mwhudson> yes <jml> barry: has anyone tried to reproduce the issue? <mwhudson> but pqm doesn <barry> mwhudson: right. but no one has reproduced the 15 minute hang on dev boxes <mwhudson> 't look at the logs * jml meant the lack-of-notification issue. <barry> jml: not to my knowledge <jml> barry: ok. <barry> third problem was lack of branch information in the logs unless the merge succeeds <barry> but if pqm doesn't write the logs, i guess it can't do that <thumper> pqm does write a log file <thumper> several actually <barry> we need a plan though, 'cause it's killing productivity. e.g. branches are getting stacked up beause parent branches aren't landing and then no one knows why <jml> in my ignorance, I'd say that PQM ought to keep a log of requests it receives and what it does with them. <thumper> jml: it does <thumper> barry: are the bugs filed against pqm? <jml> thumper: but not enough information to identify the branch? <mwhudson> i can't find any logs on devpad in the last 50 that seem to have been killed for lack of activity <mwhudson> but maybe i'm grepping for the wrong things <jml> thumper: well, the first issue isn't yet known to be an issue with PQM. <barry> thumper: i don't know. i will talk with francis in the morning and get some bugs opened <jml> thumper: although it's a decent place to start, I guess. <thumper> pqm is still pretty fresh in my mind <thumper> so feel free to send them my way if urgent <barry> thumper: thanks. i think the lack of notification is the most immediate concern. devs could fix their branch problems if they knew why they bounced <barry> [ACTION] barry to talk with francis and get pqm bugs opened <MootBot> ACTION received: barry to talk with francis and get pqm bugs opened <barry> that's all i've got. does anybody have anything not on the agenda? <barry> nope? okay, thanks everyone! see you next week <barry> #endmeeting <MootBot> Meeting finished at 21:28. <mwhudson> barry: why do you think that branches are getting killed for inactivity? <barry> mwhudson: we don't know. it shouldn't be happening <mwhudson> barry: no, i mean <mwhudson> barry: what is it that makes you think the branches are being killed in this way? <mwhudson> barry: because i don't see much evidence for it myself <barry> mwhudson: we're just guessing. it seems like branches are disappearing more now that we bumped that down, but it's just a guess <mwhudson> barry: are the branches disappearing to the extent of not producing logs on devpad? <barry> mwhudson: no, they are producing logs afaict. mars found one of my disappeared branches in the logs after some clever sleuthing <mwhudson> barry: ok, because grepping logs suggests only two branches have been killed for hanging since the change to a 15 minute timeout <barry> mwhudson: interesting. i think in my case, bzr actually complained (branch format problem because this was a loomed branch). so i wonder if more of them are happening because bzr failures don't get notifications <mwhudson> it's possible #launchpad-meeting 2008-06-11 <barry> #startmeeting <MootBot> Meeting started at 09:02. The chair is barry. <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] <barry> hello everyone and welcome to this week's ameu reviewer's meeting. who's
{'channel': 'launchpad-meeting', 'month': 6}