#launchpad-meeting 2006-08-14
<ddaa> Still missing mpool and Steve
<mpool> hi
<ddaa> Hello
<ddaa> Before the meeting starts
<ddaa> I will have a short week
<ddaa> since I'm on leave starting thursday
<SteveA> I'll not be paying much attention
<SteveA> I'm in UI meetings here today
<ddaa> until the 28th
<ddaa> SteveA: there's one or two points where I think I'll need your attention, but okay
<ddaa> MEETING STARTS
<ddaa> == Agenda ==
<ddaa>  * roll call
<ddaa>  * production status
<ddaa>  * Smart server
<ddaa>  * SFTP advertising
<ddaa>  * vcs-import knits
<ddaa>  * URTF
<ddaa>  * Python import
<ddaa>  * bzr lp://
<ddaa>  * important bugs according to bzr community
<lifeless> hi
<ddaa>  * 1.0 targets, what, who when?
<ddaa>  * critical bugs
<ddaa>  * pending sysadmin tasks
<ddaa>  * any other business
<ddaa> == Roll call ==
<ddaa> ddaa is here
<ddaa> So is Steve
<ddaa> mpool said hi
<ddaa> so did lifeless
<spiv> I'm here
<jamesh> I'm here
<ddaa> Wonderful.
<ddaa> == Production status ==
<ddaa> Nothing new. https://launchpad.net/products/launchpad-bazaar/+bug/53825
<ddaa> jamesh: so, will we get oops from script or do we need a different plan to deal with those errors?
<ddaa> last week you said you'll have a meeting with salgado about that
<ddaa> Mh, apparently not...
<ddaa> == Smart server ==
<ddaa> mpool, spiv: status?
<jamesh> ddaa: I talked with matsubara about it last week.  I don't think we'll have polished infrastructure for it soon, but I could set things up to get simple traceback OOPS reports
<jamesh> ddaa: getting SQL statement logs is a fair bit more work due to differences between webapp and zopeless environments
<spiv> We paired a couple of days on it last week, and have scheduled another day on Wednesday.
<mpool> ddaa: continuing to work with spiv on it; pairing on wednesday this week
<ddaa> spiv: mpool: any delivery estimate, for the non-integrated bit at least?
<spiv> There are a fair few tests that make assumptions about the transport that need tweaking.
<ddaa> jamesh: basically, kiko is your client for that stuff, since he's the one I expect to find the error spam most annnoying first.
<spiv> The plan is to get the last ~30 tests to pass, then start implementing actual smart operations on the new transport.
<ddaa> spiv: think you'll get it up and running on launchpad for 1.0?
<spiv> I think there's probably only a day or so left on getting the tests working, but I'm not sure how quickly it'll progress after that.  I am getting more fluent with the bzrlib code, though.
<ddaa> or is that a post 1.0 feature?
<spiv> When's launchpad 1.0?
<ddaa> end of september
* spiv hmms
<ddaa> spiv: you'll have time to answer that at the end of the meeting
<ddaa> moving on
<spiv> I think it's possible, but I'm not going to commit to that right now.
<ddaa> == SFTP advertising ==
<ddaa> jamesh posted a second draft at the end of the week. I intended to review it friday but got -ENOROUNDTUIT.
<ddaa> Action: ddaa to review jamesh second draft real soon.
<ddaa> spiv: last week you said you'd have a look, did you?
<spiv> I did too.  I haven't looked yet, I'll do that immediately after this meeting and reply.
<SteveA> spiv: two things for the smartserver: running it on the supermirror so that bzr users at large get good network performance with the SM.
<jamesh> I posted the second draft as a followup to the first thread
<SteveA> also, running it on devpad for launchpad use
<ddaa> Would be nice to get that blog posted at the end of the week.
<ddaa> SteveA: if we make the smart server post 1.0, it would certainly be nice to have run on devpad for a while, so it can mature, before putting it on launchpad.
<ddaa> == vcs-imports knits ==
<ddaa> As far as I can tell, it's done. All vcs-imports branches are know knits. But that consumed all my round tuits at the end the week.
<ddaa> lifeless: mpool: I posted two patches to the bzr mailing list, that were needed for that. I would like to have them in rocketfuel shortly after I come back from leave (on the 28th). They are currently a divergence from rocketfuel in the production code.
<ddaa> lifeless: apologies for blowing up on you on #bzr saturday morning
<ddaa> Is that an action for anybody?
<lifeless> blow up at me ?
<ddaa> well, blaming you for turning that rollout into a 12 hours marathon
<SteveA> ddaa: I need to focus on this UI discussion.  I'll read the email summary after this meeting.  Please ping me directly on this channel if there is something I need to contribute to.
<ddaa> SteveA: ack
<SteveA> ta
<ddaa> Okay, moving on. I'd just like some quick feedback on those patch, although I'll probably won't be able to act on it before leave.
<ddaa> == URTF ==
<ddaa> lifeless: jamesh: last week there was some talk about unblocking jamesh with urtf, how did that go?
<lifeless> URTF ?
<ddaa> Upstream Release Tarball Finder, you know...
<ddaa> previously known as Dyson
<jamesh> I'll look at implementing what was discussed this week
<ddaa> jamesh: where can we see the output of that discussion?
<jamesh> I was blocked last week due to sprints, rather than on input from other people
<ddaa> I'd be interested in knowing what's going on with that thing, since I spend so many hours stuffing the db with data for that.
<ddaa> s/spend/spent/
<lifeless> its in the bug
<jamesh> ddaa: https://launchpad.net/products/launchpad/+bug/53698
<ddaa> Thanks
<ddaa> == Python import ==
<ddaa> Last week I was asked to look into the problem with the Python import, that manifest itself as a DNS failure at random points in the middle of the import.
<ddaa> Planned to do so friday. Did not. Bot noticed that other large SVN imports fail in the same way. That's probably our most serious cscvs bug ATM.
<ddaa> Action: ddaa will file bug about that failure, and maybe look at it before going to leave.
<ddaa> Though it's down the list of priorities, so would not like to promise looking at it soon.
<ddaa> == bzr lp:// ==
<ddaa> sabdfl made some noises about that recently, which resulted in some activity.
<ddaa> mpool wrote a spec about the bzr-launchpad integration aspect, I will review it this week.
<ddaa> I put a braindump on the mailing list, but had no feedback. In short it boils down to:
<ddaa> * one attribute: Use ProductSeries.branch both for the vcs-imports branch and for the user specified branch. That leads to model constraints, restrictions for the user, and complication.
<ddaa> * two attributes: Use different attributes, say import_branch and explicit_trunk_branch. That essentially acknowledges that import != series, even though it's stuffed in the same table, and makes things much more flexible.
<mpool> ddaa: yes, would appreciate that
<ddaa> mpool: it's one of the important things for this week, so you can make progress on that while I'm away.
<jamesh> what is the URL of the spec?
<lifeless> speaking of specs
<lifeless> https://launchpad.canonical.com/PrivateBranches is nearly reviewed
<ddaa> mpool and ddaa favor the "two attributes" approach. But that is a sensitive topic, so I would like consensus or word from sabdfl before putting out a proper spec.
<mpool> ddaa: i'm not really qualified to give feedback on the db changes
<mpool> who will be?
<ddaa> SteveA: your attention would be welcome about the db change issue, since it's a loaded issue involving sabdfl.
<mpool> jamesh: https://launchpad.canonical.com/BranchIndirection
<mpool> who else should review either the db or ui specs?
<ddaa> lifeless: talk about that end of meeting
<ddaa> mpool: stub gets to review all db changes
<ddaa> I'm not sure that mpt has much to say about the UI in that case.
<mpool> me either
<mpool> spiv, can you please read it
<mpool> then let's JFDI
<ddaa> JFDI?
<lifeless> JustFuckingDoIt
<SteveA> ddaa: hi
<spiv> mpool: ok
<SteveA> ddaa: what's the question?
<ddaa> SteveA: backlog, just after the == bzr lp:// ==
<ddaa> discussion about changing the db schema to have two branch attributes in ProductSeries
<ddaa> Since I do not have my hands free to with that table as I wish, and since sabdfl seems to feel strongly about it (see SourceSourceRefactoring, last year)
<jamesh> the two attribute solution sounds like the simpler option.
<ddaa> jamesh: certainly, but it's acking that vcs-import != series, and for some reason that appears to be taboo.
<ddaa> No sound technical reason AFAICT
<ddaa> that's why I'm incomfortable about it
<jamesh> ddaa: really?
<lifeless> ddaa: you are uncomfortable because you got what you wanted
<lifeless> ?
<ddaa> I did not get that yet.
<ddaa> But if we have a consensus on using two attributes, great.
<ddaa> I'm happy.
<ddaa> SteveA: thank you
<ddaa> == important bugs according to bzr community ==
<ddaa> mpool: when we had that phone call a couple of weeks ago, I suggested you get feedback from the bzr community about launchpad integration issues.
<ddaa> That would be useful data to have at the beginning of september, can you commit to delivering that?
<mpool> ddaa: on consideration, i think the problem is that integration is just not very visible yet
<ddaa> Mh
<ddaa> Actually, I mean more than just integration of the client with the server.
<mpool> so "what are the bugs in it" may not get good results
<ddaa> I also mean things like the UI to the branch registry, bug branches, sftp server, tec.
<mpool> ddaa: what question are we trying to answer?
<ddaa> s/tec./etc./
<SteveA> network problems
<SteveA> back
<ddaa> The question is: "what are the bugs or features that the bzr community as a group appears to desire the most"
<SteveA> ok
<SteveA> ddaa: on the issue you asked me about
<ddaa> As an help to prioritizing tasks.
<SteveA> ddaa: if we go for 2 table fields now, can it be collapsed into 1 later with a simple database update?
<ddaa> SteveA: not really
<ddaa> it's adding degrees of freedom to the system
<jamesh> ddaa: I'd think it would be pretty easy: "update productseries set user_branch = import_branch where user_branch is NULL" then remove the import_branch
<ddaa> jamesh: it's not enough
<ddaa> jamesh: let's talk about that after meeting
<jamesh> okay
<ddaa> ACTION: jamesh and ddaa to come agreement about db change for ProductSeries
<mpool> ddaa: i think we should just decide
<mpool> and then perhaps ask for suggestions
<ddaa> well, I'd certainly not let user whims be the only factor in deciding
<mpool> i'll try to give you a list before you leave, and then we can continue
<mpool> if we start showing that we're shipping features there, people will suggest more
<ddaa> but since I'm not going to decide on anything before september, asking the community might be a good use of the time until then.
<mpool> why?
<ddaa> because I'll be only leave
<mpool> oh, from this weekend for two weeks?
<mpool> ok
<ddaa> and because I have my hands very full for this week w/o dowing planning
<ddaa> s/dowing/doing/
<ddaa> moving on
<mpool> btw it looks likely that someone new will be starting here in september, also working on lp bzr features
<mpool> ddaa: ok, in that case i'll work on it but less urgently
<mpool> and talk to spiv, steve, mark, robertc, etc
<ddaa> that's not what I consider the "bzr community", but okay
<ddaa> Let's move on.
<ddaa> == 1.0 targets ==
<ddaa> I'm a bit unclear on what is everybody's target for Launchpad 1.0 (end of september).
<ddaa> For me: I think it was bzr transition. But I'm thinking of delaying the Arch support removal until we have the new hire. That would be a good exercice to get him acquainted with a lot of the code.
<ddaa> Everybody else: What are your Launchpad 1.0 targets?
<mpool> i know it's not
<mpool> hm, let's talk about that afterwards
<spiv> My Launchpad 1.0 target is the smart server on the supermirror.
<ddaa> ACTION: ddaa mpool talk about gathering planning input
<ddaa> spiv: sounds like a challenge
<spiv> Yeah.  Achievable, I think.
<ddaa> mpool: bzr-roundtrip-svn is marked 1.0 too
<spiv> The integration with the supermirror will be a couple of days effort, I think, not much.  The main issue is having a smart server in the first place :)
<ddaa> what's the status of that, last we talked about it, you were about to have a call with mark about using jelmer's stuff without supporting it explicitly in launchpad IIRC.
<SteveA> spiv: +1
<ddaa> lifeless: from your interest, I also gather that tracking-versions is 1.0, is it?
<ddaa> it's not marked as such in the spec tracker
<lifeless> its as soon as it can be done
<lifeless> I dont know what makes something a 1.0 feature
<ddaa> AFAIK, sabdfl makes things 1.0 features
<lifeless> so, then its probably not a 1.0 feature
<lifeless> but its still as soon as possible ;)
<ddaa> mpool: about bzr-roundtrip-svn?
<mpool> ddaa: i had a call and i sent a mail reporting the result
<mpool> i'm sure you were cc'd
<ddaa> mh?
<mpool> did you not see it, or was it lost?
<ddaa> I do not remember seeing it
<mpool> i remember writing it
<ddaa> ACTION: ddaa and mpool to sort out the lost mail issue
<mpool> maybe there was a mail problem somewhere
<mpool> no, it's worth announcing here
<mpool> so the decision was that we will take no action on it
<ddaa> CANCEL THAT ACTION
<mpool> it's not a priority for canonical
<ddaa> cool
<mpool> jelmer can keep going with his work; we can support it and give advice on e.g. how to make id assignment better
<mpool> but the main things for us to focus on are
<mpool> - improving bzr performance
<mpool> - getting the other import priorities
<mpool> - exposing more feautres on launchpad
<mpool> cool?
<ddaa> Sounds quite sensible a plan.
<ddaa> If you have not sent it to the ML, please do so.
<mpool> :(
<mpool> i hate losing mail
<ddaa> == Pending sysadmin tasks ==
<ddaa> Nothing I guess.
<ddaa> Admins are perfect as usual those days.
<ddaa> == Critical bugs ==
<ddaa> Skipping that
<ddaa> In short, everything is in progress
<ddaa> I have partly implemented fix for two of them.
<ddaa> Plan to get the code up for review this week.
<ddaa> That will be the bulk of my time.
<ddaa> == Any other business? ==
<lifeless> yes
<lifeless> https://launchpad.canonical.com/PrivateBranches#preview
<ddaa> almost too late
<lifeless> I've replied to the reviews from spiv and ddaa
<lifeless> please go through them and either: 
<lifeless>  - delete the review question [you are happy] 
<lifeless>  - identify what you'd like me to do to make you happy on that point
<spiv> Ok.
<ddaa> ACTION: spiv and ddaa to review PrivateBranches again
<ddaa> will try to do it this week
<ddaa> lifeless: is that very important?
<lifeless> its a blocker for using lp with lp
<lifeless> bit of a lynchpin 
<ddaa> lynchin-r-us dear friend
<lifeless> so, its important, but long term. Dont panic on it, but dont defer indefinately.
<ddaa> Okay, but I'd rather get outstanding code finished before leaving.
<ddaa> At the latest, I'll review quickly when I'm back.
<mpool> ddaa: ok, mail is sent
<ddaa> mpool: thank you
<ddaa> I think that's all sorted out.
<ddaa> MEETING CLOSED
<ddaa> Reviewers have a break before the next meeting.
<ddaa> I'll have a restbreak too.
<ddaa> mpool: how much longer are you around today?
<mpool> i can be around for a while
<ddaa> mpool: I think we have one or two items to discuss post meeting
<ddaa> Let's have it at 1130 UTC
* ddaa runs out
<jamesh> mpool: re. the client side of BranchIndirection, it sounds like it would need the same infrastructure as needed to handle HTTP redirects
<ddaa> jamesh: yes, it's essentially a different front-end to the same functionality
<mpool> jamesh: yes, i think so - could you add some details on that?
<mpool> and also on the server side
* ddaa runs out really
<jamesh> mpool: e.g. another use for cross-scheme redirects would be if I set up my web server to redirect with "Location: bzr-smart-server://..."
<mpool> right
<mpool> and you could argue that rather than xmlrpc, we should really just do the query over http
<mpool> and expect a redirection back
<jamesh> which would be a pretty cool thing to do for http://bazaar.launchpad.net/ -- redirect the user to smart server if their user-agent indicates they have a new enough bzr
<mpool> yep
#launchpad-meeting 2008-08-12
<barry> #startmeeting
<MootBot> Meeting started at 21:04. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello and welcome to this week's asiapac reviewer's meeting.  who's here today?
<mwhudson> hi
<thumper> hi barry
<jml> I am
 * spiv is merely lurking
<barry> cool, cool
<spiv> (having been effectively defrocked ;)
<barry> ;)
<barry> is it really just down to 3 of y'all (officially) now?
<thumper> yep
<mwhudson> i guess it is
<spiv> (It was nice when we had a better than 1:1 ratio of reviewers:developers in this region...)
<barry> thumper: well, depending on how the elections go here in the states in november, i might have to take the slow boat to oz
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>    * invitation to use merge proposals
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<jml> barry: we'd welcome you!
<barry> :)
<barry> week += 1?
<mwhudson> +1
<thumper> yep
<barry> cool
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<mwhudson> (i should apologise for being totally rubbish at holding meetings while barry was gone...)
<barry> ah well.  no worries
<barry>  * thumper to submit a bug for moving ftests contents to tests
<thumper> bad thumper hasn't done this
<barry> thumper: we'll carry it over.  truth be told, i wanted to get to this at the montreal sprint, but we just ran out of time
<barry>  * jml to find out how divmodders test their javascript
<jml> I've asked. My attention needs to turn to their code.
<barry> jml: shall we just remove this a/i?
<jml> yes.
<jml> please.
<barry> done
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
 * jml is so hungry
<barry> jml: lunch time for you?
<barry> anyway, the queue looked awful last week, but it's been very light the last few days.  sinzui said friday was light and today was pretty light for abentley and myself
<jml> yes.
<barry> (though i had a number of fires to put out)
<barry> i don't really have much on the queue.  anything from you guys?
<mwhudson> oh i have a branch to review!
<thumper> barry: https://bugs.edge.launchpad.net/malone/+bug/257161 for ftests -> tests
<ubottu> Launchpad bug 257161 in malone "Move tests from 'ftests' directory to 'tests' directory" [Undecided,New]
<thumper> barry: I'm adding other bug tasks
<barry> thumper: excellent
<jml> mwhudson: yes you do!
<mwhudson> jml: other than yours
<jml> oh.
<barry> mwhudson: does too!
<barry> mwhudson: or, er, PR didn't get updated it seems
<mwhudson> barry: heh, indeed
<mwhudson> i didn't review it!
<thumper> barry: bug task additions complete for bug 257161
<ubottu> Launchpad bug 257161 in soyuz "Move tests from 'ftests' directory to 'tests' directory" [Undecided,New] https://launchpad.net/bugs/257161
<barry> mwhudson: weird
<mwhudson> i guess abel got whoever was on call to do it
<mwhudson> anyway, with deference to jml's stomach, moving on?
<barry> yes
 * barry skips mentoring
<barry> [TOPIC] review process
<MootBot> New Topic:  review process
<barry>    * invitation to use merge proposals
<barry> thumper: did you see my message on this?
<thumper> in passing
<jml> barry: one comment on the wiki page: setting the branch status doesn't really help anyone.
<barry> jml: how would you map our branch statuses onto merge proposals?
<barry> jml: or would you do it differently?
<jml> barry: branch status doesn't mean anything.
<jml> barry: it's not a big deal
<barry> jml: cool
<barry> i'm sure we'll refine this as we start to use it more
<thumper> barry: actually I hadn't seen your email, just saw it now
<barry> thumper: any eta on diffs?
<mwhudson> we don't want to make the experience too clicky
<jml> long time.
<thumper> barry: abentley is working on this, it will be more than 4 weeks
<barry> thumper: ok
<thumper> barry: we are wanting to decouple the email generation from delivery first
<barry> mwhudson: that was one thing i noticed.  i know abentley wants to hook in bzr send eventually
<mwhudson> barry: we want to do lots of things!
 * barry sympathizes
<mwhudson> first, stacked branches
<jml> then, scalability
<jml> then, distro
<barry> stacked branches +1
<barry> i think we can deal with doing the diffs locally for now
<barry> thumper: if you have any other ideas for making these easier to use, please do follow up to that thread
<thumper> ok
<barry> i don't have much else.  anything from you guys?
<thumper> nope
<jml> nope
<mwhudson> nope
<barry> coolio.  have a good lunch jml, and i'll talk to you guys next week!
<barry> #endmeeting
<MootBot> Meeting finished at 21:24.
<jml> barry: thanks!
<barry> thanks, and g'nite!
<thumper> barry: night
 * barry goes back to watching beach volleyball
#launchpad-meeting 2008-08-13
<barry> #startmeeting
<MootBot> Meeting started at 09:05. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
<allenap> me
<gmb> me
<jtv> me
<bac> me
<sinzui> me
<BjornT> me
<intellectronica> me
<EdwinGrubbs> me
<bigjools> me
<bigjools> cprov is at debconf
<gmb> splitter
<bigjools> curveball
<barry> danilos: ping
<danilos> me
<barry> jtv: ping?
<jtv> barry: on phone
<barry> jtv: np!  hi!
<jtv> hi
<salgado> me
<abentley> me
<barry> cool, let's start
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>    * merge proposals update
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<barry> week +=1 ?  anybody know they won't be here?
<abentley> I won't be here.
 * danilos , for a change, will be around in the next few months :)
<barry> abentley: cool, danilos :)
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry> intellectronica: any status on your three? :)
<intellectronica> sorry, haven't touched my action items yet. busy times :(
<barry> intellectronica: understood.  we'll carry these forward
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
<barry> first, thanks everybody for taking on those extra reviews and clearing our queue.  it was greatly appreciated
<barry> i think we actually don't look too bad right now, though there are 4 pink branches
<barry> notice testsuite2 is no longer at the top of the heap
<barry> any comments on the queue from y'all?
<sinzui> Are the three top items the ones that were assigned?
<barry> sinzui: good question.  i'm pretty sure jml is aware of the mpt branch
<barry> abentley: what's up with tim's karma branch?
<barry> stub's got a branch for abentley and bigjools has a branch for adeuring
<sinzui> I think they are...I confess that I worked on my assigned branch during my on-call day
<abentley> barry: He replied to my review last night.  I'll be re-reviewing today.
<bigjools> yeah I did abel's today
<barry> abentley: cool.  i still don't think i saw that branch to mentor it.  maybe it got stuck in my junk folder or something.  i will look around
<barry> bigjools: thanks
<abentley> barry: You're not cc'ed, but launchpad-reviews is.
<barry> abentley: okay, i'll search my folder
<barry> thanks
<barry> anything else on the queue?
<barry> [TOPIC] mentoring
<MootBot> New Topic:  mentoring
<barry> nothing much to report here from me.  open to comments from the floor
<abentley> I think that people who are being mentored should be referred to as "mentats" :-)
<EdwinGrubbs> or mentos
<barry> abentley: :)  i just watched dune on hbo a few nights ago :)
<barry> okay cool, moving on
<barry> [TOPIC] review process
<MootBot> New Topic:  review process
<barry>    * merge proposals update
<barry> bac: thanks for guinea pigging it and emailing your experiences
<bac> np. hope it was helpful.
<barry> definitely
<sinzui> Thou shall know a mentat bug the colour of his lips
<abentley> I regret the confusion between review votes and actually approving/disapproving a merge proposal.
<barry> anybody else planning on trying it out this week?
<gmb> barry: I'll see how loaded I am tomorrow.
<barry> gmb: cool
<abentley> Some projects, e.g. bazaar, require more than one review.
<barry> abentley: do you have any thoughts on changes to make that easier to understand?
<abentley> Not yet, but I'm open to ideas.
<bac> abentley: we need to update the wiki page to add in the step about doing the actual approval.  the last step mentioned is still 'vote approve'.
<barry> abentley: what do you think about being able to establish automatic rules, e.g. two approvals and no rejections == Approve
<abentley> bac: Okay.
<barry> abentley: you'll update the wiki?
<abentley> barry: I will update it.
<barry> abentley: thanks
<abentley> barry: I think automatic rules are nice.  See: Bundle Buggy.
 * barry should have known that bb already has it :)
<abentley> Code Reviews are not wholly my design; sabdfl and thumper also had significant input.
<abentley> sabdfl didn't want per-project customizations, IIRC.
<sinzui> I agree
<barry> abentley: i'm still not sure i agree with that, but we can continue discussing it on the ml
<barry> i have nothing else on the agenda, so we can continue to discuss this or call it a day
<BjornT> if we don't want per-project customizations, wouldn't it be better for merge proposals not to have a status of their own, and instead display the number of votes?
<abentley> I should mention that I've started work on supporting "bzr send" for launchpad.  So that should land sometime in August.
<barry> BjornT: interesting idea
<barry> abentley: would that be hookable so we can replace review-submit, or structures so r-s could wrap it?
<abentley> Right now, I'm only looking at changing LP, not bzr.  But yes, r-s could send merge directives today if mwhudson decided to implement that.
<barry> abentley: cool
<barry> anything else?
<abentley> Is now a good time to discuss diff trimming?
<barry> abentley: sure
<barry> abentley: floor is yours
<abentley> So I think it makes sense to trim diffs when sending a review, instead of just inserting comments in the middle of the diff.
<abentley> It makes the review more readable, and makes it harder for the reviewee to miss anything you've said.
<abentley> Do people agree, disagree, not care?
<sinzui> I don't know what you mean by trim. sorry
<intellectronica> abentley: i have  no idea what you mean by 'trimming'
<intellectronica> sinzui: high five
<bac> i definitely disagree for mentats.  the mentor needs to see even the stuff the mentor deemed uninteresting.
<abentley> trim: Remove the sections of the diff that you don't want to comment on.
<barry> bac: i agree
<abentley> bac: The mentor has a mail client that supports threading, one hopes?
<barry> bac: er, with you.  mentats should not trim
<bac> bac:  yes
<bigjools> I think it's down to the branch being reviewed
<intellectronica> abentley: i think that's not a good idea, because lots of people other than the reviewer look at those emails and want to see the full diff
<barry> abentley: yes, but that's much less convenient for mentoring
<bac> abentley: sure, but if i'm mentoring i don't want to have to compare the review with the original, threads or not.
<abentley> intellectronica: Why wouldn't they look at the full diff when it was submitted, then?
<sinzui> I prefer trimming. When I mentor, I read the entire change set after the mentoree has brought the review to merge-conditional*
<barry> fwiw, i never trim the original review, though i do trim follow ups
<gmb> Me too.
<bigjools> barry: +1
<intellectronica> abentley: oh, you mean in replies ...
<bac> also as a developer i don't think it's that easy to miss comments in a properly formated review.
<abentley> intellectronica: I mean if you want to look at the full diff, read it when it is submitted for review.
<gmb> Trimming replies I have no problem with.
<barry> also, i find that as i'm reviewing, i'll often want to go back to and comment on an earlier section.  if i trim as i'm reviewing, that's much harder to do, so i just don't trim
<intellectronica> still, i think most mail clients format this conveniently enough for the reader
<abentley> intellectronica: I do not mean replies, except in the sense that the initial review is a reply to the request for review.
<intellectronica> abentley: yes, i mean reply in that sense. i sometimes do reviews like this, by replying to the request and leaving comments interleaved with the original diff
<BjornT> i always trim the diffs when i do a review. that's the last thing i do, though, so there isn't a problem going back commenting on other sections
<barry> abentley: i sympathize with the readability issue.  it's definitely mua-specific though.  for me, mail.app makes it trivially easy to find the comments.  claws is more difficult
 * sinzui ponders how an app that supports block annotation and folding would work
<intellectronica> finally, it's more work which i won't really benefit from, so -1 from me on having a policy that requires that :)
<abentley> intellectronica: So when you do an initial review, you remove sections of the diff that you don't want to comment on?
<intellectronica> abentley: almost never
<sinzui> I too backtrack when I review. a comment may relate to 3 parts of the diff and It would be nice to select the comment to see all three chunks
<bac> i only remove the most mundane sections
<abentley> intellectronica: I think you may have misread me, then.
<intellectronica> oh
<barry> have we had complaints from devs about unreadable reviews, or in your experience, do devs often miss comments?
<barry> i'm trying to understand if this is in response to an existing problem
<abentley> intellectronica: I mean that in an initial review, and in replies, it makes sense to me to remove unnecessary sections of the diff.
<abentley> barry: No.  I just consider it good protocol, on any ML, to only quote sections that I want to reply to.
<BjornT> abentley: +1
<barry> i think then a reasonable policy would be to leave it up to the reviewer, with mentats deferring to what works best for their mentor
<intellectronica> abentley: right, so i did get you, and as i said, i wouldn't benefit from having this done by others, and it would be more work for me, so -1 on a policy that requires doing that
<bigjools> I think it should be down to the reviewer's discretion
<bac> barry: +1
<abentley> intellectronica: Are you okay with a policy that *permits* it?
<bac> IOW, status quo
<intellectronica> abentley: sure
<abentley> Because right now, policy *forbids* it, IIUC.
<bigjools> only for mentees
<abentley> barry: I'm happy with the policy you proposed.
<barry> [VOTE] allow reviewers to trim initial reviews at their desecration, mentats defer to mentor choice.  +1 agree, -1 disagree
<MootBot> Please vote on:  allow reviewers to trim initial reviews at their desecration, mentats defer to mentor choice.  +1 agree, -1 disagree.
<MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
<MootBot> E.g. /msg MootBot +1 #launchpad-meeting
<barry> +1
<MootBot> +1 received from barry. 1 for, 0 against. 0 have abstained. Count is now 1
<BjornT> +1
<MootBot> +1 received from BjornT. 2 for, 0 against. 0 have abstained. Count is now 2
<bigjools> +1
<MootBot> +1 received from bigjools. 3 for, 0 against. 0 have abstained. Count is now 3
<abentley> +1
<MootBot> +1 received from abentley. 4 for, 0 against. 0 have abstained. Count is now 4
<gmb> +1
<MootBot> +1 received from gmb. 5 for, 0 against. 0 have abstained. Count is now 5
<bac> +1
<MootBot> +1 received from bac. 6 for, 0 against. 0 have abstained. Count is now 6
<allenap> +
<sinzui> +1
<MootBot> +1 received from sinzui. 7 for, 0 against. 0 have abstained. Count is now 7
<allenap> +1
<MootBot> +1 received from allenap. 8 for, 0 against. 0 have abstained. Count is now 8
<EdwinGrubbs> +1
<MootBot> +1 received from EdwinGrubbs. 9 for, 0 against. 0 have abstained. Count is now 9
<intellectronica> +1
<MootBot> +1 received from intellectronica. 10 for, 0 against. 0 have abstained. Count is now 10
<barry> [AGREED] allow trims of initial reviews at reviewer discretion, mentats to follow mentor preferences
<MootBot> AGREED received:  allow trims of initial reviews at reviewer discretion, mentats to follow mentor preferences
<barry> we're out of time.  thanks for bringing this up abentley, so...
<barry> #endmeeting
<MootBot> Vote is in progress. Finishing now.
<MootBot> Final result is 10 for, 0 against. 0 abstained. Total: 10
<MootBot> Meeting finished at 09:49.
<barry> thanks everyone, have a good day
<bigjools> cheerio!
<intellectronica> thanks barry
<abentley> Thanks.
<gmb> Ta barry.
#launchpad-meeting 2008-08-14
<benje> hi how we cancel an attachement before save change to s"end only message ?
<benje> ther no way must i post bug about launchpad under launchpad ?
<bigjools> benje: this is the meeting channel, please ask in #launchpad
<benje> ok sorry
<bigjools> that's ok
<Rinchen> #startmeeting
<Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<MootBot> Meeting started at 13:05. The chair is Rinchen.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Rinchen> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<Rinchen> oink
<Ursinha> me!
<abentley> moo
<rockstar> me
<bac> me
<stub> me
<jtv> me
<barry> me
<adeuring> me
<gmb> me
<mwhudson> me!
<intellectronica> me
<salgado> me
<mthaddon> me
<allenap> me
<Rinchen> mrevell?
<BjornT_> me
<mrevell> me
<mrevell> sorry
<beuno> me
<mrevell> welcome beuno!
<bigjools> me
<Rinchen> apologies from diogo
<sinzui> me
<Rinchen> Releases Team is here
<BjornT_> bugs team is here
<mthaddon> (will be seeing diogo later today)
<barry> EdwinGrubbs: ping
<barry> mars: ping
<barry> Rinchen: flacoste will not be here
<Rinchen> thanks barry
<Rinchen> bugs team here? foundations?
<barry> leonardr: ping
<Rinchen> translations?
<Rinchen> soyuz?
<jtv> Rinchen: danilos sends apologies
<leonardr> mr
<leonardr> me
<Rinchen> thanks jtv - translations here
<barry> Rinchen: seems like a few of our guys are missing
<thumper_laptop> me
<bigjools> Rinchen: cprov @ debconf, al-maisan is MIA
<Rinchen> ok, code is here
<Rinchen> soyuz ok.
<Rinchen> alrighty then
<Rinchen> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (matsubara/ursinha)
<Rinchen>  * Critical Bugs (Rinchen)
<Rinchen>  * Bug tags
<Rinchen>  * Operations report (mthaddon/herb/spm)
<Rinchen>  * DBA report (stub)
<Rinchen>  * Sysadmin requests (Rinchen)
<Rinchen>  * New packages required (salgado)
<Rinchen> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<herb> me
<Rinchen> same time next week. Anyone not available?
<abentley> I am not available.
<Rinchen> ok, thanks abentley
<barry> Rinchen: i may not be, not sure yet
<Rinchen> barry, ok, update the mtg agenda please when you know
<Rinchen> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<barry> Rinchen: will do
<Rinchen> there were none.
<Rinchen> [TOPIC] Oops report (matsubara/ursinha)
<MootBot> New Topic:  Oops report (matsubara/ursinha)
 * Ursinha waves
<Ursinha> Bugs for today: 252674 and 174480, two timeouts, two for bugs team
<Ursinha> BjornT, did you have the time to look at bug 252674?
<ubottu> Bug 252674 on http://launchpad.net/bugs/252674 is private
<Ursinha> bugs/+index timeout problem
<intellectronica> Ursinha: 174480 is in pqm
<Ursinha> intellectronica, cool, thanks
<BjornT_> Ursinha: sorry, no. is it still happening?
<Ursinha> BjornT_, yes
<BjornT_> Ursinha: can you please add some recent oops to the bug report?
<Ursinha> BjornT_, ok, i'll append some more
<BjornT_> thanks
<Ursinha> np
<Ursinha> that's all for now, thanks guys
<mthaddon> Ursinha, how did the oopses look yesterday given the high DB load?
<Rinchen> thanks Ursinha
<Ursinha> mthaddon, pretty much the same
<mthaddon> Ursinha, interesting - ok, thx
<Ursinha> mthaddon, np
<Rinchen> [TOPIC] Critical Bugs
<MootBot> New Topic:  Critical Bugs
<Ursinha> Only one critical bug not Fix Commited yet, yay!
<Ursinha> [LINK] https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/255886
<Ursinha> but it's now playing on pqm, so soon will be Fix Commited, thanks mwhudson
<MootBot> LINK received:  https://bugs.edge.launchpad.net/launchpad-bazaar/+bug/255886
<ubottu> Error: This bug is private
<ubottu> Error: This bug is private
<Ursinha> that's all
<Rinchen> awesome
<Rinchen> thanks Ursinha
<Rinchen> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<Rinchen> we have 2 requests
<mwhudson> (something to mention later, pqm's queue is moving reaaaaally slowly atm)
<Rinchen> https://help.launchpad.net/TaggingLaunchpadBugs
<mthaddon> mwhudson, herb is doing a CP
<mwhudson> mthaddon: i mean more generally
<Rinchen> first one is for jml for the tag of Stacking
<Rinchen> thumper, you have this one?
<EdwinGrubbs> me
<mwhudson> mthaddon: it was only 8th in the queue when i submitted ~20 hours ago...
<mthaddon> mwhudson, https://devpad.canonical.com/~joey/pqm.html isn't much slower than normal
<thumper> ok, this is to help us identify any bugs to do with the new way we are dealing with branches
<Rinchen>  >> we'll do PQM in a sec
<kiko-fud> ai, I hate my timezone
<Rinchen> I'm +1 on the stacking tag.  I can see a need for this.
<kiko> that sounds fine
<BjornT_> stacking seems a bit too general, though
<BjornT_> how about branch-stacking?
<thumper> that's ok with me
<kiko> sounds good
<kiko> +1
<intellectronica> yes, i like that better too
<mwhudson> sounds good, as i'm going to make the same complaint about the next proposed tag :)
<gmb> So am I
<gmb> And I'm proposing it...
<Rinchen> oh mwhudson ! Hi, didn't see you
<Rinchen> [AGREED] branch-stacking tag approved.  mwhudson to update wiki page
<MootBot> AGREED received:  branch-stacking tag approved.  mwhudson to update wiki page
<mwhudson> Rinchen: er
<gmb> Heh
<mwhudson> Rinchen: it was jml who proposed the tag, but ok
<mars> oops!
<Rinchen> next up, gmb with the upstream tag.  gmb can you explain how this is different from bugwatch?
<mars> me
<gmb> Right.
<Rinchen> lol
<gmb> So, the name is far, far too general and needs to be revised.
<Rinchen> I stand corrected mwhudson
<gmb> Skipping past that...
<Rinchen> mwhudson, I'll do it then
<intellectronica> gmb: how about 'upstream-support'?
<gmb> This tag would be for organising bugs that relate to our upstream relations work (so maybe upstream-relations would work as a name). The example I've given is of a bug with the upstream report, but I'm intending for it to be used by the community team or anyone who needs us to implement a feature specifically geared towards making our (and by extension Ubuntu's) work with upstream more streamlined.
<gmb> intellectronica: Yes, that would work.
<intellectronica> or 'upstream-requirement'. more accurate but less catchy
<mwhudson> can you give some example bugs?
<gmb> Let me dig some up. They're all upstream report related ATM.
<intellectronica> bug #255050 on the wiki
<ubottu> Launchpad bug 255050 in launchpad "Statistical columns on the upstream report should turn green for values of 90% and above" [Medium,Fix committed] https://launchpad.net/bugs/255050
<gmb> bugs 249517 255050 249814 256969 would be examples
<ubottu> Launchpad bug 249517 in launchpad "The upstream report should be tracking all open tasks" [High,Fix committed] https://launchpad.net/bugs/249517
<kiko> intellectronica, hmmm, upstream-requirement is a bit too general
<Rinchen> gmb, is this simply for the report or plugins as well
<kiko> gmb, why not 'ubuntu-upstream-relations' or something like that?
<intellectronica> kiko: well, but this tag is quite general
<gmb> kiko: That would work well, yes.
<kiko> I mean, actually say what it is
<kiko> or upstream-relations-requirement
<kiko> something like that
<gmb> Rinchen: I'm intending it to be used organisationally for all ubuntu upstream relations work.
<intellectronica> i don't like -relations. nobody outside the project will understand what it's about
<kiko> intellectronica, it's okay -- that's why I said ubuntu-relations-requirement
<intellectronica> yeah, that makes sense
<kiko> it makes it very obvious that it's a tag to be used by people who know what that means. :)
<Rinchen> kiko, too long. Something shorter?
<kiko> Rinchen, why?
<kiko> I think long is fine in this case.
<kiko> it's a very special tag to be used in a very specific circumstance
<abentley> kiko: A relations requirement sounds like I have to take it to dinner before I get to have relations with it.
<Rinchen> so is oops-tools ;-)
<BjornT_> +1 on ubuntu-upstream-relations
<Rinchen> ok, ok, I'll bend
<gmb> ubuntu-upstream-relations works for me.
<Rinchen> any objections to the tag or tag name?
<Rinchen> ok then..
<Rinchen> [AGREED] ubuntu-upstream-relations tag approved. gmb to update the wiki
<MootBot> AGREED received:  ubuntu-upstream-relations tag approved. gmb to update the wiki
<gmb> Thanks.
<Rinchen> and in my best Steve Jobs voice...
<Rinchen> there's one more thing
<Rinchen> kiko and I have talked and we would like to do away with the bug tag section of  the weekly meeting
<Rinchen> and hold these discussions on the mailing list
<barry> +1
<intellectronica> +1
<Ursinha> +1
<bac> +1
<Rinchen> any objections would require some rework
<sinzui> +1
<bigjools> +1 meelion
<mwhudson> +1
<jtv> +1
<abentley> +1
 * Rinchen laughs. 
<rockstar> +1
<kiko> I think that section is so nitpicky even I can't take it much longer
<Rinchen> Ok, I get the hint/
<kiko> and I'm a nitpicker
<kiko> at heart
<Rinchen> [AGREED] death to bug tags section. Use the mailing list instead.
<MootBot> AGREED received:  death to bug tags section. Use the mailing list instead.
<Rinchen> [TOPIC] Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  Operations report (mthaddon/herb/spm)
<herb> Late Sunday (2008-08-10) Cherry pick of r6818 to the scripts server.
<herb> Early yesterday (2008-08-13) Cherry picked r6836 to PPA server and FTP master, and r6842 to lpnet* and edge*
<herb> A cherry pick for r6846 and r6850 is in queue right now and will be deployed after the meeting.
<herb> Bug 247227 (App servers dying) continues to be an issue. There have been some updates to the bug and we've been capturing debugging information. But the root cause has not yet been isolated.
<ubottu> Bug 247227 on http://launchpad.net/bugs/247227 is private
<herb> I'm on holiday on Monday.
<herb> That's it from Tom, Steve and me unless there are any questions.
<Rinchen> I'm still concerned with 247227
 * herb is too
<Rinchen> what else can we do here to get more information?
<Rinchen> would an strace help?
<Rinchen> kiko ^^
<mwhudson> kiko's suggestion in the report would help!
<stub> We can trigger it. I think we need someone with the right -fu to trace down the fault point rather than boucing between admins and our suggestions.
<mwhudson> i am (for my sins) reasonably experienced in debugging python with gdb
<mthaddon> thx for volunteering!
<mwhudson> so if we end up in a gdb prompt when i'm around, please bug me
<herb> mwhudson: we have a backtrace that was captured yesterday
<herb> we don't run gdb interactively
<mwhudson> oh
<kiko> herb, I think running it interactively would really help
<kiko> herb, and, if an actual engineer or I could do the interaction, it would be MUCH better.
<mwhudson> i can give you some more interesting stuff to run non-interactively then :)
<mwhudson> let's talk about it after the meeting
<bigjools> gdb has a remote debugging thingy doesn't it?
<herb> mwhudson: ok
<kiko> I realize I am being a heretic at suggesting that an ENGINEER might actually be able to TOUCH the software he wrote
<kiko> but hey, it's august the 14th
 * kiko winks
<herb> kiko: it's not about the software it's about the servers. :)
<stub> Think of the servers!
<kiko> herb, I don't know the difference :)
<Rinchen> Thinks of the service. :-D
<herb> stub: hehe
<mthaddon> kiko, that's why herb and I have a job
<thumper> kiko: it is the 15th here
<kiko> mthaddon, well.. unless you can debug yourself, this is really a suboptimal arrangement for this specific crisis.
<rockstar> thumper, you live in the future.  You are the exception
<kiko> I hope mwhudson can help further, but I do think that there is no big deal in having engineers able to access the servers in situations that warrant it.
<mthaddon> kiko, I think we're being pretty accommodating here - I was just meaning we have a job because you don't know the difference between software and servers :)
<kiko> and by not allowing this, we're all plastered.
<Rinchen> same team, same side
<Rinchen> fight nice
<Rinchen> :-)
<mthaddon> kiko, I think you're over-estimating that - we're doing everything you ask of us - and thx Rinchen
<Rinchen> thanks mwhudson for volunteering
 * mwhudson goes to find his scripts, which funnily enoiugh are on vostok...
<kiko> mthaddon, I disagree vehemently, but it is not to say I don't appreciate your effort
<Rinchen> [ACTION] mwhudson to get with mthaddon to see if we can super-charge gdb to give us better diagnostic info on the staging.
<MootBot> ACTION received:  mwhudson to get with mthaddon to see if we can super-charge gdb to give us better diagnostic info on the staging.
<Rinchen> anything else for the OSAs?
<Rinchen> ok, moving on
<Rinchen> thanks herb and mthaddon
<Rinchen> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<stub> We were getting a high DB load yesterday, apparently from multiple copies of some scripts running. I guess these where old ones before we had decent locking helpers. Load is back to normal now.
<stub> The script we need to run to open Intrepid for translations is increasing load enough to push some of our expensive pages (such as the bugs.launchpad.net front page) over the hard limit, causing timeouts.
<stub> We have a few options to proceed, including trying again with some tweaked tuning settings (may require bouncing PG), making the code that is being unfriendly to other processes more friendly (but slower), or scheduling some downtime while the unfriendly section of code needs to run - we think half an hour including some slack.
<stub> My read-only-launchpad branch is still blocked getting through PQM - no chance to look further today. As far as I have got, it seems that for my branch only in the PQM environment the Librarian reconnection code isn't working, instead causing the Librarian to hang. I'll need to instrament the librarian and run tests or do some manual tests stepping through the librarian code with pdb to get further - yay :-P
<stub> There are still a two post-cuttoff reviews to do - one soyuz and one from Barry that isn't in my wiki queue. The soyuz (lucille) one isn't showing up on the merge status cgi - not sure why (pushed to devpad?).
<barry> stub: crap, i'll put it in the queue right now. apologies
<abentley> stub: What's the status of my review?
<bigjools> stub: the lucille one is just a permission change, not sure why it's not showing up
<stub> That would be the one I didn't see above my queue...
<stub> bigjools: If it is just permissions, I don't need to see it.
<bigjools> ah ok
<stub> abentley: I do yours too now I see it :)
<abentley> stub: Thanks.
<Rinchen> stub, do you need someone to help with the read-only branch?
<stub> And that is my example to kiko on a place we use message_id without storing the message...
<kiko> stub, lucille?
<stub> I'll yell for help if I need twisted hand holding
<kiko> stub, or.. something else?
<kiko> stub, I've had a similar problem with the librarian before in my local tree
<stub> kiko: There are soyuz scripts still connecting as the 'lucille' db user.
<kiko> stub, and that's relation to message_id? :)
<stub> kiko: https://devpad.canonical.com/~jamesh/pending-reviews/abentley/launchpad/better-threading/full-diff
<kiko> stub, oh, abentley's branch. sorry, you really tricked me there!
<stub> kiko: I just mentioned it in my bug because I was reminded by that branch I was supposed to review.
<kiko> I like the funky caps in that patch
<stub> Its 1:40am tomorrow. Its confusing. Deal.
<kiko> stub, hmm. wonder why we don't store that message, actually. thumper?
<thumper> why should we store the whole email?
<thumper> it serves no purpose
<stub> If it is auto generated, there isn't much point.
<thumper> it will never be looked at
 * thumper agrees with stub
<Rinchen> anything else for stub before we move on?
<Rinchen> ok, thanks stub
<gmb> intellectronica apologises - he's lost his connection and will be back when possible.
<Rinchen> [TOPIC] Sysadmin requests (Rinchen)
<MootBot> New Topic:  Sysadmin requests (Rinchen)
<Rinchen> so I have a question
<Rinchen> for herb and mthaddon
<Rinchen> normally I track rt's in this section
<Rinchen> ask for ones that need some attention
<mthaddon> ?
<Rinchen> Do you guys feel that you could do this section?
<Rinchen> as in, we come to the OSAs with RT prioritization
<Rinchen> and for help in RT scheduling?
<mthaddon> Rinchen, actually, it's very useful to know which RTs you feel need prioritization
<Rinchen> mthaddon, right. Right now I hope on the IS channel and poke elmo
<Rinchen> mthaddon, I'm curious if you think the OSAs would be a better choice.
<Rinchen> so this would be your section and we could poke you
<Rinchen> vs me poking on the IS channel
<Rinchen> it has some drawbacks and some positives.
<mthaddon> Rinchen, it's better to not use us as RT proxies, but to work directly with IS - we can certainly help priortise RTs that need it, but otherwise we end up as middle men which isn't efficient for anyone
<Rinchen> ok, thanks mthaddon
<Rinchen> Is anyone blocked on an RT or have any that are becoming urgent?
 * beuno would like RT 31420
<bigjools> Rinchen: the two I emailed you about last week
<Rinchen> ok beuno I'll have a look at it
<beuno> thanks Rinchen
<Rinchen> hmm, bigjools. Ok, I'll touch base again with IS on those.
<bigjools> ta
<kiko> Rinchen, is the xlstproc stuff sorted?
<kiko> our documentation is/was pretty out of date the last time I looked into it
<salgado> AFAIK we're generating the docs manually
<Rinchen> not that I've seen. :-(
<salgado> ok, you know about that already
<Rinchen> I'll go through the priority list again today and make sure our tickets are correctly set
<Rinchen> [ACTION] Joey to review RT ticket Priorities in RT to ensure they are accurate.
<MootBot> ACTION received:  Joey to review RT ticket Priorities in RT to ensure they are accurate.
<Rinchen> [TOPIC] New packages required (salgado)
<MootBot> New Topic:  New packages required (salgado)
<salgado> anything for me?
<thumper> congratulations
<salgado> ha ha
 * stub points at the clock
<salgado> thanks Rinchen.  please move on before kiko remembers of something. ;)
<Rinchen> ok, thanks salgado. I've been pinging folks as RT's come in and ensuring they have submitted bugs for you
<Rinchen> 100% compliance so that was great
<Rinchen> which leads me to one last topic for today that was not on the agenda
<kiko> salgado, hmm, I just remembered
 * Rinchen pauses for kiko 
<kiko> salgado, I should thank you for the quick updates to meta-lp-deps the past week :)
<salgado> kiko, you're welcome!
<Rinchen> [TOPIC] Weekly meeting agenda
<MootBot> New Topic:  Weekly meeting agenda
<Rinchen> so...
<Rinchen> kiko and I have chatted briefly
<Rinchen> and we both agree we'd like to make some progressive changes to the agenda of this meeting
<Rinchen> what I'd like to know at this moment is if there are any suggested topics that you feel can be done on email and not during the meeting?
<Rinchen> the topic list again is:
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (matsubara/ursinha)
<Rinchen>  * Critical Bugs (Rinchen)
<Rinchen>  * Bug tags
<Rinchen>  * Operations report (mthaddon/herb/spm)
<Rinchen>  * DBA report (stub)
<Rinchen>  * Sysadmin requests (Rinchen)
<Rinchen>  * New packages required (salgado)
<Rinchen> bug tags is gone
<mwhudson> i guess in a perfect world, the 'report' sections could be done on list and then just talked about in here
<Rinchen> I'm going to combine oops and critical bugs into one section
<Ursinha> Rinchen, nice, i was going to suggest that
<Rinchen> mwhudson, good idea
<mwhudson> but that may require unlikely amounts of discipline
<Rinchen> it is nice though to have the reports during this meeting
<sinzui> Shouldn't "ï»¿New packages required" be handled elsewhere?
<Rinchen> sinzui, I am inclined to agree
<kiko> sinzui, the only reason we do it here is to remind people
<bigjools> yep, new packages could go offline
<mwhudson> yeah, and pasting in the reports to the channel doesn't take long at all
<kiko> in case they have forgotten
<kiko> the problem is that they have been forgotten a lot in the past, so we tried to use this to discipline ourselves
<Rinchen> I also think that RT's can be done offline. People can just ping me.
<kiko> if that need is no longer served, then let's evict it
<abentley> Do we have any criteria for things that should be discussed interactively, vs things that should be discussed in a ML?
<Rinchen> kiko, it's been good this past week but that's the first time I recall it being done consistently.
<Rinchen> abentley, that's the real crux there.
<kiko> abentley, things discussed interactively should be relevant to most of the audience here
<kiko> abentley, so changes in policy, new experiments being run, interesting anecdotes you found during the week, code bloopers and gotchas, etc
<kiko> abentley, there's a discipline side to this meeting that I generally would like to minimize -- this is the new packages stuff, the OOPS crapola, etc
<Rinchen> In truth, it's possible to take the entire existing agenda and do it via the mailing list.
<Rinchen> and keep this meeting for special topics of interest.
<Rinchen> at least, that is my feeling at the moment
<kiko> well.. I think we don't need to trash all of it, but I agree we can minimize the filler
<abentley> kiko: What you're saying sounds to me like a series of presentations-- very different from what we have now, but potentially quite useful.
<abentley> Another option might be to have each team summarize their past week?
<Rinchen> thumper, BjornT_, jtv?, anyone else with opinions?
<kiko> abentley, I would like our team to drive the meeting more
<kiko> abentley, I don't like the idea of status reports as much as I like the idea of anecdotes
<Rinchen> +1
<kiko> status reports sounds "discipline"
<kiko> what I want is "knowledge and experience sharing"
<rockstar> +1 abentley
<barry> kiko: maybe each team can drive in round robin, and present interesting things they're working on, or discovered, etc.
<mars> kiko, so a "what's new in reviews" section for the entire team?
<rockstar> Each team will have some experience to share.
<Rinchen> it might be nice to have a "good news" item that we do on the TL call
<mars> Rinchen, +1
<kiko> mars, yeeeah, something like that
<kiko> mars, "lowlights in code reviews" etc (shocker! but mostly joking)
<abentley> This is a public forum.  Is there a risk of exposing our "trade $ecret$"?
<Rinchen> ok, if you guys have any suggestions for adds and deletes to the agenda, please email the list.  By 1 Sept we'll have a new agenda running.
<Rinchen> [ACTION] Everyone: Please consider adds and deletes to the agenda to make the weekly higher-bandwidth meetings more useful.
<MootBot> ACTION received:  Everyone: Please consider adds and deletes to the agenda to make the weekly higher-bandwidth meetings more useful.
<kiko> abentley, I don't worry about those, and for the most part you shouldn't either
<Rinchen> Anything else on this topic before I close?
<abentley> kiko: Cool.
<sinzui> What we really risk exposing is our love of profanity
<mwhudson> sinzui: we're programmers.  no-one will be surprised
<kiko> abentley, there are certain topics to be careful with -- security and privacy-involved ones in particular -- but generally speaking it's okay to talk about code, design and the future
<Rinchen> http://www.techtoolblog.com/archives/wtfminute-code-reviews
<MootBot> LINK received:  http://www.techtoolblog.com/archives/wtfminute-code-reviews
<Rinchen> ooh
<Rinchen> new mootbot feature
<kiko> auto-detection of LINKs
<Rinchen> love it
<kiko> and you said you hated eggdrop :)
<Rinchen> thanks guys (and girl) for hanging in with us today
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
<Rinchen> #endmeeting
<MootBot> Meeting finished at 14:05.
<abentley> Rinchen: Thanks.
<mrevell> thanks all
<gmb> Thanks Rinchen
<mrevell> night all
<Ursinha> thanks
<jtv> MootBot: what timezone are you in!?
#launchpad-meeting 2009-08-12
<Ursinha> MootBot, owner
<Ursinha> poor MootBot
<Ursinha> !owner
<ubottu> This bot is owned by jussi01 - Questions about ubottu should be asked in #ubuntu-bots
<Ursinha> oops
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everybody and welcome to this week's ameu reviewers meeting.  who's here today?
<gary_poster> me
<EdwinGrubbs> me
<bac> me
<noodles775> me
<adeuring> me
<barry> we have apologies from rockstar and jtv
<intellectronica> me
<henninge> me, what time zone is 9:00 anyway?
<salgado> me
<bac> CDT
<deryck> me
<bac> er, central daylight, henninge
<henninge> bac: why, servers running there?
<bac> must be EdwinGrubbs
<barry> bigjools sends apologies for soyuz folks, who may be late
 * barry wonders if any non-canonical folks are joining us today
<danilos> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> * Roll call
<barry>  * Action items
<barry>  * Mentoring update
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry> let me start today by thanking bac for chairing the meetings while i was out
<gary_poster> yay bac!
<henninge> way to go bac!
<bac> it was no problem, barry.
<bac> barry: you'll note we were done in twenty one minutes both weeks!
<barry> bac: i think i will let you chair every time there are outstanding actions :)
<barry> bac: let's beat that record today! :)
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry> nothing!  wow, thanks everyone!
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> i think it's fantastic that leonardr graduated and that now all coders are reviewers.  i want to keep this item on the agenda for when wgrant applies for mentat status :)
<gary_poster> :-)
<barry> any other comments on mentoring before i move on?
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<intellectronica> perhaps just to remind that a similar program is now going on with ui reviews
<barry> intellectronica: right!  thanks.  to the extent that we can share wisdom or there's overlap it might be good to have a summary of those meetings over here
<barry> intellectronica: would you like to be the bridge between the two groups, at least until i get mentored over there? <wink>
<gary_poster> there's a move afoot (in the softarch CoP) to try and get a company-wide guideline for reviews.  I pointed them to our stuff.  Some of it needs to be transferred from the old-old wiki, not just the old wiki!
<intellectronica> sure
<barry> intellectronica: thanks
<barry> gary_poster: yes, +1  i think we need to give that as an action for someone.  does anybody want to volunteer?
<barry> i will do it then :)
<gary_poster> I'll probably volunteer next week if nobody does this week :-)
<gary_poster> oh ok, nm ;-)
<barry> curses!
<gary_poster> lol
<barry> gary_poster: maybe we can both take an action on that?
<gary_poster> actually I had that written and was just waiting to see someone else volunteer ;-)
<gary_poster> sure
 * barry must remember to read /more/ email during these meetings
<gary_poster> lol
<barry> [ACTION] gary_poster and barry will transfer review guidelines from the old{1,2} wiki to the new wiki
<MootBot> ACTION received:  gary_poster and barry will transfer review guidelines from the old{1,2} wiki to the new wiki
<gary_poster> barry, I won't have time between now and next mtg, which was why I said that, but am happy to work on it next wk.
<barry> gary_poster: cool, np
<barry> thanks
<barry> anyway, there's nothing else on the agenda.  does anybody have any other topics for today?
<barry> 5
<barry> 4
<danilos> short and sweet, I guess
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 09:12.
<danilos> good job barry, thanks all
<barry> thanks everyone.  a new record :)
<sinzui> new record
<bac> thanks barry
<danilos> ;)
<gary_poster> :-) thanks
<barry> #startmeeting
<MootBot> Meeting started at 17:31. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everyone and welcome to this week's asiapac reveiwers meeting.  who's here today?
<rockstar> ni!
<rockstar> wgrant, ping
<barry> wgrant: you are welcome to lurk or join in!
<barry> thumper, jml ping
<wgrant> me!
<barry> \o/
<rockstar> barry, jml is traipsing around Europe this week.
<thumper> barry: hi
<barry> rockstar: gotcha
<thumper> rockstar: shh
<barry> so...
<thumper> barry: jml is unavailable :)
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> ;)
<barry> well it was a very short ameu meeting, so to summarize...
<barry> intellectronica is going to keep these teams abreast of what happens in the new ui reviewer meetings
<barry> at least until i s/mentat/reviewer/
<barry> gary_poster and /me will work on transferring review guidelines from the old old wiki and old wiki to the new wiki
<barry> that's about it
<barry> we don't really have any action items, so let me open things up to y'all
<rockstar> To be honest, I think we should actually have a section lead by the UI reviewers in the reviewer meetings, instead of the super sekrit phone call.
<barry> what's been going on and what's on your mind?
<rockstar> That way, we can involve the community more.
<gary_poster> [peanut gallery] rockstar: +1 in theory
<barry> rockstar: i'd be in favor of that
<rockstar> gary_poster, why not in practice?
<gary_poster> (in theory simply because I haven't thought about the practicalities too much)
<rockstar> gary_poster, yeah, but I think having that interaction between UI reviewers should be a bit more public.  I think the phone call should be for keeping the teams up to date with other UI matters.
<rockstar> Also, another thing that came up in a review with thumper yesterday.
<rockstar> In the new views, we have to implement a page_title attribute.  Sometimes this is a function.
<rockstar> In generic edit views, we also need a label attribute, which can also be an @property
<rockstar> Do those two functions need docstrings?  We often don't include them in initialize and other functions that need implementing, unless there is a specific reason.
<thumper> barry: also worth noting there is a new lp/app/templates/generic-edit.pt that should suit most general editing needs
<barry> rockstar: the way to think about it is if/when we get sphinx output for api docs. would the docstring help?
<thumper> barry: the docstring would be the same every time
<thumper> barry: the label is rendered as the h1
<rockstar> barry, in this case, no, because in thumper's branch, all the docstrings were the same.  That's why I had him remove them.
<thumper> barry: and the page_title is the html title for the page
 * rockstar will let thumper talk about generic-edit.pt
<barry> well, another way to think about it is that when they /are/ just attributes they won't have docstrings
<barry> i think we can play those by ear.  i.e. let the dev and reviewer decide
<thumper> I'm +1 on not having docstrings for label and page_title properties
<barry> i wouldn't say they /can't/ but i agree they don't need to
<barry> thumper: tell me about generic-edit.py
<thumper> barry: a new very simple template
<thumper> barry: new 3.0 style
<thumper> barry: just renders the form
<thumper> barry: so the view has page_title, label, and other bits
<barry> from the object's schema?
<thumper> barry: refer to the generic-edit.pt (not py)
<barry> s/py/pt/
<barry> ;)
<rockstar> lp/app/templates/generic-edit.pt
<thumper> barry: I found there were many similar edit pages in code
<thumper> barry: and sinzui also had many in registry
<barry> cool.  i'll add this to the summary so other reviewers are on the lookout for when we can use it
<rockstar> And me in answers.
<thumper> barry: there are no bugs in no code (or pages)
<rockstar> Yes, so we remove templates.
<barry> which is always good!
<thumper> that's all I think
<barry> [ACTION] reviewers should watch for opportunities to remove custom templates in favor of generic-edit.pt
<MootBot> ACTION received:  reviewers should watch for opportunities to remove custom templates in favor of generic-edit.pt
<barry> thumper: thanks.  rockstar or wgrant anything from you?
<barry> wgrant how have things gone with the branches you've submitted?
<rockstar> barry, maybe I should start coming to the AsiaPac meetings instead of the early morning one for me.  :)
<thumper> barry: then we could have almost all the code team at one
<barry> rockstar: they go quicker that's for sure, though this one has already gone longer than the ameu one this morning :)
<barry> seriously: +1
<barry> abentley too?
<barry> it wouldn't be a bad time for him
<wgrant> barry: It has gone pretty well.
<rockstar> Wait, that might not be good.  Next you'll round the code team up in camps and experiment on us.
<wgrant> Although it's sometimes awkward to find Soyuz people around, it's been fairly quick and painless.
<barry> wgrant: great!  i'm really psyched to see you blazing the trail
<thumper> barry: nah, abentley will probably still go to the other one
<wgrant> ... although ec2test for contributors would be nice.
<thumper> barry: this would be too late in his evening
<barry> wgrant: +1
<rockstar> wgrant, +1
<barry> thumper: it's only 6:30pm for us
<thumper> barry: :)
<barry> 'sup to him of course
<thumper> barry: do you have a few minutes for a skype call after this?
<barry> thumper: i do
<barry> are we done?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 17:49.
<barry> thanks guys
 * barry puts on headphones
#launchpad-meeting 2009-08-13
<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
<herb> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<henninge> me
<Ursinha> me (just watching)
<intellectronica> me
<matsubara> sinzui, rockstar, bigjools: hi
<rockstar> ni!
<matsubara> apologies from sprinters: stub and flacoste
<sinzui> me
<bigjools> yarp
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (stub)
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> * matsubara to chase mwhudson/jml about failure on updatebranches script
<matsubara> * stub to delegate bug 354593 to ISD
<matsubara> * sinzui to ask barry to fix bug 403606
<matsubara> * ursinha to chase mars about OOPS-1307J16 and file a bug about it
<matsubara> * stub to request CP for his branch that fixes oops logging
<matsubara> * henninge to investigate rosetta-poimport script failure on the Aug 5th and report back to the list
<ubottu> Launchpad bug 354593 in canonical-identity-provider "SSO exceptions views need proper branding" [High,Triaged] https://launchpad.net/bugs/354593
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1307J16
<matsubara> I haven't chased jml about updatebranches script. it haven't failed in a while, so I think it's fine to remove the action item
<Ursinha> matsubara, I suck, I need to do that
<rockstar> matsubara, I'm pretty sure mwhudson was looking at it before it left.  I'd be surprised if he left without it working.
<matsubara> [action] * ursinha to chase mars about OOPS-1307J16 and file a bug about it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1307J16
<MootBot> ACTION received:  * ursinha to chase mars about OOPS-1307J16 and file a bug about it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1307J16
<matsubara> I think both stub action items were done
<matsubara> henninge, any news about the failure in the rosetta-poimport script?
<sinzui> matsubara: barry has not had time to look into bug 403606, He had a more pressing bug to work on
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<henninge> matsubara: There were several problems on that day and I had meant to get back to you and ask which one you meant ... ;-)
<matsubara> sinzui, will barry have time to fix it for 2.2.8? this is one of the most frequent oops in the summaries
<henninge> matsubara: but they are all fixed now .
<sinzui> matsubara: I cannot say. We do not know what is wrong
<matsubara> henninge, cool. thanks
<matsubara> sinzui, all right. please keep it in your radar
<matsubara> I think that's all for the action items from last week
<matsubara> thanks everyone
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> Today we have a few OOPS for bigjools and sinzui
<matsubara> bigjools, OOPS-1315A253
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1315A253
<bigjools>  /o\
<matsubara> sinzui, OOPS-1318S626 AssertionError using the API to create a ProductRelease
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1318S626
<matsubara> sinzui, OOPS-1316EA164 TraversalError adding a release
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1316EA164
<bigjools> matsubara: why is that a soyuz oops?
<matsubara> sinzui, OOPS-1321EB223 and OOPS-1318EA4 are the same bug (or going to be fixed by the same fix) for bug 402725?
<ubottu> Launchpad bug 402725 in launchpad-registry "Delete series does not untarget series-targeted blueprints" [Low,Triaged] https://launchpad.net/bugs/402725
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1321EB223
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1318EA4
<matsubara> bigjools, look at the URL failing in when %s is used as the search term
<bigjools> matsubara: look at the URL on the left, not the search term :)
<matsubara> looks like the ppa search OOPSes when you pass %s
<sinzui> matsubara: one oops is  hacked url. We can make the form not render if the release already exists
<matsubara> bigjools, well, users are trying to use the global search and they're getting an OOPS because the ppa search can't handle %s
<sinzui> matsubara: the other oops is from the baltix owner trying to do his job. The code that lets him do his job will not be on edge until saturday
<matsubara> [action] matsubara to file a bug for OOPS-1315A253
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1315A253
<MootBot> ACTION received:  matsubara to file a bug for OOPS-1315A253
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1315A253
<bigjools> matsubara: I don't see where there's a ppa search going on.  Someone is pasting a URL into the search box aren't they?
<matsubara> bigjools, nope, I was able to reproduce by just searching for %s in the global search
<bigjools> matsubara: ok let's talk after the meeting
<gary_poster> me :-)
<matsubara> perhaps the global search also uses the ppa search internally?
<gary_poster> I'm here for foundations
<bigjools> well not that I am aware of
<bigjools> global search uses google
<matsubara> bigjools, ok. we can talk after the meeting and then I'll file a bug in the correct project
<bigjools> okidoki
<matsubara> gary_poster, hi and welcome! :-)
<gary_poster> thanks :-)
<matsubara> sinzui, which one is going to be rolled out to edge on saturday?
<matsubara> sinzui, the traversalerror or the assertionerror?
<matsubara> sinzui, how about the IntegrityErrors?
<sinzui> matsubara: traversal error
<sinzui> matsubara: if you have not created bugs, I will so that I can track this
<matsubara> [action] sinzui to file bugs for OOPS-1318S626, OOPS-1321EB223 and OOPS-1318EA4
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1318S626
<MootBot> ACTION received:  sinzui to file bugs for OOPS-1318S626, OOPS-1321EB223 and OOPS-1318EA4
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1321EB223
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1318EA4
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1318S626
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1321EB223
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1318EA4
<matsubara> sinzui, what do you mean by not render the form? isn't the user using the api?
<sinzui> matsubara: you are correct, I am mistaken
<sinzui> I am not sure how to deal with that then.
<matsubara> sinzui, right. let's have bugs reported to those and then discuss in the bug tracker.
<matsubara> sinzui, thanks
<matsubara> We have two fix committed critical bugs
<matsubara> one which have been CP already
<matsubara> the other one is bug 389541
<ubottu> Launchpad bug 389541 in launchpad-foundations "Oops re-assigning bug to launchpad-registry project" [Critical,Fix committed] https://launchpad.net/bugs/389541
<matsubara> sinzui, are you going to request a CP for that one?
<matsubara> we had two script failures this week: garbo-hourly and librarian-gc
<matsubara> garbo-hourly has been fixed
<matsubara> no news about the librarian-gc
<sinzui> matsubara: I know nothing about that bug.
<matsubara> gary_poster, can you check why the librarian-gc failed and reply to the failure email sent to the internal list?
<gary_poster> matsubara: yes
<matsubara> sinzui, actually that's fix released already
<gary_poster> matsubara: (re librarian-gc, I'll ask flacoste or you for details later; I assume he has them)
<matsubara> [action] gary_poster to chase librarian-gc failure and report back to the list
<MootBot> ACTION received:  gary_poster to chase librarian-gc failure and report back to the list
<matsubara> gary_poster, right. ping me after the meeting and I can trawl some logs to find out the failure.
<gary_poster> matsubara: cool thanks
<matsubara> I think that's all for this section
<matsubara> thanks everyone
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> 2009-08-12 - We had no fewer than 8 cherry picks land.
<herb> Codebrowse (loggerhead) has regressed and is leaking memory again. I've re-opened bug #156453.
<herb> Despite our request to review the High & Triaged bugs on https://bugs.edge.launchpad.net/~canonical-losas, we haven't seen an update on any of them except the mailman issue (thanks barry).
<ubottu> Launchpad bug 156453 in loggerhead "production loggerhead branch leaks memory" [Critical,Confirmed] https://launchpad.net/bugs/156453
<herb> There is currently 1 cherry pick request that has been approved but failed testing (possibly spuriously) and 2 requests awaiting approval.
<herb> Finally, I wanted to mention that this will be my last meeting as a LOSA. Starting next week I will be moving over to a GSA role. But in return you'll get two new LOSAs who will both be more than capable of taking up what little slack is left by my transition. Chex will be moving over to join the LOSA team. And on Monday we get another new addition to the LOSA team as mbarnett starts.
<herb> Obviously I'll still be around, but since I won't be interfacing with all of you as directly as I do now, I wanted to take this opportunity to say thank you to everyone for your diligence, attention to detail and frankly all the hard work you all do to improve Launchpad and keep it running. So, thank you.
<mthaddon> we'll miss you, herb... /o\
<gary_poster> thank you herb, you'll be missed
<matsubara> rockstar, can you take a look at the codebrowse memory leak issue?
 * bigjools shakes herb's hand
<rockstar> matsubara, yeah, we've been doing a perpetual "take a look" at the memory leak.
<matsubara> rockstar, looks like it got worse recently
<rockstar> matsubara, yeah, looks like it.
<matsubara> gary_poster, intellectronica, rockstar: please look at the list of high and triaged bugs: https://bugs.edge.launchpad.net/~canonical-losas and see what can be done for 2.2.8 and 2.2.9
<gary_poster> matsubara, will do.
<intellectronica> matsubara: tbh, i looked last week already, and the conclusions was that pretty much nothing can be done for now :(
<matsubara> please either target them to a release or at least give some feedback to the losas in the report if those bugs can't be fixed before 2.2.9
<herb> even an update saying, we won't get to this before october is helpful.
<herb> then we know we can ping you in october about it. :)
<gary_poster> heh
<matsubara> intellectronica, right. if you say so in the bug report we'll have better expectation management :-)
<intellectronica> herb: sure, makes sense. also we then know to look again after 3.0 is out and we start scheduling new bugs again
<matsubara> perfect. thanks everyone
<herb> thanks everybody
<matsubara> herb, thank you for all your hard work. wish you luck in your new role!
<herb> ta
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> stub is sprint so i'll ask him to email the dba report to the list
<matsubara> [action] matsubara to ask stub to email the dba report to the list
<MootBot> ACTION received:  matsubara to ask stub to email the dba report to the list
<matsubara> and I think that's all for today
<Ursinha> nope
<matsubara> anything else before I close?
<Ursinha> I have something to ask
<matsubara> go ahead
<Ursinha> we're doing benchmark tests on basic navigation in Launchpad
<Ursinha> so, I've asked bigjools already, I wanted to know from you pages that are most likely to have timeouts
<Ursinha> rockstar, I'm already benching /launchpad and /launchpad/+activereviews
<Ursinha> rockstar, do you have any other suggestions?
<Ursinha> henninge, hi :) do you have suggestions for rosetta as well?
<matsubara> Ursinha, code.launchpad.net/launchpad/
<Ursinha> matsubara, as I told rockstar, I'm doing that already :)
<rockstar> Ursinha, no, I think you've got them then.
<bigjools> Ursinha: you got my suggestion, +queue ?
<Ursinha> matsubara, but thanks for the suggestion, do you have any others?
<Ursinha> bigjools, I took note, yes
<matsubara> there was a timeout on person code pages but that's been fixed by tim recently
<bigjools> cool
<Ursinha> thanks!
<Ursinha> matsubara, I know we had on +branches also, but tim fixed as well
<matsubara> I think that's the one I meant, IIRC
<henninge> Ursinha: For rosetta: POFile:+translate and DistroSeriesLanguage:+index
<Ursinha> intellectronica, what do you think?
<Ursinha> henninge, awesome, thanks!
<Ursinha> thanks rockstar
<matsubara> Ursinha, and look in the oops summaries if you're out of ideas
<intellectronica> Ursinha: don't know of the top of my head. we still have problems with bugs with many subscribers (though not the whole page times out)
<Ursinha> intellectronica, the portlet does?
<intellectronica> Ursinha: exactly
<Ursinha> maybe benching only the portlet
<Ursinha> intellectronica, can you take a quick look and tell me later about the timeouts you'd want me to bench, please?
<Ursinha> we're doing this today
<intellectronica> Ursinha: actually, i know there are some timeouts in +filebug lately. that's potentially quite serious
<Ursinha> intellectronica, I already created a test for /ubuntu/+filebug
<intellectronica> cool
<Ursinha> great
<Ursinha> sinzui, on registry side, do you have any suggestions?
<matsubara> Ursinha, bug 408457 is the one about the portlet timingout
<ubottu> Launchpad bug 408457 in malone "Launchpad unable to show subscribers for bug with 400 duplicates" [High,Triaged] https://launchpad.net/bugs/408457
<bigjools> Ursinha: oh one more, there's an XHR request for the PPA repo size that frequently times out
<Ursinha> matsubara, thanks
<sinzui> Ursinha: I have no suggestions
<Ursinha> sinzui, maybe milestone page...?
<matsubara> there's an open bug for timeouts on adminteammerge
<matsubara> but I guess it's not the kind of page you're looking for
<Ursinha> matsubara, I'm looking for pages of common usage
<sinzui> Ursinha: I have hacked that enough. The correct fix for that is to use ajax to retrieve rows in batches of 50. The rows are already engineered to do that in fact. The Javascript will take time away from 3.0, and my team is way behind because of other distractions
<Ursinha> thanks again
<Ursinha> okay sinzui, thanks
<Ursinha> that's fine then
<Ursinha> bigjools, I took note of the XHR one
<Ursinha> thanks
<Ursinha> that
<Ursinha> that's all from me
<matsubara> okay. thanks Ursinha
<Ursinha> thanks matsubara and all
<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:45.
<bigjools> cheers, spot on time
<herb> thanks matsubara, everyone.
<gary_poster> thanks matsubara
#launchpad-meeting 2009-08-14
<Ursinha> OOPS-1322EA278
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1322EA278
#launchpad-meeting 2010-08-18
<flacoste> me
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bigjools> me
<flacoste> me
<noodles775> me
<henninge> me
<gmb> me
<jelmer> me
<deryck> me
<adeuring> me
<sinzui> me
<EdwinGrubbs> me
<bac> gary, leonardr, mars: foundations ping
<leonardr> me
<danilos> me
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>   * Vote for one-import-per-line overwhelmingly passes
<bac>   * Congrats to Henning -- send him your UI reviews.
<bac>  * Peanut gallery
<bac> so last week i carried the vote on one-import-per-line to the AsiaPac meeting and it passed with flying colors
<bac> i've taken the task of updating the wiki and will do so this week
<bac> yesterday mars and i had a discussion and decided reviewers should not enforce the new formatting until we have some tool support to redo it.  it would be nice to get a tool written and do it all in one branch.
<gmb> Aaaa
<bac> anyone want to volunteer for that?
<gmb> bac, Not volunteering, but since it had passed I've seen it a few times already (and have asked for it once)
<bac> gmb: is that like "Aye"?
<gmb> Will that cause problems.
<gmb> s/./?
<bac> gmb: it should cause no problems.  i just think it is inhumane to ask someone to do it by hand.  /me is lazy.
<gmb> Right.
<gmb> And sadly, no. I wish I had the time to write a tool for this; I don't.
<bac> i actually wrote a tool last week during our sprint, working on the shipit debacle, that might be morphed into what we need.
<bac> so if no one else wants to tackle it, i'll look into it
<sinzui> find import (, read lines until ), split on ' ,' '\n    '.join(tokens)?
<bac> in addition to updating the wiki i'll send email to the list so community and non-reviewer canonical folks know about the policy
<bac> sinzui: yeah.  maybe with some sorting
<henninge> bac: I'll do it.
<bac> henninge: ok, great.
<bac> Many thanks to Henning for becoming a UI reviewer mentat!  Please send him your reviews.
<henninge> I am looking forward to that ;)
<bac> since stevek is now a reviewer, the asiapac meeting has moved to 0000Z.  sadly i'll have to cancel it today due to a prior appointment i have with lyle lovett tonight.
<bac> no other new topics today.
<bac> does anyone have something to bring up?
<bac> let's end early then.  thanks for coming.
<bac> #endmeeting
<MootBot> Meeting finished at 09:13.
<sinzui> thanks
<bac> hi henninge
<henninge> Hey bac ;)
<bac> henninge: when your tool is ready, are you also volunteering to do all of the formatting at once?
<henninge> bac: yes, thats what I planned.
<bac> henninge: good man
 * henninge likes big branches
<bac> brave and foolish, but good
<henninge> bac: as for scope
<henninge> bac: canonical.launchpad.* and lp.* ?
<bigjools> henninge: also do a tool to put it back in case we hate it :)
<henninge> bigjools: bzr revert
<bac> bigjools: nah, we'll make robert do it.  with nano.
<bac> henninge: that seems reasonable
<henninge> and only *.py files
<henninge> not doctests
<bac> henninge: yes, i think so
<henninge> cool, should be easy
<henninge> FLW
<henninge> ;-)
<bigjools> henninge: revert no good if loads of branches landed in the meantime :)
<bigjools> you know how fickle this team is :/
<henninge> oh no, he noticed ...
#launchpad-meeting 2017-08-14
<Spads> this is always the wrong window, for anything at all
