#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 2009-06-03
<mars> so are we still doing the reviewer's meeting?
<sinzui> mars: I held barry up
<sinzui> he should be free in a few mimutes
<barry> #startmeeting
<MootBot> Meeting started at 09:04. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello and welcome to this week's ameu reviewer's meeting.  who's here today?
<sinzui> me
<mars> me
<gary_poster> me, and I didn't do what I was supposed to yet :-P
<noodles775> me
<adeuring> me
<barry> rockstar: sends his apologies
<barry> gary_poster: oh well, next week <wink>
<gary_poster> :-)
<barry> allenap: ping
<barry> bac: ping
<barry> BjornT: ping
<bac> me
<barry> cprov: ping
<barry> danilos: ping
<allenap> me
<intellectronica> me
<abentley> me
<barry> EdwinGrubbs: ping
<EdwinGrubbs> me
<barry> flacoste: ping
<flacoste> me
<barry> gmb: ping
<cprov> me
<barry> salgado: ping
<barry> just another minute...
<danilos> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> it's a light one today, not surprisingly
<salgado> me
<barry>  * Roll call
<barry>  * Action items
<barry>  * Mentoring update
<barry>  * Peanut gallery (anything not on the agenda)
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry> we already know about gary_poster :)
<barry>  * flacoste to work on API reviewer cheat sheet
<gary_poster> :-)
 * flacoste whistles innocently
<barry> we already know about flacoste :)
<danilos> do we still need it?
<flacoste> i think we do
<flacoste> paradoxically
<noodles775> lol
<intellectronica> we've done quite good without it for a long tim
<intellectronica> time, even
<flacoste> well
<danilos> ok, let me rephrase the question: is it worth keeping it in the agenda?
<flacoste> maybe not
<flacoste> i know i need to do it
<barry> flacoste: i'll remove it.
<flacoste> there is a lot of tricky issues in API export that are often missed
* You're now known as ubuntulog
<flacoste> updating the URLs being an obvious one
<barry> but i still think it would be a good thing to have
<flacoste> but often things about the use of readonly
<flacoste> the naming conventions are kind of understood
<barry> esp. because this will go in our dev wiki so it will be helpful to outside contributors
<flacoste> btw, in the coming weeks we should be able to use launchpadlib for API testing within launchpad
<barry> flacoste: as a buildout benefit?
<flacoste> once gary moves zope to buildout and we update all the lazr.* packages to the latest version
<flacoste> barry: right on
<barry> nice!
<flacoste> btw, anybody noticed the improved tags with buildout?
<barry> flacoste: not yet!
<flacoste> try it out! you can jump to symbol in the stdlib or stuff in any eggs
<barry> flacoste: bin/tags tracebacks for me
<flacoste> oops
<flacoste> ok, we'll look into this
<barry> flacoste: cool, thanks!
<barry> between that and jml most awesome emacs module, you will never lose a symbol again
<barry> moving on...
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> any feedback from mentors or mentats?
<adeuring> I think it is time for Henning to graduate
<barry> adeuring: soon as he shows up to a reviewer's meeting <wink>
<noodles775> I'm still enjoying Celso's mentoring :), looking forward to getting back into it tomorrow after the 2 week break.
<barry> adeuring: serious, that's great
<barry> noodles775: excellent!
<noodles775> BTW: I think he's resting from Ubuflu at the moment...
<barry> :(
<barry> cool, anything else?
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<barry> anybody have anything not on the agenda?  any barcelonan epiphanies about reviews?
<intellectronica> remind your mentats to land javascript branches with [js] in the commit message
<abentley> Now that bzr 1.5 is out, everyone should check out bzr+ssh://bazaar.launchpad.net/%7Elaunchpad/lpreview-body/trunk/
<abentley> Tâhis is a bzr plugin that automatically sets the message body for an lp review request to our standard template, and includes lint output.
<barry> intellectronica: do we have a pqm regexp for that now?
<noodles775> niice
<cprov> err, sorry, was preparing a tea.
<abentley> Of course, this only works with bzr send, so this is a good reason for everyone to use bzr send.
<intellectronica> barry: no. we'd have to inspect the diff for something like that to work
<noodles775> cprov: you're meant to be sleeping off your headache :)
<cprov> barry: noodles775 is doing great reviews, his graduation will come soon too.
<barry> intellectronica: so is this a [js=somebody] tag?
<barry> cprov: fantastic
<intellectronica> barry: no, just [js]
<intellectronica> to indicate that the branch requires testing on multiple platforms
<danilos> abentley: bzr send is good, can you email the list about the plugin as well
<abentley> Also, with the recent launchpad changes, you don't need to push before you send, and you don't need to use lpsend or send --no-bundle.
<mars> barry, it is just a flag to QA that somebody needs to look at the branch in all the browsers
<danilos> abentley: perhaps document it on dev.launchpad.net as well
<barry> intellectronica: k.  do all devs know about that?  maybe a msg to launchpad@ to remind people?
<intellectronica> barry: we already had a message. i can send another one
<abentley> danilos: Okay, but I already emailed the list, and no one responded, so I thought I should bring it up here.
<barry> intellectronica: might not be a bad idea to remind people
<danilos> abentley: ^^ :)
<danilos> abentley: I am certainly going to check it out
<barry> abentley: yes, document on the dev wiki, and this sounds awesome
<abentley> barry: will do.
<barry> abentley: thanks!
<barry> anything else guys?
<barry> 5
<barry> 4
<abentley> barry: It's not open-source, so does it make sense to document on the dev wiki?
<barry> abentley: i think it's fine.  i'd still rather have one place to find relevant information, but i'll leave it up to you
<barry> abentley: is there any reason it /can't/ be open source?
<abentley> barry: Needs signoff from Mark or the holy trinity, and that hasn't happened yet.
<barry> abentley: ok.  i'd say document it on the dev wiki and we can work toward open sourcing it
<abentley> barry: The ball is currently in kiko's court on open-sourcing.
<barry> abentley: let's keep the jfdi pressure on kiko then! :)
<barry> anybody have anything else?
<abentley> barry: See https://wiki.canonical.com/OpenSource/Process
<barry> yeah
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 09:26.
<barry> thanks everyone!
<noodles775> cheers barry
<abentley> barry: thx
#launchpad-meeting 2009-06-04
<Ursinha> #startmeeting
<Ursinha> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and iss
<Ursinha> ues.
<Ursinha> [TOPIC] Roll Call
<Ursinha> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<MootBot> Meeting started at 10:01. The chair is Ursinha.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<MootBot> New Topic:  Roll Call
<Ursinha>  
<bigjools> me
<Ursinha> me!
<intellectronica> me
<sinzui> me
<henninge> ich
<rockstar> me
<Ursinha> herb, hi
<flacoste> me
<flacoste> Ursinha: stub is on leave
<herb> me
<Ursinha> flacoste, okay, I'll send him one email after the meeting
<Ursinha> flacoste, or are you speaking for him?
<Ursinha> [action] Ursinha to send one email to stub about dba report, he's on leave today
<MootBot> ACTION received:  Ursinha to send one email to stub about dba report, he's on leave today
<Ursinha> alright :)
<Ursinha> [TOPIC] Agenda
<Ursinha>  * Actions from last meeting
<Ursinha>  * Oops report & Critical Bugs
<Ursinha>  * Operations report (mthaddon/herb/spm)
<Ursinha>  * DBA report (stub)
<MootBot> New Topic:  Agenda
<Ursinha> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<Ursinha> considering we didn't have this meeting for a couple of weeks, these items are quite old
<Ursinha> let's just check them
<Ursinha>  * Ursinha to talk to intellectronica about bug 357316
<Ursinha>  * henninge to check with danilo the status of bug 302449
<Ursinha>  * flacoste to ask a cp for fix for bug 376207 after reviewing it
<ubottu> Launchpad bug 357316 in malone "hwdb +submit failing with KeyError OOPS" [Undecided,Triaged] https://launchpad.net/bugs/357316
<ubottu> Launchpad bug 302449 in rosetta "Uploading a file with the same name triggers a database constraint." [Medium,Triaged] https://launchpad.net/bugs/302449
<ubottu> Launchpad bug 376207 in shipit "LaunchpadOpenIDStore doesn't support database disconnection" [High,Fix committed] https://launchpad.net/bugs/376207
<Ursinha> about bug 357316, it's in the today's oops section, intellectronica, can you talk to abel about it, please?
<Ursinha> hi henninge :)
<intellectronica> Ursinha: you've talked to me about that bug and I explained that the OOPS is a feature, and that it's indicating that the data we get from checkbox is bad. A checkbox fix is, as far as i know, ready
<henninge> Ursinha: I did talk to him but forgot what the outcome was.
<flacoste> Ursinha: 37207 was part of the roll-out so we can close that one
<henninge> Ursinha: I had said that I thought he was working on it but I had that confused.
<intellectronica> Ursinha: what can we do to get this bug off your list? it's coming up every week but we're sure we don't want to do anything about it
<Ursinha> intellectronica, that part I didn't know, the checkbox fix, that is -- I'll make a note in the bug, thanks
<Ursinha> intellectronica, we're having oopses like everyday
<Ursinha> intellectronica, that's why it's always there
<Ursinha> intellectronica, but if you say there's hope, i'll remove it from the list and make a note in the bug
<Ursinha> thanks :)
<intellectronica> maybe we should change it so that instead of oopsing it sends the error to schwuk's mailbox
<Ursinha> intellectronica, lol
<intellectronica> Ursinha: cool, thanks
<henninge> Ursinha: I remember now: It is rathe uncommon and should not be causing much trouble.
<Ursinha> henninge, right. I'll take note in the bug as well, and watch the occurrence of the oopses. I'll let you guys know if something unusual happens
<Ursinha> thanks henninge
<Ursinha> and thanks flacoste
<Ursinha> and intellectronica
<Ursinha> moving on
<Ursinha> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<Ursinha> flacoste, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/361026
<Ursinha> rockstar, https://bugs.edge.launchpad.net/launchpad-code/+bug/344041
<ubottu> Ubuntu bug 361026 in launchpad-foundations "OOPS when registering a new account on login.lp.net with an email address that belongs to an existing profile" [Undecided,Triaged]
<ubottu> Ubuntu bug 344041 in launchpad-code "Oops when showing merge proposal details" [High,Triaged]
<Ursinha> flacoste, this oops is happening since 2.2.4, IIRC
<Ursinha> in a daily basis
<Ursinha> a few occurrences though
 * flacoste looks
<rockstar> Ursinha, how is that a critical bug?  It's already Triaged as High.
<Ursinha> rockstar, that's not a critical bug, the critical bug is bug 382795
<ubottu> Launchpad bug 382795 in launchpad-code "mirror-branch using too much memory" [Critical,In progress] https://launchpad.net/bugs/382795
<Ursinha> that was my next point!
<rockstar> Ursinha, that's actively being worked on. I'll know the status this afternoon.
<Ursinha> rockstar, of the critical? right. I'll take a note in the bug as well, and check with you guys later
<Ursinha> thanks rockstar
<rockstar> Ursinha, no problem.
<Ursinha> about the other one, it's happening regularly too
<Ursinha> do you know if someone is actually working on that?
<flacoste> Ursinha: yeah, i'm not sure it's easy to fix, removing all the shipit persons from the DB should alleviate the problem though
<flacoste> hmm, not sure actually
<rockstar> Ursinha, no is working on that, no.
<flacoste> Ursinha: actually, it might be fixable
<flacoste> Ursinha: i can ask stub to have a look in the coming week
<Ursinha> flacoste, that's fine
<Ursinha> thanks flacoste
<Ursinha> rockstar, do you have an idea of when it could be fixed?
<Ursinha> just to know
<Ursinha> considering that's assigned to you
<rockstar> Ursinha, nope.  We are all very busy.
<Ursinha> rockstar, I know the feeling
<rockstar> Ursinha, it shouldn't be assigned to me, cause I ain't werkin' on it.
<Ursinha> I'll take a note in the bug about it and deassign the bug from you
<Ursinha> will talk to thumper later
<Ursinha> thanks rockstar
<Ursinha> [action] Ursinha to make notes in all mentioned bugs about the statuses
<MootBot> ACTION received:  Ursinha to make notes in all mentioned bugs about the statuses
<Ursinha> [action] Ursinha to talk to thumper about bug 344041
<MootBot> ACTION received:  Ursinha to talk to thumper about bug 344041
<ubottu> Launchpad bug 344041 in launchpad-code "Oops when showing merge proposal details" [High,Triaged] https://launchpad.net/bugs/344041
<Ursinha> [action] Ursinha to check later with code team the status of bug 382795
<ubottu> Launchpad bug 382795 in launchpad-code "mirror-branch using too much memory" [Critical,In progress] https://launchpad.net/bugs/382795
<MootBot> ACTION received:  Ursinha to check later with code team the status of bug 382795
<Ursinha> good
<Ursinha> thanks all
<Ursinha> moving on
<Ursinha> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<Ursinha> herb, go ahead :)
<herb> Been a while since we had a meeting.
<herb> We did a couple of cherry picks before the last rollout.
<herb> 2009-05-27 - Rolled out 2.2.5.
<herb> 2009-05-29 - Updated lpnet* and edge* with final RC fixes.
<herb> 2009-06-01 - Codehosting outage. It was related to bug #382795. Code was unavailable for approximately 17 minutes.
<herb> 2009-06-03 - Cherry pick to lpnet* to fix bug #381364 and bug #378740. Also had some fixes for the script server.
<herb> Bug #118625 is still an issue. If there is anything we can do to help debug it, please let us know.
<ubottu> Launchpad bug 381364 in launchpad-registry "time out on +milestone page with high statement count" [High,Fix released] https://launchpad.net/bugs/381364
<ubottu> Launchpad bug 378740 in launchpad-registry "Invalid download link in milestone/release context" [High,Fix released] https://launchpad.net/bugs/378740
<ubottu> Launchpad bug 118625 in launchpad-code "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/118625
<Ursinha> bug 118625: rockstar, do you have anything for herb?
<ubottu> Launchpad bug 118625 in launchpad-code "codebrowse sometimes hangs" [High,Triaged] https://launchpad.net/bugs/118625
<Ursinha> or vice-versa
<Ursinha> :)
<rockstar> Nope.  We've had a busy week though.  :)
<Ursinha> busy weeks are good... in some sense :)
<herb> I seem to remember we were at a sort of impasse on it.  just figured I'd bring it up to see if there was anything the LOSAs could do to isolate the problem.
<Ursinha> rockstar, there is?
<rockstar> herb, no, the "sometimes hangs" issue is known, but we have no idea what to do about it.
<herb> rockstar: ok
<herb> rockstar: I mean, not ok.  but understood. :)
<rockstar> herb, :)
<Ursinha> rockstar, herb, :)
<Ursinha> right, anything else for herb?
<Ursinha> hmm, no.
<Ursinha> next
<Ursinha> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<Ursinha> as flacoste said, stub is on leave
<flacoste> any questions for him?
<flacoste> we now have a support contract btw
<bigjools> what's the deadline for db changes this month?
<Ursinha> good
<flacoste> bigjools: like always, week 3
<Ursinha> bigjools, why would it be different?
<bigjools> well I would not say always about that :)
<flacoste> bigjools: but if it needs to be vetted by mark, i don't know when stub has his call scheduled
<Ursinha> oh, I see
<bigjools> exactly
<Ursinha> okay.. anything else?
<Ursinha> 5
<Ursinha> 4
<Ursinha> 3
<Ursinha> 2
<Ursinha> 1
<Ursinha> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<Ursinha> #endmeeting
<MootBot> Meeting finished at 10:25.
<Ursinha> thanks all
<henninge> Thanks Ursinha! ;)
<intellectronica> thanks, Ursinha
<Ursinha> thanks guys
<herb> thanks
#launchpad-meeting 2010-06-09
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> hi, welcome to the launchpad reviewers meeting.  who is here?
<gary_poster> apres moi le deluge
<gmb> me
<noodles775> bac: can I add to the agenda that jelmer graduates?
<mars> me!
<bigjools> me
<noodles775> me
<sinzui> me
<deryck> me
<henninge> me
<abentley> me
<jtv> me
<bac> noodles775: i think that will fit nicely in the mentoring update!
<bac> EdwinGrubbs: ping
<EdwinGrubbs> me
<BjornT> me
<leonardr> me
<adeuring> me
<bac> well that looks quorum-ish, so let's start
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac>  * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * Mentoring update
<bac>  * New topics
<bac>    * make lint [deryck]
<bac>    * Using slave stores to speed up your code [bigjools]
<bac>    * ec2 fix update.
<jelmer_> me
<bac> [topic] outstanding actions
<MootBot> New Topic:  outstanding actions
<bac> firstly, i'm lax and didn't even take up abentley's offer of assistance.  will do so this week.  :(
<bac>  * bac and abentley  to define new doctest policy regarding what is "testable documentation".
<bac>  * sinzui to talk to QA about our QA tracking problem and create a proposal on the mailing list
<bac> sinzui: i didn't see this.  was it sent?
<sinzui> That was co-opted by flacoste who was to have a talk with Urshina
<sinzui> I think we need to remove this task.
<sinzui> No I think we need to redefine it. I think we still have a problem
<bac> sinzui: ok.  i'll remove it and follow up with francis
<bac> * Bjornt to set a policy on what can live in lib/lp, lib/services, and lib/coop
<BjornT> not done
<bac> BjornT: ok, roll to next week
<bac>  * gary_poster and ursinha to email the list re: orphan branches policy and solution
<sinzui> because as RM I had two lists of items reporting QA state, and I do not think either was current at the time
<gary_poster> bac: I discussed that with interested parties instead.  We ill send out email once work is done.
<gary_poster> we will
<bac> gary_poster: excellent.  i'll consider it done then for this meeting
<gary_poster> cool thanks
<bac> new items
<bac> [topic] mentoring update
<MootBot> New Topic:  mentoring update
<bac> noodles775, good news?
<noodles775> Yup... Jelmer is (and has been for a while) very ready to graduate :)
<noodles775> Congrats jelmer_ :)
<jelmer_> noodles775: thanks! :-)
<jelmer_> noodles775: ... and thanks for mentoring, it's much appreciated.
<bigjools> well done jelmer_
<bac> excellent jelmer_.  thanks for your work noodles775
<deryck> congrats to jelmer_ !
<gary_poster> yay :-)
<bac> jelmer_: please look at the schedule and pick a day that needs EU help
<bac> [topic] * make lint [deryck]
<MootBot> New Topic:  * make lint [deryck]
<jelmer_> bac: ok
<deryck> ok, so make lint has become increasingly noisy for me....
<deryck> so much so that it is not so useful anymore.
<mwhudson> deryck: please remove pylint
<deryck> 1) can we fix it?  I hear sinzui has ideas.  and 2) are people reviewing for lint anymore?
<deryck> mwhudson, others suggested this, and I don't mind doing that.  But I heard sinzui might have a better script altogether from what we have now.
<sinzui> 1) replace pyflakes with pep8 in a risky shell hack
<sinzui> 2) extract formater.py from my gdp project to be a standalone linter. It is 100% python, much faster than the shell tools, and it is more accurate
<bac> sinzui: how much effort is 2?
<sinzui> I have not put looked at it. probably doable in 6 hours
<deryck> If others are fine with those suggestions, I'm happy to take on a branch to do this, if sinzui will review it. :-)
<sinzui> We need to add pep8 to contrib in the tree
<bigjools> for those using vim, please use the pyflakes plugin, it's awesome: http://www.vim.org/scripts/script.php?script_id=2441
<bac> sinzui: do you want to take that task, in your abundance of time?
<bac> bigjools: and the one for emacs rocks too!
<sinzui> I can look at it in 7 hours
<bac> sinzui: thanks.
<deryck> bigjools, bac -- I imagine this is how make lint became useless is we all have individual linters, but having a useful make lint is nice when reviewing.
<bac> [action] sinzui to work on extracting a new linter
<MootBot> ACTION received:  sinzui to work on extracting a new linter
<bigjools> it needs to be accurate though, the noise we get now on the webservice declarations is incredible
<bac> deryck: i agree.  when people include the lint output in their MPs it makes me happy.
<abentley> deryck, also the lp_review_body plugin will include it in the review body.
<sinzui> bigjools, my linter uses pyflakes, pep8 and builtin libs to provide s consistent report, I even designed the report to use GUI and command line output (makes testing easy)
<bigjools> nice
<bac> bigjools: but those webservice declarations are actually things we can fix to silence
<bac> [topic] * Using slave stores to speed up your code [bigjools]
<MootBot> New Topic:  * Using slave stores to speed up your code [bigjools]
<bigjools> hai
<deryck> thanks for the discussion on lint, ya'll. :-)
<bigjools> so with the snafu on db performance this week and in particular the depwait-scanner, I converted it to use the slave store as much as possible
<bac> deryck: a real southerner knows how to spell y'all!
<deryck> dang.
<bigjools> you y'all is the plural
<bigjools> anyway
<deryck> real southerners can't spell
<bigjools> I used the information in lib/canonical/launchpad/doc/db-policy.txt
<bigjools> which is a veritable mine of useful info on slave databases
<bigjools> I encourage everyone to read it
<deryck> adeuring is about to convert bug search to use slaves.
<bigjools> the depwait scanner runs quite a bit quicker using the slaves
<jtv> Not to mention potential future scaling.
<bigjools> I'm also perusing the code for anything that hard-codes MAIN_STORE which is utterly gross
<bigjools> I suggest we all do the same
<jtv> bigjools: MAIN_STORE or MASTER_FLAVOR?
<bigjools> and maybe, just maybe LP will be that bit quicker
<jtv> Because MAIN_STORE usually makes sense to me.
<bigjools> I am using the adapter instead
<bigjools> IMasterStore(object)
<bigjools> the getUtility is gross
<abentley> (or even IStore(class))
<bigjools> that doctest doesn't even mention it
<bigjools> the doctest also shows a cool with: syntax
<bigjools> anyway, read it guys
<bigjools> EOT
<bac> thanks bigjools
<bigjools> welcome
<bac> [topic] * ec2 fix update.
<MootBot> New Topic:  * ec2 fix update.
<bac> so good news from mars on ec2.  windmill tests are re-enabled.  thanks mars.
<mars> bac, and bad news
<gary_poster> there's a bit of a snafu if you use a symlinked ec2 to test legacy branches, as I do.  It will make for some very quick, erroneous successes.
<gary_poster> oh sorry
<mars> about to send out a warning to the list: you MUST merge devel into any branch you plan to run through ec2test for the next few hours
<mars> This mucks up db-devel ec2 runs - sorry, it will be fixed soon.
<mars> More details will be in the list mail I will send shortly.
<bac> thanks mars
<bac> [topic]  move code out of c/l [thumper]
<MootBot> New Topic:   move code out of c/l [thumper]
<bigjools> haha
<bac> in the asiapac meeting last week thumper brought up his desire to start getting more stuff out out canonical/launchpad
<bac> our big code re-org was started in march 2009...so it's been a long while that we've had stuff festering there
<bac> thoughts?
<gary_poster> Devil's advocate (gary_poster prepares for rotten tomatoes):
<gary_poster> Right now it seems like we have core bits like webapp in c/l
<gary_poster> and everything else elsewhere
<gary_poster> I fond things pretty easily
<gary_poster> um, find
<gary_poster> Is the cost of continuing the code reorg going to bring an appropriate level of benefit?
 * gary_poster goes and looks at c/l as he should have before opening his mouth
<sinzui> gary_poster, oh. I have a branch that removes most of the glob imports and had to remove hacks to webapp imports
<jtv> Do we need a lib/lp/webapp?
<bigjools> lib/lp/core maybe
<sinzui> lp/services/webapp
<gmb> gary_poster, I think that mailnotification.py needs to be refactored into the separate applications so that it can be got rid of altogether.
<abentley> Yeah, webapp doesn't describe a lot of its contents well.
<gmb> But that might be a separate issue, thinking about it.
<sinzui> gary_poster, everyone. do not talk about moving these until you have also made plans to deal with shipit
 * sinzui cannot consider asking for a review of super import fix without first decoupling shipiy
 * deryck cries "death to mailnotification.py!"
<bac> part of thumper's annoyance was seeing *new* stuff appearing in c/l.
<gary_poster> is mailnotification.py really a reason to get rid of c/l?
<sinzui> 1. do not land in c/1, 2. if you must change work with something in it, move it first
<mars> bigjools, +1 on core
<abentley> gary_poster, lib/lp is a reason to get rid of lib/canonical/launchpad
<gary_poster> I don't like that.
<bac> gary_poster: which that?
<gary_poster> what sinzui proposed
<gary_poster> abentley, but what's the benefit?
<deryck> gary_poster, no, that file should be dismantled anyway.  regardless of what happens to lib/canonical
<gary_poster> right now, this is what I see:
<gary_poster> (agreed, deryck)
<abentley> gary_poster, consistency.  Not having two names for something.
<gary_poster> lp has lots of bits that are specific to the core apps
<abentley> gary_poster, I would have been fine with keeping canonical/launchpad, but since we have come this far, we should finish the renaming.
<gary_poster> l/c has stuff that...foundations touches.
<gary_poster> abentley: fair enough, I see your perspective.  I don't buy that the cost is worthwhile.  I don't buy that sinzui's approach alone is going to get us anywhere except more separation for what foundations touches
<gary_poster> But this is a vote sort of thing
<bac> gary_poster: indeed
<gary_poster> So, I said my piece :-)
<mars> gary_poster, I'm +1 on refactoring.  There are no less than six places that the test infrastructure is set up - refactoring at least straightens stuff out: if you find something, you will try to move it to a better place
<sinzui> gary_poster, it does not get us far because most engineers are not comfortable refactoring the code, and I believe they fear that they do not have permission or time do dtrt
<bac> [vote] We should move towards dismantling canonical/launchpad into more appropriate spots within lib/lp.
<MootBot> Please vote on:  We should move towards dismantling canonical/launchpad into more appropriate spots within lib/lp..
<MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
<MootBot> E.g. /msg MootBot +1 #launchpad-meeting
<abentley> +1
<MootBot> +1 received from abentley. 1 for, 0 against. 0 have abstained. Count is now 1
<mars> +1
<MootBot> +1 received from mars. 2 for, 0 against. 0 have abstained. Count is now 2
<gary_poster> -1
<MootBot> -1 received from gary_poster. 2 for, 1 against. 0 have abstained. Count is now 1
<adeuring> +1
<MootBot> +1 received from adeuring. 3 for, 1 against. 0 have abstained. Count is now 2
<gmb> +1
<MootBot> +1 received from gmb. 4 for, 1 against. 0 have abstained. Count is now 3
<bigjools> +1
<MootBot> +1 received from bigjools. 5 for, 1 against. 0 have abstained. Count is now 4
<bac> +1
<MootBot> +1 received from bac. 6 for, 1 against. 0 have abstained. Count is now 5
<sinzui> The easy work was done. Most of the remaining code does not have an obvious place. We often need to know the tree names to do a rename, ans we do not know them for these service-like code
<henninge> +1
<MootBot> +1 received from henninge. 7 for, 1 against. 0 have abstained. Count is now 6
<gary_poster> That's probably enough, isn't it :-)
<sinzui> +1
<MootBot> +1 received from sinzui. 8 for, 1 against. 0 have abstained. Count is now 7
<bac> voting ends in 10 seconds
<jelmer_> +1
<MootBot> +1 received from jelmer_. 9 for, 1 against. 0 have abstained. Count is now 8
<bac> [endvote]
<MootBot> Final result is 9 for, 1 against. 0 abstained. Total: 8
<bigjools> lol
<gary_poster> :-) fair enough
<sinzui> I saw pagetitles.py was updated for shipit yesterday. we do not support page titles, but shipit and some pages are still using the dead code
<bigjools> easy for every who's *not* doing the work to +1 that :)
<bac> the results won't be official until the new zealand and colorado precincts report
<bigjools> everyone*
<sinzui> Who is fixing shipit?
<gary_poster> heh
<bac> bigjools: yeah, signaling our intent is easy.  doing the work is harder.
<gary_poster> (well, I'm not going to be keen on scheduling foundations to do much of that to be honest, except as part of other refactoring, as sinzui said.)
<bac> gary_poster: i think that is appropriate.
<gary_poster> cool
<bac> [topic] peanut gallery
<MootBot> New Topic:  peanut gallery
<sinzui> I will post an email about names. The migrater script can move most of the chunks of code if we have names for them.
<bac> any  other topics in the remaining 4 minutes?
<jelmer_> actually, I was wondering if anybody had any good suggestions for my regular review day
<deryck> no one was around this morning when I needed a review. :-)
<jelmer_> I'm on thursdays together with noodles775 at the moment but according to the schedule we already have one person for each weekday in europe
<bac> jelmer_: it looks up to you.  every day has EU coverage
<bigjools> Friday - it's the best day;  Just ask sinzui
<deryck> unless pqm is closing that day ;)
<bigjools> shhh
<deryck> heh
<jelmer_> :-)
<henninge> jelmer_: I think you could support jtv because he is not really in EU timezone
<jtv> Isn't allenap in the proper EU slot?
<bac> good suggestion, henninge
<sinzui> I give out RCs before PQM closes. I think you do want to ask me for the review in that case
<bac> jtv: allenap is on rotation
<jtv> facepalm
<jtv> of course
<bac> thanks for coming everyone and for the good discussion
<bac> #endmeeting
<MootBot> Meeting finished at 09:44.
<jtv> thanks bac
<deryck> thanks bac
<jelmer_> thanks bac
<noodles775> Cheers
<gary_poster> thank you
<bac> hi rockstar, thumper.  is this a good time?
<rockstar> bac, sorry, still on the standup.  thumper is long winded...  :)
<bac> rockstar: ping me when he runs out of steam
<rockstar> bac, it could be a while...  :)
<bac> i've nowhere to go...
<thumper> bac: standup finished now
<bac> cool
<bac> Let's start the NZ-CO-NC reviewers meeting
 * rockstar  
<bac> you don't say?
<bac> so we had a lively meeting this morning
<bac> no one actually got to any of the outstanding actions.  i think i should remind people on mondays but i never get around to it...
<bac> deryck whinged about 'make lint' spewing way too much junk to be useful.
<bac> sinzui has a plan to replace pyflakes with a tool he's written.  claims it is much more accurate and faster.
<bac> not sure when he'll get to it.
<rockstar> bac, I think pyflakes is okay, it's pylint that's annoying.
<rockstar> bac, a few times I've been close to just changing the Makefile to kill the pylint call and asking forgiveness later.
<bac> it is possible i got those two confused
<bac> anyway the plan is for sinzui to swap out the crap one with something better.
<wgrant> I love pyflakes, but pylint is more an exercise in adding ignores than anything else.
<bac> and then we all buy him beer
<rockstar> bac, many of us run pyflakes in $EDITOR and it works pretty quickly.
<bac> rockstar: right.  i do in emacs.  bigjools pointed out the vim plug in.
<bac> (and no flame war erupted)
<sinzui> I run pyflakes, pep8 in my editor + real xml parsing the checks entities
<rockstar> sinzui, aren't you using gedit?
<bac> bigjools also brought up the huge gains he got by converting some code to use the slave store.
<sinzui> yes
 * rockstar shudders
<sinzui> I wrote the plugin
<bac> he suggested lib/canonical/launchpad/doc/db-policy.txt should be required reading for all of us.
<bac> mars talked a bit about his fixes to ec2 and mentioned some short-term pain wrt db-devel
<bac> but the good news is it looks like he's got a handle on getting it to be more reliable and that makes me very happy.
<bac> and then i brought up thumper's concern from last time about moving stuff out of canonical/launchpad
<bac> we had a good discussion where gary questioned whether it was worth the effort.
<bac> everyone else thought it was worthwhile.  but it will remain as a techdebt issue to be handled as we have time.
<thumper> I think it is worth the effort :)
<bac> yeah, i figured it would get one or two votes here
<bac> oh and the other good news was that jelmer has graduated as a reviewer.
<bac> did everyone see flacoste's email suggesting a 'text' review type for mrevell to look at textual changes?  sounds like a good plan to me.
<bac> that's about it from the AMEU meeting.
<bac> either of you have new topics?
<bac> going once
<thumper> no
<bac> ok.  well i guess that's it then.
<thumper> thanks bac
<bac> i'll see you later.
#launchpad-meeting 2010-06-10
<Ursinha> #startmeeting
<Ursinha> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<MootBot> Meeting started at 11:00. The chair is Ursinha.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Ursinha> [TOPIC] Roll Call
<Ursinha> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<MootBot> New Topic:  Roll Call
<gmb> me
<gary_poster> me
<Ursinha> me
<matsubara> me
<Ursinha> Chex, sinzui, rockstar, hello
 * rockstar  
<bigjools> me
<Ursinha> Chex and sinzui are missing
<Chex> me
<Ursinha> :)
<Ursinha> only sinzui
<Ursinha> let's move on, try to break rockstar's last week record
<Ursinha> :)
<Ursinha> [TOPIC] Agenda
<Ursinha>  * Actions from last meeting
<Ursinha>  * Oops report & Critical Bugs & Broken scripts
<Ursinha>  * Operations report (mthaddon/Chex/spm/mbarnett)
<Ursinha>  * DBA report (stub)
<MootBot> New Topic:  Agenda
<Ursinha>  * QA stats of the week
<Ursinha>  * Proposed items
<Ursinha> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<Ursinha> None
<Ursinha> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<Ursinha> only one bug, soyuz
<Ursinha> bigjools must love me
<Ursinha> bigjools, I see the last noodles' comment in https://bugs.edge.launchpad.net/soyuz/+bug/580181, do you know if that's being tracked and fixed in another bug or one needs to be filed?
<bigjools> it's in progress
<ubot5> Launchpad bug 580181 in Soyuz "DistributionSourcePackageRelease page still oopsing with NotOneError/LocationError (affected: 1, heat: 8)" [High,Fix released]
<bigjools> Ursinha: it needs a new bug
<Ursinha> bigjools, so soyuz has two, this one and the critical
<bigjools> heh
<Ursinha> bigjools, I'll file one right after this meeting
<sinzui> me
<bigjools> cheers
<Ursinha> bigjools, bug 589073 is in progress?
<ubot5> Launchpad bug 589073 in Soyuz "Unhandled exception processing upload: permission denied for relation emailaddress (affected: 1, heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/589073
<Ursinha> is it really critical?
<bigjools> Ursinha: yes, jelmer should have set that in progress ;)
<bigjools> I don't think it is actually, I'll downgrade it
<Ursinha> thanks bigjools
<Ursinha> we have two critical bugs, one soyuz, one foundations, both being worked on then
<Ursinha> failing scripts are retry-depwait, that's being fixed by bigjools, and karma-update, allocate-revision-karma and others that, according to spm's email, are failing because nightly.sh is taking about 36 hours to run
<Ursinha> Is anyone taking care of this?
<bigjools> retrydepwait is fixed and released
<Ursinha> bigjools, right, cool
<Ursinha> last failure was yesterday
<Ursinha> gary_poster, about nightly.sh, is that foundations' domain?
<sinzui> Ursinha, I think nightly.sh is/was a victim of the master/slave issue
<Ursinha> sinzui, right
<Ursinha> sinzui, it failed yesterday again
<sinzui> nightly.sh has no owner. The losas do a lot of tinkering with it and they do not think they should
<gary_poster> nominally foundations then I suppose
<gary_poster> :-/
<sinzui> Since it takes 36 hours to run, we would expect it to fail even after the db was fixed
<rockstar> It's a good thing that days are longer than 36 hours so that it can actually run nightly...
<sinzui> Another failure to run on time would be worrisome and will warrant further investigation
<gary_poster> agreed
<Ursinha> yeah, right
<gary_poster> And I certainly have not regarded nightly.sh as a foundations responsibility.  I guess that needs to change.  Ursinha, please do help me kick myself about this :-)
<gary_poster> but for now I think we can move on
<Ursinha> gary_poster, sure
<Ursinha> :)
<Ursinha> good
<matsubara> I don't think nightly.sh should be exclusively foundations
<sinzui> gary_poster, rockstar, other than the karma-cache update, I think everything in nightly can be parallelised.
<matsubara> I think the losas are pretty good at identifying which scripts run by nightly.sh are the worst offenders and then the responsible team should take care of that script
<sinzui> the scripts in it belong to code, bugs, translations, and registry
<matsubara> taking the last run for example, package cache and bugtask target names are the worst offenders
<gary_poster> matsubara: no, but if no-one is in charge of something, historically that means foundations.  I'd certainly like it if losas could take that ownership though
<sinzui> and soyuz then
<matsubara> so malone and soyuz(?) should take care of those first
<sinzui> Most failures are spurious.
<Ursinha> matsubara, sinzui, gary_poster, what do you think about discussing that in the email spm sent? this way we can be sure everyone else can join the discussion
<gary_poster> cool thanks
<sinzui> The 9 times out of 10, the last proc ran late because of something else run in the sequence
<Ursinha> ok, so I'll move on
<Ursinha> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Chex> hello everyone, short report this week:
<Chex>  - LP incidents of note, quiet week:
<Chex>         : Jun 08: lpnet15 died, restarted
<Chex>         : Jun 10 : poppy on germanium had died (process died) - restarted
<Chex> Us LOSAs are now searching on Canonical-losas -tagged bugs, here:
<Chex> https://pastebin.canonical.com/33309/
<Chex> I am curious about status of: 45419      Launchpad needs a way of easily flagging spam
<Chex> In the future I will try to bring up critical LP related bugs from this list, to see progress and such, and see if you need any help from us at all.
<Ursinha> bug 45419?
<ubot5> Launchpad bug 45419 in Launchpad Foundations "Launchpad needs a way of easily flagging spam (affected: 7, heat: 60)" [High,Triaged] https://launchpad.net/bugs/45419
<Ursinha> gary_poster should know that ^
<gary_poster> Foundations does not have that anywhere in our plans ATM.
<Ursinha> right..
<Chex> gary_poster: ok, fair enough, then
<Ursinha> anyone else has questions to Chex?
<gary_poster> Chex, that doesn't mean you can't/shouldn't make a stink about that fact :-)
<sinzui> If this is a foundations issue, we schema a behavioural changes made near/on IMessage so that all types of messages get the desired feature
<Chex> gary_poster: aha, ok then.  It is a time-consuming task for us, and having a automated spam-reporting/tagging feature would be highly useful to us
<Ursinha> ok, moving on
<Ursinha> thanks Chex
<Ursinha> [TOPIC] * DBA report (stub)
<Ursinha> Already requested
<MootBot> New Topic:  * DBA report (stub)
<Ursinha> [TOPIC] * QA stats of the week
<MootBot> New Topic:  * QA stats of the week
<Ursinha> I followed up the bugs' ownership in the mailing list
<gary_poster> Chex: spam-reporting: mars and sinzui have the expertise here.  I'll try to coordinate with them.
<sinzui> I had a plan
<rockstar> sinzui, it's because you're a Cylon.
<sinzui> a comprehensive one infact
<gmb> Was it a cunning plan?
<sinzui> That would explain why I can do so long without sleep
<matsubara> heheh
<sinzui> It had a tail like a fox
 * gary_poster chuckles
<gmb> Any more pop-culture references we can fit in here?
<Ursinha> hahaha
<sinzui> We seem to have missed monthy python
<sinzui> Monty Python
<sinzui> I will include that in my email to gary_poster and maris
<Ursinha> thanks sinzui hehe
<gary_poster> thanks sinzui
<Ursinha> moving on again then
<Ursinha> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<Ursinha> I have one
<Ursinha> we know that this meeting's format isn't ideal, and we couldn't find a way to change it to become really useful
<Ursinha> we also realized the qa contacts initiative isn't that effective as we thought in the beginning
<rockstar> Ursinha, for the code team, the only things that are really useful for us are the DB and LOSA reports.
<Ursinha> rockstar, yeah, I'm getting there :)
<rockstar> "Shutting up sir"
<Ursinha> haha no
<Ursinha> so, after talking with flacoste, we decided to get rid of this meeting as we know
<sinzui> I care about the oopses actually. Since I read them every day I like to know when they will be closed or provide info about how to close them
<Ursinha> pause for cheering and etc
<rockstar> Ursinha, so we're doing away with it entirely?
<Ursinha> rockstar, yeah
<bigjools> *golfclap*
<Ursinha> sinzui, as a replacement, there will be created a section in the TLs meeting, a QA one
<Ursinha> and me and matsubara should attend
<Ursinha> we'll keep discussing that with the TLs, so sinzui, you'll still know about the oopses
<sinzui> sweet. I wonder if the meeting will go back over an hour again
<Ursinha> and bigjools, you won't get rid of us
<Ursinha> *evil laugh*
<Ursinha> :P
<gary_poster> :-)
<bigjools> :)
<Ursinha> about the LOSAs and DBA report
<Ursinha> a weekly report should be sent to the list, so we'll all keep posted about it
<Ursinha> so, that's it
<Chex> ok, sounds good, I can do that.
<rockstar> Ursinha, maybe we can have a [QA] subject addition for QA related items.
<Ursinha> thanks a lot Chex, losa's reports are really important
<rockstar> (I suspect I'll still have to deal with QA stuff within my team)
<Ursinha> rockstar, well, it should be dealt with whoever attends the TLs meeting in behalf of code
<Chex> Ursinha: yes I understand that, it helps us, too. I will try to pop my head in on the TLS meetings, too,
<Ursinha> is that you?
<rockstar> Ursinha, no.
<Ursinha> rockstar, so I guess you will only have to worry about your own QA from now on
<rockstar> Ursinha, okay.
<Ursinha> that's all then
<Ursinha> anyone else wants to add something?
<Ursinha> okay
<Ursinha> so, it was very nice to have you for these two years in this weekly meeting
<Ursinha> thanks all
<gary_poster> thank you Ursinha :-)
<Ursinha> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<gary_poster> bye
<Ursinha> #endmeeting
<MootBot> Meeting finished at 11:28.
<Ursinha> sinzui, I thought the irc meeting was postponed in one hour to avoid conflicting with the TLs call
<sinzui> Ursinha, oh yes, it was. We changed the meeting format a short while ago to avoid the extra meeting on Thursday
<Ursinha> sinzui, oh, I see
