#launchpad-meeting 2008-05-28
<mrevell> ning!
<bigjools> moo
<barry> #startmeeting
<barry> tbot
<barry> hello everyone and welcome to this week's ameu reviewers meeting.  who's here today?
<BjornT> me
<bigjools> me
<EdwinGrubbs> me
<sinzu1> me
<bac> me
<sinzui> me
<allenap> me
<flacoste> me
<gmb> me
<schwuk> me
<flacoste> salgado is on leave
<BjornT> intellectronica is also on leave
<barry> danilo_: ping
<barry>  * (Julian) Since I seem to be finding it hard to get my Soyuz comrades to follow our own informal coding standards, when reviewing Soyuz code please make sure you don't let code of the form: ` if archive.purpose == ArchivePurpose.PPA:` land, instead it should be the simpler: `if archive.is_ppa:` which not only encapsulates the decision in IArchive, it should remove an import of the DBEnum.
<barry> erg
<bigjools> ahem
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>    * Help people learn how big branches can be split up (BjornT)
<barry> * (Julian) Since I seem to be finding it hard to get my Soyuz comrades to follow our own informal coding standards...
 * barry sighs
<barry>  * Next meeting
<barry> everyone okay with week += 1
<bigjools> yep
<barry> anybody know you'll be sprinting or away?
<barry>  * Action items
 * barry had an action item to communicate our multiline guidelines
<barry> i've updated PythonStyleGuide and will send an email to the list after this meeting
 * schwuk reads the updated wiki page
<barry>  * barry to solicit ideas to better handle review scheduling and workload
<barry> FAIL
<statik> me (sorry I'm late)
<barry> schwuk: i welcome yours (and everyone's) feedback!
<barry>  * flacoste to add `safe_hasattr()` to `lazr.utils`
<barry> flacoste: ?
<flacoste> i still suck, please keep it
<barry> k
<barry>  * bjorn to add recommendation to test style guide saying don't use asserts in doctests
<barry> BjornT: ^^
<BjornT> oops, not done
<barry> BjornT: np, we'll keep it on the agenda
<barry>  * Queue status
<barry> it's week 4 so a light week for branches i think
<barry> EdwinGrubbs: how's that adeuring branch going?
 * bigjools has got a corker Soyuz branch coming up today
<EdwinGrubbs> barry: I was waiting for the dependent branch to be finished being reviewed.
<schwuk> EdwinGrubbs: is that the hwdb one?
<EdwinGrubbs> yes
<EdwinGrubbs> is that done?
<schwuk> If so, -1 has just gone to merge-conditional* and it's waiting on sinzui's attention.
<schwuk> However I'm sure we'll revisit this branch in BjornT's agenda item...
<barry> EdwinGrubbs, schwuk thanks
<barry> we have 3 other ping branches: reviewers = flacoste, jtv, allenap
<flacoste> barry: mine is done
<barry> s/ping/pink/
<barry> flacoste: excellent, thanks
<flacoste> need to update the status
<allenap> doing that one today, sorry gmb for being slow.
<barry> allenap: thanks
<barry> anything else on the queue status?
<gmb> allenap: I hadn't noticed through the Ubuflu fog.
<allenap> gmb: Get well soon, but not before I've done your review.
<gmb> Thanks, I think.
<barry>  * Mentoring update
<sinzui> schwuk: I'll follow up  your review today while I lobby for an RC.
<barry> since it's week 4, if you have any recommendations for graduations or recruits, send them my way
<bigjools> I did one for jml at UDS but otherwise it's been lean for me this cycle because of UDS and holidays
<barry> other than that, any comments from mentors or mentorees?
<barry> bigjools: that's my impression too
<bigjools> barry: I'll get some done next Monday
<schwuk> Not really, although week 3 was kind of lean for me (apart from the hwdb branch) as people tend to prefer non-mentored reviews. Especially on Friday :)
<barry> bigjools: cool.  sorry i wasn't ocr this monday; us holiday
<barry> schwuk: of week 3, eh? :)
<bigjools> I seek out mentored reviews if it's not urgent - I get the benefit of two pairs of eyes
<barry> schwuk: but really, we need to make sure mentorees have enough branches to review
<bigjools> barry: no problem re: ocr, I was at UDS anyway
<barry> cool
<barry> any other mentoring updates?
<barry>  * Review process
<barry>    * Help people learn how big branches can be split up (BjornT)
<barry> BjornT: i know we talked about this a few weeks ago, but i don't think we came up with anything specific.  any new thoughts on this?
<barry> guess not :)
<BjornT> no, no new thoughts from me. my proposal is still to require people submitting too large branches, to go through them with a reviewer, to see how it could have been split up.
<schwuk> Pre-implementation calls are the killer here - case-in-point abel's current branch which a) didn't have one and b) is huge.
<bigjools> schwuk: my thoughts also
<schwuk> It also doesn't lend itself well to being chunked for review.
<bigjools> is he even aware of the size restriction?
<BjornT> except that pre-implementation calls don't always happen...
<bac> schwuk: but abel did split his work up.  his problem was submitting all of the parts for parallel review.
<bac> schwuk: albeit he split them after the fact, to your point
<schwuk> bac: yes
<schwuk> and I'm -1 on that sort of splitting as context can be broken
<schwuk> e.g. he had comments referring to a function that wasn't implemented in the branch I was reviewing.
<gmb> schwuk: What if one reviewer reviewed the chunks in series?
<bac> schwuk: ok, that's nasty
<bigjools> oy
<gmb> schwuk: So the big branch is split into chunks a, b and c, which you agree ahead of time to review.
<schwuk> However in his defence, it's very difficult to fit a whole new feature into 800 lines, but he should have had a pre-imp call to chunk the work more.
 * BjornT thinks it would be best to limit this discussion to how we can get people to try to split up the work, not how to actually do the splitting
<sinzui> Bjorn +1
<bigjools> insist on pre-imps
<BjornT> i also don't think pre-imp calls is the answer here. they are good, but we've tried to require people to have pre-imp calls before, and it didn't work.
<schwuk> gmb: no agreement was made (by me). From my perspective he made the branch, chunked it and submitted it concurrently
<BjornT> bigjools: how?
<barry> BjornT: it still doesn't work.  pre-imps are rare ime
<bigjools> BjornT: well some time ago I thought they were made mandatory by Steve
<gmb> bigjools: I don't see how we can enforce them.
<BjornT> bigjools: yes. and that didn't work.
<bigjools> jeez
<gmb> I nearly *always* forget to have a pre imp (though I often have mid-imp sanity checks).
<BjornT> bigjools: that's why "people should have a pre-imp call" isn't a good answer.
<sinzui> I think a small plan is required before coding can start. Another developer must agree to the plan
<bigjools> so are we to wipe everyone's bottoms for them too?
<flacoste> BjornT: i think it's our responsibility as team leads to ensure that people do pre-impl
<BjornT> if we can find a way to really get people to have pre-imp calls, than that's fine.
<gmb> sinzui: But again that's an enforcement issue, isn't it?
<flacoste> we can check that up in the daily standup
<flacoste> did you have your pre-impl call?
<BjornT> flacoste: sure, that's a good point.
<BjornT> i still think that it's really useful to go through a real diff, though.
<flacoste> so if somebody didn't have a pre-implc call, blame the team lead
<sinzui> gmb: If part of the cover letter is written during the plan, it might be doable. That is to say. the pre-imp has a deliverable that we can track
<flacoste> sinzui does this
<flacoste> and it works well
<BjornT> it's easier to learn going through a diff, than to just talk about the problem.
<gmb> sinzui: But you've still got the "whoops, I forgot, sorry, review-it-anyway please, kthxbye" factor.
<sinzui> gmb: That is true, there is also the critical branch that even I skip the implementation plan
<gmb> Right.
<barry> i also think reviewers need more latitude to kick a branch (or several branches) out of the review queue if they are not organized well and/or didn't have a preimpl
<sinzui> gmb: We want best practices, not dogma
<flacoste> agreed
<gmb> Also true.
<sinzui> We need better planning, but we don't need to require planning to the point of unprodictivity
<barry> sinzui: true
<bigjools> I think this should be brought up at the team meeting
<bac> barry: you mean remove not just reject?  i did that yesterday but didn't feel like there was much precedent.
<schwuk> barry: You're right. There's (unseen) pressure to review a branch even if it exceeds the line limit or hasn't been pre-imp'd.
<bigjools> then it will have more weight
<schwuk> Maybe we do need to kick more branches out.
<barry> bac: yes
<bac> barry: +1
<barry> reject if you can't get to it, but remove (with an email) if there are fundamental problems with the branch
<barry> if there are questions, contact me and we can decide together
<bac> perhaps, for a bit, we can set all branches with no pre-imp to 'needs-reply' where the developer has to explain why they didnt' do a pre-imp.  it might then sink in.
<barry> our time as reviewers is limited and valuable and we should not be spending time on branches that really weren't ready to code
<flacoste> bac: i think that would only introduce more dealys
<flacoste> in the process
<barry> since that reduces our productivity and thus the productivity of the entire team
<schwuk> How about peer review? If a pre-imp call doesn't happen (for whatever reason) then the code should be reviewed by a peer (i.e. same team) before submitted for permission-to-merge.
<flacoste> lack of pre-impl is only a problem if it is a problem
<flacoste> if the code is easy to review
<bac> flacoste: yes it would.  but you're trying to change culture and that may require some temporary pain
<flacoste> who cares that it didn't have a pre-imp
<BjornT> bac: i don't think that will help. people already have to "explain" why the branch is large. and the answer is usually, "sorry, it couldn't be split up".
<bigjools> schwuk: particularly with junior/new team members
<bac> BjornT: :) ok, so you got me there
<barry> flacoste: i agree, plus a "pre-impl" call can be fairly liberal for easy branches or fairly indepth for complicated branches
<BjornT> a pre-imp call can also slow you down sometimes. that's why i don't what to require it.
<barry> maybe we need a buddy system for new devs or devs having persistent problems with this?
<flacoste> that's a nice idea
<sinzui> buddy-buddy live?
<barry> e.g. i'm buddying abentley when thumper isn't around.  we don't talk often, but he knows he can always ping me with questions
<barry> flacoste: do you think buddying by default with your team lead is a good idea, or should it be a non-superior peer?
<flacoste> barry: i don't know, i think team leads are fine, but i may be biased here :-)
<barry> :)
<bigjools> In the Soyuz world, we've buddied Muharem and it's worked well
<barry> bigjools: cool.  can you provide some details?  e.g. was he buddied by one person, the whole team?
<bigjools> well there's only three of us, so Celso and I took it in turns
<bigjools> because Soyuz is so complicated it's kinda necessary anyway, we still check his landings to make sure nothing awry is going on
<schwuk> BjornT: I don't think pre-imp calls should be mandatory for the same reasons as you, but I do think that a large branch without a pre-imp call should be flagged.
<bigjools> schwuk: instadeath to large branches with no pre-imp
<BjornT> yes, so let's back up a bit
<barry> bigjools: +1 to that
<BjornT> let's say that someone submits a branch that is too large
<BjornT> what should happen?
<bigjools> firstly, reject. secondly, get someone to explain how it could be split
<sinzui> I think sending a summary of what you intend to do ï»¿for sign off will suffice in many cases. If there are concerns, a call is needed.
<barry> reject.  send email to dev and their team lead
<flacoste> yeah, that's good
<BjornT> sinzui: what do you mean by "what you intend to do"?
<flacoste> i think he's talking about the cover letter
<flacoste> as a pre-impl artefact
<BjornT> right. that's what happens today, isn't it?
<flacoste> reading the email, you can tell, yes that's fine, no call needed
<flacoste> BjornT: only in sinzui's case
<sinzui> This is what I started yesterday for a plan:https://pastebin.canonical.com/5582/
<flacoste> he's talking about writing the cover letter before doing the implementation
<flacoste> and have that letter be sanity-checked by someone else as part of the pre-impl phase
<sinzui> I need to know how to test and where to code change points are still.
<BjornT> flacoste: ok. how do you do that, after you've submitted the branch for review? ;)
<flacoste> right, that's a separate process :-)
<BjornT> flacoste: yes. i'd like us to limit the scope of the discussion a bit :)
<BjornT> 17:38 < BjornT> let's say that someone submits a branch that is too large
<BjornT> 17:38 < BjornT> what should happen?
<flacoste> i think bigjools and barry suggestions were very good
<BjornT> +1 to bigjools, since that was basically my original proposal
<schwuk> < barry> reject.  send email to dev and their team lead
<bigjools> yup
<schwuk> BjornT: who is the someone though?
<schwuk> The reviewer, or the team lead?
<bigjools> team lead I think
<bigjools> reviewer is already busy
<schwuk> bigjools: that was my thought as well
<flacoste> ?
<flacoste> someone is the developer in that sentence
<barry> flacoste: that's what i thought too
<flacoste> a developer submits a branch that is too large
<BjornT> well, all team leads are reviewers, so there should be a greater chance of finding a reviewer that is free
<flacoste> action: reviewer rejects the review emailing the dev and his team-leads
<bigjools> flacoste, barry: we're talking about who to ask to discuss the large branch with the dev
<flacoste> ok, i get it
<schwuk> too many someones...
<flacoste> yeah, i'm sure the team lead can help the dev or find somebody to help him out
<BjornT> i think it doesn't matter who you discuss the branch with, as long as an e-mail is sent to the list, with the result. then other people can chime in as well.
<bigjools> in fact, yes, anyone else in the team, not just the lead
<flacoste> that's unless the dev happened to fall on a friendly reviewer like sinzui who's always willing to help you split your branches :-)
<sinzui> I suck as saying No
<barry> right :)
<barry> oops, we're out of time and have one more item
<barry> apoligies for going over
<barry> i like this idea, and we should flesh it out on the ml
 * barry will start the discussion going
<barry>    * (Julian) Since I seem to be finding it hard to get my Soyuz comrades to follow our own informal coding standards, when reviewing Soyuz code please make sure you don't let code of the form: ` if archive.purpose == ArchivePurpose.PPA:` land, instead it should be the simpler: `if archive.is_ppa:` which not only encapsulates the decision in IArchive, it should remove an import of the DBEnum.
<bigjools> sorry for the long item :)
<bigjools> but it says it all
<barry> bigjools: +1
<bigjools> kthxbye
<barry> that's it from me.  anything else for today?
<schwuk> So do we need domain specific cheat sheets for reviewers?
<bigjools> thanks in advance to the reviewers if you can police this
<barry> schwuk: that's not a bad idea
<bigjools> +1
<barry> links off of TipsForReviewers i think
<bigjools> mwh once started an informal SoyuzReviewerCheatSheet or somesuch
<barry> bigjools: wanna get that started for soyuz?
<bigjools> sure thing
<barry> great, thanks
<barry> okay, that's it then.  sorry for going long
<barry> #endmeeting
<barry> thanks everyone
<schwuk> Thanks barry
<bigjools> thank you
#launchpad-meeting 2008-05-29
<kiko> harken all
<Rinchen> well, let's see if mootbot has recovered
<Rinchen> I think it hasn't
<gmb> 10:1 against.
<Rinchen> #startmeeting
<Rinchen> right then, I know seeker's been working on it
 * gmb wins
<matsubara> me
<Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<abentley> me
<mrevell> me
<Rinchen> Roll Call
<mrevell> me
<gmb> me
<sinzui> me
<Rinchen> me
<barry> me
<bac_> me
<bigjools> me
<allenap> me
<statik> me
<adeuring> me
<jt1> me
<jtv> me
<mthaddon> me
<flacoste> me
<matsubara> me
<thumper> me
<herb> me
<kiko> eu
<Rinchen> SteveA, danilos ?
<leonardr> me
<mpt> meme
<Rinchen> schwuk, ?
<jtv> Rinchen: just pinged danilos
<mpt> me
<schwuk> me
<mars> me
<Rinchen> ah mpt, are you here for the full meeting?
<SteveA> me
<BjornT> me
<flacoste> salgado is on leave, Foundations is complete
<mpt> Rinchen, I think so
<Rinchen> k
<Rinchen> thanks flacoste
<Rinchen> releases is here
<mpt> I just love you guys too much
<Rinchen> rockstar, ?
<rockstar> me
<BjornT> Bugs is here as well. intellectronica is on leave
<Rinchen> cprov-out, ?
<Rinchen> muharem is not here today with a hall pass
<cprov-out> me
<Rinchen> ok, let's get going
<Rinchen> Agenda
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (Matsubara)
<Rinchen>  * Critical Bugs (Rinchen)
<EdwinGrubbs> me
<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> * Numbered experiments and [WWW] https://launchpad.canonical.com/Experiments (kiko)
<Rinchen>  
<Rinchen> Next meeting
<Rinchen> same time, same place, June 5th?
<kiko> +1
<Rinchen> Anyone know they will be absent?
<Rinchen> ok.  If you find out later, please update the agenda
<Rinchen>  
<Rinchen> Actions from last meeting
<Rinchen>  
<Rinchen> None remaining open
<Rinchen>  
<Rinchen> Oops report (Matsubara)
<matsubara> Today's oops report is about bugs 235818, 200572
<SteveA> I'll be absent
<matsubara> danilo, #235818 is for you. Are you going to re-enable relicense translations
<ubottu> Launchpad bug 235818 in rosetta "Relicense translations link broken" [Undecided,New] https://launchpad.net/bugs/235818
<matsubara> in an RC? If not, can you disable the link for the second rollout?
<ubottu> matsubara: Bug 200572 on http://launchpad.net/bugs/200572 is private
<matsubara> flacoste, any news about 200572?
* Rinchen changed the topic of #launchpad-meeting to:  Launchpad Meeting Grounds | Channel logs: http://irclogs.ubuntu.com/
<SteveA> actually, I'll be absent for 2 meetings in a row
<matsubara> danilos: ^
<flacoste> matsubara: no
<matsubara> flacoste: should I add that exception to the "User generated errors" section?
<jtv> matsubara: danilos may be having system problems again.
<matsubara> jtv: ok. I'll chase him after the meeting then. thanks
<flacoste> matsubara: if you can identify them reliably, i guess so, i don't think we have time for this before 2.0
<kiko> matsubara, the first one, for danilo, is already fixed in RF, just landed.
<matsubara> thanks kiko
<matsubara> flacoste: ok. I'll give it try. thanks
<matsubara> anything else shows up in the oops report today, and I'll follow up directly with people
<matsubara> I'm done Rinchen
<Rinchen> Thanks matsubara
<Rinchen>  
<Rinchen> Critical Bugs (Rinchen)
<Rinchen>  
<matsubara> thanks everyone
<kiko> matsubara, I don't see any issue with moving that into UGE
<Rinchen> It seems that we've talked about everything on my list or it has been fixed (thanks flacoste) so I have nothing for this week.
<matsubara> kiko: ok. I'll do that
<Rinchen>  
<Rinchen> Bug tags
<Rinchen>  
<Rinchen> We have 2
<Rinchen> https://help.launchpad.net/TaggingLaunchpadBugs
<Rinchen> matsubara, bughistory
<Rinchen> we'll start with yours first
<matsubara> hmm ok
<matsubara> it's a tag to handle all bugs related to our +bug-activity page
<kiko> +1
<matsubara> actually it's +activity page
<matsubara> and given the number of examples, I think it's worth to have it.
<Rinchen> could we make that generic enough to handle blueprint histories when we get them?
<Rinchen> perhaps just "activity"
<kiko> Rinchen, no.
<Rinchen> or "activityhistory'
<kiko> no
<matsubara> Rinchen: I'd rather keep it bughistory
<kiko> they are completely unrelated -- there is no shared code or anything
<flacoste> well
<mpt> Eventually they might be shared code
<mpt> but not in the short term
<flacoste> one doesn't exists
<matsubara> and then change the meaning to history-logging or whatever when we get there
<flacoste> so i think it's premature
<Rinchen> Sure, I'm ok with all of that.
<Rinchen> Wanted to make sure we thought about it.
<mars> are the issues we will be tagging data integrity bugs, UI bugs???
<Rinchen> BjornT, your comments?
<SteveA> how about "activitypage" ?
<mpt> I disagree with having "page" in the tag name
<mpt> because one of the bug reports is about not showing activity on a separate page at all :-)
<kiko> bughistory
<kiko> this is not about generic activity pages
<BjornT> Rinchen: +1
<kiko> it's about not or incorrectly recording bug history
<matsubara> yeah, i agree with mpt
<Rinchen> ok, we have 2  plus 1s for bughistory
<Rinchen> any against?
<mpt> I'm fine with bugactivity or bughistory
<Rinchen> 3 vs 0
<Rinchen> ok, approved.
<Rinchen> matsubara, please update that page
<Rinchen> kiko, announcements
<kiko> project-announcements maybe?
<kiko> I dunno
<matsubara> will do as soon as we reach an agreement for the second tag
<matsubara> Rinchen: ^
<kiko> I know there are a few bugs related to that and we can't group them easily
<mpt> Is there likely to be any other kind of announcement?
<Rinchen> bac, your comments?
<kiko> mpt, well, hmmm
<kiko> not sure
<Rinchen> In this case, I'm +1 for this tag which I won't go into here
<mpt> I guess the bet is, will any other kind of announcements be introduced *and* need its own tag, before mass tag-renaming is implemented :-)
<kiko> I'm +1 too
<kiko> just not sure about the name
<mpt> If not, it can just be "announcements"
<kiko> but this is a specific feature, project and distro announcements
<kiko> I feel announcements is a bit too generic a term
<Rinchen> kiko, project-announcements ?
<kiko> but that's a mild feeling not a strong thing
<kiko> that's what I suggested
<kiko> <kiko> project-announcements maybe?
<Rinchen> ok, 2 for that. Any objections?
<matsubara> if we're sticking a project- on it how about project-news ?
<kiko> sure
<Rinchen> yeah, I'm ok with that as well
<bac_> i'd stick with announcements since that's what they are called in the UI
<kiko> -news is so much shorter.. okay, whatever, official-bug-tags will solve that eh BjornT :)
<kiko> project-announcements it is
<kiko> matsubara, ko do it!
 * Rinchen doesn't tend to get obsessive with the names so long as they don't exclude anything we want to include or are insanely long.
<matsubara> ok. thanks everyone
<Rinchen> ok, approved.
<Rinchen> kiko, please ensure that page is updated.
<Rinchen>  
<Rinchen> Operations report (mthaddon/herb)
<Rinchen>  
<herb> It's been a pretty quiet week. We needed to restart codebrowse/loggerhead a couple of times due to memory utilization. We discussed this last week and I believe mwhudson is aware of the issue.
<herb> Rolled out 1.2.5 yesterday. Went smoothly with 25 minutes of downtime. To the best of my knowledge we haven't heard anything about a re-roll. Will there be a re-roll with this release and, if so, when?
<flacoste> herb: how is the memory usage of the app servers been going since the max batch size fix?
 * Rinchen notes we should call the 2nd roll-out something other than re-roll :-)
<herb> flacoste: we haven't had to restart them.  they still grow, but the systems haven't been swapping.
<kiko> herb, there will be a re-roll, I was hoping for first thing tomorrow if that's ok with you?
<barry> Rinchen: twotsee-roll
<herb> kiko: no problem.  sounds good.
<mpt> rick-roll
<Rinchen> I was thinking more like a polish-roll   (and in Shiny not the country)  :-)
<kiko> I was thinking polish corridor
<Rinchen> right, anything else for herb?
 * barry likes polish-roll-the-country :)
<herb> Tha's it from Tom and me.  Thanks.
<Rinchen> thanks herb and mthaddon
<Rinchen>  
<Rinchen> DBA report (stub)
<Rinchen>  
<statik> not for herb specifically but I'm curious whether the bzr smartserver we are running now supports protocol3
<Rinchen> stub's not here
<Rinchen> so I'll ask for the DBA report via email
<kiko> statik, we are still on 1.3 on the codehost
<statik> kiko: thanks
<Rinchen>  
<Rinchen> Sysadmin requests (Rinchen)
<Rinchen>  
<Rinchen> Is anyone blocked on an RT or have any that are becoming urgent?
<kiko> jml wants to upgrade the codehost code but not bzr -- bzr will upgrade on monday in RF
<statik> kiko: that will give us stacked branches and the new network protocol, eh? very exciting
<Rinchen> ok, nothing heard...moving on
<Rinchen>  
<Rinchen> New packages required (salgado)
<Rinchen>  * A top user-affecting issue (mrevell)
<Rinchen> er
<kiko> statik, yes, very
<Rinchen> salgado is not here
<Rinchen> please talk to him if you have any packages that you need added
<Rinchen>  
<flacoste> or me
<Rinchen>  top user-affecting issue (mrevell)
<Rinchen>  
<mrevell> :)
<mrevell> This week, the outstanding issue has been the on-going discussion on launchpad-users of how we work to prevent the use of Launchpad accounts for spamming purposes.
<mrevell> However, as we're looking into solutions I'm not sure there's much to discuss here. Otherwise, it seems we've had a relatively quiet week, user-issues-wise
<kiko> mrevell, Rinchen, SteveA and I had an interesting call about this
<kiko> Rinchen, can you remind us of the interesting ideas SteveA had
<Rinchen> there were to proposals
<SteveA> we may end up doing what facebook does
<kiko> there were from proposals too
<kiko> right
<SteveA> and using capchas for each and every interaction that causes information to be seen by other users
<kiko> if you haven't validated you get captcha-annoyance at every step
<SteveA> until someone validates their account
<SteveA> and there may be many ways of validating an account
<kiko> flacoste, you got that? it might be foundations 2.0+
<kiko> one way of validating an account is to sign the coc!!
<SteveA> including associating it with a mobile phone sms number
 * kiko snickers
 * Rinchen can't receive sms
<SteveA> or being part of the strongly connected GPG group
<SteveA> or whatever
<sinzui> Rinchen: That is sooooo 1990s
 * Rinchen is part of a strongly connected GPG group. :-)
<mrevell> Would it be churlish to mention the stories of teams of people paid to fill-out captcha forms?
<SteveA> Rinchen: then... YOU LOSE ;-)
<Rinchen> sinzui, blame it on T-Mobile
<kiko> I can receive sms but not from the USAAAA
<kiko> mrevell, not for every single step, I doubt they do that
<flacoste> my mobile is turned-off in a drawer unless i travel
<Rinchen> anyway.....
<kiko> the captcha farm myth probably only applies to account registration captchas
<mrevell> Right
<kiko> not for every step I take captchas
<kiko> the police captchas
<SteveA> every move I make capchas
<Rinchen> So to recap, we have a few proposals that we are interested in evaluating further.
<SteveA> we'll be watching you
<bigjools> captcha in a bottle
<kiko> that's so 1984
<mars> SteveA, the GPG web of trust tie-in is interesting
<Rinchen> mrevell, anything else? SteveA, anything else?
<flacoste> since most data is seen by other users, it's basically a captcha on every form...
<kiko> mars, tie-in being a pun there?
<mrevell> Rinchen: that's all from me, thanks
<SteveA> nothing else from me
<Rinchen> thanks
<kiko> flacoste, yes, simpler that way too
<Rinchen> Doc Team report (mrevell)
<flacoste> LaunchpadEditForm-voodoo
<kiko> doc team!!!
<mrevell> Hello!
<mrevell> Although the doc team meeting last week was a wash-out, we've had another member sign up and offer to do German translations!
<mrevell> I'm particularly excited about that, but the chap does warn that he's a touch rusty.
<mrevell> In other doc news: Had a useful meeting with Mark S and the SEM designer, Gavin, on Tuesday. Tour is progressing well. Thanks to those who've sent comments on the inner page graphics.
<mrevell> Thanks also to those who've given comments on the release announcement. I'll deal with those after the meeting.
<mrevell> Later today, Elliot and I will be recording episode 3 of the podcast.
<mrevell> Thanks Rinchen
<Rinchen> thanks mrevell
<Rinchen>  
<Rinchen> Numbered experiments and [WWW] https://launchpad.canonical.com/Experiments (kiko)
<Rinchen>  
<kiko> hello hello
<SteveA> I like this
<kiko> I put that wikipage up
<kiko> because I'd like us to record the experiments we run
<SteveA> thanks kiko!
<kiko> and at least detail what the experiment is and what the outcome was
<kiko> the experiments are sequentially numbered and it's FCFS based on wiki edit
<statik> very nice
<kiko> so if you want to, say, experiment by right-aligning all form elements in a specific launchpad form
<kiko> (which is a pretty bad idea)
<kiko> you add an entry to that page and call it experiment n+1
<kiko> where n is the last experiment recorded there
<mpt> Result: mpt chased you with a cheese grater
<Rinchen> I like this too. I'd like to request that the outcome be documented somewhere of course (on the wiki page associated with the experiment for example)
<kiko> there you go
<kiko> now I need a candidate to fill out LP001
<kiko> who's that gonna be
 * Rinchen raises flacoste's hand.
<mars> kiko, I gather that's process experiments as well, like Foundations cycle planning?
<kiko> mars, yes.
<kiko> it's basically any experiment
<Rinchen> I think flacoste could doc up planning poker :-)
<flacoste> Rinchen: yeah, Foundations will come up with one, don't know it will be the first one though
<flacoste> Rinchen: well, that experiment is over
<kiko> you can do retroactive entries there too
<Rinchen> :-)
<flacoste> ah, then that could be it
<Rinchen> I was going for something easy
<kiko> there you go
<kiko> please run experiments
<kiko> and please record them there
<kiko> experiments are fun and cheap
<Rinchen> experimentation is good
<Rinchen> so long as nobody gets hurt
<Rinchen> kiko, anything else?
<Rinchen> on this topic
<kiko> no
<Rinchen> k
<Rinchen> I have a last minute addition
<kiko> secret topic?
<Rinchen>  
<Rinchen>  
<Rinchen> Storm n you (kiko)
<Rinchen>  
<kiko> aha
<kiko> I knew it!
<kiko> so
<barry> bigjools: did you want to bring up the big branch topic?
<kiko> jamesh is struggling with quite a few of our tests
<kiko> and has been so for the past week or two
<kiko> I've asked him to do a full run of all tests and figure out how much is failing
<kiko> but it is getting close to the point where I am going to move devel focus over to storm
<kiko> this will make edge much less useful
<SteveA> a bold move, kiko
<SteveA> I support it
<kiko> and also commits us to doing the work to make storm work in a very short period of time
<kiko> so if you are a launchpad engineer
<flacoste> why edge will be less useful?
<kiko> and if you are a team lead
<kiko> then you may need to prepare for a few days interruption to fix any remaining tests
<barry> kiko: anything we can do to help?
<kiko> barry, yes, very soon, fix the tests which fail with storm
<barry> kiko: cool.  that'll be fun
<kiko> flacoste, because we'd not update edge until all the tests actually passed in-tree
 * Rinchen questions barry's idea of fun.
<BjornT> kiko: do we have a list of tests that fail?
<flacoste> i don't understand how this will work
<kiko> this can be very disruptive; we're not sure how much, but if it's a mess we'll need to figure out what to do with 1.2.6
<flacoste> we'll close PQM?
<mars> or we will focus PQM on Storm integration?
<flacoste> i mean, the test suite pass or doesn't pass
<flacoste> there is no way to land if the test suite doesn't pass
<kiko> flacoste, no, but we'll either disable all failing tests and merge
<mthaddon> I'm assuming we'd keep PQM open, but would be working on the storm integration branch instead of devel
<kiko> or work on the storm integration branch
<kiko> mthaddon, doesn't that require all tests pass?
<mthaddon> kiko, it does, but it's up to you however many of the tests you want to enable - can do it progressively, or all at once
<kiko> BjornT, not yet, but james will produce one. I'm hoping it's 30 not 150
<flacoste> kiko: if problematic tests are disabled to allow some merge to go, that doesn't help keep the focus on storm
<kiko> if it's 150 then it's a no-go
<kiko> so we'll see
<kiko> mthaddon, gotcha
<Rinchen> what I'm hearing is merging storm integration with devel and fixing it so everything passes. Until then, edge won't update.
<kiko> flacoste, it's not "some merge" it's the storm merge onto RF
<kiko> Rinchen, yes
<Rinchen> a bold move indeed
<BjornT> kiko: ok should we make an effort into finding performance regressions as well?
<kiko> BjornT, yes, though to me that's second priority
<flacoste> mars produced a script for that
<BjornT> kiko: or rather, how much of an effort should we make
<flacoste> but jamesh never give feedback on it
<Rinchen> mars, I saw that spec and script. I meant to ask about that.
<kiko> BjornT, it's serialized -- once your tests pass, you can look at that
<mars> flacoste, yes, but it needs a kind soul to try it out
<kiko> flacoste, I think jamesh is stuck before that point
<flacoste> i don't think so, all page tests run
<flacoste> and this analyze the log file of the page tests
<kiko> doctests don't
<BjornT> flacoste, mars: does the script use existing sample data?
<kiko> flacoste, sure, but jamesh is only one bold soul
<mpt> Would it make sense to have a ratchet, so that storm can land while tests are still failing, but you can't make any further landing that increases the number of failures?
<mpt> that would help keep the focus
<kiko> mpt, too complex to add at this point, though interesting
<kiko> flacoste, he won't look at perf regress until he's got all the tests running
<mars> BjornT, it compares the access logs for two runs, so you can benchmark storm-storm, or storm-trunk
<kiko> anyway
<kiko> I don't want to run overtime, but I also think we need to be serious about the move and help us acheive what we set out to do
<kiko> storm is the future
<flacoste> anyway, this introduce more uncertainty in the 1.2.6 planning
<kiko> flacoste, yes, I noted that up-front. we have some buffer time.
<flacoste> no we don't :-)
<kiko> be brave!
<kiko> we do at my discretion only ;-)
<BjornT> mars: so i can create a bunch of data, access a few pages, and compare the result?
<kiko> Rinchen, feel free to wrap up, people are going to start asking me complicated questions now
<Rinchen> ok, time to wrap up now that the storm is over :-)
<flacoste> BjornT: yes
<mars> BjornT, yep
<BjornT> cool
<Rinchen> ok then... what an eventful chat
<kiko> AH!
<cprov> very cool !
<Rinchen> please ensure any of your absent team members read the log
<kiko> one thing I can provide for you to look into
<kiko> oh damn, it's in my xchat log
<kiko> one sec
<kiko> on devpad: ~jamesh/errors-systemdocs.txt
<kiko> that's the failures accumulated in doc/*
<mars> Rinchen, should we stick around after the meeting end to pepper kiko with questions? :)
<Rinchen> mars, you can!
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting.
<Rinchen> == the end ==
<kiko> == snif ==
<Rinchen> on time photo finish
<sinzui> _consider me gone_
<SteveA> thanks!
<Rinchen> Ok __sinzui__
<mrevell> thanks
#launchpad-meeting 2010-06-02
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> hi, and welcome to the launchpad reviewers meeting
<bac> who is here today?
<EdwinGrubbs> me
<sinzui> me but I am not really in my head yet
<henninge> me
<abentley> me
<BjornT> me
<deryck> me
<gary_poster> me
<jelmer_> me
<jtv> me
<leonardr> me
<mars> me
<bac> noodles775, jelmer_: ping
<bac> sorry jelmer_
<bac> gmb: ping
<bac> team leads would you round up your strays?
<gmb> me
<noodles775> me
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac>  * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * Mentoring update
<bac>  * New topics
<bac>    * Schedule shuffle
<bac>    * Reminder about policy for reviews and landings from external contributors. Making sure the "lander" is recorded is a Good Idea. [henninge]
<bac> [topic] outstanding actions
<MootBot> New Topic:  outstanding actions
<bac> * bac to define new doctest policy regarding what is "testable documentation".
 * bac didn't do anything last week.  roll.
<bac> on that note, i apologize for the very late cancellation of this  meeting last week.
<bac> [topic] * sinzui to talk to QA about our QA tracking problem and create a proposal on the mailing list
<MootBot> New Topic:  * sinzui to talk to QA about our QA tracking problem and create a proposal on the mailing list
<henninge> bac: np
<abentley> bac, I could take a run at the "testable documentation" thing if you like.
<sinzui> That is stalled
<bac> sinzui: ok.
<bac> abentley: thanks.  let's talk later today.
<abentley> bac, sure.
<bac> [topic] * Schedule shuffle
<MootBot> New Topic:  * Schedule shuffle
<bac> due to some personel changes we've had holes in our schedule
<henninge> bac: you skipped the Mentoring update ;-)
<bac> henninge has agreed to move to Monday/EU
<henninge> yup
<bac> thanks henninge
<bac> mars and leonardr have also agreed to start doing OCR again, sharing a shift.  they will alternate OCR on tuesdays.
<bac> to accomodate them i'm moving to take the friday shift
<bac> with those changes we have pretty good daily coverage again
<bac> thanks to everyone for being flexible.
<bac> [topic] * Ursinha's comments on orphaned commits after last week's meeting. [henninge]
<MootBot> New Topic:  * Ursinha's comments on orphaned commits after last week's meeting. [henninge]
<henninge> oh, a new topic.
<henninge> ;)
<henninge> bac: isn't that what sinzui's action item is about?
<sinzui> it overlaps
<bac> henninge: is that item a leftover?
<bac> sinzui, henninge: yes, it looks like it can be rolled into one
<henninge> well, she commented on the orphaned commit discussions, I summarized on the agende page.
<sinzui> bug numbers, qa tags, and kanban is my broad topic that needs team leads to provide a clear process
<bac> [topic]  Reminder about policy for reviews and landings from external contributors. Making sure the "lander" is recorded is a Good Idea. [henninge]
<MootBot> New Topic:   Reminder about policy for reviews and landings from external contributors. Making sure the "lander" is recorded is a Good Idea. [henninge]
<henninge> ok, I prepared that ...
<henninge> Because it just came up, I want to remind everybody to please require external contributors (community, but also non-LP afaik) to have had a pre-imp with somebody from the relevant team.
<henninge> Unless, of course, you are on that team. ;-)
<henninge> If not, you could either ask the contributor to do that before you start the review or you could pass it off to be reviewed by somebody from that team if he/she agrees.
<henninge> Also, please make sure that your name is mentioned when you land a branch for somebody else. In the case at hand that was not done and the reviewer was not really sure if he did the landing.
<henninge> In an earlier discussion two possible ways to land were mentioned.
<henninge> 1. Create your own branch, merge in the contributor's branch, land that. The commit will obviously mention your name. Here it makes sense to add "landed on behalf of ..." to the commit message.
<henninge> 2. Land the contributor's branch directly, e.g. "ec2 land <mp-url>". Here the landing goes through under the contributor's name and you need to add "landed by ..." to the commit message. (and not "on behalf of")
<henninge> That's all. ;-)
<mars> henninge, for 2., should we also use the --author flag?
<henninge> mars: I don't know about that flag, tbh
<mars> henninge, ok, nm :)
<bac> i'd like to discourage using 2. as it allows for unreviewed changes to slip in
<henninge> oh, right, I remenber that discussion
 * henninge always uses 2.
<Ursinha> gary_poster and I had a conversation yesterday about the orphaned commits
<bac> henninge: thanks for the reminder about pre-imp calls for contributed work.  it really is vital.
<gary_poster> (Yeah, I didn't know when or if to bring that up)
<bac> anything else on henninge's topic?
<bac> gary_poster: wait for peanut galllery...
<gary_poster> :-) +1
<bac> [topic] mentoring update.
<MootBot> New Topic:  mentoring update.
<bac> jelmer_: are you getting a sufficient number of non-soyuz branches?
<jelmer_> bac: Yep
<jelmer_> bac: Last weeks shift was quite busy with other code.
<bac> great.
<bac> [topic] peanut gallery
<MootBot> New Topic:  peanut gallery
<bac> other issues?  gary?
<abentley> I have one.
<gary_poster> thanks
<gary_poster> ok
<gary_poster> go ahead :-)
<bac> abentley: go ahead with yours
<abentley> I'm noticing we're getting some stuff under lp/ that isn't teams.
<abentley> ie lp/buildmaster and lp/poppy.
<abentley> I thought items like that were supposed to go under lp/services.  Am I misunderstanding?
<sinzui> If they are not user visible, I think they are services
<jtv> There's also answers & blueprints of course.
<jtv> So maybe that should be "that aren't tabs"
<sinzui> They are user visible and are applications so they are not services
<abentley> jtv, I could say "applications", I guess.
<jtv> Not that that diminishes your point.
<bac> abentley: well, then that would move registry
<sinzui> Services are expected to be requires by one or applications
<jtv> Didn't we go over this on one of the mailing lists?  ISTRM "coop" as the proposed solution.
<abentley> jtv, isn't that for shared code that is part of applications?
<jtv> True.
<abentley> poppy is an sftp server, buildmaster part of the build farm.
<sinzui> coop is for application-to-application code. cross domain code
<abentley> sinzui, I'm not sure what "they" meant" in "they are user-visible".
<jtv> What I see under lib/lp is all nicely stand-alone stuff.  Maybe we just shouldn't worry about this until it becomes a problem again.
<abentley> jtv, well, it seems weird that the jobs system and the build system are in different places.
<sinzui> is users cannot see poppy, no api, web, rss, I think it may be a service
<jtv> Well, the jobs system is much more generic isn't it?  For instance the build system makes use of it.  So for that, the current structure makes sense to me.
<jtv> I don't know about poppy but buildmaster is a beast that may not fit comfortably in the same cage as worlddata or the jobs system.
<abentley> jtv, "makes use of it" is a bit strong.  There is a bit of model/interface sharing.
<mars> sinzui, abentley, maybe punt to BjornT?  Those systems are interfaces to Launchpad, just not HTTP-based ones.  He can make the call as to which interfaces are at the root of the tree.
<jtv> abentley: Job plays a pretty central role in buildmaster.
<abentley> jtv, it plays a role, but it's an entirely different role to the one it plays in the jobs system.  The equivalent of Job is Build.
<bac> mars: i agree, in discussion with bigjools.
<bac> BjornT: will you take that as an action item?
<BjornT> bac: sure. if someone sends a mail to the list summarizing the issue
<bac> well the issue seems pretty straightforward.  we need a decision about what belongs in lib/lp and if poppy and buildmaster are inappropriate for there where should they move.
<gary_poster> OK, I'm taking that as a "move to next item" marker.
<gary_poster> Ursula and I got an action item both from the reviewers meeting and from the team lead meeting to make orphan branches (those merged to PQM without a bug) "illegal" somehow.  In the team lead call we also talked about handling branches that are incremental branches towards a bug that can't be QA'd individually.
<gary_poster> Ursula and I came up with a solution that we think will address these concerns.  We will send an email to launchpad-dev about this solution.
<bac> [action] Bjornt to set a policy on what can live in lib/lp, lib/services, and lib/coop
<MootBot> ACTION received:  Bjornt to set a policy on what can live in lib/lp, lib/services, and lib/coop
<bac> thanks abentley for bringing it up
<gary_poster> ok, was slightly early :-)
<abentley> bac, np
<bac> gary_poster: done?
<gary_poster> bac, yes, unless you want me to summarize.  The summary takes a while.
<bac> nope
<bac> thanks
<bac> that seems to be it.
<bac> thanks for coming everyone.
<bac> #endmeeting
<MootBot> Meeting finished at 09:30.
<mars> thanks bac
<bac> mars: are you ok with an alternating tuesday OCR slot?
<mars> bac, yes, I discussed that with Gary.  It should be fine.
<bac> thanks
<gary_poster> thank you
<gary_poster> plural you :-)
<henninge> "thank you all" ;-)
<bac> rockstar, thumper: meeting?
<rockstar> bac, sure.
<bac> how's it going rockstar?  progress on the van?
<rockstar> bac, yea, enough progress to know I want to pay someone to do some of the progress...
<bac> :)
<rockstar> bac, body work is hard, so I'm going shopping.
<bac> probably a wise move
<bac> is tim around?  thumper?
<bac> well, i guess not.
<bac> not much happened at the AMEU meeting today.
<bac> abentley brought up the fact that lib/lp is getting lots of new stuff in it and he doesn't think it is the proper location.
<bac> poppy and buildfarmmaster were his two examples
<wgrant> Well, buildmaster needs to become lib/lp/services/buildfarm eventually.
<wgrant> Not sure about poppy.
<bac> wgrant: yeah, moving to services was the idea
<rockstar> wgrant, have you a branch that does that?
<wgrant> rockstar: No. There was also a proposal to remove it from the tree entirely.
<thumper> hi
<bac> we assigned bjornt the task of finding homes for those things and creating a policy for what should live in lib/lp lib/lp/services and lib/lp/coop
<bac> hi thumper
<rockstar> wgrant, what was the reasoning for removing it from the tree?
<thumper> I hate lp.coop
<thumper> it is a stupid name
<thumper> that is why I've not put things there
<bac> yes, i think francis blessed us with that one
<rockstar> thumper, you are so rational.  :)
<wgrant> rockstar: The tree is big, and lp.buildmaster shouldn't really depend on too much.
<bac> the tree is too big.  no more code.
<thumper> I get sad when I see new files in lib/canonical/launchpad
<bac> thumper: yep
<thumper> which I saw a lot of last cycle
<thumper> I've started moving the code security adapters into lp.code.security
<thumper> other teams should do the same
<wgrant> Well, but a bit of stuff has been removed from lib/c/l the last couple of cycles. It's looking better.
<thumper> I also started moving some tales adapters into lp.app.browser
<bac> yeah, we've moved a lot of the JS out, thanks to rockstar's example
 * rockstar does a little dance
<bac> that bug is highly abused, though
<thumper> which bug?
<bac> the one for moving JS.  it gets the full cycle of QA tags each release.
<thumper> ah
<bac> hope two teams never tackle it the same release
<bac> so, y'all have anything new, review-wise?
<thumper> yep
<thumper> during review we should strongly suggest moving code to lp namespace from canonical.launchpad
<bac> it doesn't affect you, but the ameu schedule has been shuffled about to ensure better coverage
<thumper> even if it makes the branch bigger
<bac> [action] bac to discuss moving code out of c/l in AMEU reviewers meeting per thumper's suggestion
<thumper> ta
<bac> oops, i forgot to wake up mootbot
<bac> anything else?
<thumper> I don't think so
<bac> me neither.  you guys have a good day/evening.
<thumper> ciao
#launchpad-meeting 2010-06-03
<henninge> rockstar: did I miss the meeting or is it in 32 minutes?
<henninge> 33
<rockstar> henninge, 1 hour and 33 minutes.
<henninge> oh!
<henninge> rockstar: thanks ;)
<henninge> that's late
<rockstar> henninge, that's the usual time.
<henninge> haven't been there in a while ...
 * rockstar tries to figure out Mootbot
 * gary_poster says "me" too early
<rockstar> startmeeting
<rockstar> Anyone know how to wake up MootBot?
<gary_poster> bac might
<adeuring> use a '#' as a prefix?
<bigjools>  # start meeting
<rockstar> #startmeeting
<MootBot> Meeting started at 11:02. The chair is rockstar.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<rockstar> Hi Mootbot!
<gary_poster> :-)
<Chex> hehe
<rockstar> Welcome to today's (Diet) Launchpad Production Meeting.  Who's here?
<gary_poster> me
<henninge> me
<Chex> me
<sinzui> me
<bigjools> o/
<rockstar> Is this all the teams then?
<adeuring> me
<rockstar> It looks like it.
<rockstar> Okay, let's get started.
<rockstar> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<rockstar> Here's the agenda:
<rockstar> OOPSes and Critical Bugs
<rockstar> Er, dammit...
<rockstar>  * Actions from last meeting
<rockstar>  * Oops report & Critical Bugs & Broken scripts
<rockstar>  * Operations report (mthaddon/Chex/spm/mbarnett)
<rockstar>  * DBA report (stub)
<rockstar>  * QA stats of the week
<rockstar>  * Proposed items
<rockstar> There.
<rockstar> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<rockstar> DONE: Ursinha to open a bug for the failing upgrade_branches script - filed bug https://bugs.edge.launchpad.net/launchpad-code/+bug/586467
<ubot5> Launchpad bug 586467 in Launchpad Bazaar Integration "upgrade_branches script failing (affected: 1, heat: 6)" [Undecided,New]
<rockstar> That's the only action from last week, and it's a bug I can close as "Invalid" so I'm a happy puppy...
<rockstar> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<rockstar> So, matsubara only pointed to two oopses.
<rockstar> https://lp-oops.canonical.com/oops/?oopsid=OOPS-1614C2901 looks like a regression of bug 580181 but on DistroArchSeriesBinaryPackage
<ubot5> Launchpad bug 580181 in Soyuz "DistributionSourcePackageRelease page still oopsing with NotOneError/LocationError (affected: 1, heat: 10)" [High,Fix released] https://launchpad.net/bugs/580181
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1614C2901
<rockstar> bigjools, ^^
<bigjools> noodles is looking into that still
<bigjools> he has a branch
<rockstar> https://bugs.edge.launchpad.net/launchpad-code/+bug/583395 is going to be cherry picked when it's ready.
<ubot5> Launchpad bug 583395 in Launchpad Bazaar Integration "OOPS accessing +new-recipe page not logged in (affected: 1, heat: 6)" [High,Triaged]
<bigjools> waiting for PQM to open
<rockstar> bigjools, okay, thanks.
<rockstar> So, as far as failing scripts, most of them had comments on what's going on.
<rockstar> That's helpful, and I think it provides more transparency than the meeting does.
<rockstar> Moving on...
<rockstar> [TOPIC] * Operations report (Chex)
<MootBot> New Topic:  * Operations report (Chex)
<rockstar> Chex, you have the floor.
<Chex> hello everyone
<Chex> here is the report for this week:
<Chex> - Launchpad Full Production V10.05 was rolled-out on Wednesday morning, Jun-02.  Rollout went well, with
<Chex>         no major problems.
<Chex>  - LP incidents of note:
<Chex>         : May 25 : CP 9346 to cesium
<Chex>         : May 25-Jun 1: several LP App-server memory full restarts needed.
<Chex>         : Codebrowse restarts slowed in past week.
<Chex> any questions or comments for us LOSAs?
<gary_poster> Note that I have plugged *a* appserver memory leak
<bigjools> \o/
<gary_poster> If we get more, I'll need more meliae dumps
<rockstar> Chex, the codebrowse stuff is good news!
<rockstar> Chex, is that all?  Anyone have something for Chex?
<Chex> rockstar: I quite agree! and seems to have held after the last rollout, too.
<Chex> rockstar: but I shouldnt say nary more..
<Chex> gary_poster: yes, seems there is still something else going on with memory, altho less severe
<gary_poster> Chex, well, ...yay for less severe I guess :-/ :-)
<rockstar> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<gary_poster> he sent it via email
<rockstar> stub isn't here.  He sent it to the list.
<rockstar> gary_poster, jinx?  :)
<gary_poster> :-)
<rockstar> Okay, moving on.
<rockstar> [TOPIC] * QA stats of the week
<MootBot> New Topic:  * QA stats of the week
 * sinzui likes the pace of this meeting
<rockstar> Uh, so there aren't any untriaged bug stats, and we don't (hopefully) have any untested stuff.
<rockstar> So let's move on again...
<sinzui> we do on the last
<bigjools> soyuz has one untriaged bug
<rockstar> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
 * rockstar gives bigjools a cookie.
<sinzui> https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=qa-needstesting
<bigjools> yum yum
<rockstar> bigjools, fix that bug, it's your fault ^^
<rockstar> :)
<bigjools>  /o\
<sinzui> https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.searchtext=&orderby=targetname&field.status%3Alist=NEW&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branche
<sinzui> s=on&field.has_no_branches.used=&field.has_no_branches=on&search=Search&batch=100
 * sinzui hates urls with no content
<rockstar> sinzui, E_URL_TOO_FUCKING_LONG
<bigjools> if only we had a way of shortening them
<sinzui> We had a rise in new bugs in part caused by UDS travel
<sinzui> http://tinyurl.com/276ga78
<MootBot> LINK received:  http://tinyurl.com/276ga78
<rockstar> sinzui, I think lifeless's point on the list is a good point.  We have too many queues...
<sinzui> yes
<rockstar> I think that's outside the scope of this meeting though...  :)
<sinzui> The queue here are owned by teams, they should be able to manage themselves
<sinzui> Need I remind you that I found security issues in New bugs when I went through the backlog last year
<rockstar> Ouch.
<rockstar> Anyone else have something for this meeting?
<bigjools> I hope to sort that out soon, Bryce fixed the bug I filed about the security contact being attached to bugs that move projects
<sinzui> We need Ursula report about finding owners for all these projects
<sinzui> mrevell might hate me because I nominated him for 4 of them
<bigjools> then we can have a separate security list
<sinzui> I think malone is still behind, and all others nee owners
<sinzui> rockstar, are we done?
<rockstar> sinzui, I believe so thene.
<rockstar> Thanks everyone.
<rockstar> #endmeeting
<MootBot> Meeting finished at 11:21.
<gary_poster> thank you rockstar
<bigjools> cheers
<sinzui> best meeting ever
<adeuring> cheers
<rockstar> sinzui, if I had my way, I'd take out a few of those topics as well.  :)
<bigjools> I nominate rockstar to run the meeting again
