#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 here today?
<gmb> me
<gmb> ...
<sinzui> me
<statik> me
<EdwinGrubbs> me
<flacoste> me
<allenap> me
<intellectronica> me
<bac> me
<barry> BjornT: ping
<barry> bigjools: ping
<BjornT> me
<bigjools> me
<schwuk> me
<barry> danilos: ping
 * sinzui passes caffeine to the meeting 
 * bigjools has an alarm for the meeting and still misses the start
<barry> [TOPIC]  * Next meeting
<MootBot> New Topic:   * Next meeting
<barry> week += 1?
<barry> anybody know you'll be sprinting or offline?
<bigjools> I hope to be around but it depends on how my son's surgery goes on Monday
<barry> bigjools: hope everything goes well!
<bigjools> barry: thanks, me too :)
<barry> [TOPIC]  * Action items
<MootBot> New Topic:   * Action items
<barry>  * barry to get with flacoste to open pqm bugs
<barry> flacoste: we'll chat after the meeting
<flacoste> hmm
<flacoste> can't rememberr what this wa about
<barry> flacoste: new item from asiapac meeting
<barry> [TOPIC]  * Queue status
<MootBot> New Topic:   * Queue status
<barry> only observations i have is that pqm is HUGE
<barry> and there are a few new pink branches on pending-reviews
<barry> bigjools: i know i have a mentor review for you today
<bigjools> pqm has 17 branches and it's only week 2 ... oy
<barry> any comments on the queue?
<barry> yeah, it's crazy!
<sinzui> I think we have a lo of pink because we have been alocating at the end of the on-call review
<bigjools> yeah I got one today that was already 2/3 days old
 * barry apologizes for forgetting to do that this week
<intellectronica> i just picked up a branch that was put up for review a week ago, and got rejected
<sinzui> bigjools: That is because I suck. I miss-assigned it
<intellectronica> let's try to get those branches into someone's hands quickly
<bigjools> sinzui: you purposely giving me soyuz ones? :)
<intellectronica> it may be an idea, to ask that if someone rejects a branch because of workload (rather than a problem with the branch), they try to find someone else so take on it
<sinzui> bigjools: I did pause for a moment before pass it to you
<bac> intellectronica: good idea
<bigjools> np, at this busy time it makes sense
<barry> intellectronica: +1
 * sinzui must bring up the subject of how assigned branches relate to on-call times
<barry> sinzui: ?
<salgado-brb> me
<salgado> sorry
<sinzui> barry: Do we subtract the time done on an assigned review from the time we would spend doing on-call reviews?
<barry> sinzui: everyone except you
<barry> sinzui: :)
<sinzui> barry: That is is not entirely true. I take only easy one on saturday
<barry> sinzui: dunno.  if we're getting more branches than we can reasonably review, well, we've got other problems
<barry> sinzui: i generally work them (and mentor reviews) around other work
<intellectronica> i usually just go with the flow, and try to only pick up branches out of review days if i've come to a natural pause, or it makes sense in the grand scheme of things
<intellectronica> sinzui: if it becomes too much of a burden, you should probably start rejecting branches
<sinzui> I see one or more branches are not really need-review too.
<sinzui> intellectronica: EdwinGrubbs ask me the question after I assigned him a branch
<sinzui> We don't have an official answer
<sinzui> half of the pink branchs are really needs-reply
<barry> i think the answer is, reject branches if you overloaded.  if lots of branches are piling up rejected or not meeting the sla, then this part of the process is saturated and we need to find other solutions
<barry> sinzui: is that just reviewers not keeping PR up-to-date?
<sinzui> barry. correct
<bigjools> pending branches has an update lag though
 * sinzui was reading the launchpad-reviewer archive
<sinzui> bigjools: but the lag is not measured in days
<bigjools> ah, that would be bad then
<bigjools> it would be interesting to see how many of those unchanges ones are from on-call reviews where the reviewer didn't know there was an entry in PR
<bigjools> unchanged*
<barry> bigjools: i always ask for a PR block for any branch i review
<bigjools> right, but I don't think all the reviewers do that
<barry> i know
<bigjools> and some devs stick one in anyway
<bigjools> hurry up PR-killer :)
<barry> bigjools: that's the real answer! :)
<barry> anyway, moving on
<barry> [TOPIC]  * Mentoring update
<MootBot> New Topic:   * Mentoring update
<bigjools> perhaps we can get time assigned for that post 2.0
<barry> any comments here either from mentors or mentorees?
 * bigjools still wants a translations branch to review
<barry> bigjools: maybe add a note on your PR queue?
<bigjools> good idea
<barry> [TOPIC]  * Review process
<MootBot> New Topic:   * Review process
<barry>   * Module alternatives - do we really want them?
<barry> dunno what this one is about
<barry> who added this one?  please take the floor
<gmb> intellectronica, I think...
<intellectronica> right
<intellectronica> so, sometimes, we have imports of the form `try: from import cFoo as Foo \n except: import Foo`
<intellectronica> do we really want to do that?
<intellectronica> consider that we have pretty tight control over the environment in which we run
<sinzui> I have done that twice, both times I had an XXX about when the hack could be removed
<intellectronica> and that falling back silently to an inefficient implementation, is not necessarily a good thing
<sinzui> intellectronica: The Gutsy to Hardy transition is a good example when we need while all the machines are upgrading
<intellectronica> i mean, what what happens if one day the native-code module disappears from one of the production servers? we'll only notice this when the performance starts degrading
<barry> i don't think we need to do that for things like cStringIO, etc.  just use the most appropriate one
<intellectronica> don't we run everything on hardy now anyway?
<bigjools> not quite
<barry> after today tho, right?
<intellectronica> and specifically, what about elementtree? is the native code version a new thing we're not guaranteed to have on older systems?
<bigjools> no, next week will see everything upgraded IIRC
<sinzui> intellectronica: We removed one hack shortly after PQM was upgraded
<barry> that's a bit different because when we /do/ switch to py2.5, we'll have it available there instead of as a separate pkg
<flacoste> barry: but the import path is different
<flacoste> from xml.etrees
<flacoste> or etree
<barry> flacoste: right.  isn't that what intellectronica means?
<allenap> Is it worth having a canonical/alternatives.py module which does all of this, and we import from there. Then we all use the right modules (and we don't get false lint)
<intellectronica> allenap: i like this idea a lot
<flacoste> it does introduce a layer of indirection
<flacoste> but i guess from canoniocal.alternives import ElementTree
<flacoste> wouldn't be too confusing
<intellectronica> flacoste: sure, but it should be used sparingly. in most cases we should import the most specific version
<barry> yes, very sparingly
<barry> is elementtree the only example?
<barry> well, that one fizzled out :)  any other topics for today?
<BjornT> looks like it
<intellectronica> that's the only example i have
<barry> BjornT: if so, i wouldn't add all the extra machinery just for it
<BjornT> i agree. is there a bug open on lint for this?
<intellectronica> yeah, i guess not. but i'd recommend adding an XXX if we must do this trick
<intellectronica> BjornT: what do you mean? would like lint warning for such cases suppressed?
<BjornT> intellectronica: well, why is lint complaining about this?
<BjornT> intellectronica: i don't want lint to complain at all
<intellectronica> BjornT: the thing is, to make sure that it's correct, the try clause should have only one statement
<intellectronica> i suppose if we handle that correctly, we can have lint not complain
<BjornT> intellectronica: right. and it has only one statement, hasn't it?
<intellectronica> yes. if we handle this specific case it should be ok
<intellectronica> i'll file a bug on lint (if there isn't one already)
<intellectronica> ACTION: ^^^
<barry> [ACTION] intellectronica to file bug on lint issue regarding elementtree import
<MootBot> ACTION received:  intellectronica to file bug on lint issue regarding elementtree import
<barry> cool.  that's all i have today.
<sinzui> That special case will require either an ugly sed hack, or a replacement lint script written in python
<intellectronica> python, puh...
<intellectronica> thanks barry
<barry> i take that as a sign.
<barry> #endmeeting
<MootBot> Meeting finished at 09:43.
<barry> thanks everyone
#launchpad-meeting 2008-06-12
<kiko> a hoy
<Rinchen> #startmeeting
<MootBot> Meeting started at 13:02. The chair is Rinchen.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Rinchen> wootbot
<Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<Rinchen> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<Rinchen> me
<mrevell> me
<bigjools> me
<jtv> me
<abentley> me
<leonardr> me
<bac> me
<intellectronica> me
<EdwinGrubbs> me
<sinzui> me
<barry> me
<al-maisan> me
<schwuk> me
<gmb> me
<thumper> me
<adeuring> me
<kiko> me
<mpt> me
<salgado> me
<kiko> cprov sends apologies but had to dash!
<flacoste> me
<Rinchen> matsubara?
<BjornT> me
<matsubara> me
<kiko> thanks jtv for being with us
<thumper> rockstar?
<rockstar> ,e
<Rinchen> releases team is here
<rockstar> er, me
<bigjools> cprov sends his apologies, I am covering for him
<stub> me
<kiko> stub!
<Rinchen> herb, mthaddon ?
<kiko> good to have you here
<herb> me
<mthaddon> here
<Rinchen> statik, ?
<Rinchen> hmm
<Rinchen> well, we're missing a few people
<Rinchen> but i'll move fwd
<mrevell> Rinchen: I believe statik is travelling today
<Rinchen> thanks
<Rinchen> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (Matsubara)
<Rinchen>  * Critical Bugs (Rinchen)
<Rinchen>  * Bug tags
<Rinchen>  * Operations report (mthaddon/herb)
<Rinchen>  * DBA report (stub)
<Rinchen>  * Sysadmin requests (Rinchen)
<Rinchen>  * New packages required (salgado)
<Rinchen>  * A top user-affecting issue (mrevell)
<Rinchen>  * Doc Team report (mrevell)
<Rinchen> plsu
<Rinchen> er
<Rinchen> plus
<Rinchen>     *
<Rinchen>       Policies for launchpad dependency packages (kiko)
<Rinchen>     *
<Rinchen>       Storm and Hardy Updates (kiko)
<Rinchen>     *
<Rinchen>       iframe on every LP page (kiko)
<Rinchen> hmpf
<Rinchen> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<Rinchen> I won't be here next week
<BjornT> i won't be here next week
<Rinchen> kiko, can you run the the meeting?
<kiko> yes
<kiko> I can
<kiko> I am good at such things
<Rinchen> very well
<kiko> (making messes out of meetings)
<Rinchen> ok, same time same place?
<abentley> kiko: he said "run", not "ruin" :-)
<Rinchen> [AGREED] meeting next week, same place, same time, Kiko to rui...er...run the meeting. :-)
<MootBot> AGREED received:  meeting next week, same place, same time, Kiko to rui...er...run the meeting. :-)
 * kiko scratches eyes
<Rinchen> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<kiko> so he did, maybe that wasn't such a great id..
<Rinchen> we had none
<Rinchen> [TOPIC] Oops report (Matsubara)
<MootBot> New Topic:  Oops report (Matsubara)
<matsubara> today's oops report is about bug 239519
<ubottu> Launchpad bug 239519 in launchpad-bazaar "BranchCreationException setting source details for a code import" [Undecided,New] https://launchpad.net/bugs/239519
<matsubara> thumper: can you take that one?
<thumper> I'll allocate it, yes
<matsubara> there's another OOPS which I'm checking but haven't filed a bug yet. https://devpad.canonical.com/~matsubara/oops.cgi/2008-06-11/EC36
<matsubara> salgado: I think that oops is for you :-)
<matsubara> it's an AssertionError in peoplemerge
<Rinchen> [AGREED] Thumper to allocate someone to look at bug 239519
<MootBot> AGREED received:  Thumper to allocate someone to look at bug 239519
<salgado> matsubara, I'll have a look
<matsubara> thanks, we can coordinate about it after the meeting.
<matsubara> Rinchen: that's it from me. thanks
<Rinchen> [AGREED] salgado to look at a particular oops :-)
<MootBot> AGREED received:  salgado to look at a particular oops :-)
<kiko> matsubara, I think it only occurs when I fuck it up, but it should be very easy to fix
<Rinchen> thanks matsubara
<matsubara> thanks everyone
<kiko> oh, no
<kiko> it's not
<Rinchen> [TOPIC] Critical Bugs (Rinchen)
<MootBot> New Topic:  Critical Bugs (Rinchen)
<Rinchen> [LINK] https://bugs.edge.launchpad.net/soyuz/+bug/234254
<Rinchen> cprov, what's the status with this one? This appears to me to either be fixed committed or high, but no longer critical.
<MootBot> LINK received:  https://bugs.edge.launchpad.net/soyuz/+bug/234254
<ubottu> Rinchen: Error: This bug is private
<ubottu> MootBot: Error: This bug is private
<bigjools> Rinchen: it's a config change
<bigjools> I think cprov did a branch for it, I don't know if it's in PQM or landed yet
<Rinchen> there is one branch from a while ago documented but history shows that you've raised it in priority since then
<Rinchen> I haven't seen any recent activity, hence my questioning.
<bigjools> it's config for the restricted librarian
<kiko> bigjools, can you check and update the bug accordingly, please?
<bigjools> yup
<kiko> bigjools, no bugs should be left critical
<kiko> NONE
 * kiko blows the cavalier trumpet
<bigjools> AFAIK cprov is actively working on it
<bigjools> so don't panic!
<Rinchen> [ACTION] Julian to review and update bug 234254
<ubottu> Rinchen: Bug 234254 on http://launchpad.net/bugs/234254 is private
<MootBot> ACTION received:  Julian to review and update bug 234254
<Rinchen> thanks jules
<kiko> bigjools, it's not cprov's responsibility. it's the team's. it's a critical bug.
<ubottu> MootBot: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/234254/+text)
<Rinchen> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<Rinchen> we have one
<kiko> i.e. if you don't know about it, something's wrong
<Rinchen> https://help.launchpad.net/TaggingLaunchpadBugs
<kiko> a bug tag, my favorite
<bigjools> I do know about it
<Rinchen> package-diff  - cprov
<Rinchen> bigjools, do you have anything to say on the bug tag on behalf of cprov-out?
<adeuring> f
<Rinchen> I'm ok with it if it helps your team out.
<bigjools> Well he mentioned it to me before dashing off earlier, I know as much as you just pasted - I guess it's for bugs relating to the new package diff calculations, since there seem to be a few
<bigjools> (BTW the fix for 234254 is #2 in PQM's queue)
<Rinchen> we can approve it, reject it, or postpone it.   kiko, you have any thoughts?
<Rinchen> al-maisan, any thoughts from you?
<kiko> let me check.
<bigjools> I would be happy with it
<kiko> sure, I think that's fine
<al-maisa1> Rinchen: sorry my connection dropped
<al-maisa1> missed the question
<Rinchen> al-maisa1, package-diff bug tag proposed by cprov
<al-maisa1> fine with me
<kiko> yeah, it makes sense to me
<Rinchen> ok, so carried.
<Rinchen> [AGREED] Package-diff tag approved.
<MootBot> AGREED received:  Package-diff tag approved.
<Rinchen> bigjools, can you get cprov-out to update that page again please and move the tag to approved?
<bigjools> wilco
<Rinchen> thank you sir
<Rinchen> [TOPIC] Operations report (mthaddon/herb)
<MootBot> New Topic:  Operations report (mthaddon/herb)
<herb> Monday (2008-06-09) lpnet1 & lpnet2 had died around midnight.  Was caught by the SAs and they restarted.
<herb> Monday (2008-06-09) lpnet4 died with logrotate. It was manually restarted.
<herb> There are currently 2 CP requests awaiting approval. (r6410 & r6451)
<herb> We're about mid-way through the hardy upgrades. The app servers are going today
<herb> as we speak.
<herb> Thanks to an update today edge is now using storm.
<herb> The new codeimport system seems to be working well, but it hits the DB pretty ha
<herb> rd. It doesn't seem there is any connection pooling of any kind which can result in 50+ open db connections.
<herb> I failed to update Bug 224623 last week with the debug logs as promised.  Look f
<ubottu> herb: Bug 224623 on http://launchpad.net/bugs/224623 is private
<herb> or them before the end of my day today.
<Rinchen> thumper, any activities on the radar to address the db connections?
<kiko> okay.
<kiko> thumper, yeah, was going to ask that
<thumper> hmm
<herb> we haven't opened a bug on it yet.  just started noticing it recently.
<herb> we can get a bug opened on it today if you'd like.
<flacoste> herb: any idea why the app server died?
<thumper> I'll talk with mwhudson_ about it this morning
<stub> Is this one connection per process or thread, or just the usual open-and-close connections really fast? If the latter, Storm could fix that.
<herb> flacoste: sadly no.
<Rinchen> herb, if you could please, open a bug and let thumper and mwh know the number. Please include any data/output you have in the report.
<herb> Rinchen: will do.
<matsubara> ls
<kiko> stub, hmm, I think it's the latter, tbh
<kiko> thumper, do you know?
<thumper> there are up to 10 processes running at once on each import machine
<thumper> we only have two slaves
<thumper> so I'd expect to see around 20 not 50
<kiko> right
<kiko> okay -- we'll figure it out with mwh the import code master
<Rinchen> perhaps it is just an optimization issue....unused connections being closed later than expected.
<herb> thumper: keep on eye out for the bug a bit later today.
<Rinchen> any other questions for herb and mthaddon ?
<stub> Previously, the zopeless commit would close and reopen a new connection. This behavior has (hopefully) been sorted as a side effect of the storm branch landing.
<Rinchen> should be interesting to see what effect that has
<Rinchen> thanks herb
<herb> thanks
<Rinchen> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<stub> This close and reopening is often done so fast you have 2 or 3 times as many clients on the db as necessary as they are being opened faster than PG can clean them up.
<stub> Production DB will be upgraded to PostgreSQL 8.3 on Tuesday during the Hardy upgrade window.
<stub> The rest of the DB reviews for this cycle will be done tomorrow and the db freeze lifted if edge is in good shape with todays branch. I might delay opening until Monday or Tuesday if there are urgent fixes that need landing on edge and kiko agrees. With luck, the freeze will be lifted by landing the auth-person-split branch.
<stub> PQM has been running PG 8.3 for two days apparantly. I haven't confirmed this with my own eyes yet though as I just noticed the RT request followup :-) Thanks to Lamont and Tom.
<stub> The databases on carbon (staging, demo) should be switched to 8.3 ASAP - I'll look at this if the losas don't beat me to it. The upgrade will also switch the DB to the correct locale (currently running default, should be C locale to match production).
<stub> Nothing else to report.
<kiko> stub, I had expected staging and demo to be running 8.3 already tbh
<Rinchen> yay for auth-person-split
<kiko> stub, will you do this before the weekend?
<mars> me! phooey.
<stub> Yes. staging and demo where to be done after PQM. The downtime window approached more rapidly than expected.
<kiko> stub, I am kinda hoping everything will fall into place tomorrow -- the only thing I can imagine will help us on edge is fixing mars' favorite iframe and possibly a storm optimo, but it's OOPSes that might tell me otherwise
<kiko> stub, yeah, we got things in gear now :)
<stub> Yup
<flacoste> mars' favorite iframe?
<Rinchen> agenda item
<Rinchen> anything else for Stu?
<stub> beer!
<Rinchen> and thai food, yes I read the lodging request :-)
<Rinchen> thanks stub
<Rinchen> [TOPIC] Sysadmin requests (Rinchen)
<MootBot> New Topic:  Sysadmin requests (Rinchen)
<kiko> fun
<Rinchen> Is anyone blocked on an RT or have any that are becoming urgent?
<stub> RT #30960 needs action Monday at the latest so I can confirm the PG upgrade will go smoothly.
 * flacoste pokes barry
<kiko> none from me, IS have nuked all of mine so quickly
<bigjools> cprov asked me to mention 30778
<barry> flacoste, Rinchen we are no longer blocked
<flacoste> cool!
<bigjools> which is the Gina machine
<barry> well, my branch won't land for another 11 hours, but the rt was marked resolved :)
<Rinchen> ok thanks. I'll have a look at them after the meeting, set dates and priorities, and ping the cuddly red fellow
<Rinchen> a little deviation here for a moment
<Rinchen> [TOPIC] Policies for launchpad dependency packages (kiko)
<MootBot> New Topic:  Policies for launchpad dependency packages (kiko)
<kiko> aha!
<kiko> so today we had a bit of a revelation when we figured out that our dependencies packages aren't being directly used on the appservers
<kiko> they are being used as references, but not literally
<kiko> I had a call with james today to attempt to sort that out
<kiko> turns out that there are some bad things we're doing, so I want salgado to document and follow a policy for package updates
<salgado> on the app servers they are used, no?  just chokecherry that was missing them?
<kiko> salgado, well, it varies. the PQM chroot, for instance, doesn't use l-d-d
<kiko> anyway
<kiko> let me cover the specifics, and then the policy
<kiko> 1. httplib. I understand we're using a version that isn't in intrepid yet. is there a bug open for this being packaged in Ubuntu intrepid and backported to hardy?
<kiko> (that's for barry and flacoste)
<barry> kiko: not that i know of
<kiko> barry, okay. there should be. see policy coming up in a sec.
<kiko> 2. apache and ssh. both packages are required for l-d-d. they are both daemons and can't really be run inside the PQM chroot.
<kiko> so following comes a policy definition
<kiko> for our dependencies packages
<kiko> 1. it's not okay to depend on daemons. you can recommend a daemon, but not depend on it.
<kiko> 2. if you require a version which isn't available in the current ubuntu release we're running, then it's okay to use a custom package /as long as/ there is a request to package that version in Ubuntu, and that bug is escalated to the distro team
<kiko> that's all. I guess this needs to go into a document, but I'll let Rinchen sort that out with salgado!
 * barry will open a bug for httplib2
<salgado> AFAIK, we need apache to run launchpad
<salgado> not to run, but to access it
<kiko> salgado, PQM doesn't have it, so no, we don't really.
<salgado> most package managers don't do anything with recommends, so that may cause developers to have to manually install it
<kiko> salgado, it's okay to have l-d-d recommend apachd
<salgado> kiko, I meant for a user to access.  tests are something else
<kiko> salgado, I actually think apt follows recommends.
<Rinchen> in any event, I could modify the newlaunchpadder docs to ensure folks install recommends
<flacoste> it's usually a config policy
<stub> It doesn't really matter if RocketFuel setup documents an extra command - it isn't like anyone follows that process every day.
<thumper> aptitude does
<salgado> and I don't know what update-manager does with Recommends
<abentley> Wouldn't it be okay to require apache for launchpad-developer-dependencies, but not launchpad-dependencies?
<Rinchen> good point
<salgado> that's what we do currently
<salgado> maybe we should have launchpad-tests-dependencies
<kiko> abentley, no.
<salgado> and launchpad-developer-dependencies
<abentley> shouldn't PQM et al be using plain launchpad-dependencies?
<kiko> salgado, it's unnecessary. recommends works.
<salgado> then PQM would only have lp-tests-deps installed
<Rinchen> launchpad-dependences today recommends launchpad-developer-dependencies
<kiko> and that's fine
<kiko> as I said, recommends works
<kiko> can we move on, Rinchen?
<salgado> abentley, PQM needs the dev deps in order to run the testsuite
<Rinchen> kiko, yes if you are done.  Salgado, can you get with kiko if you have further questions?
<abentley> salgado: Okay.  I can see the argument that we don't want too many metapackages.
<Rinchen> [TOPIC] New packages required (salgado)
<MootBot> New Topic:  New packages required (salgado)
<salgado> any new dependencies for this week?
<Rinchen> [ACTION] Joey to ping Salgado about documenting package dependency policy
<MootBot> ACTION received:  Joey to ping Salgado about documenting package dependency policy
<kiko> sounds like no :)
<Rinchen> [TOPIC] A top user-affecting issue (mrevell)
<MootBot> New Topic:  A top user-affecting issue (mrevell)
<mrevell> Hello. Three things today.
<mrevell> First up: quick reminder that we'll have service interruptions on 17th, 18th and 19th June. You can find out more in our blog post at: http://news.launchpad.net/notifications/launchpad-service-interruptions-17th-18th-and-19th-june
<mrevell> Second: Kiko's going to talk about this later, but here's a quick note to any non-team members present: you may spot an empty box at the bottom of pages on edge. We're aware of this, so please don't worry about filing a bug.
<mrevell> And the main issue this week: matsubara mentioned that intellectronica is currently helping one of our users who is experiencing problems with the email interface.
<mrevell> This person, Iain, is sending GPG-signed messages for both the bug tracker and Answers, but getting no response. So far, one other person has reported the same problem.
<mrevell> You can see the question at: https://answers.edge.launchpad.net/launchpad/+question/35165
<mrevell> I think intellectronica would welcome a discussion of what could be causing this.
<mrevell> Thanks Rinchen.
<Rinchen> Anything for mrevell or intellectronica?
<intellectronica> to add more information to that - the user doesn't seem to be able to get even as far as requesting help via the email interface
<barry> intellectronica: let me know if there's anything i can help with
<Rinchen> [TOPIC] Doc Team report (mrevell)
<MootBot> New Topic:  Doc Team report (mrevell)
<kiko> mrevell, matsubara, intellectronica: I have confirmation from IS that the message hits us
<kiko> who should I forward that information to?
<intellectronica> kiko: me
<mrevell> Cool, thanks guys.
<mrevell> A busy week for me working on user guide material, and primarily further tweaks to the tour, following Mark's feedback. I'd like to arrange a call with each team lead to go through the relevant section of the tour content with you. Please ping me with suitable times.
<mrevell> No news from the doc team this week.
<mrevell> Thanks Rinchen.
<intellectronica> there's a question. maybe this is the time to convert it to a bug
<Rinchen> sounds good to me :-)
<flacoste> intellectronica: i would look into signed_message_from_string failing
<flacoste> intellectronica: look at the log, you should be able to find the email failing
<kiko> intellectronica, will do. thanks!
<Rinchen> [TOPIC] Storm and Hardy Updates (kiko)
<MootBot> New Topic:  Storm and Hardy Updates (kiko)
<kiko> aha
<kiko> I am the bearer of great tidings
<kiko> staging and our edge server are nor updated to latest Storm
<kiko> err
<kiko> now updated
<kiko> we are aware of some performance regressions that this will impact
<kiko> for instance, BjornT has seen the number of queries on certain bug pages going up surprisingly
<kiko> we also know that PQM took a 15 minute hit
<kiko> this is somewhat expected and we'll be working on fixing it as we progress
<kiko> there's also an OOPS on the wild that mthaddon has triggered, which is something we're going to investigate further
<kiko> ZStormError: Store named 'main' already exists
<kiko> is what the OOPS says
<kiko> aaaanyway. help us through the rough waters by offering help and objective issue reports. general whining is not ok.
<kiko> last item of news is hardy upgrades -- you guys know this is happening next week, along with pg8.3 coming on tuesday thanks to stub and the losas
<kiko> so keep your eyes peeled for any issues that come during this period, and let us know
<kiko> thanks and sorry for running overtime -- it's always like that when you let me do the talking...
<Rinchen> and for the final topic...
<Rinchen> iframe on every LP page (kiko)
<Rinchen> [TOPIC] iframe on every LP page (kiko)
<MootBot> New Topic:  iframe on every LP page (kiko)
<kiko> why is this me?
<kiko> anyway.
<kiko> edge has an iframe being rendered on every single page.
<kiko> it's a CSS mistake, I believe -- invisible isn't actually causing invisibility.
<flacoste> should be display: none
<intellectronica> fyi, it also has a javascript error on all pages. it's part of the same bug
<mars> kiko, working on it now
<kiko> it's a critical problem, and as soon as we have a branch (tests for it will be.. interesting) we should push this right up to the front of the PQM queue.
<sinzui> Invisible != none
<kiko> mthaddon, herb: can you work with mars and intellectronica to ensure that happens? will owe you a tall glass 'a beer
<sinzui> I thought the intent *was* to have it load everytime, so invisible was used.
<herb> kiko: not a problem
<kiko> I know the beer's not a problem. I meant the PQM reorder. :)
<mpt> It shouldn't be invisible, it should be non-existent until summoned
<mthaddon> kiko, sure
<Rinchen> like a good familiar
<Rinchen> err
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting.
<Rinchen> #endmeeting
<MootBot> Meeting finished at 13:53.
<thumper> mpt: not existant implies created with JS
<abentley> Thanks Rinchen
<mpt> thumper, exactly
<thumper> Rinchen: thanks
<barry> Rinchen: thanks
<mrevell> thanks rinchen
 * Rinchen attempts to summon the mootbot logs
#launchpad-meeting 2008-06-13
* Rinchen changed the topic of #launchpad-meeting to:  Launchpad Meeting Grounds | Channel logs: http://irclogs.ubuntu.com/ | Meeting Logs: http://www.novarata.net/mootbot/
<Rinchen> mootbot logs are back
#launchpad-meeting 2009-06-10
<henninge> Hi jtv!
<jtv> hi henninge!
<danilos> hi jtv!
<danilos> hi henninge!
<abentley> Hi danilos, jtv, henninge!
 * mars wonders if he has the right meeting - looks like translations
<jtv> hi abentley!
<danilos> hi abentley!
<rockstar> Hey, code's here too!
<jtv> mars: we arrive by team now, like the Olympics
<henninge> Hi rockstar!
<danilos> ok, ok, we can stop this :)
<abentley> Hi rockstar!
<abentley> Hi mars!
<mars> jtv, heh, so who gets to light the MootBot flame?
<danilos> heh
<mars> hi abentley!
 * jtv plots out nÂ² for some ballpark values of n
<bac> hi barry?
<rockstar> It's really early for me.  This is my least favorite meeting of the week.
<sinzui1> barry lost his connection 3 minutes
<sinzui1> ago
<mars> rockstar, could be worse - look at thumper's TL calls :)
<rockstar> mars, yes, those would be even worse.
<mars> barry!
<barry> irc sucks for me today
<barry> sorry
<sinzui> barry: your back for our meeting?
<barry> #startmeeting
<MootBot> Meeting started at 09:09. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everyone.  who's here today?
<EdwinGrubbs> me
<jtv> me
<BjornT> me
<mars> me
<bac> me
<henninge> me
<abentley> me
<adeuring> me
<gary_poster_> me did not send the email *and* is not around for to give reviews today, again.
<jtv> and danilos, too
<gmb> me
<danilos> me
 * mars pokes flacoste
<flacoste> me
<barry> gary_poster_: ack
<salgado> me
<barry> allenap: ping
<barry> cprov: ping
<allenap> me
<cprov> me
<sinzui> me
<barry> gmb: ping
<barry> oops, gmb sorry
<gmb> still me...
<barry> noodles775: ping
<barry> rockstar: ping
<noodles775> me :)
<rockstar> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> very light day today i thik
<barry>     * Roll call
<barry>     * Action items
<barry>     * Mentoring update
<barry>     * Peanut gallery (anything not on the agenda)
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> anything to report ?
<henninge> I hear I graduated?
<adeuring> yes, that's at least my proposal
<henninge> Sorry for missing last week's meeting ...
<barry> henninge: you did. i will send out the announcement today.  congratulations!
<cprov> barry: noodles775 is almost there.
<barry> cprov: fantastic
<henninge> barry, adeuring. Thank you!
<jtv> barry missed the opportunity for a cruel joke there
<barry> jtv: :)
<barry> henninge: you can switch from euro/friday if you want
<henninge> anybody any suggestion?
<barry> henninge: we have good euro coverage, so it's up to you.  if anyone else wants to switch, that's fine too
<barry> i just want at least one person for each euro day
<henninge> I think I had look a Tuesdays
<barry> and remember al-maisan is on loan to ubuntu
<barry> henninge: cool, just ping me when you decide
<henninge> ok
<barry> who is currently /not/ a reviewer (other than team leads)?  i know about deryck and leonardr
<jtv> barry: I'm a reviewer but without OCR slot
<jtv> (was holding this for the peanut gallery)
<barry> jtv: let's get you a slot!
<henninge> barry: noodles775 and me were the only ones when we started.
<barry> jtv: what would work for you?
<henninge> barry: so since onyl deryck has joined lately, I guess that is all.
<jtv> barry: working day when I'm here starts 06:00 UTC.
<barry> henninge: right.  and deryck has started doing js reviews
<jtv> any glaring holes in the schedule for the hours after that?
<barry> jtv: so america probably doesn't work for ya :)
<jtv> barry: nyet, comrade
<barry> jtv: we have two wholes in asia on tuesday and wednesday
<jtv> barry: oh, you're beginning to spell like an Asian
<barry> jtv: but other than that we have pretty good coverage.  you're always welcome to double up on a euro slot
<danilos> jtv, henninge: it would be nice not to have you guys taken up on the same day to OCR
<barry> jtv: sorry, i meant too hoales
<henninge> danilos: I was just thinking that
<jtv> barry: ohh, hoales
<intellectronica> me (apologies for joining late)
<jtv> so we're looking at a swap, not a hole
<jtv> s/at/for/
<gmb> jtv: How about Tuesday?
 * gmb just wants an easier life ...
<barry> gmb: or henninge on tuesday and jtv on friday?
<jtv> gmb: yes, that would work
<gmb> Either way works for me.
<henninge> me on tuesday, jtv on wednesday.
<jtv> barry: disadvantage of friday is: one needs-reply can bump your branch across my weekend.
<henninge> friday gets pretty crowded, too.
<henninge> reviewer-wise
<jtv> which is just great for week 3's
<henninge> yeah
<barry> jtv, henninge why don't you guys work it out.  i'm fine with whatever you decide, just let me know
<barry> i do think friday is well covered either way
<jtv> barry: aye-aye
<barry> thanks!
<henninge> barry: me on tuesday, jtv on wednesday. My favorite.
<barry> henninge: works for me.  jtv?
<jtv> henninge: shall we do this out-of-channel?
<jtv> oh
<jtv> yeah, sure
<barry> [AGREED] henninge to move to euro/tue, jtv to euro/wed
<MootBot> AGREED received:  henninge to move to euro/tue, jtv to euro/wed
 * jtv conspicuously fails to race to the needs-review queue Right Now
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<barry> anybody have any topics not on the agenda?
<flacoste> mars:
<flacoste> ?
<noodles775> Maybe the import error lint (F040...)
<barry> noodles775: can you elaborate?
<mars> barry, I have one
<noodles775> There seems to be disagreement whether the lint warning about import errors should be disabled or left...
<barry> mars: you're next
<noodles775> Currently many files complain about this (i think after the code-reorgs...)
<flacoste> noodles775: i think it's more buildout related actually
<flacoste> i don't kjnow
<abentley> noodles775 is describing lint failure messages when anything imports from canonical.launchpad
<flacoste> but i also noticed that pylint is reporting crack error
<barry> flacoste: maybe pylint doesn't have the correct sys.path?
<flacoste> barry: it probably doesn't
<gary_poster_> I'll look...
<barry> flacoste: let's fix pylint if possible
<barry> gary_poster_: thanks!
<sinzui> We have other pylint issues
<barry> [ACTION] gary_poster_ to look at bogus pylint import failures
<MootBot> ACTION received:  gary_poster_ to look at bogus pylint import failures
<danilos> we've seen them before buildout as well
<sinzui> pylnt is different on jaunty and hardy
<sinzui> They support different error messages
<flacoste> yeah the utilities lint script should probably be moved to be generated by buildout
<flacoste> so that it has the correct sys.path
<bac> gary_poster_: if you fix the problem please look to remove directives in code which disable that warning
<barry> flacoste: +1
<flacoste> gary_poster is on leave for the next week
<flacoste> so that will wait for 2 weeks at least
<gary_poster_> bac, barry, flacoste, ok.  I'm out for a week and a day starting tomorrow, so I was intending to just diagnose
<barry> gary_poster_: diagnose is fine.  please submit a bug report
<gary_poster_> barry: ack, cool
<barry> gary_poster_: thanks
<barry> sinzui: as for the other pylint problems.  new bug report, or tack onto the one gary_poster 's going to file?
<gary_poster> the interface stuff sinzui was mentioning in the review channel seemed unrelated, IIUC
<sinzui> If we control the version of pylint, the we do not need to second guess what warning and suppressions are supported
<noodles775> gary_poster: just fyi, an example here: https://code.edge.launchpad.net/~michael.nelson/launchpad/bug-376320-add-ppa-name-to-builder-status/+merge/7236
<gary_poster> noodles775: gotcha.  looks very suspiciously buildout related, yes
<sinzui> gary_poster: the interface/adapter stuff is not new, but in jaunty the frequency of false positives has increased
<barry> cool, thanks guys.  let's move on to mars's issue
<gary_poster> gotcha.  sounds like a legitimate problem, worthy of a bug report, maybe
<sinzui> gary_poster: I don't think we can teach pylint about differed_import
<mars> thanks barry
<mars> ok, something for the JavaScript writers in the room
<gary_poster> deferred, maybe not
<mars> about two weeks ago QA started an experiment to bring manual testing into the JavaScript review pipeline
<mars> https://wiki.canonical.com/Launchpad/Experiments/JavascriptTesting
 * sinzui has pondered replacing his navel-lint script with apure python script that only enforces his rules.
<mars> the idea is to have QA look at the work in different browsers during the code review step
<mars> since it should be easier to catch and fix UI and browser issues while the branch is in development, rather than after-the-fact, on staging
<mars> By the way, this is unrelated to the [js] landing tag
<barry> mars: since after this cycle, it's all ui from here on out, should we enforce this experiment for the next cycle at least, if not all of the rest of 3.0?
<mars> barry, I was going to ask for volunteers, rather than a team-wide experiment
<mars> but it could work both ways
<mars> the process is pretty simple
<barry> what do others think?
<intellectronica> i think it would be better to have everyone participate
<rockstar> barry, I think it should be enforced now.
<intellectronica> we don't really have time for partial experimentation. if we find that there are problems, we'll fix them
<barry> i don't want to start this cycle, but i'd be willing to enforce it for 2.2.7
<gmb> One thing to bear in mind here
<gmb> Is sabdfl's edict at UDS:
<gmb> UI reviews shouldn't be blockers to landing things.
<gmb> Does this come under that?
<intellectronica> that's a different thing
<intellectronica> and no, it doesn't come under that
<flacoste> "UI reviews shouldn't be blockers to landing things."
<barry> gmb: right, separate.  and remember we have [ui=rs] (with the understanding that you'll back fill that review later)
<flacoste> !?!
<flacoste> that's the first i heard of it
<flacoste> and not what we are applying now
<mars> gmb, that's a design review, rather than "I just denied IE users access to the site"
<rockstar> gmb, yes, this is the first I've heard of it too.
<intellectronica> imperfect UI can be fixed (and anyway it's often a matter of taste). broken code is really bad and the shortest time to fixing is too long
<flacoste> beuno's review are blocking
<gmb> flacoste, rockstar: He said it in a Launchpad gripe session for, IIRC, the community team (could be wrong about which track it was in; it was all a blur).
<intellectronica> yeah, i also never heard about ui reviews not blocking, b.t.w
<jtv> flacoste: that's exactly the part that he said we shouldn't be blocking on.
<gmb> What jtv said
<flacoste> that's new
<sinzui> The principle problem with UI reviews blocking is that developers are not submitting designs to beuno *before* they write code
<flacoste> and should be discussed
<flacoste> i don't agree
<rockstar> gmb, I think we need clarification on what he meant, because as it is now, beuno's reviews block.
<flacoste> we are very bad at fixing thigns later
<intellectronica> are UI reviews a bottleneck at the moment? i didn't have that impression
<gmb> So why does ui=rs exist then?
<flacoste> for trivial stuff
<gmb> intellectronica: A bit. It depends how much of a fight beuno and kiko get into.
<flacoste> it's not uised anyway
<sinzui> gmb: I can get rs if I designed the UI with beuno *first*
<barry> flacoste: no.  ui=rs exists explicitly not to block on beuno's review
<intellectronica> gmb: for trivial landings or when you absolutely can't get a ui review and are very confident
 * barry remembers discussion that very fact with the man himself :)
<rockstar> flacoste, the fact that we are bad at fixing things later is another issue.
<intellectronica> gmb: surely if there's a disagreement it's even more important to resolve it before landing
<sinzui> I am doing UI review *before* code, and I don't start until Martin and seen my proposal
<rockstar> sinzui, I am doing the same.
<gmb> intellectronica: Right, but I've had branches wait up to three weeks because of UI disagreements + week 4.
<gmb> I'm not saying that we should just land things without talking to Martin.
<jtv> I believe full UI reviews were ultimately to be for "real" design decisions, not for "does it look okay like this."
<rockstar> sinzui, because often, more code changes happen on UI review than code review.
<gmb> That's just crackpottery.
<sinzui> rockstar: :)
<intellectronica> gmb: sounds like you have to work a bit on your social engineering skills ;)
<mars> jtv, good point
<jtv> just repeating...
<barry> rockstar: yes!  it's the 80/20 rule
<flacoste> gmb: we should do a root-cause-analysis on your experience
<rockstar> sinzui, also, I dread UI reviews, where I don't dread code reviews, so I do the band-aid thing.
<barry> or its inverse. or something.
<flacoste> anwyay, that's kind of besides the current discussion i think
<flacoste> if we want to discuss UI reviews, we should bring that separately as another topic
<gmb> flacoste: Well, I've got another big UI branch coming up in the next couple of days, so let's analyse that one rather than rehash my previous experience.
<barry> flacoste: good point.
<barry> let's take up ui review issues on the ml please
<barry> as for js, let's vote on requiring the experiment for all devs in 2.2.7
<rockstar> So, with the current QA plan, at least they can defer it.  I think we should request a review from them (so they get an email) but not block on it.
<mars> barry, so!  full-team experiment for manual UI testing next cycle?
<barry> [VOTE] require full-team experiment for manual ui testing in 2.2.7
<MootBot> Please vote on:  require full-team experiment for manual ui testing in 2.2.7.
<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
<barry> +1
<MootBot> +1 received from barry. 1 for, 0 against. 0 have abstained. Count is now 1
<mars> rockstar, we'll see if they get swamped - it's their call
<mars> +1
<MootBot> +1 received from mars. 2 for, 0 against. 0 have abstained. Count is now 2
<gmb> +0
<adeuring> +0
<MootBot> Abstention received from gmb. 2 for, 0 against. 1 have abstained. Count is now 2
<MootBot> Abstention received from adeuring. 2 for, 0 against. 2 have abstained. Count is now 2
<rockstar> +0
<MootBot> Abstention received from rockstar. 2 for, 0 against. 3 have abstained. Count is now 2
<bac> +0
<MootBot> Abstention received from bac. 2 for, 0 against. 4 have abstained. Count is now 2
<jtv> +0
<MootBot> Abstention received from jtv. 2 for, 0 against. 5 have abstained. Count is now 2
<gary_poster> +0
<MootBot> Abstention received from gary_poster. 2 for, 0 against. 6 have abstained. Count is now 2
<noodles775> +0
<MootBot> Abstention received from noodles775. 2 for, 0 against. 7 have abstained. Count is now 2
<henninge> +1
<MootBot> +1 received from henninge. 3 for, 0 against. 7 have abstained. Count is now 3
<jtv> maybe we haven't talked this through enough; I for one don't have a clear picture of how it would fit into the process.
<intellectronica> +1
<MootBot> +1 received from intellectronica. 4 for, 0 against. 7 have abstained. Count is now 4
<flacoste> +0
<MootBot> Abstention received from flacoste. 4 for, 0 against. 8 have abstained. Count is now 4
<flacoste> actually, that should be a +1
<sinzui> What really is manual UI testing? What how do I know it is successful
<flacoste> +1
 * sinzui cannot vote, and wants to
<mars> sinzui, I was about to get to that, then a car hit my topic :)
<barry> sinzui: it's outlined on the wiki page
 * gmb apologises for DUI.
<intellectronica> sinzui: ideally, we should prepare test plans with clear predicates, but sometimes it will be just monkeying about with the interface
<mars> the process is simple: you write up a manual test plan in the cover letter
<abentley> -0
<abentley> +0
<MootBot> Abstention received from abentley. 4 for, 0 against. 9 have abstained. Count is now 4
<mars> QA follows it for the A and C browsers
<jtv> mars: who is responsible for making sure the branch goes all the way through the process?  Still the reviewee as usual?
<mars> jtv, yes
<flacoste> actually, i'm -1 on a full team experiment at this point
<flacoste> not that it matters :-)
<sinzui> I don't think this test can be performed by the team if they do not posses all the A-grade browsers
<intellectronica> flacoste: why? and it does matter
<mars> jtv, QA handles wrangling the people with the browsers for testing
<flacoste> well, i don't have a veto :-)
<mars> sinzui, we do
<jtv> flacoste: I think that brings you to a total of 3 votes  :-)
<barry> sinzui: devs don't but qa does
<flacoste> i think the experiment is too vague at this point to make the whole team follow it
<intellectronica> sinzui: iiuc diogo and ursula have access to all platforms, and it's up to them to delegate the work if and when they feel they can't handle the load
<mars> sinzui, we do have the browsers.  QA has access to them, and to the pool of people who have registered as having the alternative environemnets
<flacoste> and given that 2.2.7 is all-UI
<flacoste> it could degenerate
 * noodles775 is unsure *how* i can go about fixing my branch if it fails for IE6 on XP? XP licenses as per the email?
<intellectronica> flacoste: it's clear in my mind. could it be that it's not adequately expressed?
<flacoste> noodles775: you disable the feature for IE :-)
<flacoste> intellectronica: probably
<mars> noodles775, disable the feature, yes
<flacoste> and we haven't experimented it at all yet
<flacoste> (i think)
<sinzui> our China OEMs are using IE6 on XP. They are not permitted to change browser or OS
<intellectronica> flacoste: that's why experimenting during the remainder of 2.2.6 can help doing the real thing for 2.2.7
<sinzui> They do not like Launchpad
<noodles775> flacoste, mars: ok, FF3 on OSX?
<jtv> sinzui: my shoes are broken, I don't like pavements :)
<mars> sinzui, that's what we are addressing with this
<barry> intellectronica, mars so perhaps volunteers for 2.2.6 to flesh out the process so everyone understands it?
<flacoste> intellectronica: so let's do a two-weeks experiment using volunteers
<mars> noodles775, not a concern, just the browser, not the environment
<barry> btw, if the experiment is a failure we don't need to keep running it for the whole cycle!
<noodles775> ok
<sinzui> jtv: I bought new All-stars and Doc Martins in London because I had holes in my shoes
<mars> noodles775, Opera on Linux is fine, no need for Opera on Win/OSX
<jtv> flacoste: sounds good to meâreviewers could encourage reviewees to participate
<jtv> flacoste: ...and if people don't want to, note a probable point for improvement
<flacoste> that's the idea, volunteering reviewers
<flacoste> are to make sure that the process is followed
<sinzui> When using safari (Webkit) can we substitute Konqueror or Epiphany-webkit?
<barry> we've gone over, and i apologize for that.  i will really try to fix my irc by next week
<flacoste> if all the AJAX-team reviewers volunteer
<mars> flacoste, I'll rely on barry's experiement experience here, but I do agree with your points, there is risk because it hasn't been tried yet
<intellectronica> i rather do it for the remainder of 2.2.6 rather than two weeks, for simplicity, but either way is fine. i agree that a limited experiment is a good idea
<flacoste> we kind of have a de-facto whole team experiment
 * Ursinha reads
<mars> sinzui, that I'm not sure about
 * sinzui want to add small devices to to list
<intellectronica> i'll most definitely volunteer, as i'm sure everyone from the bugs team will ;)
<mars> sinzui, for Konqueror, no, you absolutely can not
<sinzui> mars: they run the webkit version
<barry> let's defer the whole-team decision until we see how the volunteer experiment works for the rest of 2.2.6
<sinzui> Epiphany is on tip
<mars> sinzui, heh, nice try, but no, the Webkit Konqueror is *not* Safari
<flacoste> volunteers should sign up on the JavaScript experiment page
<mars> I know, I tried it
<sinzui> mars: 4.2 is I thought
<barry> flacoste: +1 thanks
<sinzui> QT
<flacoste> and
<jtv> barry: may haev to start a new vote before the bot gets confused
<flacoste> we should put the link to the experiment in the launchpad-reviews channel
<flacoste> for OCR
<mars> sinzui, the engine, sure.  But it still doesn't work the same as Safari.
<barry> #endvote
<flacoste> so that dev can look if they need to follow-it
 * barry knows a sure fire way to end the vote...
<barry> #endmeeting
<MootBot> Vote is in progress. Finishing now.
<MootBot> Final result is 4 for, 0 against. 9 abstained. Total: 4
<MootBot> Meeting finished at 09:55.
<barry> thanks everybody!
<intellectronica> thanks barry
<jtv> thanks barry!
<EdwinGrubbs> sinzui, mars: I had some good results using Arora to test webkit after I disabled its network caching.
<sinzui> flacoste: can we engineer a JS oops AJAX lib that run in staging/edge clients and send us reports when our users know we broke something
<mars> sinzui, yes, we can try.  It's on my Todo list
<mars> sinzui, well, my Todo wishlist :)
<flacoste> sinzui: we can anything, priorities, priorities, priorities
<sinzui> flacoste: I think that by putting enough eyes on the problem (per the Open Source mantra) there will not be a problem
<sinzui> We use automated testing because we do not have enough eyes
<sinzui> JS + automated testing is painful
<sinzui> so using oopses might be the best way to verify scripts
<abentley> sinzui: JS + manual testing is also painful
<sinzui> abentley: test for the sake of testing is painful. but users of staging and edge do not mind testing for us because we provide them newer services
<thumper> hi barry
<barry> #startmeeting
<MootBot> Meeting started at 17:30. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi thumper
<barry> jml, mwhudson hi
<mwhudson> hello
<jml> hi
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> # Roll call
<barry> # Action items
<barry> # Mentoring update
<barry> # Peanut gallery (anything not on the agenda)
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> just wanted to let you know that henninge has graduated
<thumper> cool
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<thumper> I've got a few things
<barry> thumper: go ahead
<thumper> the launchpad code team have moved all interface enums to lp.code.enums module
<thumper> you may want to consider this too
<thumper> also looking into trying out lp.code.errors for our exceptions
<thumper> moving the enums reduces circular dependency issues
<thumper> as they only rely on lazr.enum
<barry> thumper: very nice
 * jml has one item.
<thumper> it was mentioned in the team lead call this morning
<thumper> and foundations and registry may do the same
<thumper> although I don't think foundations has any...
<barry> thumper: +1
<barry> registry has a lot
<barry> thumper: did you talk at all about making .enums a package?
<thumper> I'm done
<thumper> barry: not exactly
<barry> i'm a little concerned about having really huge modules
<thumper> why make it a package than a module?
<thumper> would the enums/__init__.py pull them in?
<barry> thumper: no, but maybe that would just re-introduce the circs
<barry> in any event, it's not a big deal for now at least
 * barry was just curious
 * thumper nods
<thumper> lets see how it goes
<barry> thumper: +1.  thanks.  did you have another issue?
<thumper> there are advantages to just having one module
<thumper> to get enums
<thumper> from
<thumper> like not having to think :)
<barry> :)
<jml> barry: does beuno attend a reviewers meeting?
 * thumper passes floor to jml
<barry> jml: he does not.  probably should though
<thumper> perhaps I should pass the talking-stick to jml
<jml> barry: even if it's just every second week, it'd probably be useful.
<barry> jml: +1 i'll ask him to (i think he did at one point)
<barry> jml: you're up
 * barry has one when you're done
<jml> barry: that was my topic :)
<barry> jml: cool!
<barry> at the ameu meeting, mars brought this up: https://wiki.canonical.com/Launchpad/Experiments/JavascriptTesting
 * thumper looks
<barry> the idea is to put qa in the critical path for branch approval.  this is manual js testing by qa
<thumper> hmm..
 * mwhudson mutters something about a "fix verified" bug status
<barry> mars and company are asking for volunteers for 2.2.6 and we're considering making it mandatory team-wide (as an experiment) for 2.2.7
<thumper> seems like a branch blocker
<barry> that's not decided yet though
<thumper> "fix confirmed" ?
<barry> thumper: it could be yes
<thumper> how would the qa be done?
<jml> barry: I'll try to have a look at the page later on today
<thumper> if it wasn't landed on trunk?
<mwhudson> ec2!
<barry> thumper: i think qa would run the branch and try it with the A and C browsers
<jml> barry: my first reaction is "I thought we were trying to improve UI velocity"
<barry> jml: btw, this is separate from ui=* and the js tags on pqm commits
<barry> it's also separate from ui reviews
<thumper> is it going to be a requested review from the qa team that has to be approved?
<barry> thumper: i believe that's the idea
<thumper> hmm...
<jml> barry: this seems to confirm my impression that this will slow down branches :)
<barry> ;)
<thumper> I'm with jml on the velocity issue
<barry> anyway, i just wanted to make you aware of the discussion at ameu :)
<thumper> I was also going to raise the UI review not being blocking issue
<jml> barry: thanks.
<barry> that's all i have
<jml> barry: I'd like to read this page & send my thoughts on later.
<barry> jml: please do!
<mwhudson> maybe we could have something like, if it works, the qa person should submit the branch
<mwhudson> 1 less handoff
<barry> that's an interesting idea too
<mwhudson> or say, it's something the code reviewer should do
<barry> anything else guys?
<mwhudson> if we can build tools to make it easy
 * thumper wants branch merge queues in LP
<jml> barry: a low priority thing
<mwhudson> thumper: yes
<mwhudson> thumper: also, a pony
<jml> barry: have you ever looked at the bzr developer docs?
<barry> jml: it's been a while
<jml> barry: http://doc.bazaar-vcs.org/latest/developers/index.html
<jml> barry: maybe this is something we can work towards before, during & after open sourcing
<barry> yes!  i'd also like to take a shot at sphinxing our docstrings
<jml> doctests, itym
<barry> both actually, as we markup more of our docstrings
<mwhudson> there's still nightly pydoctor output
<jml> right. was about to mention :)
<mwhudson> at https://devpad.canonical.com/~mwh/canonicalapi/
<thumper> :(
<thumper> we don't have much documentation for lp.code
<jml> barry: anyway, what I mean is -- *I* get lost trying to find our reviewer, developer, testing docs & guidelines
<jml> barry: it's an oral tradition for me
<mwhudson> (i get emailed a list of which docstrings aren't valid reST every night...)
<jml> (which is why these meetings are so valuable)
<barry> jml: i hear ya
<barry> mwhudson: any chance you can send those to launchpad@?  would make a nice email nag to reduce techdebt
<jml> better yet, any chance you can get 'make lint' to tell us about them.
<barry> or that
<mwhudson> i would really really really like it if it was someone's job to make the developer experience better
<thumper> foundations?
<mwhudson> barry/jml: yes, am wary of spamming launchpad@ more
<jml> me too.
<mwhudson> thumper: a nice idea, it's not what they actually do though
<barry> i'm not.  i already have too much spam, so a little more won't hurt :)
 * jml tries.
<mwhudson> jml: file a bug about having make lint warn about this?
<barry> mwhudson: me too.  *especially* after we open source. i'm hoping to find time to actually work on that
<jml> ok.
<mwhudson> jml: it's not that we don't try, it's that it's noone's main responsibility
<barry> mwhudson: exactly
<jml> mwhudson: agreed.
<jml> I think we're coming to a close here.
<thumper> agreed
<barry> and with that...
<barry> #endmeeting
<MootBot> Meeting finished at 17:54.
<mwhudson> thanks barry
<barry> thanks guys
<thumper> thanks barry
<jml> mwhudson: https://bugs.edge.launchpad.net/launchpad/+bug/385736
<ubottu> Launchpad bug 385736 in launchpad "'make lint' should warn about invalid docstrings" [Low,Triaged]
<mwhudson> jml: thanks
#launchpad-meeting 2009-06-11
<matsubara> #startmeeting
<MootBot> Meeting started at 10:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<sinzui> me
<intellectronica> me
<matsubara> herb__, stub, flacoste, rockstar, bigjools, henninge: hi
<rockstar> me
<flacoste> me
<stub> me
<bigjools> me
<henninge> me
<herb__> me
<matsubara> ok, everyone is here.
<matsubara> apologies from Ursula as she's on holiday
<matsubara> [TOPIC] Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (stub)
<MootBot> New Topic:  Agenda
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> all action itens are Ursinha's so I'll talk to her later
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<matsubara> bug 361026 for foundations
<ubottu> Launchpad 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" [High,Triaged] https://launchpad.net/bugs/361026
<matsubara> looks like this one is happening daily
<sinzui> hmm, salgado wont be available until Monday
<matsubara> stub would take care of it, according to Ursinha
<sinzui> matsubara: yes he can
<matsubara> stub, any news about that one?
<flacoste> hmm
<stub> matsubara: I haven't looked at that yet
<flacoste> actually
<flacoste> i never mentioned it to stub
<flacoste> my bad
<matsubara> oh
<matsubara> well, you did in the bug report
<matsubara> shall I target it to this milestone?
<flacoste> yes please
<matsubara> thanks
<matsubara> 3 critical bugs, 2 fixed and one in progress
<matsubara> so, let's move on
<matsubara> thanks stub, flacoste
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> um
<matsubara> herb, ?
<herb> quiet week
<stub> yay!
<herb> only thing of note
<herb> is the 4 cherry picks awaiting (dis)approval
<matsubara> flacoste, could you take a look at those later on today?
<flacoste> sure
<matsubara> thanks flacoste
<matsubara> herb, anything else?
<herb> that's it
<matsubara> herb, all right. thank you
<matsubara> moving on
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> The new slave has been built, ready for the next rollout. We are not keeping a spare slare database around to use for the stand-alone read only replica during Launchpad upgrades. This makes rollouts easier and means post rollout we have our normal quota of slave databases running.
<stub> Well done to the Translations team. Rather than taking days, the test run of opening Karmic for translations took just minutes. Hopefully QA will report that it worked as expected.
<stub> Nothing else to report. That I can think of :-)
<rockstar> stub, do you think you'll be able to address my bug-branch status db patch with Mark?
<stub> rockstar: It has gone off with the rest of them.
<rockstar> stub, okay.  Many of us in code would like to see that land.
<stub> DB patches have been sent for veto/comments from Mark too.
<matsubara> ok. anything else for stub?
<matsubara> thank you stub
<matsubara> I think that's it for this week's LP production meeting.
<matsubara> thanks everyone
<matsubara> 3
 * bigjools likes quick meetings
<matsubara> 2
<matsubara> 1
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:14.
#launchpad-meeting 2010-06-16
<bigjools> me
<bac> #startmeeting
<MootBot> Meeting started at 09:01. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> Hi and welcome to the reviewers meeting.
<bac> who is here, besides eager bigjools ?
<abentley> me
<sinzui> me
<adeuring> me
<noodles775> me
<adeuring> deryck is off today
<bac> thanks adeuring
<bac> gmb, leonardr, mars: ping
<gmb> Erk
<gmb> me
<mars> me
<bac> gary_poster:  ping
<EdwinGrubbs> me
<leonardr> me
<henninge> me
<gary_poster> me-ish
<henninge> ;)
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac>  * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>    * Lots of unlanded, approved branches [bac]
<bac>  * Peanut gallery
<bac> [topic] outstanding actions
<MootBot> New Topic:  outstanding actions
<bac> * bac to update TestStyleGuide.
<bac> l've begun doing this and will seek input from abentley and sinzui before finalizing
<bac> * Bjornt to set a policy on what can live in lib/lp, lib/services, and lib/coop
<bac> i don't think BjornT is with us ATM, so i'll roll this over.
<bac> * *Everyone* read lib/canonical/launchpad/doc/db-policy.txt
<bac> last week bigjools talked about using the slave store and recommended reading this document.
<bac> i hope everyone has had a chance to review it as there is lots of good information in there.
<bac> if you haven't, please take some time this week to do so.
<bac> </nag>
<bac> * Sinzui to replace pylint
<sinzui> I have not completed that
<bac> sinzui:  were you able to make any progress in liberating your script?
<sinzui> No.
<bac> sinzui:  last week i think you stated it would replace pyflakes, but that was a misstatement, right?  we want to keep pyflakes and replace pylint?
<sinzui> I agreed to replace the entire lint.sh for a faster python script
<sinzui> sorry, but my family insisted that I be with them
<sinzui> I never promised my work hours for this
<bac> sinzui:  that's quite alright.  understood.
<bac> there are no other new topics for discussion.
<bac> does anyone have anything not listed?
<mars> bac, I do
<bac> go ahead mars
<mars> A quick question for the room: has ec2 test been working properly for everyone since last week?
<bac> mars: it has worked for me the few times i've run it.
<mars> alright, I'll take that as a good sign
<bac> mars what is the status of 'ec2 land'?
<mars> If anyone does notice a disappearing branch, please ping me
<mars> bac, that was fixed as well
<bac> mars: ok, great.  i'll start using it again.
<bac> anything else from anyone?
<bac> if not, let's end very early.
<bac> thanks for coming.
<bac> #endmeeting
<MootBot> Meeting finished at 09:14.
<mars> bac, the "unlanded branches topic"?
<bac> oh, yeah
<bac> thanks mars
<bac> i just looked on +activereviews and noticed a large number of approved branches that have not landed.
<bac> please, everyone, take a look and take some action on your branches.  if they are really old either land them or change the status.
<bac> that's all.
<bigjools> let's review that again next week
<bigjools> see if the number changes
<bac> good idea bigjools
<bac> #endmeeting-again
<bigjools> it's *waste* in LEAN terms :(
<mars> yeah
<bac> bigjools:  perhaps the team leads can help.  :)
<mars> and more effort to re-sync later
<bigjools> there's only so much I can beat them :)
<mars> like a debt with a low interest rate
 * bac sees lots of soyuzy branches...
 * noodles775 notes that one of the branches listed there is dependent on a subsequent branch in the pipeline.
<thumper> bac: I'm not going to be around for the reviewer meeting, and rockstar isn't either :)
<thumper> bac: so probably worth skipping this week
<bac> thumper:  it's unanimous!
<bac> see you next week
#launchpad-meeting 2018-06-16
<Serim> TESTING TESTING
<Serim> TESTING TESTING
