#launchpad-meeting 2006-08-28
<jamesh> ddaa: last week's minutes are here: https://launchpad.canonical.com/BazaarMeeting20060821
<ddaa> jamesh: thank you, I've read them already
<ddaa> MEETING STARTS
<ddaa> This is the Greenhouse meeting, on techniques of growing Bazaar branches in a Launchpad, if that means anything.
<ddaa> I am just coming back from vacation, so I'll let you guys do most of the talking today.
<ddaa> jamesh: thank you for last week's meeting minutes, it's very good.
<ddaa> == Agenda ==
<ddaa> * Roll call
<ddaa> * Production status
<ddaa> * Smart server
<ddaa> * Advertising
<ddaa> * vcs-imports knits
<ddaa> * Release finder
<ddaa> * Python import
<ddaa> * bzr lp://
<ddaa> * 1.0 targets
<ddaa> * Critical bugs
<ddaa> * Sysadmin tasks
<ddaa> * Any other business?
<ddaa> == Roll call ==
<ddaa> mpool apologized.
<spiv> I'm here
<lifeless> hi
<jamesh> I'm here
<ddaa> SteveA: hey?
<ddaa> SteveA late :P
<ddaa> == Production status ==
<ddaa> Anything to report?
<ddaa> jamesh: how is the future of oops-from-scripts looking?
<jamesh> haven't looked at it at all since last meeting
<ddaa> lifeless: do you know if jelmer fixed the bug in bzr-svn?
<lifeless> no
<ddaa> We would probably have to purge the filesystem data for his branch when he has fixed them.
<ddaa> ACTION: ddaa to bother jelmer about the bzr-svn bug
<lifeless> he should bump his namespace
<lifeless> the revisions are corrupt, no telling how far its spread
<jamesh> we still need to make sure data like that doesn't get past the puller
<ddaa> lifeless: know how we can achieve that? Past discussion we had about that I remember as inconclusive.
<lifeless> note it in the bug thats already open
<ddaa> ACTION: ddaa to resume discussion about filtering bad branches in the puller
<ddaa> == Smart server ==
<ddaa> mpool said: We've continued work, most recently pairing with Andrew on
<ddaa> letting it be run over ssh.  Andrew can report more.
<lifeless> ddaa: no, thats not what I said
<lifeless> ddaa: dude, I said 'jelmer should bump his revision namespace'
<ddaa> lifeless: okay, will say that in the bzr-svn bug
<ddaa> but there is the separate issue that jamesh mentioned
<ddaa> I'm happy not to fix it for now though.
<spiv> Right, so the code to run the protocol-so-far over SSH is basically there.
<lifeless> its not the pullers problem, I really think its purely a bzrlib bug if it happens, file a bug and we'll fix it
<spiv> Lots of the infrastructure for that has been submitted for merging to bzr.dev, and is ready to go into 0.11
<lifeless> talk with me after the meeting, so we dont block now. But I dont think we should design the bzrlib fetch code twice. It does not make sense.
<ddaa> lifeless: okay. But the puller should be able to recover w/o manual intervention, and I do not think I can ATM.
<ddaa> spiv: sounds great
<ddaa> == Advertising ==
<ddaa> spiv: should I make you the current owner of this task about blogging on similarities between SVN and bzr checkouts (in relation to Launchpad of course)?
<spiv> lifeless & mpool & I will be meeting in person tomorrow to continue work on the smart server.  lifeless has figured out some good goals w.r.t. supermirror integration and HTTP integration that's the next step.
<SteveA> hi
<SteveA> i'm on a public holiday
<jamesh> after the next rollout, we'll be able to advertise that --create-prefix isn't necessary anymore
<spiv> ddaa: yes, in fact I've actually got a draft already
<ddaa> Okay, sorry for not taking notes, I have not yet handled the email backlog.
<ddaa> SteveA: ^
<ddaa> When the fixes to the greenhouse UI are rolled out, I'll probably post something about that too. People have been asking for that for a long time.
<lifeless> greenhouse ?
<ddaa> launchpad-bazaar = greenhouse
<lifeless> did I miss something ?
<ddaa> There was some discussion in the past about that, sabdfl appeared keen to have a cute name, and I like a shorter name.
<ddaa> So I sent an email to the launchpad mailing list to "codify the status quo"
<lifeless> oh :(. Its about as good as dyson was IMO.
<ddaa> lifeless: I'll adopt anything you can agree on with sabdfl
<lifeless> how about launchpad-bazaar? Clear, precise, to the point.
<jamesh> ddaa: most areas of Launchpad are being debranded in the UI (e.g. blueprint => features), so at most it would be an internal codename
<SteveA> it will be called "code" in the launchpad UI
<ddaa> I'm not the one pushing for using cute code names. I'm merely trying to make the boss happy, and taking the opportunity to save a few keystrokes.
<SteveA> I see where you're coming from.  Honestly, I think it creates more keystrokes all round.
<SteveA> because people have to ask about it
<SteveA> and it isn't a "sticky in your mind" name like "rosetta"
<ddaa> SteveA: I'm happy to abandon "greenhouse", but please post a followup to my mail on the launchpad mailing list.
<ddaa> I have no desire to risk an argument with sabdfl about that issue.
<SteveA> I dont think it is even worth discussing
<jamesh> should we move on?
<ddaa> Okay, then the issue is closed.
<SteveA> we can just agree to use the obvious "launchpad-bazaar"
<ddaa> == vcs-imports knits ==
<ddaa> Apparently all deployed.
<ddaa> Still a couple of outstanding bzr branches. Have been reviewed, will act on reviews during the week and coordinate with lifeless about getting the patches in rocketfuel.
<ddaa> ACTION: ddaa to advance merging of outstanding bzr fixes into rocketfuel.
<SteveA> and we'll understand mark or others if they use "greenhose"
<ddaa> SteveA: ++
<SteveA> but we can choose to use "launchpad bazaar"
<ddaa> lifeless: anything interesting to report about the progress of those patch in the bazaarsphere?
<lifeless> ddaa: they are both in the stack of patches spiv is managing
<ddaa> spiv: does that mean that I do not have to do any more on those patches?
<ddaa> silence is consent
<ddaa> == Release finder ==
<ddaa> jamesh: did stub do a test run on staging this week, as reported on the last meeting?
<jamesh> yes
<spiv> I don't know anything about ddaa's upgrade-no-workingtree branch
<ddaa> spiv: okay, then I'll apply some traction there.
<spiv> But the list_dir one I'm on top of, yes.
<jamesh> ran into another bug (bug 57220), which I'm working on a fix for
<jamesh> hopefully we'll complete a full run with that problem fixed.
<lifeless> spiv: I referred it to you in reply to a mail from John on the list. 
<spiv> lifeless: Thanks, I'll take a look
<ddaa> jamesh: good, so next week I'll ask about the outcome of the full staging run
<jamesh> yep
<ddaa> == Python import ==
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/56360
<ddaa> Was on leave, so made no progress on that.
<ddaa> Plan to look at this problem, but after acting on outstanding patches and giving spec feedback. Probably not come around to it this week.
<ddaa> == bzr lp:// ==
<ddaa> Last week's action were:
<ddaa> spiv: read the spec
<ddaa> mpool: read/integrate comments
<ddaa> Progress?
<spiv> I'm pretty sure I gave feedback on the spec.
<spiv> Yeah, I did.
<jamesh> you appear to have, yes.
<ddaa> Okay, so the ball is in mpool's camp.
<spiv> Yep.
<ddaa> ACTION: mpool to read/integrate comments on BranchIndirection
<ddaa> == 1.0 targets ==
<ddaa> smart server: is that still on track for the end-of-month deadline?
<ddaa> importd bzr transition: the essential functionality was delivered. I'd like to put that on hold until we have the new hire, and have him do the Arch support wipeout.
<ddaa> SteveA: is that okay? Hom to update the spec?
<ddaa> bzr-roundtrip-svn: in my understanding, we will achieve that by replacing cscvs by bzr-svn when/if we feel comfortable enough with that. 
<lifeless> I thought roundtrip was cancelled for now
<ddaa> roundtrip-svn: that means the status of this spec should be changed, since no further action is expected before 1.0
<ddaa> I got heat from sabdfl by closing the spec as "not for us", because it means something specific to ubuntu folks.
<ddaa> So I restored it to the previous status.
<lifeless> apparently it means 'never'
<lifeless> as roundtrip is clearly a nice thing to do if we ever get around to it, I'd say 'low'
<ddaa> quoting sabdfl:
<ddaa>  "Not for us" has a specific meaning, in the text of any spec with that status you will see it. Basically it means "this spec is regarded as pointless and not interesting to the project managers, we will not land any code for this even if you contribute it". 
<ddaa> If you want to say "we are not going to work on this now", then Lowpriority would be more appropriate.
<jamesh> "not for us" was coined as a nicer way of saying bugger off
<ddaa> Should we also remove the 1.0 target as well?
<jamesh> if it isn't a 1.0 target anymore, then I'd guess so
<ddaa> I'd guess so, but you know what you say about burned cats.
<ddaa> spiv: is smart-server on track for the end-of-month deadline?
<ddaa> SteveA: do you agree on postponing Arch cleanups to give to the new recruit?
<lifeless> SteveA is not here
<lifeless> the smart server is not complete.
<ddaa> Ah, right. On holiday...
<SteveA> ddaa: I have no idea of how extensive the arch cleanups are
<lifeless> we're aiming to land the core transport and get launchpad support for it in side the 0.11 dev cycle
<SteveA> as in, how long it would take one knowledgeable, capable person to do so
<spiv> What lifeless said :)
<ddaa> lifeless: does that leave enough room to get it up on launchpad by the end of the month?
<lifeless> no
<lifeless> 'not finished'
<ddaa> So I think we need to say this spec will be late. Okay.
<jamesh> end of the month is 3 days away
<ddaa> jamesh: I mean the end of next month :)
<lifeless> ddaa: then you might have said
<lifeless> yes, we will have the core support rolled out by end of next month
* spiv agrees
<lifeless> IF things go smoothly, that might include the performance improvements too
<ddaa> SteveA: I think a couple of days for me. It's large and sweeping but simple now. I'm suggesting to postpone because I think that's a good exercice for the new recruit to see a lot of the importd code.
<lifeless> this is my compatriot ?
<ddaa> lifeless: I think it would be good to get something up on launchpad once there is working code, so we can shake down potential operational issues in parallel with performance improvements.
<ddaa> well, s/we/spiv/
<ddaa> lifeless: yes
<lifeless> ddaa: we have a plan for that that is low risk, and staged
<lifeless> ddaa: can we move on?
<ddaa> I'm still not clear on whether the feature is on target, but let's move on.
<ddaa> == Critical bugs ==
<ddaa> https://launchpad.net/bugs/31308 Cannot set branch associated to a product series.
<ddaa> https://launchpad.net/bugs/37897 renaming project, product or series breaks vcs imports.
<ddaa> https://launchpad.net/bugs/51130 cannot use +admin on a branch I own
<ddaa> I plan to act on reviews for 37897 and 51130 this week.
<ddaa> Plan to start work on 31308 after that and spec feedback, so late this week or early next week along with bug 56360.
<ddaa> IOW, I do not plan to do any new stuff this week.
<ddaa> == Sysadmin tasks ==
<ddaa> == Any other business? ==
<jamesh> none from me
<ddaa> mbp said something about
<ddaa> new item: Strategic planning document: mbp will need feedback on this
<ddaa> from people in the launchpad-bazaar team; watch for mail in next couple
<ddaa> of days.  If you have ideas let me know.
<ddaa> Not sure exactly what that means, but I think it's related to the post-1.0 planning discussion.
<lifeless> its not
<lifeless> watch for a mail
<ddaa> Okay. Then if there's nothing more to discuss
<ddaa> the bazhouse meeting can be closed
<ddaa> or the greenzaar
<ddaa> MEETING CLOSED
<ddaa> Thank you everybody for attending.
<ddaa> oh right
<ddaa> ACTION: spiv and ddaa to review PrivateBranches again
<ddaa> I think I saw something from spiv recently, will try to do my part this week too.
<SteveA> ddaa: so, I don't think doing the arch removal stuff is good material for the new bzr=launchpad recruit
<SteveA> i think implementing private branches would be better, for example
<ddaa> Okay, if that's what you think.
<ddaa> We'll talk next week about how to prioritize that work against the Python import and the native-productseries-branch thing.
<SteveA> ok
<SteveA> to save me asking tomorrow...
<SteveA> what do you plan to do during this week?
<ddaa> Email catchup
<ddaa> Reply to reviews, try to get outstanding branches merged.
<ddaa> I have a lot of those.
<ddaa> So I expect that to keep me busy until friday at least. I may have some time at the end of the week to start doing some new stuff.
<SteveA> what are the branches?
<ddaa> david/bzr/upgrade-no-workingtree
<ddaa> david/launchpad/importd-bzr-native
<ddaa> david/launchpad/branch-edit
<ddaa> david/launchpad/importd-publish-source
<ddaa> The latter is going to need some doing to deploy too.
<ddaa> Also, do PrivateBranches spec review and maybe some BranchIndirection.
<ddaa> SteveA: sounds reasonable?
<SteveA> what is branch-edit about?
<ddaa> Letting people change the name, owner and product of branches.
<SteveA> ok
<SteveA> I've got a lot on this week, but I'd like to keep up with how these things are going
<SteveA> would you ping me occassionally on irc for a brief chat about how things are going?
<ddaa> If you wish, I can report daily.
<ddaa> But I expect that to be relatively uneventful.
<SteveA> that's fine
<SteveA> thanks!
<ddaa> have a nice holiday
<ddaa> and get away from the computer
<SteveA> thanks, and I will
#launchpad-meeting 2008-08-26
<barry_> #startmeeting
 * barry_ kicks mootbot
<barry_> hi everybody and welcome to this week's asiapac meeting.  who's here today?
 * barry_ knows tim's not here
<barry_> jml, mwhudson ping?
 * barry_ slinks off
<barry_> #endmeeting
<sinzui> Ha
#launchpad-meeting 2008-08-27
<barry> #startmeeting
 * barry sighs
<abentley> me
<barry> hello everyone and welcome to this week's ameu reviewers meeting.  who's here today?
<intellectronica> i
<abentley> you
<bac> me
<intellectronica> barry: gmb and allenap are on leave, BjornT is sprinting
<barry> intellectronica: thanks for the update
<barry> salgado, sinzui ping
<salgado> me
<cprov> me
<barry> EdwinGrubbs: ping
<barry> danilo_: ping
<EdwinGrubbs> me
<sinzui> me
<barry> cprov: ping
<danilo_> me
 * sinzui was getting coffee
<cprov> barry: I'm here ;)
<barry> cprov: :)
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>    * watch for dead end links ([[https://bugs.edge.launchpad.net/launchpad/+bug/254436|bug 254436]] - flacoste)
<ubottu> Launchpad bug 254436 in launchpad "Launchpad contains lots of dead-end links" [Undecided,Incomplete]
<ubottu> Launchpad bug 254436 in launchpad "Launchpad contains lots of dead-end links" [Undecided,Incomplete] https://launchpad.net/bugs/254436
<barry>    * watch out for config or other changes w/ possible operational effects
<barry>    * ideas for encouraging branches which cleanup/reduce tech debt
<barry> week += 1?  if you know you won't be here, please update the wiki page
 * barry thanks allenap for sending his apologies
<intellectronica> i won't be here
<barry> intellectronica: cool, thanks
<barry> [TOPIC] action items
<barry>  * abentley to update UsingMergeProposals with the extra approval step
<abentley> I believe I did that.
<barry> abentley: cool, thanks
<barry> [TOPIC] queue status
<barry> nothin' much from me on this.  does anybody have any comments here?
<danilos> well, I broke the pending-reviews page for everybody on Friday
<sinzui> how?
<danilos> so, it didn't get updated until yesterday
<barry> oh noes!
 * sinzui noted it did not update for 48 hours
<intellectronica> danilos: how did you do that?
<intellectronica> (just so we know what not to do)
<danilos> I did a "bzr upgrade" on my repo, it apparently didn't finish, and left my repo in a limbo state; I haven't noticed it broke anything until it was too late (rm -rf backup.bzr)
<danilos> intellectronica: ^^
<danilos> so, I moved all of my branches out of the way in PendingReviews for it to start working again
<barry> abentley: what's the current state of mars's remove-structural-objects-ui branch?  are you waiting on me?
 * barry notices it has 8 conflicts now
<abentley> barry: I thought mars was the next person to take action.
<mars> that's what I thought as well
<barry> abentley: it's still in needs-review state so if it's merge-*, just update PendingReviews
 * barry issues another plea to remove branch summaries from PR when they've landed
<abentley> barry: okay
<barry> [TOPIC] mentoring update
<barry> i just wanted to mention that we have slots open, so if anybody has a reviewer nominee in mind, please let me know
<barry> [TOPIC] review process
<barry> flacoste isn't here so we'll carry his forward
<barry>    * watch out for config or other changes w/ possible operational effects
<barry> did anybody not catch the recent thread on config file changes breaking operations?
<sinzui> On a related note, I should have ask for rsync to pull the oops reports from xmlrpc-private.
<barry> cool, i guess everyone saw it.  so when you're reviewing just keep an eye out for changes (such as to configs, scripts, etc) that the LOSAs might need to be aware of, and please point that out in your reviews
<barry>    * ideas for encouraging branches which cleanup/reduce tech debt
<intellectronica> i don't think we should encourage them
<barry> intellectronica: go ahead
<intellectronica> tbh, i really don't like it when we mix new developments with cleanups. it makes reviewing harder
<barry> intellectronica: do you mean drive-bys or separate cleanup-only branches?
<intellectronica> i much rather review a branch which /only/ cleans up, in addition to a branch which introduces new work
<intellectronica> barry: i mean drive-bys
<sinzui> I like to clean up technical-debt in a preliminary branch that setup up my next branch.
<intellectronica> individual branches with cleanups are great, of course
<barry> intellectronica: cool.  this btw is in reference to joey's push for reducing our tech debt
<barry> sinzui: that's a good idea
<barry> intellectronica: so let's concentrate on cleanup-only branches
<barry> i'd love to have your thoughts on how we can do more cleanup-only branches
<barry> why do we tend not to do them?
<intellectronica> i think one thing we can do it, is that if in a review we notice something that we think should be cleaned up, insist on opening a bug, and following up on it (making sure that it's at the very least scheduled, if not completed immidiately after the original branch)
<cprov> can't we list related XXX in `make lint` ? that would encourage 'drive-by-cleanups', no ?
<abentley> barry: I would think it's because we tend to encounter cleanup opportunities in the course of new development.
<abentley> And starting a new branch for the cleanup feels like a lot of overhead.
<intellectronica> cprov: that can be annoying, like that sample data experiment
<abentley> looms reduce that overhead, of course.
<barry> intellectronica: very often i'll ask to open a bug for a deferred cleanup, but we don't seem to get around to it
<intellectronica> abentley: overhead? starting new branches is cheap as chips
<cprov> well, 'encourage' in that context would be more like 'force' and that might become hard to handle in content-class changes, for instance.
<barry> abentley: i think that's a good observation.  maybe looms is one technique for reducing that overhead
<barry> as you point out
<abentley> intellectronica: I'm not talking about IO time.
<abentley> I'm talking about effort.
<sinzui> lint could report XXX, but I'm not sure that helps up to know when we have an opportunity to remove an XX
<abentley> Now you're working on two branches instead of one, and you have to get both reviewed and merged..
<cprov> sinzui: that's true, XXX related with the fix might be in a untouched file.
<intellectronica> abentley: looms solve the problem for you locally, then you can export separate branches from them for reviewing
 * sinzui should put the XXX report into Makefile so that we can easily where they are and how they releate.
<abentley> intellectronica: I know, because I wrote the export functionality.
<intellectronica> :)
<barry> [ACTION] sinzui should put the XXX report into Makefile so that we can easily where they are and how they releate.
<sinzui> I guess I can work on my porn branch today
<barry> sinzui: rs=barry
<barry> does anybody think that we're so feature-driven that you don't have time to do the cleanup branches you want to do?
<abentley> barry: I think we *were* when I joined.
<abentley> (January)
<barry> abentley: but no more?
<sinzui> A pre-imp call is the best time to discuss closing XXX's
<abentley> barry: No impending major release hanging over our heads now.  Feels like there's some breathing room.
<barry> abentley: i ask because in foundations, we're planning 20% of our coding time for 2.1.9 to reducing the tech debt
<barry> i'm curious if other teams are doing the same?
<abentley> barry: Code team's big focus is scalability.  We must become scalable before we run out of disk space in October or so.
<barry> what do people think about an lp tag 'cleanup' so we can easily find the bugs related to cleanups?
<abentley> I don't think we're working on a 20% rule per se, but cleanups (authserver => internal xmlrpc) are happening now.
<barry> abentley: thx
<intellectronica> barry: i don't know if that's a very good name, but +1 for having a tag
<intellectronica> cleanup can mean so many things
<intellectronica> maybe 'tech-debt'?
<barry> intellectronica: i'll email the list for better suggestions :)
<intellectronica> anyway, we can discuss on the list
<barry> let me also invite you to email me or irc/skype if you have any thoughts on changes to our process that would allow us to regularly pay down this debt
<intellectronica> maybe we should also propose some ritual way of following up on cleanup opportunities that came up in reviews
<barry> i'm /very/ keen on doing this before we go open source
<barry> intellectronica: any thoughts on how that would work?
<intellectronica> for example, a weekly report on cleanup actions from each team
<barry> intellectronica: maybe in the general lp meeting?
<intellectronica> maybe, although, that would encourage /short/ reports
<danilos> barry: jtv and myself have planned to do cleanup sprints, but that has probably been discussed already
<barry> danilos: yes, i think those are really good ideas, especially for big ticket items
<barry> like tree reorg and such
<barry> another (leading) question: does anybody feel that some kind of reward system would help, hurt, or be neutral in getting cleanups done?
<danilos> barry: right, but you can also do much more easy cleanups when you don't have to worry about being constantly available, and when you have the entire team next to you
<barry> danilos: high bandwidth pair-programming and insta-reviews
<danilos> barry: indeed  :)
<bac> barry: what about bringing back Fix it Friday for tech-debt issues?
<barry> bac: i like that idea
<sinzui> I think we need to introduce Darma, We need to do our job of closing technical debt to earn it
<barry> [ACTION] barry will propose a new bug tag for paying down tech debt
<abentley> barry: I'm worried about productivity loss.  Already, I'm only coding 4 days out of 5.
<intellectronica> bac: although i never took part in it (it was stopped just after i joined) i must say that i find the segregation to one week-day to be a bit strange. did you have a good impression from that while it was on?
<barry> abentley: of course, you would still be coding, but just not on a specific feature
<sinzui> abentley: that is the downside of being a reviewer.
<barry> abentley: but i get what you're saying
<sinzui> abentley: I agree that each developer needs the power to say no so that he can focus on code.
<barry> although remember, it's total team throughput that we want to measure
<bac> intellectronica: i did have some good experiences.  the aspect that it is a single day is odd, but the idea that the team would encourage clean-up activity was rewarding.
<barry> and don't cleanup branches feel GOOD? :)
<bac> intellectronica: we could do something similar.  let a dev pick his day.
<sinzui> massive deletes are very cathartic.
<barry> bac: kind of like on-call
<abentley> barry: Yeah, but I can choose to do cleanup any time.
<bac> barry: sure, but not so formal, i'd think
<abentley> This would actually discourage me from doing cleanup except on fridays.
 * barry nods
<bac> abentley: it's just a gimick, but perhaps a useful one.  individuals can choose to manage their time however they and their team wants.
<abentley> I think the right way to do this is to ensure team leads give tech debt a high priority.  Then they can make sure their team gives it enough focus.
<bac> abentley: i agree with that.  and i was gratified to see the time blocked out on the foundations schedule.
<barry> we're running out of time, so let me wrap this up for today.  i really want to thank everyone for their ideas.  i'll continue the discussion on the ml, so please do keep thinking about it
<abentley> quick note: People may have noticed that review-submit is generating out-of-date MoinMoin markup.  I have a branch in the queue to fix that.
<barry> in the last 2 minutes, does anybody have any other topics not on the agenda?
<barry> abentley: excellent, thanks
<barry> okay, that's it then
<barry> #endmeeting
<barry> thanks very much everybody!
<intellectronica> thanks barry
<Rinchen> we will give tech debt a high priority :-)
<abentley> thanks barry.
<barry> Rinchen !
<Rinchen> working rule of thumb is about 20% of the cycle
<barry> Rinchen: -> #lp-code?
#launchpad-meeting 2008-08-28
<matsubara> ok
<matsubara> it's that time
<matsubara> #startmeeting
<mthaddon> here
 * matsubara pokes MootBot 
<matsubara> bah
<matsubara> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<matsubara> [TOPIC] Roll Call
<matsubara> who's here today?
<sinzui> me
<bac> me
<barry> me
<mwhudson> me
<mars> me
<adeuring> me
<mthaddon> me
<allenap> me
<intellectronica> me
<matsubara> Ursinha: ?
<EdwinGrubbs> me
<Ursinha> me
<cprov> me
 * \sh 's lurking to catch some news about the api ;)
<matsubara> please check that your teams are here
<matsubara> salgado: ?
<salgado> me
<matsubara> releases is here
<bac> leonardr: meeting ping
<abentley> me
<intellectronica> matsubara: bugs are here minus BjornT (sprinting) and gmb (holiday)
<matsubara> so, we're missing code, foundations, losas, soyuz.
<matsubara> cprov: you're the only one from soyuz, is that right?
<cprov> soyuz is - bigjools (sprinting) - al-maisan (apologies)
<matsubara> mthaddon: only you from losas?
<mthaddon> matsubara, herb's on holiday this week, spm is asleep :)
<matsubara> danilos: ?
<matsubara> mthaddon: okie
<bac> foundations is here minus flacoste (sprinting), leonardr, and stub
<stub> me!
<matsubara> hmm I forgot the apologies section
<matsubara> # Team Leads (sprinting)
<matsubara> # herb
<matsubara> # gmb
<matsubara> # sinzui
<matsubara> # mwhudson
<matsubara> # mrevell
<mwhudson> rockstar: ping
<mwhudson> (i am here anyway!)
 * sinzui is still here
<matsubara> okie, let's move on, we have at least one representative from each team
<matsubara> [TOPIC] Agenda
<matsubara>  * Next meeting
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs (matsubara/ursinha)
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (stub)
<matsubara>  * Sysadmin requests (Rinchen)
<matsubara>  * New packages required (salgado)
<matsubara> same bat-time, bat-channel next week?
<Ursinha> +1
<rockstar> me
<intellectronica> bat-?
<matsubara> all right, no complains is good.
<matsubara> intellectronica: that's a joke. maybe it only works for brazilians.
<intellectronica> matsubara: apologies, i won't be here - i'm going on a much needed holiday
<matsubara> intellectronica: nm that ;-)
<abentley> intellectronica: http://en.wikipedia.org/wiki/Batman_(TV_series)
<matsubara> abentley: exactly :-)
<matsubara> intellectronica: ok. please add yourself to the apologies list
<intellectronica> abentley: cheers for the cultural reference
<matsubara> [TOPIC] Actions from last meeting
<matsubara> * LOSAs to contact LP Devs ASAP when staging gdb breakpoint reached for interactive debugging.
<matsubara> mthaddon: any news about that ^?
<mwhudson> yeah, i made some comments on the bug
<mwhudson> https://bugs.edge.launchpad.net/launchpad/+bug/247227
<ubottu> Error: This bug is private
<mthaddon> matsubara, we've had a good gdb dump and it's suggested an upgrade to psycopg2
<mthaddon> matsubara, which is in progress
<matsubara> all right, so the interactive debugging was done and we moved forward with the bug. cool. thanks mthaddon and mwhudson!
<mwhudson> although i had a chat with jamesh about that yesterday, and maybe maybe it's a bug in zope
<mwhudson> (it's pretty a pretty subtle issue)
<matsubara> mwhudson: right.
<matsubara> mwhudson: do you need any more input from LOSAS re: interactive debbuging?
<matsubara> ok, let's move on and that can be discussed in the bug report.
<mwhudson> no
<matsubara>  * Oops report & Critical Bugs (matsubara/ursinha)
<mwhudson> (more stacktraces would still be interesting)
 * Ursinha waves
<Ursinha> okay guys, i'll merge bugs and critical bugs into one today
<Ursinha> this is gonna be tough: 8 bugs, of these, 1 candidate to critical (CC), 2 critical (C)
<Ursinha> the bugs: 3 for foundations (262328, 261915 (CC), 259440 (C)), 2 for code (260206, 260140), 1 for bugs (252947), 1 shipit (259947) and 1 for translations (261507) (C)
<Ursinha> foundations first
<Ursinha> bug 262328 (leonardr?)
<ubottu> Launchpad bug 262328 in launchpad "API oopsing with UnicodeEncodeError " [High,Triaged] https://launchpad.net/bugs/262328
<Ursinha>  bug 261915 (+participation) (CC) - let's make it critical?
<ubottu> Bug 261915 on http://launchpad.net/bugs/261915 is private
<Ursinha> bug 259440 (MailinglistApiView) (C)
<ubottu> Launchpad bug 259440 in launchpad "OOPS in MailingListAPIView" [Critical,In progress] https://launchpad.net/bugs/259440
<barry> i'm working on it.  stub helped me with the magic to cut the queries in about 1/4 in the test suite
<Ursinha> ok barry, thanks
<barry> but mthaddon reports that it's still oopsing on staging
<barry> so still working on it
<matsubara> salgado: should the bug in +participation be made critical?
<salgado> matsubara, the bug won't stop the OOPSes
<mthaddon> barry, have you had a chance to look at the logs yet, or after meeting?
<barry> mthaddon: after the meeting
<salgado> matsubara, I mean, fixing the bug won't stop them
<salgado> matsubara, to stop them we need to get approval to run the SQL script I posted yesterday night to launchpad@
<Ursinha> barry, it's indeed oopsing on staging
<matsubara> salgado: I was expecting that the resolution to the bug would include the page stop oopsing :-)
<Ursinha> barry, thanks for taking care of it
<barry> Ursinha: we may have to take a more radical approach then :/
<matsubara> salgado: oh right, I see. and all the people that can approve it are meeting now :-/
<salgado> matsubara, there's no need to wait for the bug resolution to run the SQL script
<salgado> matsubara, correct
<intellectronica> zorry. got disco
<matsubara> salgado: maybe stub could approve that query?
<matsubara> can you stub?
<Ursinha> salgado, but it may be raised to critical?
<salgado> Ursinha, the bug is not critical, IMO
<salgado> fixing the data is
<stub> Which query is this?
<Ursinha> salgado, got it
<stub> I like to see things before I approve them ;)
<salgado> stub, https://pastebin.canonical.com/8613/plain/
<salgado> stub, seeing stuff before approving is for wussies ;)
<matsubara> Ursinha: what else?
<stub> Approved. No idea if it is correct, but we can always rebuild that table from scratch if we mess it up too much.
<Ursinha> may i change to code?
<matsubara> Ursinha: go ahead, it's better to parallelize things in this section otherwise we take the whole meeting time
<salgado> stub, thanks. I'll coordinate with mthaddon to try it on staging first, btw
<stub> A run on staging first wouldn't hurt though ;)
<Ursinha> ok
<Ursinha> now, for code
<mwhudson> Ursinha: i'll take 260206
<Ursinha>  bug 260206 (another resolve_lp_path problem, maybe mwhudson?), and bug 260140 (revisions.atom), how's that?
<ubottu> Launchpad bug 260206 in launchpad-bazaar "resolve_lp_path oopses with ValueError" [Medium,Confirmed] https://launchpad.net/bugs/260206
<ubottu> Bug 260140 on http://launchpad.net/bugs/260140 is private
<Ursinha> thanks mwhudson
<Ursinha> very fast :_
<Ursinha> :)
<mwhudson> revisions.atom is thumper's
<Ursinha> and he's not here
<matsubara> [ACTION] stub approved salgado query to be run on production db, after salgado has run it on staging to check everything works as expected
<rockstar> As far as I know, thumper is still working on revisions.atom
<Ursinha> rockstar, thanks for the info
<Ursinha> moving on
<Ursinha> now, bugs
<Ursinha> bug 252674 - the bugs/+index pain
<ubottu> Bug 252674 on http://launchpad.net/bugs/252674 is private
<Ursinha> i'd like to know how is that, someone from bugs?
<matsubara> intellectronica: ^
<intellectronica> Ursinha: i think BjornT was working on this
<intellectronica> obviously he's sprinting now, so i guess it's delayed
<Ursinha> intellectronica, i'll ask him later so
<Ursinha> intellectronica, thanks
<Ursinha> the one for translations, a critical, bug 261507
<ubottu> Bug 261507 on http://launchpad.net/bugs/261507 is private
<Ursinha> jtv or danilos, what is the status? it seems half-fixed reading the bugs comments
<Ursinha> danilos, ?
<intellectronica> Ursinha: looks like they're both MIA, you'll have to ask them later
<matsubara> jtv is sprinting and danilos doesn't seem to be here
<Ursinha> i'll ask them later too
<Ursinha> and the latest shipit strange bug:  bzr_version_info.py not found bug - bug 259947
<ubottu> Bug 259947 on http://launchpad.net/bugs/259947 is private
<matsubara> [ACTION] Ursinha to ask danilo /jtv about bug 261507
<ubottu> Bug 261507 on http://launchpad.net/bugs/261507 is private
<Ursinha> how's that going, it keeps happening from time to time
<matsubara> [ACTION] Ursinha to ask Bjornt about bug 252674
<ubottu> Bug 252674 on http://launchpad.net/bugs/252674 is private
<Ursinha> mthaddon, ^
<Ursinha> oh man
<Ursinha> ok
<matsubara> Ursinha: did it happen again lately?
<Ursinha> a few times
<Ursinha> it's sporadic
<Ursinha> anyway, i'll ask mthaddon later too
<Ursinha> that's all for now, thanks anyway guys
<matsubara> ok. thanks Ursinha
<matsubara>  * Operations report (mthaddon/herb/spm)
<mthaddon> â¢ App servers dying with pidfile seems to have been traced to psycopg2, so that's hopeful - SA working with packagers to get that taken care of - mentioned earlier in the meeting
<mthaddon> â¢ Had one CP this week, to codehosting
<mthaddon> â¢ Codebrowse has been giving us problems since 2.1.8, but I think mwhudson has identified the issue
<mthaddon> â¢ MailingListApi OOPSes are a real problem in terms of the amount of space the OOPSes use up (on production and staging, esp as logs are synced) - mentioned earlier in the meeting
<mthaddon> â¢ That's about it from herb, spm and I unless there are any questions
<Ursinha> so here is the man
<matsubara> any questions?
<matsubara> moving on
<matsubara>  * DBA report (stub)
<stub> Growth of the Librarian has been noticed. I sent out a report on the break down of usage. We should set the expiry date on the LibraryFileAlias when possible, which will allow the garbage collector to remove the file from disk when it is no longer needed. The entries remain in the database - just rendering the LibraryFileAlias will give a (deleted) marker instead of a hyperlink and the Librarian will give 404s if someone attempts to retriev
<stub> I've still got a branch landing blocked on psycopg2 being upgraded on the PQM environment, and we won't know if the bug fixed version solves our appserver crashes until we try. As launchpad-database-dependancies has been updated, devs should already be running the updated version. Tracked in RT #31577
<stub> losas are moving the db graphs from cricket to their new system, which is great. Generating all the metrics every 10 mins is a big load, and now we will be able to do most of them once per day, which is all we need for the trends.
<stub> oot
<matsubara> thanks stub
<matsubara> and thanks mthaddon, forgot to say in the previous section
<matsubara>  * Sysadmin requests (Rinchen)
<mthaddon> matsubara, I'll survive
<matsubara> anyone blocked on RT requests?
<stub> RT #31577 as mentioned two or three times this meeting :)
<matsubara> pass them on to me and I'll follow up with IS/Joey
<matsubara> stub: yep, noted that.
<matsubara> ok, moving on.
<matsubara>  * New packages required (salgado)
<salgado> anything this week?
<salgado> matsubara, quick, move on!
<salgado> before kiko shows up
<matsubara> okie, thanks salgado
<matsubara> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
<matsubara> unless there's something else?
<matsubara> #endmeeting
<mwhudson> thanks matsubara
<intellectronica> matsubara: thanks, great meeting!
<barry> matsubara: thanks!
<bac> thanks matsubara and Ursinha
<Ursinha> matsubara, great job! :)
<stub> salgado, mthaddon: Should I run salgados SQL or will a losa be handling it?
<stub> Oh.. nm....
<Ursinha> everybody is gone
<Ursinha> it's sad
<stub> Its bed time
#launchpad-meeting 2008-08-29
 * allenap is having problems with xchat crashing.
 * e-jat brb .. zzZZzz sleepy .. 
 * e-jat back .. 
#launchpad-meeting 2009-08-26
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everyone and welcome to this week's ameu launchpad reviewer's meeting. who's here today?
<bigjools> me
<gmb> me
<EdwinGrubbs> me
<noodles775> me
<bac> me
<deryck> me
<beuno> me
<cprov> me
<henninge> me
<jtv> me
<barry> adeuring, leonardr, salgado ping
<danilos> me
<barry> mars and sinzui send their apologies
<salgado> me
<adeuring> whoops, me
<barry> allenap: ping
<leonardr> ping
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Action items
<barry>  * UI review call update
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry>  
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * beuno to add a 'ui' specialty to ReviewerSchedule
<beuno> did not do it  :(
<beuno> will do today
<beuno> PROMISE
<allenap> me
<barry> beuno: thanks!  i was asked at our standup who our mentors and mentats were and i just can't remember ;)
<beuno> UI mentor, just me for now
<beuno> I will graduate people
<barry> cool
<barry>  * gary_poster and barry will transfer review guidelines from the old wiki and old old wiki to the new wiki
<barry> not done
<barry> i will work on this this week
<barry> [TOPIC]  * UI review call update
<MootBot> New Topic:   * UI review call update
<barry> beuno: do you want to give an update?
<beuno> so
<beuno> we continued to talk about what works and what doesn't
<beuno> and I have a lot of notes that I need to update the wiki with
<barry> beuno: how well do you think reviews are going these days?  how is ui 3.0 shaping up?
<beuno> I think they are going very well
<beuno> and that 3.0 is shaping up much better than I expected
<intellectronica> me
<beuno> developers are very involved in taking decisions
<beuno> the navigation changes are in place, which is a big one
<barry> beuno: do you think we're going to hit our ui 3.0 deadline?
<beuno> barry, I don't think well hit 100% of the pages for Sept
<beuno> but pretty close
<barry> cool.  beuno anything else, or does anybody have any other questions or issues about ui reviews?
<barry> okay, moving on...
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<barry> any other topics not on the agenda?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> cool.  thanks everyone, and thanks for all the great reviewing everyone's doing.
<barry> #endmeeting
<MootBot> Meeting finished at 09:15.
<bigjools> thanks barry
<jml> what, huh?
<jml> no meeting?
<jml> barry, hi
<jml> we're 20+ minutes late, right?
<barry> jml: yes, my apologies
<barry> we'll start in a minute
<jml> barry, no worries, I just wanted to check :)
<barry> #startmeeting
<MootBot> Meeting started at 17:54. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> jml, thumper, rockstar, mwhudson hi! welcome to this week's asiapac reviewer's meeting.  how are you guys doing?
<thumper> here
<jml> hello
<rockstar> ni!
<mwhudson> hello
<jml> I'm well thank you
<jml> rockstar, when did you move to asiapac?
 * mwhudson is under an email molehill rather than a mountain
<barry> jml: settling into your new position yet?
<jml> barry, "settling", hmm not quite
<wgrant> New position?
<jml> barry, I'm more like a pioneer on my long trek west
<barry> rockstar: joined us here a few weeks ago
<jml> barry, to borrow a myth from your country :)
<barry> :)
<barry> wgrant: welcome!
<rockstar> jml, this way, I can get my morning chores done in the morning.
<wgrant> Morning barry.
<barry> so... not much really to speak of in the ameu meeting
<jml> wgrant, the public announcement should come out soon
<barry> beuno updated the ReviewerSchedule page with the ui mentats
<barry> beuno is the only full fledged ui reviewer but he is going to do some graduations soon
<mwhudson> barry: anything happen in reviewer meeting land in the last 3 weeks?
<mwhudson> barry: jml and i haven't been here
<barry> mwhudson: not much really.  we've been having very short meetings in both timezones
<mwhudson> barry: hooray
<barry> so, i'll just open up the floor.  what's on y'all's mind today?
<mwhudson> "gosh, we get a lot of email"
#launchpad-meeting 2009-08-27
<barry> mwhudson: heh
 * barry laughs when he hears of people complaining about a few hundred messages a day
 * jml thinks...
<jml> any feedback from non-Canonical contributors about the review process?
 * barry looks at wgrant
<mwhudson> i guess i can take the opportunity to do a little survey
<wgrant> barry: Working well for me.
<barry> i'll just say again that it is /fantastic/ to see yours and others from the community landing branches
<wgrant> It's great to finally be able to!
<mwhudson> as build engineer for the next cycle, what's causing you, the developer, the most pain?
<wgrant> My only slight issue is that sponsors are often unclear on how to do things.
<wgrant> Is this not documented?
<wgrant> mwhudson: 'build engineer'?
<jml> wasn't that announcement on launchpad-dev!
<wgrant> No. We don't find anything out.
<barry> wgrant: can you elaborate?
<mwhudson> bah
<mwhudson> and the wiki page is internal
 * jml frowns
<mwhudson> still learning at this sort of thing it seems :)
<barry> yep.  old habits die hard, but we're really trying to move more and more resources, communications, etc. into the public square
<wgrant> barry: Well, some of my sponsors have had trouble working out how to ec2test my branches. I'm not sure why.
<wgrant> What was this email meant to contain?
<barry> mwhudson: we really should find a way for non-Canonicals to run ec2
<jml> we're going to have a build engineer position
<wgrant> barry: +inf
<jml> it's a rotating postiition
<mwhudson> "Each development cycle, a different engineer will be taken off his normal development duty, and have has main focus for the cycle the development and well being of the build system. "
<jml> the build engineer works on making developers lives more pleasant, essentially
<wgrant> Aha. I see.
<mwhudson> i'm the first one, starting officially on monday
<jml> mwhudson, in answer to your question
<mwhudson> i'm probably going to tackle some buildbot annoyances first
<mwhudson> jml: you sent me an email about this that i haven't read yet :)
<wgrant> mwhudson: Bonus points for making it public.
<mwhudson> wgrant: yeah, that should be possible
<jml> mwhudson, my email wasn't so much about my pain points, actually :)
<jml> mwhudson, it takes way too long to land branches; buildbot should only send emails that require action; test failures in devel break ec2test runs
<barry> jml, mwhudson what is the main hold up to allowing the public to run ec2?  is it the payment issue?
<mwhudson> barry: i imagine so
<mwhudson> also ec2test is still private i think, but that will change soon (?)
<jml> mwhudson, not a pain point for me, but one I've had to watch: it takes too long to get set up with a dev env
<barry> surely we can find a way to subsidize the ec2 costs.  it's gotta be trivial in the scheme of things.  i usually feel guilty expensing it every quarter
<jml> mwhudson, the main meta issue is that it's really hard to see what the status of various build-related projects are (e.g. buildbot going public, ec2test going public, etc)
<rockstar> barry, when we have a UEC set up in the data center, it might be easier.  *shrug*
<barry> rockstar: good point
<mwhudson> jml: i think A build engineer, though probably not me, should focus on getting buildbot running the test suite in parallel across several instances
<jml> mwhudson, I very strongly agree.
<rockstar> mwhudson, abentley and I had a discussion about test layers today, and whether or not we're really using the layers properly.
<rockstar> I find I spend a lot of time setting up and tearing down the test harnesses just to run one test (that usually runs in shorter time than set up or tear down.
<mwhudson> rockstar: i would claim that using layers correctly is close to impossible, but maybe that's a bit bigoted
<barry> rockstar: i can almost bet we're not.  the layers are horribly named and it is not intuitive to know what layer a test should go in
<mwhudson> rockstar: there's also the terrible way we start daemons in tests, that doesn't help
<rockstar> barry, yeah, GoogleServiceLayer and LibrarianLayer were two we identified as not really necessary for most of our tests.
<jml> switching to testresources would help here
<mwhudson> +1 jml
<jml> I'm a little terrified about the work involved
<rockstar> jml, +1
<barry> rockstar: and they take a long time to start
<jml> but maybe if we actually explored what needed to happen, it would be less terrifying
<rockstar> barry, yeah, which is basically what I spent much of yesterday doing.
<wgrant> librarian takes forever!
<jml> wgrant, indeed.
<rockstar> wgrant, this morning it took 15.391 seconds to start up, and 7.3 seconds to tear down the librarian.
<jml> mwhudson, so, that's not really a survey, since it's just me :)
<wgrant> rockstar: It's about twice as fast here, most of the time.
<rockstar> mwhudson, really, if I had a pony request, it'd be a graph for how long the test suite is taking, and maybe some mini graphs of different sections of the test.
<mwhudson> for all that, step 1 is still going to be force build on buildbot
<mwhudson> rockstar: that's a good idea
 * jml agrees -- it's in an email I sent :)
<rockstar> jml, dammit.  You and your organization...
<rockstar> Do we have a place to aggregate all of these ideas?
<jml> exactly!
<rockstar> jml, did you send an email about that too?
<jml> I was about to say, step 0 should really be tracking this.
<barry> rockstar: like a wiki? <wink>
<jml> rockstar, it was in the same email as the graph stuff :)
<rockstar> barry, wikis are TERRIBLE issue trackers.
<jml> barry, or, umm, a bug tracker.
<jml> barry, I've got this good one I can sell you
<rockstar> I know these really great guys who spend a lot of time writing a bug tracker...
<mwhudson> step -1: move BE wiki pages to dev.lp.net
<barry> :)
<jml> mwhudson, \o/
<mwhudson> step 0: a tag in launchpad-project, i guess
<rockstar> Maybe a product in launchpad-project.
<wgrant> Wouldn't a separate product be much better?
<jml> rockstar, wgrant, maaybe
<jml> I don't think that the way Launchpad uses products is the way Launchpad wants others to use products though
 * jml makes a note about that
<wgrant> No.
<wgrant> But this one is different.
<jml> wgrant, yeah, I think so too, but I'm not sure how it's different.
<wgrant> jml: It's not part of the codebase.
<jml> wgrant, some of the bugs are in the code base
<wgrant> Most of the other products are.
<wgrant> Hmm.
<jml> wgrant, but a subproduct would fit there, I guess
 * mwhudson writes another thing down, "make sure buildbot config is in a branch or two on launchpad"
<jml> the secret, proprietary project with all of our developer utilities might well belong as a public sub-project of Launchpad
<barry> jml: +1
<wgrant> jml: lp-dev-utils, or is there something else?
<jml> wgrant, lp-dev-utils, yes.
<jml> wgrant, that is, I can neither confirm nor deny the existence of said project...
<wgrant> Heh.
 * wgrant whines about the product/project/project/projectgroup confusion.
<jml> patches accepted :)
<barry> wgrant: beuno just today told me i could jfdi (rename those things :)
<jml> either that, or sabotage barry's bass so he gets some more free time
<barry> jml: that is so cruel
<wgrant> Heh.
<jml> wgrant, all you need to do is add an extra string -- it'll baffle him
<jml> barry, <3
<barry> jml: ouch :)
<barry> does that mean we're done here?
<jml> I think so.
<barry> wgrant, rockstar, mwhudson anything else?
 * wgrant can think of nothing more to whinge about.
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<jml> Thunderbirds are go!
<barry> #endmeeting
<MootBot> Meeting finished at 18:24.
<mwhudson> cheers all
<barry> thanks guys!  see you back at the farm
<jml> barry, thanks!
<lifeless> jml: subunit has been a huge help for me in getting statistics
<lifeless> FWIW
<jml> lifeless, I'll bet.
<jml> there's probably an interesting paper in 'making a test suite fast again'
<lifeless> I just submitted a merge for bzr to make its testresults python2.7 shiny and more reusable
<lifeless> jml: and ./bzr selftest selftest is down to 3.3 seconds on my laptop [by the reporter, so not including test loading time. Thats a TOFIX]
<jml> lifeless, why are you only measuring the time for 'selftest' tests?
<lifeless> jml: its a brain food spike
<lifeless> jml: 'make this little bit of the test suite as lean and mean as possible'
<lifeless> it was ~ 60 seconds when I started
<jml> lifeless, makes sense.
<lifeless> so far I've reduced overall test load time by 10%
<lifeless> and identified that our base TestCase is about 2000 times more expensive than unittest.TestCase
<jml> heh heh
<lifeless> so theres still lots of fat to go
<lifeless> this bit comes first, because fixing other areas will mean changing this bit and that should be a pleasure not a pain
<jml> *nod*
<matsubara> #startmeeting
<MootBot> Meeting started at 10:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<Ursinha-afk> me
<gary_poster> me
<intellectronica> me
<barry> me
<rockstar> ni!
<bigjools> me
<intellectronica> Ursinha: and i thought you're doing your telepathic typing trick again...
<Ursinha> intellectronica, hehe
<matsubara> Chex, hi
<Chex> matsubara: hello
<matsubara> ok, so we're missing stub and henning/danilo
<danilos> me
<matsubara> hi danilos
<matsubara> :-)
<danilos> matsubara: no you are not :)
<matsubara> so, from now on, you'll be attending the prod meeting, right?
<danilos> matsubara: well, not necessarily, let's see :)
<matsubara> ok, let's move on then
<danilos> matsubara: but soon I will be replacing henninge as our QA contact
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara>  * DBA report (stub)
<matsubara>  * Proposed items
<matsubara> danilos, ok
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>   * cprov to follow up on bug 413749
<matsubara>   * stub to investigate garbo-hourly failure after spm adjusted script checking to 12h
<matsubara>   * sinzui to poke barry about ExpatError OOPSes (bug 403606)
<matsubara>   * danilos, Ursinha and matsubara to discuss oops summaries split per team
<ubottu> Bug 413749 on http://launchpad.net/bugs/413749 is private
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<danilos> matsubara: we kind of did that, flacoste is involved as well, and it's all on track I'd say :)
<matsubara> ok, I know that stub replied to the garbo-hourly failure email, so I think that's done
<matsubara> danilos, right. if you have more suggestions let me know
<danilos> sinzui is on unavailable I believe
<matsubara> barry, hi!
 * barry has some thoughts about the expat errors
<barry> matsubara: hi!
<matsubara> barry, what's up with those expat errors?
<cprov> matsubara: I did reply on 413749 as well, needs discussion, though.
<matsubara> thanks cprov
<Ursinha> matsubara, the one with the expaterrors I'd bring in the oops section
<barry> matsubara: well, some more investigation might be warranted, but they are intermittent and i've always chalked them up to problems with xmlrpc.  i believe they can be safely ignored though because the system will "catch up" the next time mailman talks to xmlrpc server.
<Ursinha> barry, here's the problem, they happen every day
<barry> matsubara: ultimately, we should get rid of the xmlrpc stuff.  it was a solution to a problem we no longer have (namely gpl pollution between mailman and launchpad)
<matsubara> if it's safe to ignore them, can we add some code to catch the exception and not log the oops?
<matsubara> hi stub
<Ursinha> you said in the bug report that we have only a handful a week, but I see them everyday, and their numbers are the highest count
<barry> Ursinha: i get many oops reports for mailman that are clean.  am i looking at the wrong reports?
<Ursinha> barry, I think so :)
<Ursinha> look at the lpnet reports
<barry> Ursinha: meaning the daily emails
<barry> hmm.  okay.  i see them only rarely in the mailman daily email.  i will double check next time i see the report, but i think ignoring the error is the right thing to do
<Ursinha> barry, ok. it floods the summary, and that's annoying
<barry> Ursinha: gotcha!  i hadn't realized that.  i'll do something about it then
<gary_poster> When I discussed hiding the problems, given the frequency, Francis suggested that we not hide them but investigate a bit.  Maybe a small timebox would be appropriate?
<Ursinha> thaaaanks muchly barry!
<gary_poster> eh, nm
<gary_poster> :-)
<Ursinha> gary_poster, :)
<barry> gary_poster: yes, we can do that.  it will take losa intervention and some cowboy debugging, but it's probably worth it
<gary_poster> ok cool
<matsubara> [action] barry to continue debug on bug 403606
<MootBot> ACTION received:  barry to continue debug on bug 403606
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<matsubara> thanks barry, gary_poster, Ursinha
<Ursinha> thanks
<matsubara> let's move on
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<Ursinha> ok
<matsubara> Ursinha, take the stage please
<Ursinha> so the ExpatErrors were already discussed here
<Ursinha> I have only one bug
<Ursinha> intellectronica, bug 408738
<ubottu> Launchpad bug 408738 in malone "OOPS when rendering bug activity" [Undecided,Triaged] https://launchpad.net/bugs/408738
<Ursinha> that's another one that happens pretty often
<intellectronica> really? if so then we should at least recover gracefully from it
<Ursinha> intellectronica, I see those everyday as well
<intellectronica> i mean in addition to figuring out why we have records like those
<Ursinha> I agree
<Ursinha> intellectronica, could you take a look or poke someone to do so, please?
<intellectronica> yes yes
<Ursinha> thanks intellectronica :)
<Ursinha> matsubara, [action] intellectronica to take a look or find someone to take a look on bug 408738
<ubottu> Launchpad bug 408738 in malone "OOPS when rendering bug activity" [Undecided,Triaged] https://launchpad.net/bugs/408738
<matsubara> [action] intellectronica to take a look or find someone to take a look on bug 408738
<MootBot> ACTION received:  intellectronica to take a look or find someone to take a look on bug 408738
<Ursinha> thanks :)
<matsubara> thanks Ursinha and intellectronica
<matsubara> we have 2 critical bugs
<Ursinha> critical bugs are fix committed, and the process-pending-packagediffs script failure was already explained by cprov
<Ursinha> so, we're done!
<matsubara> both fix committed
<Ursinha> you can move on, matsubara
<Ursinha> thanks guys!
<matsubara> thanks everyone
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Chex> hello everyone :
<Ursinha> hi Chex :)
<Chex> the report for this week:
<Chex> Lots more cherry picks this week
<Chex> More and more problems with codebrowse (per the Incident Log)
<Chex> New losas getting up to speed (Chex and mbarnett)
<Chex> Testing tarmac for oops-tools project - making progress but not quite there yet
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=tools
<Chex> Will begin process of implementing recommendations from SplitIt Sprint before too long
<Chex> One of our top priority bugs is bug 416990 - others per https://bugs.launchpad.net/~canonical-losas
<Chex> That's it unless there are any questions
<ubottu> Launchpad bug 416990 in bzr "Memory usage of codehosting processes is excessive" [High,Confirmed] https://launchpad.net/bugs/416990
<matsubara> Chex, re: tarmac setup for oops-tools, I'll submit a merge proposal to tarmac today with the remaining fixes needed.
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=tools
<matsubara> Chex, I'll coordinate with mthaddon later on
<mthaddon> cool
<Chex> matsubara: ok, great
<matsubara> rockstar, can you poke people in your team about the codehosting memory issue?
<danilos> matsubara: is it worth fixing ubottu not to choke on oops-tools mention? ;)
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=tools
<Ursinha> lol
<matsubara> I can ask the maintainer
<danilos> matsubara: thanks :)
<matsubara> [action] matsubara to chase ubottu maintainer to fix regexp used to identify oopses
<MootBot> ACTION received:  matsubara to chase ubottu maintainer to fix regexp used to identify oopses
<matsubara> let's move on
<matsubara> thanks Chex
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> The long running transaction killer is back set to 3 hours, thanks to the Rosetta team sorting out the language pack export issue quickly.
<stub> oot
<Ursinha> that was fast
<matsubara> hehe
<bigjools> like mrevell, it was short
<matsubara> thanks stub and rosetta people :-)
<matsubara> lol
<Ursinha> lol
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> we have no proposed items
<mrevell> haha bigjools
<matsubara> anything else before I close?
<matsubara> hi mrevell
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<mrevell> matsubara: nothing from me, just responding to bigjools... :)
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:24.
<Ursinha> thanks everyone!
<bigjools> mrevell: I apologise profusely, please don't hurt me
<mrevell> bigjools: Ah, ok, just this once
<danilos> thanks matsubara, all
<Ursinha> oops-thisisnotright
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=thisisnotright
<danilos> Ursinha: come on, come, don't be too hard on it
<Ursinha> :P
<bigjools> oops-I-did-it-again
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=I
#launchpad-meeting 2010-09-01
<EdwinGrubbs> bac is unavailable today, and it doesn't look like there is anything new for discussion, so the reviewer meeting is cancelled.
<gmb> bac, Is the reviewers meeting going ahead, or did I miss the mail?
<adeuring> me
<henninge> adeuring: HI! nothing happening yet ...
<adeuring> interesting...
 * gmb listens to the wind whistling through the channel
<wgrant> 23:50:48 < EdwinGrubbs> bac is unavailable today, and it doesn't look like there is anything new for discussion, so the reviewer meeting is cancelled.
<wgrant> gmb, adeuring, henninge: ^^
<gmb> wgrant, Ah, thanks.
<adeuring> wgrant: thanks!
<henninge> good night, wgrant! ;)
#launchpad-meeting 2010-09-02
<rockstar> bac, is the meeting today or tomorrow?
<bac> rockstar: that is really an existential question
<bac> it is your today
<bac> but it is thursday
<bac> at greenwich
 * rockstar hates at timezones.
<bac> rockstar: so, in summary, it is in 30 minutes
<rockstar> bac, okay, I'm going to have to relocate soon then.
<bac> are you at your fancy coworking spot?
<rockstar> bac, after this semester, I'll probably go back to the Euramerican meeting.
<bac> i do that about once a month
<rockstar> bac, yeah, for night cow orking.
<bac> coworking, i mean
<bac> ok, see you soon
<rockstar> I go in the evenings on Wednesday, and then I (try to) go on Fridays
<bac> ours closes at 6
<bac> and i don't qualify for a key
<bac> but i only pay $10/day
<bac> which is roughly $10/month
<rockstar> Yeah, I pay about $60/month.
<rockstar> They do a night coworking thing on Wednesday nights, and I'm trying to start my little game company, so I spend my Wednesdays doing that.
<bac> ah, neat
<thumper> me
<mwhudson> em
<bac> #startmeeting
<MootBot> Meeting started at 19:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
 * rockstar  
<bac> y'all are an anxious bunch
 * wallyworld 
 * mwhudson is a bit hungry
<bac> lifeless, StevenK: ping
 * StevenK waves
<bac> hurrah
<lifeless> hi
 * thumper is hungry too
<bac> woot, we're all here
<wallyworld> thumper is always hungry
 * bac just had a lovely dinner
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>   * Henning Rocks.  One-import-per-line now done and in effect.
<bac>   * Mentat update.
<bac>   * gary: benji is checking in our generated WADL and adding tests of the WADL generated for our webservice versions.  This is supposed to mean that changing the frozen versions of the webservice in a backwards-incompatible way will be more easily caught by reviewers: don't allow it! It should also mean that running make initially will be noticeably faster.
<bac>   * Some of the UI reviewers have graduated, but ReviewerSchedule indicates that no one has graduated.
<bac>   * https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<bac>  * Peanut gallery
<bac> [topic] outstanding stuff
<MootBot> New Topic:  outstanding stuff
<bac> lifeless, can you remind us of the lib/coop mess was settled?
<lifeless> yes its settled. We all know what it is and that the name sucks.
<thumper> what is it?
<thumper> remind me plz
<lifeless> it is buganswers, answersbranches etc
<thumper> ok
<lifeless> I'm in favour of a rename to 'inter' if we bother.
<lifeless> but I don't think that that actually removes the need for folk to read the package docstring
<lifeless> which is entirely clear.
<bac> ok, thanks
<lifeless> as I don't think it will remove that need, I'm in favour of doing nothing and worrying about other stuff
<bac> i should mention there was no AMEU meeting today due to me having a dr's appt and forgetting all about it
<lifeless> no worries
<bac> last week we noted henning did a great job on the import script. \o/
<bac> [topic] mentat update
<MootBot> New Topic:  mentat update
<bac> thumper, StevenK: how goes it?
<thumper> slowly
<StevenK> What he said
<bac> i must apologize for breaking the mentoring cycle last week as i had a branch that i really wanted to land.  hope you still got good feedback from edwin, StevenK
<StevenK> I've figured out that reviewing is effectively asking yourself or the submitter a bunch of questions. Now to learn what are good questions to ask.
<bac> StevenK: geez, you're channeling kiko
<StevenK> Argh!
<StevenK> bac: It's fine, urgent is well, urgent.
<bac> [topic] WADL files
<MootBot> New Topic:  WADL files
<bac> * gary: benji is checking in our generated WADL and adding tests of the WADL generated for our webservice versions.  This is supposed to mean that changing the frozen versions of the webservice in a backwards-incompatible way will be more easily caught by reviewers: don't allow it! It should also mean that running make initially will be noticeably faster.
<bac> did that email go out?  i don't recall seeing it
 * gary_poster is not really here (hi!)
<bac> anyway, i'm just the messenger
<bac> gary_poster: ^^?
<mwhudson> i don't recall an email or a landing to that effect yet
<gary_poster> benji couldn't land it because it depended on a new version of lazr.restful that was being integrated for another effort
<gary_poster> still pending
<lifeless> we make no guarantees about devel though, do we ?
<gary_poster> correct, lifeless
<lifeless> just 1.0
<thumper> lifeless: no we dont'
<lifeless> phew
<gary_poster> and "beta"
<lifeless> ah
<bac> [topic] * Some of the UI reviewers have graduated, but ReviewerSchedule indicates that no one has graduated.
<wgrant> beta is only Karmic, right?
<MootBot> New Topic:  * Some of the UI reviewers have graduated, but ReviewerSchedule indicates that no one has graduated.
<gary_poster> wgrant: yeah, I think that's right
<bac> i sent a request to rockstar to update the wiki
<bac> who added this agenda item?
 * rockstar completed the request
<bac> rockstar: thanks!
<lifeless> wgrant: until yesterday beta was still on the 'jahacking the api' wiki page
<rockstar> Although I should say that everyone should be a ui* or javascript*
<lifeless> bac: bryceh noticed the disconnect
<StevenK> bac: I noticed that myself -- also the wiki page still shows jelmer is being mentored by noodles.
<bac> lifeless: ok.  it's nice to put your [name] on the items
 * rockstar hates wikis
<lifeless> bac: sure. I didn't add that one :P
<lifeless> bac: I did the next, I forgot toblame myself.
<bac> lifeless: no, but...
<lifeless> ^W^Wtake credit
<bac> [topic]  * https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<MootBot> New Topic:   * https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<bac> lifeless: that has your fingerprints!
<lifeless> I raised this at the Epic in my presentation
<lifeless> I've been slack writing it up.
<lifeless> its now in a moderately consumable form.
<lifeless> I'm asking the review team to take on a new challenge
<lifeless> which is to help people get their code to meet the values on that page, and [its experimental] the metrics.
<lifeless> I know the metrics are bad and wrong. But it would be nice to have some, so lets try and iterate.
<lifeless> This is a form of review that none of the current guides covered
<lifeless> but I feel it is very much in the spirit of review - helping each other end up with code that does what we want and is easy to care for
<lifeless> -fin
<bac> lifeless: i notice you've been following up on a lot of reviews.  those follow ups are excellent reminders to keep the architecture in mind.
<lifeless> bac: I read every review
<bac> lifeless: but, of course, you cannot do it yourself.  i'll bring this to the larger crowd.
<lifeless> bac: but sometimes I skim :)
<lifeless> I've got two goals with that page
<lifeless> firstly, I hope that by adding this info explicitly into our memesphere
<lifeless> folk will turn up at review with these values already embodied in their code
<lifeless> secondly, where they haven't, I hope they have a discussion with the reviewer and can decide whether they want to invest and improve things immediately, or before they move onto the next kanban card, or $schedule-phrase
<mwhudson> right, as per usual, the review is too late to catch this sort of problem in an ideal world
<lifeless> mwhudson: exactly
<rockstar> abentley and I have regular calls every day and they usually spin into pre-implementation calls.  That seems to help.
<bac> mwhudson: yes, ideally these issues would be raised in a preimp call
<rockstar> It's kinda like swimming with a buddy, only without the swimming, and with coding.
<lifeless> :)
<bac> and no hurricanes
<lifeless> so anyhow, I didn't find anything that matched the structure-of-code in our guidelines
<rockstar> bac, oh, there are hurricanes.  Have you seen the buildd code?  :)
<lifeless> they were all pretty cosmetic or surface stuff
<bac> do you have hurricanes in NZ?
<thumper> oh yes
<bac> is that what you call them?
<thumper> not really tornados though
<thumper> yes hurricanes
<lifeless> I'm hoping this page can stay focused on structure and outcomes
<thumper> in fact that is also the name of the Wellington super 14 rugby team
 * rockstar was hoping to learn the Maori word for hurricane.
<lifeless> and we can spin specific techniques off to PythonSG / Performance pages etc etc
 * mwhudson adds to the distraction: http://en.wikipedia.org/wiki/Cyclone_Bola
<rockstar> lifeless, we're listening, we promise.
<bac> thanks lifeless for powering through our meteorological distractions
<lifeless> thats ok, its all there for mootbot
<mwhudson> lifeless: +1 to all that
<bac> so you *do* call them something else
<bac> thanks robert
<bac> that's it for the scheduled items
<bac> does anyone have anything else to discuss?
<thumper> not today
<rockstar> bac, I would like to suggest an experiment.
<bac> rockstar: go
<thumper> oh?
<rockstar> bac, I've been thinking about this a lot, and trying it in my own development.
<rockstar> I would like to suggest we make our review diff line max much smaller.
<rockstar> Like, maybe by half.
<lifeless> +1 if I can get a permanent exception
<bac> rockstar: is this part of the salgado-hovey cadence grail?
<lifeless> :P
<rockstar> lifeless, exceptions can be evaluated on a case-by-case basis.
<rockstar> bac, well, yeah, if that's what you want to call it.  thumper and I had been experimenting with it before the epic though.
<rockstar> Reviews are SO EASY when they are small and concise.  It's easy to tell where you might have missed some tests, etc.
<bac> i spent a lot of time thinking about curtis' talk and it is clear it only works if you're riding a fixed gear bike
<bac> on the flats
<lifeless> rockstar: I think thats true with new code, but its really not true with existing code.
<wgrant> But it's sometimes possible to get large refactorings down below 800 lines.
<wgrant> 400 lines... I doubt it.
<StevenK> I've been discovering most feature branches are easily over 600 lines
<lifeless> rockstar: I routinely, at the moment hit 700 lines, on *trivial* things, because there is so much debt.
<wgrant> We'd have a *lot* more exceptional branches.
<wgrant> lifeless: Exactly.
<bac> lifeless: yep
<rockstar> lifeless, the debt should be reviewed separately than the actual change.
<bac> i had a silly branch today that came in at 602
<mwhudson> i worry that LOC is a poor surrogate for complexity
<rockstar> mwhudson, this is true.
<rockstar> Especially with twisted code.
<bac> and all i did was catch an exception and display a nice message
<lifeless> rockstar: so, I think its great to *encourage* focused branches, but not great to *penalise* ones that are large but still focused.
<lifeless> mwhudson: yes.
<bac> make it a goal, but one you an exceed by 100%
<StevenK> Perhaps a wording change is in order?
<lifeless> rockstar: when we *add* effort to do something *simple*, we're doing it wrong.
<rockstar> Like I said, experiment.
<lifeless> rockstar: I'm merely pointing out concerns.
<StevenK> "We'd prefer diffs to be 400 lines or less, but should review diffs of up to 800 lines."
<bac> rockstar: you said you've been doing it a while.  how has it worked out?
<rockstar> lifeless, yeah, and I thank you for that.  I know it won't happen all the time, but judging by thumper's branches, we aren't staying under 800 anyway.
<rockstar> bac, I think it's brilliant.
<StevenK> Over 800 lines may require bribes, at the reviewers discretion?
<lifeless> StevenK: already does.
<rockstar> StevenK, that's how it works now.
<lifeless> but I think that setting a review limit *misses the point*
<lifeless> the benefit of focused branches is that they are focused and fast and easy.
<rockstar> lifeless, yeah, it's only a limit as far as our current limit.
<bac> lifeless: but a review *target* doesn't
<lifeless> bac: no, it does.
<lifeless> the current limit misses the point.
<lifeless> it was a surrogate when we introduced it, and its a surrogate now.
<rockstar> You don't have to land your branches separately.  You can keep them in a pipe or whatever.  I think getting them reviewed in chunks is a good idea.
<lifeless> Its obviously a poor surrogate because rockstar and others are arguing that its wrong
<rockstar> lifeless, not wrong, but sub-optimal maybe.
<lifeless> I would rather say 'Have no more than N changes in your thing to be reviewed'
<lifeless> where we might say N is - 4.
<thumper> I think we should have minus four changes too
<lifeless> If you can describe in english, without tricks, your entire branch in 4 simple clauses, its got to be pretty focused.
<lifeless> if you need more to describe it, its less focused.
<lifeless> (this is off the cuff, I'm simply saying that lets talk about the root issue: our *target for developers* is a surrogate. Maybe there is a better surrogate, if we feel people are failing to achieve focus)
<rockstar> lifeless, I think 1 change is enough though.
<StevenK> Does that include drive-bys, though?
<rockstar> I think one of the problems is that we are trying to fix too many things.
<rockstar> StevenK, yes.  Ask thumper about the little drive-by fix in his refactoring branch last week.  :)
<thumper> it has always been a soft limit anyway
<lifeless> rockstar: 1 is ideal, but is definitely not enough for anything deep. Perhaps I'm seeing a biased slice of the code.
<rockstar> Yeah, and I'm saying maybe, as a team, we should ratchet down the soft limit and see if that helps the team.
<mwhudson> i have to be honest: i've basically ignored the 800 line limit for years
<lifeless> me too
<thumper> mwhudson: and done what?
<bac> mwhudson: i'm a pretty big offender too.  sinzui will review anything.
<mwhudson> thumper: tried to stay focused
<mwhudson> i think my branches are mostly under 800 lines
<StevenK> I use 800 lines as "Uh oh, I should try and split this monster up."
<rockstar> bac, yeah, when my manager asks me to review 2X lines of code, what do I say? No?  :)
<mwhudson> i have no idea -- that's what i mean by ignore
<bac> rockstar: yeah, but it's the other way around...
<rockstar> I think mwhudson's approach is the best.  lifeless illustrated a good way to measure it, but 4 things is too many.
<rockstar> MAYBE 2 things.
 * bac calls time
<lifeless> I can propose another approach
<mwhudson> pipelines ftw, as usual
<lifeless> bac: if I may
<rockstar> mwhudson, yes.
<bac> lifeless: ok
<StevenK> Why not both, we recommend 2 things, but up to 4, per discretion
<lifeless> remove the limit. Gone. Replace it with:
<bac> lifeless: wrap it up as mwhudson is hungry
<lifeless>  * if the reviewer feels its too big to review sensibly, from *whatever perspectve*, they ask the reviewee to split it with pipelines.
<thumper> +1
<lifeless> we don't have 5K and 10K branches coming in anymore
<lifeless> the cultural is radically different.
<thumper> thankfully
<mwhudson> lifeless: +1
<bac> lifeless: is there an easy way to do that?  even with pipelines?
<thumper> add-pipe --before
<thumper> merge -i
 * bac may need a tutorial
<bac> +1 then
<lifeless> limits like this are always going to be a discussion, so lets make it explicit about the tradeoffs: ease of review / clarity etc and let the participants have the discussion
<mwhudson> didn't aaron do a tutorial at the epic about this?
<lifeless> bac: there are various ways; pipelines are pretty nice.
<lifeless> bac: or just a regular branch + merge -i
<bac> mwhudson: yeah but it assumed lots of familiarity with pipelines already
<mwhudson> ok
<lifeless> personally, I try to just do enough to be confident in the change and stop there
<lifeless> by the time I need a stack of things, I've usually gotten myself tied up in knots already
<mwhudson> as always, it depends
<mwhudson> my blueprints hacking last week feel easily into three steps: move, sanitize, change
<lifeless> mwhudson: you forgot delete.
<mwhudson> it helps if you can see the steps ahead of you i guess
<bac> rockstar thanks for bringing up the topic.   i think the discussion was helpful.  we'll need more time to figure out a plan.  perhaps lifeless and i can talk before next week to come up with a solid proposal.
 * rockstar acks
<lifeless> bac: drop me a mail ?
<bac> any other things?
<bac> lifeless: sure
<thumper> lets finish plz
<bac> 3...
<bac> 2
<bac> 1
<bac> #endmeeting
<MootBot> Meeting finished at 19:39.
<thumper> thanks bac
<bac> thanks all
<bac> g'night
<mwhudson> thanks bac
<thumper> lunch time
 * mwhudson lunches
<lifeless> thanks y'all
