#launchpad-meeting 2007-01-08
<SteveA> hi
<SteveA> is there a meeting here now?
<thumper> #bzrlp on Canonical server
#launchpad-meeting 2008-01-08
<thumper> = Meeting Time =
<thumper>  * Roll call
<thumper>  * Next meeting
<thumper>  * Action items
<thumper>  * Queue status
<thumper>  * Mentoring update
<thumper>  * Review process changes
<thumper>    * Tool update
<thumper> * Roll call
<thumper> appologies from jml
<thumper> BjornT_: ping
<thumper> and I'm guessing that jamesh and spiv are here
<spiv> I'm here, although only briefly.
<BjornT_> i'm here
<jamesh> I'm here.
<thumper> spiv: ok I'll be quick
<thumper> since spiv has to go
<thumper> I'll raise the only contentious part first
<thumper> barry has requested that we move the reviewer meeting so he can attend
<thumper> the times he gave me are 0:00UTC or 05:00UTC
<thumper> how does that work for you ozzies?
<thumper> obviously my preference is for 00:00UTC
<thumper> 05:00UTC is midnight for barry
<thumper> so I'm guessing his preference would be for 00:00UTC too
<spiv> So 1 hour ago or 6 hours ago?
<thumper> spiv: right
<spiv> Those are both fine with me.
<thumper> jamesh: you are west-most
<thumper> how is 6 hours earlier for you?
<spiv> (Although I'm probably the least important person, given how little I've been reviewing lately)
<thumper> BjornT_: do you care too much?
<jamesh> 05:00 is fine for me.  00:00 is okay during daylight savings (9am)
<jamesh> I think the plan was for barry to replace BjornT, right?
<BjornT_> thumper: no, choose what's best for you guys. i don't have to attend it.
<thumper> jamesh: I think so
<thumper> jamesh: how about 00:00UTC and re-evaluate when DST ends
<jamesh> okay
<thumper> sold
 * thumper looks at the queue
<thumper> 13 branches pending
<thumper> 2 over (one of those unallocated)
<thumper> 3 unknown/broken branches
<thumper> 9 unallocated
<thumper> ok so 4 of those are mine...
<spiv> 3 is a lot of unknowns.
<thumper> I was hoping to hit barry up tomorrow morning for at least two of them
<thumper> spiv: yeah, don't know what's going on with those
<jamesh> I've got sabdfl's jumbo branch to do, but that's not listed in the queue
<thumper> sabdfl has another jumbo one?
 * thumper shakes his head
<jamesh> the one from just before the break
<thumper> I might put two into barry's queue that I care desperately about
<thumper> the others can be done by anyone
<thumper> I'm prepared to trade reviews
<thumper> :)
 * spiv -> gone
<thumper> barry is on call morning US time
<thumper> spiv: bye
<thumper> jamesh: can you allocate some reviews later?
<thumper> or I could do it
<jamesh> thumper: sure.
<spiv> Have a good rest-of-meeting!
<jamesh> I'm on call at the moment too, in case there is anything that needs quick turn-around
<thumper> Actions from the last meeting:
<thumper>  * barry to edit him some wikis about on-call procedures
<thumper>  * intellectronica to work on a cover letter template
<thumper> nothing for us to do
<thumper> jamesh: ah, ok
<thumper> I'll poke you in a few minutes
<thumper> * no proposed items
<thumper> * any other business?
<thumper> 5
<thumper> 4
<thumper> 3
<thumper> 2
<thumper> 1
<thumper> 0.5
<thumper> = Meeting ends =
<thumper> thanks for coming
#launchpad-meeting 2008-01-09
<statik> me
<bac> me 2
 * sinzui says me
<barry> welcome to the ameu launchpad reviewers meeting, for the next 45 minutes or less
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>   * Leftover branches - confirm that the on-call reviewer should allocate all remaining branches on the general queue at the end of his shift (or discuss a different solution).
<barry>  * Mentoring update
<barry>  * Review process changes
<barry>    * Tool update
 * barry goes a reviewer-rustlin'
<BjornT_> me
<salgado> me
<intellectronica> me
<gmb> me
<statik> me
<sinzui> me
<flacoste> me
<bac> me
<barry> great, welcome to our first meeting of 2008!
<barry>  * Next meeting
<barry> today + 1week?  any objections?  any known absences?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry>  * Action items
<barry> Actions from the last meeting:
<barry>  * barry to edit him some wikis about on-call procedures
<barry>  * intellectronica to work on a cover letter template
 * barry sucks; he will edit him some wikis
 * intellectronica sucks too
<barry> i really will try to do that this week
<barry> * Queue status
<barry>   * Leftover branches - confirm that the on-call reviewer should allocate all remaining branches on the general queue at the end of his shift (or discuss a different solution).
<barry>  * Mentoring update
<intellectronica> i'll try to do this promptly and talk to mwh about inclusion in his tool
<barry> (oops c&p error there)
<barry> intellectronica: excellent, thanks
<barry> so the general queue got pretty big
<sinzui> intellectronica: mwh is out for the next 3.5 weeks
<barry> and intellectronica reminded me this morning that we'd decided to have on-call reviewers do a general queue assignment at the end of his shift
<intellectronica> sinzui: well, i won't talk to him, then
<barry> intellectronica: we can keep this on the agenda until mwh gets back
<barry> i don't think it's urgent
<barry> fwiw, i gave lifeless the opportunity to shed load so he won't be doing PR assignments for now
<barry> and i know we all want to just kill off PR anyway
<barry> but for now, intellectronica can you do a general queue assignment when you're done for the day?
<intellectronica> will do. if ppl /don't/ want branches for review tonight, drop by in #launchpad-reviews and say yo
<salgado> I'd stopped doing the allocations because then on call reviewers could take the unassigned ones when there wasn't any branches for them to review
<intellectronica> salgado: but today, for example, by the time i finish the queue will, in all likelihood, still have quite a few branches in it
<barry> salgado: i wonder if falling behind was mostly an aberration around the holidays/new years?
<salgado> yeah, I was wondering that as well
<sinzui> barry: That and the fact that reviewers are still out
<intellectronica> barry: from what i can tell the queue filled up significantly after your shift yesterday
<intellectronica> barry: so it's something we can expect to happen every now and then
<barry> intellectronica: it was pretty full when i checked toward the latter part of my shift, but by then i was already booked on reviews
<intellectronica> either way - allocations are not going anywhere, even with on call reviews :-/
<barry> we need to clear the backlog, so let's do this: intellectronica do an assignment at the end of today and let's all do our reviews the old way
<barry> that should clear the backlog and let us get back to our super-efficent on-call process :)
<salgado> sounds good to me
<barry> so maybe we should do general assignments on an as-needed basis only, and not as s.o.p. for on-callers?
<flacoste> well
<flacoste> i have some problems with that strategy
<flacoste> problem being that branches on the general queue still should be serviced in the <48H SLA
<flacoste> so they sould be assigned ASAP for that
<flacoste> if the on-call cannot do them
<flacoste> otherwise, there is a risk that they'll be unassigned for a complete shift
<flacoste> because the on-call is prompted for new branches
<flacoste> and then branches on general reviews will linger
<flacoste> so i think the process should be
<flacoste> on-call reviewer does allocation
<flacoste> many times during the day
<flacoste> if he has slack he assigns some to himself
<flacoste> put assign others
<flacoste> no keeping in general queue for the case - where the on-call "might" have time
<flacoste> reviewers should still check PendingReviews daily to see if they have assigned branches
<sinzui> +1
<barry> ok, that's fine by me
<flacoste> i would suggest that after each review, the on-call does an allocation run
<intellectronica> flacoste: you've got a point there
<intellectronica> +1
<flacoste> and it's ok for new branches to pre-empt stuff in the general queue
<flacoste> iow, even if there are unallocated reviews in the general queue, the on-call should still accept an interactive request for a review
<flacoste> the 'general queue' stuff will be assigned to other reviews
<flacoste> reviewers
<flacoste> one gotcha though
<barry> sounds good.  the only risk is that the on-caller will not have anything to do while there are still needs-review branches in other people's queue.  i'm okay with that
<flacoste> allocation of reviews to somebody who is fed up with reviews because he was on-called the previous day
<flacoste> or something like that
<barry> flacoste: that reviewer can always move the branch to the rejected queue
<flacoste> good point!
<flacoste> and we should emphasis that!
<barry> yep
<flacoste> don't be afraid of rejecting reviews because you had a full on-call day!
<flacoste> of course, allocating to the next on-call is probably a good idea
<bac> or on-call reviewers can mark their queue with /!\ if they really don't want to accept other reviews.  20% is a lot for of time for reviewing
<barry> hey, there ya go.  we should just wipe all the review queues and round-robin all needs-reviews to the next on-caller :)
<flacoste> barry: i fear for the SLA with that strategy
<barry> flacoste: i was kidding
<barry> well, this is never going to be perfect until we get rid of PR anyway <wink> so let's go with flacoste's plan and see how it goes
 * barry will edit him some wikis
<barry> anything else on this topic?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry>  * Mentoring update
<gmb> I've had no reviews for salgado or mwhudson to mentor since last cycle.
<barry> gmb: cool.  you're next on-call is coming up right?
<gmb> A combination of sickness and super-efficient on-call revfiews, I think.
<gmb> barry: I think so. salgado, are you o/c tomorrow?
<salgado> gmb, yep
<gmb> salgado: Mind if I join you?
<salgado> gmb, not at all!
<gmb> Cool.
<flacoste> hey, another worthwhile allocation strategy: gives them to mentoree!
<gmb> barry: There's your answer then :)
<barry> gmb: excellent!
<barry> flacoste: you're the perfect straight man.  which leads me to my next question...
<barry> is it time for more recruits?
<barry> right now we have just gmb, ddaa, and jvt
<flacoste> with mwhudson off, i think it's a good idea
<barry> i think jvt will never graduate (by his own choice iiuc)
<flacoste> some people just like staying in school all their life!
<barry> any nominations?
<intellectronica> cprov
<flacoste> barry: i think you had volunteers?
<barry> flacoste: i did
<barry> jsk was one :/
<barry> schwuk was another
<flacoste> maybe
<flacoste> we should
<flacoste> send an request for candidates to launchpad
<barry> there aren't too many others left are there? :)  allenap, edwin, bigjools (actually i think he volunteered too), leondardr
<bigjools> I did indeed
<barry> how many can we reasonably digest now?  we need mentors for each
<cprov> intellectronica: here
<sinzui> allenap attended our reviewer's meeting at all hands. I thought he was interested
<intellectronica> cprov: i was just suggesting that you might want to become a reviewer
<flacoste> i suggest a "call for candidacy"
<cprov> intellectronica: wait, you are nominating me to become a reviewer ...
<flacoste> and collect candidates and try to find mentors next week
<barry> flacoste: i say a volunteer candidate has to rustle himself up a mentor.  :)
<flacoste> that's also a good strategy
<barry> and we'll accept whoever 1) volunteers; 2) has an agreed mentor
<flacoste> ok
<flacoste> and we can talk about people who have 1) but not 2) in next meeting
 * barry feels like we're getting very close to "everyone is a reviewer"
<barry> flacoste: +1
<barry> oh yeah, abel too
<barry> (abel is not a reviewer yet)
<barry> great.  anthing else on this topic?
<barry> 5
<flacoste> carlos and danilos are two others
<barry> flacoste: right!
<barry> 4
<barry> 3
<barry> 2
<cprov> intellectronica: maybe after 1.2.5, I feel busy enough until Soyuz 2.0 features get established, but thanks for considering it
<flacoste> as is Edwin
<barry> 1
<danilos> I should start the procedure soon enough
<danilos> (as discussed with kiko last year :)
<barry> danilos: it's never to early to find a mentor :)
<barry> * Review process changes
<barry>    * Tool update
<danilos> barry: will look into finding one, thanks for the heads up
<barry> danilos: i will send a "call for candidates" later today
<danilos> barry: great, thanks
<barry> gmb: anything to report on the tool?  i had some problems with the plugin yesterday, but i think it was because my rf was messed up.  i re-branched and it worked great
<gmb> barry: No, nothing new. With sickness etc I haven't touched on it much, though allenap has volunteered to help with it when he gets time.
<sinzui> I always use the -d option to pass the diff I made. I sometimes annotate the diff
<barry> gmb, allenap_ great!
<barry> okay, that's it from me.  we have 3 minutes left.  anybody have anything not on the agenda?
<barry> sounds like we're done then
<barry> MEETING ENDS
<barry> thanks everyone!
<bac> thanks barry
<mwhudson> notes from off: there's a branch on the bazaar mailing list that will make the diff computation review-submit does much faster
<barry> mwhudson: cool
#launchpad-meeting 2008-01-10
<danilos> you?
<jtv> me?
<barry> mii
<ddaa> self
<bac> yo
<sinzui> I
<SteveA> Who is chairing today's meeting?
<danilos> kiko or someone he delegates :)
<danilos> that's what the MeetingAgenda says
<SteveA> who has kiko delegated?
<SteveA> BjornT_: would you run today's meeting?
<danilos> apparently, nobody
<BjornT_> SteveA: sure, i'll do it
<SteveA> thanks
<BjornT_> so, roll call. who's here?
<jtv> me
<mrevell> me
<SteveA> me
<matsubara> me
<flacoste> me
<mpt> me
<schwuk> me
<bac> me
<statik> me
<jamesh> me
<barry> me
<adeuring> me
<ddaa> me
<stub> me
<sinzui> me
<intellectronica> me
<salgado> me
<mthaddon> me
<allenap> me
<danilos> me
<gmb> me.
<BjornT_> == Agenda ==
<gmb> Sorry.
<BjornT_>  * Roll call
<BjornT_>  * Agenda
<BjornT_>  * Next meeting
<BjornT_>  * Actions from last meeting
<BjornT_>  * Oops report (Matsubara)
<leonardr> me
<BjornT_>  * Critical Bugs (Rinchen)
<BjornT_>  * Bug tags
<BjornT_>  * Operations report (mthaddon)
<BjornT_>  * DBA report (stub)
<BjornT_>  * Sysadmin requests (Rinchen)
<BjornT_>  * A top user-affecting issue (mrevell)
<BjornT_> ----
<BjornT_>  * Test plans ownership (flacoste)
<BjornT_>  * Add your bug feed to your website (mrevell)
<BjornT_> ----
<BjornT_>  * Blockers
<BjornT_> who will not be here for the meeting next week?
<BjornT_> ok. so next meeting will be as usual, 17th jan, 1400 UTC
<BjornT_>  * Actions from last meeting
<BjornT_> there were no actions from the last meeting
<BjornT_>  * Oops report (Matsubara)
<matsubara> Today's oops report is about bugs 181772, 181770
<ubotu> Bug 181772 on http://launchpad.net/bugs/181772 is private
<matsubara> bigjools: can you take181772?
<matsubara> I've chatted with flacoste about #181770 already and assigned to him
<matsubara> bigjools: ?
<bigjools> hi
<matsubara> am I lagged?
<SteveA> bug 181770
<ubotu> Launchpad bug 181770 in launchpad "Oops deleting a package link" [Undecided,New] https://launchpad.net/bugs/181770
<bigjools> matsubara: I can take that
<SteveA> matsubara: I don't think you are lagged
<ddaa> I'd be happy to take that
<matsubara> thanks bigjools
<matsubara> ddaa: please coordinate with flacoste about it. thanks for volunteering
<flacoste> ddaa: if you mean 181770, yes, I think it's a fallout from your branch
<ddaa> flacoste: indeed
<BjornT_> ok, let's move on. there has been an amendment to the agenda. SteveA has an item now.
<matsubara> BjornT_: I'm done with oops reports. I'll move on to Joey's critical bugs
<BjornT_>  * launchpad-security team (SteveA)
<matsubara> BjornT_: ok, go on
<matsubara> SteveA: stage is yours :-)
<SteveA> thanks
<carlos> sorry, I forgot the meeting completely...
<SteveA> right now, we have the launchpad-security team
<SteveA> and it is automatically subscribed to bugs that are marked as related to security
<SteveA> the problem with that is that we often need to have private bugs for launchpad that are not related to security
<SteveA> so, there's a lot of noise for members of launchpad-security
<SteveA> both in bugs that that team is subscribed to
<SteveA> and in new bugs being temporarily subscribed to, and then unsubscribed
<SteveA> I'm going to work around this by creating a new team: launchpad-security-autosubscribed
<mpt> SteveA, currently "Launchpad Developers" is a member of "Launchpad Security"
<SteveA> that will have launchpad developers as a member, and will be the security contact for launchpad projects
<SteveA> we'll need to manually subscribe the "real" launchpad-security team to bugs that are really security issues
<mpt> so "members of launchpad-security" means "all the developers"
<SteveA> we have some outside help on launchpad-security, including james troup and kees cook
<mpt> yes
<barry> SteveA: doesn't it (perhaps also) make sense to have a separate checkbox for "this is a private (not security) bug" or somesuch?  currently the workflow for private-not-security bugs is a pita
<cprov> me (sorry)
<SteveA> barry: yes, I've separately proposed better support for projects like launchpad
<SteveA> barry: that will take a while to get done
<barry> SteveA: cool, thanks
<SteveA> barry: it's with the lpcomm team
<SteveA> so, I'll be doing this change today
<SteveA> any questions?
<SteveA> 4
<SteveA> 3
<SteveA> 2
<SteveA> 1
<SteveA> thank you
<BjornT_> ok, thanks
<BjornT_>  * Critical Bugs (matsubara)
<EdwinGrubbs> me, sorry I'm late
<matsubara> We have two critical bugs not yet started: bug 181766 and bug 181771.
<ubotu> Launchpad bug 181766 in launchpad "fix mailing list message headers and footers" [Critical,Triaged] https://launchpad.net/bugs/181766
<ubotu> Bug 181771 on http://launchpad.net/bugs/181771 is private
<matsubara> barry, do you have a status report about them?
<flacoste> why are those critical?
<barry> matsubara: i just reported them about 10 minutes ago :)
<barry> flacoste: sorry, they shouldn't have been critical, but high
 * barry will fix
<matsubara> barry: all right
<matsubara> so, no critical bugs atm
<matsubara> BjornT_: I'm done here.
<barry> fixed
<BjornT_>  * Bug tags
<BjornT_> no new tags have been proposed
<BjornT_>  * Operations report (mthaddon)
<mthaddon> Staging update script in progress
<mthaddon> Staging supermirror rewritemap script now in place
<mthaddon> Staging mailman complete (I believe?)
<mthaddon> Scheduled downtime tomorrow to enable BBWC and for a PostgreSQL security update
<mthaddon> Any final comments on the paramiko/bzr upgrade tests before we roll those out to all LP servers?
<mthaddon> That's it from me unless there are any questions
<barry> mthaddon: YES!  thanks so much
<mthaddon> cool
<barry> mthaddon: we may want to run a few more tests (including a full rebuild) once my branch that flacoste is reviewing lands
<mthaddon> barry, absolutely - just let me know when
<barry> mthaddon: great, thanks
<BjornT_> ok, moving on
<BjornT_>  * DBA report (stub)
<stub> DB patch review call happened today with Mark. A couple of patches will
<stub> get name changes. Two are rejected (bugs forwarded upstream,
<stub> and bugs fixed elsewhere/upstream). I'll be doing the formal reviews tomorrow.
<stub> Nothing else happening.
<BjornT_> any questions for stub?
<BjornT_> 4
<BjornT_> 3
<BjornT_> 2
<BjornT_> 1
<BjornT_>  * Sysadmin requests (Rinchen)
<BjornT_> anyone have any outstanding rt requests rinchen should know about?
<BjornT_> 5
<BjornT_> 4
<BjornT_> 3
<BjornT_> 2
<BjornT_> 1
<BjornT_>  * A top user-affecting issue (mrevell)
<mrevell> Howdy
<mrevell> Hello. Today's user-affecting issue is related to bug 60915.
<ubotu> Launchpad bug 60915 in usplash "usplash messes up colors on console" [Undecided,Confirmed] https://launchpad.net/bugs/60915
<mrevell> At present, non-authenticated users see an obfuscated version of email addresses in bug comments.
<mrevell> However, email addresses in bug comments are still displayed to logged-in users.
<mrevell> This has caused a complaint from someone who has reported a bug to Cocinella project. The bug reporter felt that as they had chosen to hide their email address in Launchpad it should not appear in bug comments at all.
<danilos> mrevell: is it really 60915?
<mrevell> danilos: Thank you, no, not that one. Sorry.
<SteveA> I see one email address there
<mrevell> bug 60195
<ubotu> Launchpad bug 60195 in launchpad-answers "May need to obfuscate email addresses in comments" [Medium,Fix released] https://launchpad.net/bugs/60195
<SteveA> at the domain paul.sladen.org
<SteveA> is that the email address being objected to?
<mrevell> The bug that caused the complaint is: bug 180132
<ubotu> Launchpad bug 180132 in coccinella "Login settings are not saved" [Undecided,New] https://launchpad.net/bugs/180132
<mrevell> comments 1 and 3 include the email address and comment 11 is where the reporter asked for removal
<SteveA> what's bug 60915 then?
<ubotu> Launchpad bug 60915 in usplash "usplash messes up colors on console" [Undecided,Confirmed] https://launchpad.net/bugs/60915
<mrevell> SteveA: A typo on my part. Sorry.
<BjornT_> mrevell: could you file a bug or send a mail to the list about this? we won't be able to come up with a solution in this meeting.
<mrevell> BjornT_: Thank you. I shall file a bug.
<BjornT_> thanks
<carlos> SteveA: do we parse and hide email addresses included in bug comment text ?
<BjornT_>  * Test plans ownership (flacoste)
<SteveA> carlos: yes, but only for non-loggedin-users
<carlos> SteveA: because that other bug has an email address because someone added it manually
<carlos> I see, ok
<bigjools> the same obfuscation takes place in package changelogs
<flacoste> hmm, ok, i think i remember what this was about
<flacoste> i want to know on which team test plan a bug or blueprint should appear
<flacoste> is it on the team's responsible for the functional area
<flacoste> or the team of the person who will test the bug
<SteveA> mrevell: please make sure the person who complained and the person who inadvertantly posted their mail address knows that we care.
<mrevell> SteveA: I shall.
<BjornT_> flacoste: that sounds like a question better suited for the list, doesn't it?
<flacoste> BjornT_: probably
<flacoste> i'll email the list about it
<flacoste> i think there was some other issue, but can't recall (i posted that item nearly one month ago)
<BjornT_> flacoste: cool. i'm curious about the answer myself :)
<BjornT_>  * Add your bug feed to your website (mrevell)
<mrevell> I've placed my bug feed on my home page at http://www.understated.co.uk/
<mrevell> It'd be great to see other people do something similar on their website, so that we can demonstrate the feeds feature we introduced with 1.1.12.
<mrevell> It's very easy to do using MagpieRSS, Wordpress and tools such as http://wigitize.com/
<mrevell> I've posted a quick Wordpress how to at:
<mrevell> http://www.understated.co.uk/2008/launchpad-bug-feeds-in-wordpress/
<mrevell> I'm keen to see how people are using their feeds, so please post links to the launchpad-users list if you go ahead.
<mrevell> Thanks, back to BjornT_
<BjornT_> thanks mrevell
<BjornT_>  * Blockers
<mrevell> Releases: not blocked
<BjornT_> Bugs: not blocked
<jtv> Translations team: Not blocked
<flacoste> Foundations: not blocked
<SteveA> SC: not blocked
<schwuk> HWDB: not blocked
<ddaa> Code: dunno, just came back from vacation and have not synced up yet. Presumably not blocked.
<statik> lpcomm: not blocked
<bigjools> Soyuz Team: not blocked
<BjornT_> ok, that should be everyone. thanks for coming!
<BjornT_> MEETING ENDED
<schwuk> Thanks BjornT_
<statik> thanks for running the meeting BjornT_
<matsubara> Thanks BjornT_
<SteveA> thank you BjornT_.  very smooth.
<mrevell> thanks all
<barry> thanks BjornT_
#launchpad-meeting 2008-01-13
 * Hobbsee wins against chanserv!
#launchpad-meeting 2009-01-07
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everybody.  happy new year and welcome to the first ameu reviewer's meeting of 2009.  who's here today?
<allenap> me
<sinzui> me
<intellectronica> me
<bac> me
<flacoste> me
<barry> gmb, salgado, and rockstar all send their apologies
<barry> adeuring: ping
<EdwinGrubbs> me
<adeuring> whoops, me
<barry> bigjools, cprov danilos ping
<bigjools> moo
<barry> mars: ping
<bigjools> cprov is out
<barry> bigjools: cool, thanks
<mars> me
<mars> thanks barry
<barry> it's a very light agenda for today...
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  * Action items
<barry>  * Mentoring update
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<barry> i literally have nothing on the agenda for today, so before i get to action items, let me throw it open to the floor.  do you all have any topics you'd like to discuss?
<bigjools> are we any closer to solving circular imports with the API?
<bigjools> I guess not :)
<barry> not from me.  i didn't get a chance to work on that over the break
<barry> ;)
<barry> one thing i would like people to start thinking about is how (maybe: if :) we're going to do reviews of contributions when we open source lp
<barry> we don't need to solve that now, but as we get closer i'd like to have a strategy for that
<barry> ok!
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * barry to look into techniques for eliminating back-patching of schema types (avoiding circular imports)
<barry> not done
<barry>  * barry to add `pretty()` functions to reviewers docs
<barry> not done
<barry>  * flacoste to work on API reviewer cheat sheet
<flacoste> not done
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
 * barry doesn't even remember who we're still mentoring
 * al-maisan is mentored by gmb
<barry> al-maisan, gmb how are things going?
<barry> of course gmb isn't here, so al-maisan you can rip on him if you want :)
<allenap> I'm mentoring abel.
<allenap> He's brilliant :)
<adeuring> allenap: uh, thanks !
<barry> excellent!
<al-maisan> I did reviews on two Mondays and these went reasonably well.
<bigjools> allenap: so you might say he's very abel to do his job
<barry> har har
 * bigjools is here all week, enjoy the buffet
<al-maisan> On some of the days I had a lot of work to do and didn't do any reviews.
<al-maisan> I guess that somewhat of a general "problem"
<barry> bigjools: don't forget to tip your bartenders
<al-maisan> *that's*
<barry> al-maisan: yep, that's the way it goes sometimes
<barry> btw, we have some new padders who might make good mentats
<allenap> bigjools: Oh my. Couldn't you have taken some more holiday?
<barry> should we roust up a fresh batch of noobs?
<allenap> bigjools: Or maybe that would make it worse :)
<barry> :)
<bigjools> barry: I was thinking that we have particularly good community contributions we can turn them into reviewers
<bigjools> allenap: it can get worse? :)
<barry> bigjools: kind of like for bzr?
<bigjools> dunno how bzr works
 * barry should have pinged abentley
<bigjools> and maybe commit access when people have built up trust
<barry> one thing though: we'll have to be careful about keeping the overall vision reins so things don't get committed that we're not cool with
<intellectronica> i think best is to first require contributors to arrange a sponsor, and then pick good contributors to get commit access
<bigjools> yep
<barry> +1
<bigjools> like I said, they'll need to build trust first
<intellectronica> where a sponsor is someone you talk to before starting to work on something, when you get it to review and when it's time to commit
<barry> btw, internally, i think henning, gary and noodles are available for mentoring
<barry> but they may need a little more baking (or in noodle's case, boiling)
<barry> well.  maybe that's it for today.  i've got nothing. shall we end early?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 09:23.
<barry> thanks everyone!
<al-maisan> :)
<bigjools> Thunderbirds are go
<al-maisan> thanks barry !
#launchpad-meeting 2009-01-08
<matsubara> #startmeeting
<MootBot> Meeting started at 09:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<rockstar> me
<bigjools> moi
<intellectronica> me
<henninge> me
<stub> em
<sinzui> me
<matsubara> apologies from Ursula, she's having connectivity issues
<matsubara> flacoste: ping
<flacoste> me
<matsubara> ok, everyone is here.
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Next meeting
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs
<matsubara>  * QA pending items
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (DBA contact)
<matsubara> [TOPIC] * Next meeting
<MootBot> New Topic:  * Next meeting
<matsubara> so next meeting, same time next week?
<matsubara> no objections, so same time, same channel next week
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>  * al-maisan to take a look at OOPS-1083D1281 (ubuntu/+build timeout)
<matsubara>  * Ursinha to watch for new occurrences of OOPS-1083H1147 the next hours/days (+newaccount timeout)
<matsubara>  * Ursinha and rockstar to talk to code people about 260171 and 252807
<matsubara>  * sinzui to find out the priority of automatizing manual processes such as bug 49676
<matsubara>  * Ursinha to talk to abentley about the status of bug 252807
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1083D1281
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1083H1147
<ubottu> Bug 49676 on http://launchpad.net/bugs/49676 is private
<ubottu> Bug 252807 on http://launchpad.net/bugs/252807 is private
 * matsubara waves to Ursinha 
<matsubara> sinzui: nes about bug 49676?
<ubottu> Bug 49676 on http://launchpad.net/bugs/49676 is private
<matsubara> s/nes/news/
<matsubara> bigjools: is muharem working on that time out?
<bigjools> no idea!  just asked him to join
<bigjools> aha
<al-maisan> hello there!
<matsubara> * al-maisan to take a look at OOPS-1083D1281 (ubuntu/+build timeout)
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1083D1281
<matsubara> hey al-maisan
<matsubara> any news about that OOPS?
<sinzui> matsubara: I think we should close this bug this cycle. I believe flag-expired-members is broken because disabled accounts are not always remvoed from teams
<al-maisan> hello matsubara
<al-maisan> matsubara: unfortunately, no.
<al-maisan> I added it to our (Soyuz) OOPS page but did not work on it. Sorry!
<matsubara> al-maisan: do we have a bug report for that one?
 * al-maisan checks
<al-maisan> matsubara: I don't think so.
<matsubara> I'll chase Ursinha later on about her action items
<matsubara> [action] matsubara to talk to ursinha about pending action items
<MootBot> ACTION received:  matsubara to talk to ursinha about pending action items
<matsubara> al-maisan: I'll file a bug for that one and assign to you. Can you take care of it this cycle?
<matsubara> [action] matsubara to file a bug about soyuz timeout oops OOPS-1083D1281 (ubuntu/+build timeout) and assign to al-maisan
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1083D1281
<MootBot> ACTION received:  matsubara to file a bug about soyuz timeout oops OOPS-1083D1281 (ubuntu/+build timeout) and assign to al-maisan
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1083D1281
<al-maisan> I guess so.
<matsubara> thanks al-maisan
<al-maisan> you are welcome.
<matsubara> sinzui: thanks. I'll target to this milestone then, if that's ok. who should be the assignee?
<sinzui> matsubara: I do not know, My team is quite busy, so I'm waiting for an opportunity to present itself
<matsubara> sinzui: is it ok to assign to you and then you assign to someone else in your team?
<sinzui> I suppose that will do. Maybe I can do it during my sprint
<matsubara> all right. thanks sinzui
<matsubara> moving on
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<matsubara> we have 3 OOPSes
<matsubara> https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/300798
<ubottu> Launchpad bug 300798 in launchpad-bazaar "+merge-queue gives OOPS" [Medium,Triaged]
<matsubara> rockstar: can you coordinate with someone in your team to have that one fixed this cycle? Looks like an easy fix
<rockstar> Hrm, that one is not a happy one.
<rockstar> Yea, I'll make sure it gets fixed soon.
<matsubara> it's a broken link rather than an OOPS but needs fixing anyway
<rockstar> matsubara, yup.
<matsubara> the other two OOPSes are: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1103A3748 and https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1103D2789 which Ursinha is already coordinating with gmb
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1103A3748
<ubottu> https://devpad.canonical.com/~jamesh/oops.cgi/1103D2789
<matsubara> we have 2 critical bugs, one is fix committed and the other is in progress
<matsubara> flacoste: bug 310096 is in progress and have 2 branches (already merged in) but have no assignee or milestone target
<ubottu> Launchpad bug 310096 in launchpad-foundations "+pre-authorize-rp still fails because of replication set-up" [Critical,In progress] https://launchpad.net/bugs/310096
<flacoste> matsubara: it's fix released
<matsubara> flacoste: can you update the status/assignee/milestone please?
<flacoste> matsubara: doing this now
<matsubara> flacoste: great! thank you!
<matsubara> that's all for the oops & critical bugs section. thanks everyone
<matsubara> moving on
<matsubara> [TOPIC] * QA pending items
<MootBot> New Topic:  * QA pending items
<matsubara> hmm this section is done by Ursinha
<matsubara> this is the friendly weekly reminder of things that needs testing
<matsubara> but I don't have the list handy.
<bigjools> the QA lists weren't being updated until recently so prob not worth nagging
<matsubara> so, I'll ask Ursinha to nag the teams individually after the meeting :-)
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<matsubara> bigjools: yeah, Ursula is fixing the script to have the test plans up to date again
<matsubara> herb: ?
<matsubara> hmm herb doesn't seem to be around. I'll skip this section for now and get back to it if herb shows up
<matsubara> in any case, I'll ask the Losas to send the report to the list
<matsubara>  * DBA report (DBA contact)
<stub> Everything going smoothly. Low load as expected for this time of year. Nothing interesting apart from the looming disaster if the Librarian runs out of disk space. We will be ok if the Soyuz team is correct and we have a lot of wasted space in old PPA binaries. Otherwise we need disk.
<matsubara> stub: ^
<stub> oot.
<bigjools> working on that - we need to notify the PPA users before deleting their old binaries
<herb> matsubara: I'm not ready.  just started for the day.  I'll send a report to the list in a little while
<matsubara> thank you herb
<matsubara> thanks stub
<stub> bigjools: We need to be aware of time frames if there is notification etc. that needs doing.
<bigjools> stub: yeah there's a bit more to it, I can chat after the meeting if you want
<matsubara> bigjools: please coordinate the announcement with mrevell
<bigjools> matsubara: already doing that :)
<mrevell> yep, we're on the case :)
<matsubara> you rock! thanks
<matsubara> both of you rock :-)
<mrevell> heh
<matsubara> so, anything else before I close?
<stub> Its not so much my issue but the losas - they need to ensure the disk is freed before the red line is crossed. I don't know what the predicted explode date is.
<stub> Or plug in a terrabyte USB drive or something as a temporary fix ;)
<bigjools> cheap as chips :)
<matsubara> hehe
 * rockstar wants chips
<matsubara> all right. Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 09:23.
<bigjools> rockstar: British or US chips?  both are good :)
<rockstar> British chips.  The others I'm more picky about.
<stub> STOP MAKING ME HUNGRY YOU BASTARDS
<intellectronica> thanks matsubara
<bigjools> soaking in vinegar
<rockstar> stub, you're in curry central.  I don't feel sorry for you.
<bigjools> a touch of black pepper
#launchpad-meeting 2010-01-13
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> welcome to the AMEU Reviewers meeting.
<bac> who's here today?
<flacoste> me
<sinzui> me
<henninge> me
<mars> moo
<adeuring> me
<bac> EdwinGrubbs, deryck, gmb, BjornT: ping
<EdwinGrubbs> me
<gmb> me
<gmb> Erk
<deryck> me
<bac> gary_poster: ping
<gary_poster> bac: thank you, me
<bac> team leads ping your peeps
<gary_poster> done.  May not get too many from my team.
<danilos> me
<bac> i know we have a lot of people missing today due to sprints, so let's move on.
<henninge> bac: jtv is sprinting
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> yay, mootbot is not case sensitive!
<gary_poster> heh
<bac>  * Roll call
<bac>  * Action items
<bac>  * Limit doctests to 200 lines [allenap]
<bac>  * Security checks: ``try:...except UnauthorizedError:...`` vs. canView [gary]
<bac>  * Cleaning up ImportFascist warnings [bac,sinzui]
<bac>  * Peanut gallery (anything not on the agenda)
<allenap> me
<intellectronica> me
<danilos> allenap, (a nice trick to get pinged through agenda ;)
<bac> [topic] outstanding actions
<MootBot> New Topic:  outstanding actions
<bac> [topic] * intellectronica to draft guidelines for drive-by cleanups
<MootBot> New Topic:  * intellectronica to draft guidelines for drive-by cleanups
<intellectronica> sorry, haven't done that. please keep it on the list and i'll get it for our next meeting
<bac> intellectronica: excellent, thanks!
<bac> [topic] invite other teams to do lazr-js code reviews? (See if this was sent to the ML.) [mars/bac]
<MootBot> New Topic:  invite other teams to do lazr-js code reviews? (See if this was sent to the ML.) [mars/bac]
<bac> i searched through the ML's and did not see it had been discussed
<bac> mars did you have some thoughts on the topic?
<mars> bac, I'm going to add it to the agenda for the lazr-js taskforce call tomorrow
<bac> mars: ok, so you can report back here next week.
<mars> bac, you can keep it on the list here if you would like to see a wrapup item next week
<bac> [action] mars to report on outcome of lazr-js review discussion
<MootBot> ACTION received:  mars to report on outcome of lazr-js review discussion
<mars> yeah :)
<bac> great, moving on to new items
<bac> [topic] Limit doctests to 200 lines [allenap]
<MootBot> New Topic:  Limit doctests to 200 lines [allenap]
<bac> gavin, take it away
<allenap> Right,
<allenap> Because of the accumulation of state in doctests
<allenap> I think it would be good to limit new doctests to 200 lines or less.
<allenap> gmb wrote a new doctest last week of just under 200 lines and it was still perfectly comprehensible.
<allenap> So that's where the number comes from.
 * gmb notes that it got changed into a unittest anyway during the review process...
<danilos> I don't think that'd be right for large classes and corresponding doctests, 200 sounds as artificially low limit
<allenap> Although manuel (?) adds a reset-globs directive whihc might make this moot.
<flacoste> and there is an alternative to the state problem
<danilos> perhaps large classes are the problem, but we do have them
<flacoste> exactly, reset-globs in manuel
<gary_poster> agree with danilos.  Also, agree with allenap's observation of manuel
<sinzui> allenap: I have thought about breaking many registry doctests into smaller themes
<flacoste> manuel also adds the option of running specific section of a doctest
<sinzui> allenap: but my motivation it to control the layer the test is run on.
<intellectronica> i think limiting the length is not the best way to handle this. instead i suggest dividing tests thematically
<mars> I agree, I don't see the problem as much with larger narratives as it is with naughty test code state.
<danilos> sinzui, I think the problem with existing doctests is that we don't have a good structure of tests in general (oh, I'd like to clean most of translations ones as well)
<intellectronica> that is, stop and start a new file when you're really testing something new (with new state and so on)
<bac> intellectronica: i agree
<allenap> The main problem I have is trying to understand the object and database state by the end of the test. That can't really be fixed by reset-globs or manuel as I understand it.
<danilos> intellectronica, +1, basic doctests (those which are usually large) should be basic class documentation; specific tests should be unit test
<allenap> intellectronica: The limit is an incentive to split :)
<allenap> intellectronica: But I agree.
<danilos> allenap, I see the point, but artificial limit would have to be broken in so many valid cases
<intellectronica> allenap: yes, i understand that, but somehow it feels a bit too artificial to me. are you concerned that without a hard limit developers/reviewers won't bother?
<bac> allenap: it is a good point but i'd rather see us have smaller, more themed tests as a guide rather than adopting a limit
<gary_poster> We do have a "800 line limit for reviews" that is a guideline but often breached
<intellectronica> also, i'll play sinzui and ask: who's going to split all the existing test? ;)
<danilos> how about instead spreading a rule "enforce corner-case testing through unit tests" among reviewers instead? those tend to make doctests harder to read
<mars> instead of a hard limit, can we call it a "refactor point"?  As in, over X lines, the reviewer should look for a possible refactoring
<allenap> Okay, sounds good. Is there a way to measure or have more concrete guidelines, or is it at developer/reviewer discretion?
<mars> it's ok if they do not find such a point
<mars> kind of like review lint
<intellectronica> allenap: there is a measure. variables shouldn't be recycled
<danilos> mars, I still believe that those complex doctests should really be turned into unittests, and that's exactly where you can't reuse variables :)
<allenap> intellectronica: I don't think we should split the existing tests... until it is no longer possible to not split them.
<allenap> intellectronica: I like that :)
<allenap> intellectronica: There's still a problem of db state.
<mars> danilos, well, if they are over 800 lines, then you would recommend the refactoring, wouldn't you? :)
<intellectronica> allenap: if we adopt this as a policy we will eventually have to split the tests, if only so that they don't serve as a negative example for new contributors
<allenap> danilos: +1
<mars> danilos, or 400, or whatever
<sinzui> intellectronica: One line that creates a file or email message requires that the test be run on a different layer. In many cases the test is actually moving to a new theme and I think it is easier to read the that aspect of the test separately.
<allenap> intellectronica: Good point.
<intellectronica> allenap: i guess it's the same for db state. don't rely on db state unless it's either set in the sample data or in the prologue to your test
<danilos> mars, well, reviewers should always look for points of refactoring, so I just feel such "rule" wouldn't really make any difference, but sure :)
<allenap> intellectronica: I agree, and I don't know of a way to make it less vague than that. I suppose that's what I was looking for.
<gary_poster> I find the stories that doctests tell valuable.  The stories are often long--and in fact, I often wish they were *better* connected, not less, from a narrative standpoint.  That viewpoint would make me want to see manuel a preferred option, or perhaps Sphinx involved for tying together story chunks, but that is maybe herder.
<intellectronica> sinzui: so what you're saying is that we should split tests if we're required to run the test in a lower layer because of a change in the middle of the test?
<danilos> mars, even when the diff you are looking at is 10 lines, as a reviewer, you should wonder if the code is sitting in the right place
<gary_poster> and means that it doesn't help for reading text files, only processed files
<mars> danilos, well, I don't think of it as a rule, just a recommendation for reviewers.  Kind of a warning, or code advice.
<gary_poster> s/herder/harder/
<mars> danilos, right
<danilos> anyway, it seems this is a hot topic
<danilos> allenap, bac, shall we move it to the mailing list or try to come up with a conclusion here?
<gary_poster> I think a lot of people talking about dividing things up are coming from the perspective of (1) expertise and (2) testing.
<sinzui> intellectronica: yes. In the exampled I am thinking about, registiry object deletion, email notification, these themes are different from the core uses of the object.
<allenap> danilos: Mailing list I think. There are many threads of conversation and this isn't going to end here anyway ;)
<gary_poster> they are valuable, but these are narratives.
<intellectronica> sinzui: yes, i think that's a good guideline
<danilos> allenap, right, I think the general consensus is that we don't want 200 as the limit, so it's best to discuss other solutions to the problem you observe on list
<bac> danilos: yes, let's move the discussion to the mailing list.  allenap will you start the discussion there?
<allenap> bac: Sure.
<mars> gary_poster, good point
<gary_poster> :-) thank you mars
<bac> [action] allenap to start discussion on the ML about doctest size, refactoring, moving corner cases to unittests, etc
<MootBot> ACTION received:  allenap to start discussion on the ML about doctest size, refactoring, moving corner cases to unittests, etc
<bac> [topic] Security checks: ``try:...except UnauthorizedError:...`` vs. canView [gary]
<MootBot> New Topic:  Security checks: ``try:...except UnauthorizedError:...`` vs. canView [gary]
<gary_poster> OK I almost have the conversation pastable but not quite.
<gary_poster> I was talking with EdwinGrubbs about a security check.  He was checking whether a user had a specific permission on an object.  He was using a utility in the LP tree that I forget.
<gary_poster> I said that my top preference would be try:...except UnauthorizedError:... and my next preference would be canAccess and canWrite from zope.security.checker.
<gary_poster> canView is nicer because you do not specify the permission, which is fragile.
<gary_poster> The try/except approach uses the basic security machinery directly.  It is of course the basic mechanism that Zope provides.
<gary_poster> Edwin pointed out that this was not a pattern in the LP tree.  He was also afraid it would be slower.
<gary_poster> I'm pretty sure it will not be slower than calling a Python function, but can verify with a timeit test.
<gary_poster> So, I suppose I have these thoughts:
<gary_poster> 1) I'd like to make sure that we generally agree that we don't want to specify permissions unless we have to
<gary_poster> (that is, my main suggestion from the story above)
<gary_poster> 2) I'd like people to consider using the try/except approach, and for it to be a reasonable/approved one.  If we want me to construct a timeit test to verify I can.
<gary_poster> That's it.
<gary_poster> s/conversation pastable/introduction pastable/ ;-)
 * danilos reads
<intellectronica> gary_poster: i also think that using try/except is clearer
<gary_poster> cool
<bac> i think a lot of us have heard the "wisdom" that try/except is slower.  i think a timeit test to disprove that would be useful.
<danilos> I know we are using checkPermission for these things
<gary_poster> EdwinGrubbs: are you around to say remind me what the utility was that you used at first?
<gary_poster> Maybe it is checkPermission
<EdwinGrubbs> yes, it was check_permission()
<danilos> from canonical.launchpad.webapp.authorization import check_permission
<gary_poster> ah ok, looking
<danilos> bac, +1
<flacoste> it's a wrapper around checkPermission
<intellectronica> bac: why is performance an issue here? usually you don't call these in loops
<gary_poster> flacoste: oh ok
<danilos> example: check_permission('launchpad.Edit', pofile)
<flacoste> and i think actually the try: except: is what is used under the hood by check_permission anyway
<EdwinGrubbs> you do call them in loops if you are displaying a list of objects
<gary_poster> so generally, I don'y think we should use check_permission (or checkPermission) again, if at all possible.  That's my #1,
<gary_poster> canAccess and canWrite are less fragile
<gary_poster> I'm happy to do the timeit check.  I still think that try/except will be faster than a Python function, but I think that's interesting information, so I can do that and report back to the list.
<henninge> gary_poster: Is this in view or in model code?
<EdwinGrubbs> view code
<bac> intellectronica: it may be in a loop.  if some timing tests can show it is a myth then i think that's useful.
<henninge> good
<intellectronica> bac: knowing is definitely useful, but i think that even if we find that it is slower, we should still consider using try/except in cases where it doesn't affect performance _drastically_
<flacoste> hmm, right
<flacoste> canAcess / canWrite uses try: except
<flacoste> whereas checkPermission uses the checker information
<bac> intellectronica: well, a lot of these cases are in vocabularies, IIRC.  many of those do have performance issues
<intellectronica> bac: yes, where we do it iteratively we definitely should optimize for performance
<danilos> the reason I don't like try...except is that (especially with API), we will get a lot of cases where we'll have multiple conditions we are checking for
<danilos> so, nested try..excepts sound ugly to me
<gary_poster> If try:except is faster, as I suspect, then we do not have to have the theoretical discussion.  suggested resolution for now: I'll do the timeit test and report back to the list.  If there is a clear answer in favor of try/except for performance as well, then that's easy.  ...except for danilo's case...
<gary_poster> danilo, can you send me an example to look at?
<danilos> gary_poster, I am not even sure it's a valid example, but there are cases where we do an OR of multiple permission checks
<gary_poster> danilos: right, I'd like to see if it is valid; if it is not, we should know what a preferred spelling us
<danilos> but that's probably just bad design where objects are not properly security-wrapped
<bac> [action] gary to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again next week.
<gary_poster> is
<MootBot> ACTION received:  gary to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again next week.
<gary_poster> cool thanks
<bac> thanks for bringing it up gary
<bac> [topic] Cleaning up ImportFascist warnings [bac,sinzui]
<MootBot> New Topic:  Cleaning up ImportFascist warnings [bac,sinzui]
<bac> jml's fix to the import fascist revealed lots of places where we have problems
<bac> we need to drive those warnings back to zero or we'll continue to expand the problem
<danilos> gary_poster, sure, why don't you ping me later and we can take a look (basically, lp.translations.browser.distroseries.DistroSeriesLanguagePackView has an example)
<bac> sinzui has a branch that accomplishes a lot of it but has reported new code is  introducing more problems
<bac> sinzui where did you find the bulk of the offenders to be?
<gary_poster> danilos: awesome thank you
<sinzui> Most were explicit import from _schema_circular_imports which were not needed
<sinzui> They were easy to remove
<bac> sinzui: does your branch solve the problem for LP or just registry?
<sinzui> LP, but there are two new ones in the last 12 hours
<bac> ah, cool.  so once this branch lands we can go back to zero tolerance as reviewers, no?
<sinzui> BranchJobDerived BranchJobType are not in BranchJob.__all__, but are imported by translationtemplatesbuildjob and translationtemplatesbuildjob
<gary_poster> should we make them errors?
<gary_poster> I thought that was an option
<sinzui> I could add these two classes to __all__, but I think the code team and translations team need to coordinate
<danilos> sinzui, if it has happened during last 12h, it's something that's happening during a sprint in Wellington
<sinzui> correct
<danilos> sinzui, and I don't really overlap with them, so I'd appreciate if you mention it to jtv when he shows up and I am sure he'll be happy to fix the issue or find someone who will :)
<sinzui> I will
<danilos> sinzui, thanks
<bac> so we're in agreement to get this cleaned up over the next week and then keep it under control?
<danilos> sinzui, and thanks for spending the effort to fix it everywhere else as well, I hope we didn't have many issues in translations since we shouldn't be able to import stuff if we do (because we are not using global imports either)
<danilos> bac, +1
<bac> [action] sinzui to land a import cleanup branch and then reviewers will enforce zero tolerance for introducing new issues.
<MootBot> ACTION received:  sinzui to land a import cleanup branch and then reviewers will enforce zero tolerance for introducing new issues.
<bac> that's it for agenda items
<danilos> sinzui, bac: just to confirm, this will also be part of lint checks?
<bac> [topic] peanut gallery
<MootBot> New Topic:  peanut gallery
<sinzui> landing is challenging since we are in phantom testfix
<danilos> (i.e. easy to spot)
<danilos> sinzui, js buildbot?
<bac> danilos: i'm not sure.  sinzuie?
<bac> er, sinzui?
<sinzui> danilos: importfacist has never been a part of lint since the testrunner has alwyas reported them
<bac> thanks
<sinzui> danilos: I thought I saw rockstar land a reversion to get us out of testfix
<flacoste> sinzui: it's not phantom
<flacoste> db_lp has three failures
<bac> moving on, does anyone have an issue that is not on the agenda?
<flacoste> related to code hosting
<flacoste> i have
<bac> flacoste: go
<flacoste> but it's not related to reviewers :-)
<bac> hmm
<flacoste> but would like the opportunity that we have a lot of attention :-)
<flacoste> we need a volunteer to fix the db_lp failures
<bac> flacoste: ok, reminding you we're at 45 minutes
<flacoste> that's all
<flacoste> bac: you can cloase the meeting
<bac> flacoste: let's try to resolve that outside the meeting
<bac> #endmeeting
<MootBot> Meeting finished at 09:46.
<bac> thanks everyone for coming
<gary_poster> thanks bac
<mars> thanks bac
<flacoste> these are the errors:
<flacoste> Tests with errors:
<flacoste>    lp.code.model.tests.test_branchjob.TestRevisionsAddedJob.test_getMergedRevisionIDs
<flacoste>    lib/canonical/launchpad/ftests/../../../lp/bugs/doc/bug-set-status.txt
<danilos> thanks bac
<flacoste>    lp.code.model.tests.test_codeimport.TestCodeImportDeletion.test_deleteIncludesJob
<bac> flacoste: what about the other two?
<sinzui> LayerIsolationError
<bac> oh, nm
<sinzui> for all of them
<flacoste> indeed
<sinzui> I suspect the test env, not the test
<flacoste> well
<flacoste> test_deleteIncludesJob
<flacoste> is an Unauthorized error
<sinzui> sorry, I did not see that
<flacoste> well, no
<flacoste> layerIsolationError are problems with the test
<flacoste> it means that an object created by the test cannot be garbaged collected
<sinzui> The bug test has not change in 6 months, and before that 2 years ago
<flacoste> right
<flacoste> the problem is that these layerIsolation might not be directly associated with the test
<flacoste> but it sure comes from some kind of changes
<flacoste> looking at the garbage left, it seems to be bzrlib objects
<sinzui> I saw this happen when the order of tests changed
<sinzui> I had to set the dirty db flag in some tests to fix the issue
<flacoste> was the garbage related to bzr in that case?
<flacoste> should we simply revert these revisions?
<sinzui> No. two or three years ago I discovered that many unit tests were creating objects. I had to modify the tearDown(). The error was only observed by testing the layer
<flacoste> is the Unauthorized error reproducible locally at least?
<sinzui> No it does not fail
<flacoste> sinzui: should we simply trigger a rebuild?
<sinzui> flacoste: I was tempted.
<sinzui> mars: do you have a script that scores new users yet?
<sinzui> losas ping
<jml> sinzui, what's your boggle?
#launchpad-meeting 2010-01-14
<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
<gary_poster> me
<Chex> me
<henninge> me
<matsubara> rockstar, allenap, hi
<henninge> hi matsubara
<henninge> ;)
<matsubara> hi henninge, thanks for standing in for daniloff
<allenap> me
<matsubara> ok, let's move on. rockstar can join in later
<matsubara> apologies from Ursula and bigjools
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<henninge> matsubara: rockstar's in Wellington AFAIK
<mrjazzcat> Brian is also attending
<matsubara> oh, ok, so apologies from rockstar as well :-)
<matsubara> hi Brian, welcome!
<mrjazzcat> thanks
<matsubara> mrjazzcat, ^
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara>  * DBA report (stub)
<matsubara>  * Proposed items
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>  * salgado to take bugs 504300 and 504291 to foundations discussion
<matsubara>  * Chex to discuss with rockstar about bug 497945
<matsubara> Chex, did you have a chance to discuss that bug with rockstar?
<matsubara> gary_poster, any news about those two foundations bugs?
<matsubara> hmm
<matsubara> ok, I can see that both are in progress
<gary_poster> 1 sec
<gary_poster> ty
<matsubara> so that's fine
<Chex> matsubara: no I did not, sorry.
<matsubara> Chex, 497945 is a dupe of 486076, can it be considered actioned upon?
<matsubara> not sure on the nature of the discussion from the previous meeting action
<Chex> matsubara: I think the git import issue is less of an issue as I think that server received a large RAM upgrade, but it should still be looked at..
<matsubara> Chex, it's assigned to Jelmer
<matsubara> Chex, would you like this action item to be brought again in the next meeting?
<Chex> matsubara: no I think we can close it down for now, I will bring it up again if it becomes an issue later, thank you
<matsubara> thanks Chex
<matsubara> so let's move on
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<Chex> hi everyone, quick report today..
<matsubara> We have 3 oopses needing attention, one for henninge, one for allenap and another one for rockstar
<matsubara> Chex, hang in there, buddy
<Chex> - LP Librarian space issue: Bug# 506489: We still need help with
<Chex>      addressing the space issues on the librarian, can someone let us
<Chex>      know the latest status of helping us cleaning up space?
<Chex> - LP incidents of note:
<Chex>         ; LP Cherry-picks: revno 8811 rolled out to lpnet 08-Jan,
<Chex>           revno 8812 rolled out to lpnet 13-Jan
<Chex> oh sorry
<matsubara> hehe
<matsubara> no worries
<henninge> matsubara: bug 506925 is mine and the fix is next up in pqm - after the current cp is through ....
<matsubara> allenap, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1474EA771 doesn't look like bug 329917. it has the same exception type but looks like a differnt bug
<matsubara> can you confirm?
<matsubara> henninge, I was wondering about https://bugs.edge.launchpad.net/rosetta/+bug/507498
 * allenap looks
<matsubara> and the one for the code team is https://bugs.edge.launchpad.net/launchpad-code/+bug/507487
<matsubara> which I'll email tim about
<matsubara> [action] matsubara to email tim about  https://bugs.edge.launchpad.net/launchpad-code/+bug/507487
<MootBot> ACTION received:  matsubara to email tim about  https://bugs.edge.launchpad.net/launchpad-code/+bug/507487
<allenap> matsubara: That does look like a different bug. Very odd. I'll file a bug and take it to the team.
<matsubara> henninge, sorry for the crap description. not sure if it describes the problem well. it looks like a high priority bug since it OOPSes on GET to that page
<matsubara> [action] allenap to file a bug about OOPS-1474EA771 and discuss it with Bugs team.
<henninge> matsubara: seems spurious, I can GET that page now ...
<MootBot> ACTION received:  allenap to file a bug about OOPS-1474EA771 and discuss it with Bugs team.
<matsubara> thanks allenap
<matsubara> henninge, it still oopses for me
<matsubara> so likely to be a permission issue
<matsubara> maybe because you're a rosetta admin?
<henninge> matsubara: yes
<henninge> oh, probably
 * henninge logs out
<matsubara> henninge, can you (or assign someone in Translations) to get that one fixed this cycle?
<henninge> matsubara: all sick or on sprint, I'll do it.
<henninge> ;-)
<matsubara> thanks a lot henninge
<matsubara> [action] henninge to fix bug 507498
<MootBot> ACTION received:  henninge to fix bug 507498
<matsubara> I'll add a note to the bug report that it doesn't oops for rosetta admins :-)
<henninge> cheers
<matsubara> we had a couple of script failures since last week
<matsubara> rosetta-export-queue
<matsubara> translations-import-queue-gardener
<henninge> matsubara: that's what my current fix in pqm is fore (export-queue)
<matsubara> allocate-revision-karma
<henninge> matsubara: jtv submitted a fix for the gardener
<matsubara> and another one for update-cache
<henninge> matsubara: and some sql for the immediate fix.
<matsubara> sinzui, any news about the allocate-revision-karma and update-cache?
<matsubara> henninge, that's great. thank you
<sinzui> matsubara: the former stopped the latter from running
<matsubara> sinzui, and is there work in progress to fix the karma script?
<sinzui> matsubara: the former (allocate-revision-karma) is something that the code-team thought was fixed, but we may be experiencing a reversion
<sinzui> matsubara: revisions are code-team
<matsubara> oh, it's a code team issue.
<matsubara> all right. I'll email tim about it as well
<matsubara> thanks sinzui
<matsubara> [action] matsubara to email tim about allocate-revision-karma script still blowing up
<MootBot> ACTION received:  matsubara to email tim about allocate-revision-karma script still blowing up
<sinzui> matsubara: That was broken a few weeks ago because it tried to recalculate the ENTIRE history. and it went into recursion. Tim landed a fix only work with recent changes
<matsubara> we have 8 critical bugs, 4 fix committed, 2 in progress, 1 triaged and 1 new (bad!)
<matsubara> gary_poster, can you take a look at the one which is new (bug 504696)?
<gary_poster> matsubara: yes
<matsubara> [action] matsubara to talk to someone from soyuz about critical bug 506489
<MootBot> ACTION received:  matsubara to talk to someone from soyuz about critical bug 506489
<matsubara> [action] gary_poster to triage and assign bug 504696
<MootBot> ACTION received:  gary_poster to triage and assign bug 504696
<matsubara> thanks gary_poster
<gary_poster> matsubara: stub is working on it.  Will adjust bug status to show
<matsubara> [action] matsubara to cancel previous action item. it's already done
<MootBot> ACTION received:  matsubara to cancel previous action item. it's already done
<matsubara> thanks gary_poster
<matsubara> sinzui, was it cp?
<matsubara> maybe it's still blowing up because the code is not running with the fix?
<sinzui> matsubara: I believe it was because the errors disappeared for a few fays
<matsubara> sinzui, oh, right. I'll talk to tim about it them. thanks for the info
<matsubara> moving on. thanks everyone
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara> Chex, now it's your turn, take the stage please :-)
 * mbarnett prepares to heckle 
 * henninge looks up heckle
 * matsubara too
<henninge> ah! we are all quiet, though... ;-)
<Chex> sorry everyone, I will repost the report
<Chex> - LP Librarian space issue: Bug# 506489: We still need help with
<Chex>      addressing the space issues on the librarian, can someone let us
<gary_poster> bah, you all don't know what heckle means?  What kind of IRC participation is this?!
<Chex>      know the latest status of helping us cleaning up space?
<Chex> - LP incidents of note:
<Chex>         ; LP Cherry-picks: revno 8811 rolled out to lpnet 08-Jan,
<Chex>           revno 8812 rolled out to lpnet 13-Jan
 * gary_poster demonstrates heckling
<henninge> gary_poster: lol!
<Chex> and thats the report for this week..
<flacoste> about the librarian space issue
<flacoste> bigjools was testing a query to reclaim some space yesterday
<flacoste> Bjorn was to approve it
<flacoste> i don't know if it happened or not
<flacoste> there is no record on the bug
<flacoste> nor on LPS
<flacoste> so we'll have to ask when they wake up in Wellington
<matsubara> flacoste, I'll email bigjools about that bug today and will ask for an update in the bug report
<Chex> flacoste: ok, sounds good, thanks for the update
<matsubara> thanks Chex and flacoste (and gary_poster for the heckling demo :-))
<matsubara> let's move on
<gary_poster> :-) np
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> stub sent the report to the list. if you have question it's better to follow up there
<matsubara> I won't paste it here because it was sent to the private list
<matsubara> so let's move on
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> there is no proposed item
<matsubara> anything else before I close?
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:32.
#launchpad-meeting 2011-01-12
<bac> #startmeeting
<MootBot> Meeting started at 09:01. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<jtv> me
<EdwinGrubbs> me
<jcsackett> me
<mrevell> me
<sinzui> me
<adeuring> me
<mars> me!
<jelmer> me
<leonardr> me
<henninge> me
<benji> me
<gary_poster> me? does it matter to wait for the rollcall?
 * gary_poster assumes not
<bac> nah
<gary_poster> cool
<gmb> me
<bigjools> me then
<deryck> me
<flacoste> me
<deryck> me can't resist me
<gary_poster> heh
<bac> gmb:  welcome, i think
<mars> ?
<gmb> bac: ?
<bac> mars: i was about to announce gmb's regrets but i see, do to travel mess up, he's here anyway
<bac> sorry for being cryptic
<gary_poster> heh
<gary_poster> gmb, happy you're around, I think ;-)
<gmb> bac: Ah, yes, forgot to update the wiki page.
<gmb> gary_poster: Thanks, I think ;)
<gary_poster> :-)
<bac> let's do this informal and hopefully speedy today
<bac> there are no new agenda items
<bac> jelmer: a couple of meetings back you volunteered to update the wiki regarding style guide for api_ naming.  did you get to that?
<jelmer> bac: No, I wasn't aware that was one of my action items. I'll do it after the meeting.
<bac> jelmer: there was some confusion.  if you don't mind that would be great.
<bac> [topic] * Mentat update.
<MootBot> New Topic:  * Mentat update.
<bac> * Salgado (ui)
<bac>    * StevenK (code)
<bac>    * Benji (code)
<bac>    * JCSackett (code)
<bac>    * MRevell (ui)
<bac> any comments from the mentats or mentors?  mrevell i saw you got some UI reviews recently
<sinzui> We have had some UI review requests. It could not find mrevell or salgado yesterday to do one
<StevenK> I've not done OCR this week, due to timezones.
<bac> salgado is probably unavailable this week
<mrevell> bac, I'd like a chat about the review I did. sinzui Sorry, I was on calls.
<bac> StevenK: have you been gettin any reviews in general?
<sinzui> I wonder if mentats are missing from the UI review team
 * sinzui looks
<bac> "gettin'"  -- i'm practicing for next week
<StevenK> bac: Er, some. :-)
<jcsackett> i've noticed that reviews have definitely picked back up on my OCR shift.
<gary_poster> EdwinGrubbs is leaving soon, so we should figure out what that means for benji's mentat process
<bac> good point gary_poster
<bac> benji i'd be happy to take over if you'd like
<sinzui> rock needs to add mrevell and salgado to https://launchpad.net/~launchpad-ui-reviewers
<benji> sounds good
<bac> sinzui: i'll ask him to do that.  thanks for the heads up.
<sinzui> We need more admins on that team to ensure we can control who gets the requests for reviews
<bac> sinzui: you, perhaps?
<sinzui> 4 members need to be removed too
<bac> [topic] thunderdome reviewer throw down
<MootBot> New Topic:  thunderdome reviewer throw down
<sinzui> Yes me. I fear rockstar will not com back from U1. I suspect there will only ever be 2 UI reviewers at a time
<bac> reminder, we're going to have a couple of sessions next week about the state of reviews.  if you have comments you'd like to make to me please do so soonish.  i welcome all input
<flacoste> sinzui: rockstart will come back, it's a rotation, not a move :-)
<sinzui> barry
<bac> [topic] other stuff?  open floor.
<MootBot> New Topic:  other stuff?  open floor.
<mars> sinzui, we also have Huw with us now
<flacoste> bac: do we have a wiki page with the list of requested topics
<flacoste> for the thunderdome
<flacoste> i've put two sessions on the schedule to discuss review topics
<bac> flacoste: no, but that's a fine idea.  i'll do it this morning
<flacoste> would be good to have a wiki page so that people can prepare for these
<flacoste> sinzui: barry was the first, and an exception
<StevenK> What do you mean by Thunderdome Reviewer Throw down?
<flacoste> all reviewers gets in, and one gets out :-)
<bigjools> you need to wear body armour
<bac> StevenK: just we've got two 1 hour session scheduled to talk about our review process and how to improve it
<StevenK> Crap
<mars> StevenK, is that an objective opinion? :)
<mrevell> :)
<StevenK> I'll let you know 30 minutes into the first thrown down session
<bac> any other topics?
<henninge> Does anybody disagree if I update the "Python Test Cases" section a bit?
<bigjools> thumper will win
<henninge> https://dev.launchpad.net/TestsStyleGuide#Python Test Cases
<bac> henninge: i guess it depends on what you write.  :)
<jtv> whoo didn't see _that_ answer coming!
<henninge> It still sounds like they are a nice alternative to doctests.
<henninge> whereas nowadays we strongly prefer them.
<gary_poster> bac, we'll figure out what to do about EdwinGrubbs / benji later?
<gary_poster> oh duh
<gary_poster> you said you'd do it
<gary_poster> sorry
<gary_poster> awesome thanks
<bac> np
<henninge> Also, the recommended use of comments in asserts does not match our common practice.
<henninge> We usually don't add comments.
<henninge> Things like that.
<bac> henninge: i think we aspire to have comments in asserts...
<henninge> we do?
<gmb> henninge: You do if I'm reviewing it.
<jtv> I have a suspicion that that note migrated from "assert" to TestCase.assert*
 * gmb removes grumpy trousers, goes back to sitting in the corner.
<gmb> ... that sounded better in my head.
<flacoste> bac: i think we don't do comments much nowadays because of testtools awesomeness
<StevenK> Bwahaa
<flacoste> many assetions method build a decent comment automatically
<henninge> flacoste: that's what I thought
<jtv> AIUI we always required a failure string for "assert" in regular code.  As flacoste says, TestCase.assert* is usually better at composing messages for tests.
<henninge> In fact, I was once asked by reviewer (in my early days) to remove the comments because of that and never has anybody asked me to add them.
<bac> flacoste: good point
<henninge> ok, I'll update that.
<bac> henninge: thank you.
<bac> any other topics?
<StevenK> Bring on the epic!
<jtv> "Long-winded, old story characterized by the absence of character development"?
<bac> ok, see you next week.  bring a sweater.
<bac> #endmeeting
<MootBot> Meeting finished at 09:21.
<jelmer> :-) thanks bac
<StevenK> A? I think bring 2 or 3
<bigjools> s/epic/thunderdome/
<jtv> I volunteer to be the sweaterâI can go right back to the tropics.  âº
