#launchpad-meeting 2006-10-09
<poolie> hullo?
<lifeless> hi
<poolie> if i'm lucky i can go back to my dinner...
<poolie> s//delicious &
<lifeless> :)
<poolie> (meeting ends... :-)
<lifeless> fastest meeting ever
<lifeless> all present say bye
<poolie> 5..
<poolie> bye!
<lifeless> 'bye'
<spiv> bye :)
<poolie> lifeless: happy hacking tomorrow
<poolie> spiv: see you later
<poolie> new bzr benchmark: meeting performance improved 900% !
<jamesh> no meeting?
<poolie> jamesh: lack of interest...
#launchpad-meeting 2008-10-08
<barry> #startmeeting
<MootBot> Meeting started at 09:01. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<intellectronica> me
<barry> hello everybody and welcome to this week's meeting.  who's here today
<rockstar> me
<sinzui> me
<bac> me
<gmb> me
<mars> me
<bigjools> me
<flacoste> me
<salgado> me
<allenap> me
<abentley> me
<cprov> me
<EdwinGrubbs> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<intellectronica> barry: Bjorn mentioned that he'll be away this afternoon, maybe he's not back yet
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Cross-referencing monkey patches in code (intellectronica, bigjools)
<barry>  * If there's time, the old boring script
<barry>    * Next meeting
<barry>    * Action items
<barry>    * Queue status
<barry>    * Mentoring update
<barry> [TOPIC]  * Cross-referencing monkey patches in code (intellectronica, bigjools)
<MootBot> New Topic:   * Cross-referencing monkey patches in code (intellectronica, bigjools)
<barry> intellectronica, bigjools the floor is yours
<intellectronica> ok, i'll go
 * bigjools looks at intellectronica since he added the topic :)
<intellectronica> sometimes we need to monkey patch code
<intellectronica> this became quite frequent since we started exporting stuff to the API
<flacoste> ?
<bigjools> circular imports
<intellectronica> since in order to avoid circular imports we often need to amend classes after they're first declared
<barry> intellectronica: can we define "monkey patch" :)
<flacoste> that,s not monkey patching!
<flacoste> that's working around circular imports!
<intellectronica> flacoste: ok, since you oobviosly understand what i'm talking about, how about you propose a better definition?
<sinzui> barry is the master of monkeypatching
<sinzui> see launchpad/mailman/monkeypaches
<flacoste> intellectronica: well, you are talking about the working around of circular imports, right?
<intellectronica> flacoste:
<intellectronica> flacoste: yup
 * barry is a patched monkey
<flacoste> intellectronica: ok, so what is the issue you wanted to raise about this?
<intellectronica> see l/c/l/interfaces/bugtask.py:634 for a representative example of the problem i'm referring to
<intellectronica> so, while working through a problem bigjools and i realised that it's often quite difficult, when you look at the class definition, to know where it's being amended
<intellectronica> and wanted to suggest that we make it a requirement to cross reference the places using comments
<intellectronica> so that next to the general definition, you'll have to add a comment saying where it's being patched
<barry> intellectronica: that seems like good practice to me
<flacoste> so where we have schema=Interface, # ITeamMembership
<flacoste> we would have
<flacoste> schema=Interface, # ITeamMembership, in teammembership.py?
<bigjools> see interfaces/archive.py for an example of how bac recommended I do this yesterday
<intellectronica> flacoste: yes, maybe even something more specific, as long as it's maintainable
<abentley> I think that this fixup requirement is a framework bug.  We should allow schema='ITeamMembership'
<mars> flacoste, wild speculation, can Zope 3.4 deferred imports take care of this?
<barry> abentley: you beat me to it.  +1
<intellectronica> abentley: that's a _really_ nice idea
<flacoste> yes, now that we have zope 3.4, we can look into deferredimport
<barry> eliminating the patch up is definitely the right way to go
<flacoste> gary reports that it's not necessarily nice
<flacoste> so if that turns out to be true
<abentley> I'm happy with requiring an xreference until that's fixed.
<flacoste> we should look into supporting schema='canonical.launchpad.interfaces.ITeamMembership'
<barry> agreed.  so who can i give an action item to for that?
<flacoste> foundations
<flacoste> we can look into deferredimport
<flacoste> and fix all of them
<flacoste> otherwise, we'll file a bug
<barry> [ACTION] flacoste & foundations to look into techniques for eliminating back-patching of schema types to avoid circular imports
<MootBot> ACTION received:  flacoste & foundations to look into techniques for eliminating back-patching of schema types to avoid circular imports
<flacoste> actually, iirc, there is already a bug reported about using deferredimport
<barry> anything else on this topic?
<abentley> flacoste: We also have the option of using bzrlib's lazy_import.
<flacoste> interesting!
<flacoste> i diN,t know about that one
 * barry wishes python had a standard way of doing it
<abentley> barry: What about the one in the email module :-) ?
<barry> abentley: yech :)
 * rockstar notes that barry can make a standard way of doing it with his commit access.
 * bigjools coughs and mentions that even C has a way of doing this
 * barry emits an evil chortle
<barry> that's all the fun stuff on the agenda, so it's boring script time
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * barry will move the preimp discussion to the ml
<barry> fail.  but i did pull my half written email out of my drafts folder so i'll do that today <wink>
<barry>  * flacoste to take discussion of rest v. moin to ml
<flacoste> that will happen once gary finishes his example
<flacoste> should be soon
<barry> flacoste: excellent, thanks
<barry>  * rockstar to take discussion of adding launchpadlib tests for exposed api to ml
<rockstar> Oh noes!  This has been an my TODO list for a week!  I will start the discussion now.
<barry> rockstar: thanks!
<barry>  * abentley to investigate current code coverage tools for lp tests
<abentley> barry: I haven't done this yet.
<barry> abentley: np, we'll just carry it over
<gmb> abentley: ISTR allenap did something related to this a way back.
<gmb> Unless I remember incorrectly.
<gmb> abentley: So it might be worth tapping his newly-returned cranium for information.
<sinzui> abentley: gmb: allenap did!
<gmb> Thank you, Launchpad team historian.
<barry> :)
<barry> [TOPIC]    * Queue status
<MootBot> New Topic:     * Queue status
<barry> any comments on the queue?  either the review queue, pqm, etc.
<gmb> Apart from the occasional overnight buildup
<gmb> (AMEU time)
<gmb> The queue is very manageable at the moment.
<gmb> (At least ona Thursday)
<intellectronica> we've got more reviewers, that really helps
<barry> btw, i'm hoping that by epic we can try merge proposals again.  the redesigned u/i really looks great
<barry> intellectronica: indeed.
<rockstar> barry, that should land soon
<barry> rockstar, abentley: correct me if i'm wrong, but diffs are still a ways away
 * rockstar looks at abentley 
<abentley> barry: Hard to say.
<rockstar> Database patches...  :)
<barry> ah :)
<abentley> I'll be implementing diffs this week or next, I think.
<barry> abentley: will that include diffstats?
<abentley> barry: Not initially.
 * bigjools has to duck out now
<barry> cool, thanks
<barry> [TOPIC]    * Mentoring update
<MootBot> New Topic:     * Mentoring update
<barry> any feedback here?
<gmb> barry: mars is doing an exceelent job.
<bac> rockstar continues doing a great job
<gmb> Not all that many reviews to do, sadly.
 * rockstar feels warm inside
 * gmb hands rockstar an antacid
 * barry feels bad that he's missed abentley's last few sessions
<barry> abentley: we'll get back on track after epic
<abentley> barry: We managed alright.
<barry> abentley: yep, appreciated!
<abentley> The big problem was getting attention from Rinchen and kiko the first time, when I didn't know what to do.
<barry> yep, they're busy guys :)
<barry> anyway, that's all i have today.  do you have any topics not on the agenda?
<rockstar> Negative
<abentley> barry: No.
<barry> okie dokie!  have a great week everybody and thanks for coming
<barry> #endmeeting
<MootBot> Meeting finished at 09:34.
<gmb> Thanks barry.
#launchpad-meeting 2008-10-09
<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
<sinzui> me
<matsubara> so, who's here today?
<cprov> me
<rockstar> me
<Rinchen> me
<bigjools> me
<matsubara> intellectronica, herb, danilos, flacoste: ?
<danilos> me
<intellectronica> me
<flacoste> me
<herb> me
<matsubara> Apologies from Ursula, she had to run some errands
<flacoste> him
<matsubara> hi stub
<stub> hi
<matsubara> ok, everyone is here.
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Next meeting
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (DBA contact)
<matsubara> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<matsubara> same time next week?
<sinzui> yes
<matsubara> so be it.
<matsubara> [topic] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> flacoste: * foundations to look up bug 277129
<ubottu> Launchpad bug 277129 in launchpad-foundations "OOPS when attempting to render a timeout page" [High,Fix committed] https://launchpad.net/bugs/277129
<flacoste> we have a fix for it
<flacoste> that landed
<matsubara> well, seems to be done :-)
<flacoste> yesterday
<flacoste> well
<flacoste> we don't know
<flacoste> if the OOPS disappears, it worked
<matsubara> thanks flacoste
<flacoste> otherwise its back to the drawing board
<matsubara> I'll ask Ursinha to keep an eye on those OOPSes
<matsubara> and comment on the bug.
<matsubara> thanks for handling it
<flacoste> (only on edge for the moment)
<matsubara> all right
<matsubara> [topic] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<matsubara> Today's oops report is about bug 279561
<ubottu> Launchpad bug 279561 in malone "No url for <Message at ...> when trying to access bug messages through the API" [Undecided,Triaged] https://launchpad.net/bugs/279561
<intellectronica> this one is really weird, and i'm still working on diagnosing it
<matsubara> intellectronica: hi tom, can you set importance on that one? Ursinha told me that one is happening quite frequently
<intellectronica> the good news is that it's quite rare. only a few messages are affected by it
<intellectronica> if it happens frequently it's only because both myself and thekorn have been hitting it a lot for testing
<intellectronica> it only happens when accessing comments via the api, and only very few comments
<flacoste> intellectronica: might be related to the fact that there are several "kind" of messages
<intellectronica> shall we say importance=high? i don't think it deserves critical
<sinzui> intellectronica: is the comment from a user with a hidden email address?
<intellectronica> flacoste: tell me more
<matsubara> right. I'll ask Ursinha to keep an eye on users other than you and the korn triggering it
<flacoste> intellectronica: and that the canonical url is only registered for a couple of those
<flacoste> intellectronica: well, Message, BugComment, BugCommentWithDecorations (that last one is not named like that)
<matsubara> intellectronica: high seems to be the right importance
<flacoste> intellectronica: i think canonical url is only registered for BugComment, if you return a Message in some case, it will probably fail
<matsubara> interesting
<intellectronica> this is always bug comments, i can't think why we'd return anything that's not a bug comment there
<intellectronica> sinzui: don't know. i'll check, but i find it hard to imagine that this would be the problem, since the user's email is never involved in getting the canonical url for a comment
<flacoste> intellectronica: i'm talking about the class of the object
<sinzui> intellectronica: understood
<flacoste> intellectronica: and this isn't consistent in the bug api
<flacoste> intellectronica: something you get Messages, something BugMessage, sometime BugComment
<intellectronica> flacoste: but doesn't the canonical url adapter rely on the interface, rather than the class?
<intellectronica> they all implement IMessage, for which there is an adapter
<flacoste> intellectronica: yes, but they provide different interfaces, especially IMessage
<flacoste> there is a canonical url for IMessage?
<flacoste> i wouldn't think so
<intellectronica> yes, there is
<flacoste> ok, i shut up then :-)
<flacoste> i have no clue!
<intellectronica> matsubara: anyway, i'm setting the importance to high and continue investigating
<matsubara> [ACTION] intellectronica to continue diagnosing bug 279561
<MootBot> ACTION received:  intellectronica to continue diagnosing bug 279561
<ubottu> Launchpad bug 279561 in malone "No url for <Message at ...> when trying to access bug messages through the API" [Undecided,Triaged] https://launchpad.net/bugs/279561
<matsubara> thanks intellectronica
<matsubara> moving on
<matsubara> we have a single critical bug
<matsubara> which is fix committed
<matsubara> so, it's all fine
<matsubara> thanks all
<matsubara> [topic] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> 2008-10-07 - Migrated codehosting to a new, much more powerful server. There was a few hours of downtime for code as we did the migration.
<herb> Had a couple of instances where codebrowse became unresponsive and needed to be restarted.
<herb> Had a few instances of app servers core dumping. Seems niemeyer and kiko made some progress on isolating the problem. Where do we stand on fixing it?
<herb> BTW, is there a bug for the app servers core dumping?
<flacoste> i don't know the answer to both of these questions :-/
<matsubara> herb: yes, I think
 * herb hopes so.
<herb> so no update on a fix?
<matsubara> I think there's one filed by mthaddon a long time ago. I can't find it now.
<herb> if not, that's it from the LOSAs.
<mthaddon> I'll see if I can find it
<flacoste> actually
<matsubara> haven't heard from kiko about a fix herb
<Rinchen> the one Tom filed was for stale pidfiles
<Rinchen> not for core dumps
<flacoste> the last i heard was that barry was going to look into writing a dedicated parser for apport email
<flacoste> and his quick strategy didn't work
<flacoste> sinzui: anything else from barry?
<mthaddon> Rinchen, true, yeah
<sinzui> Nothing else
<matsubara> bug 273618 perhaps?
<flacoste> sinzui: is he still working on a fix?
<ubottu> Bug 273618 on http://launchpad.net/bugs/273618 is private
<sinzui> barry: solution failed outright
<Rinchen> I'm beginning to to grow increasingly uncomfortable with the core dumps and would like to see appropriate debugging attention applied to those please.
<flacoste> i know he's on leave today
<danilos> fyi, forster is, last I heard, pretty CPU starved, especially when language packs are being built, so if that might be related, take it into consideration
<flacoste> Rinchen: we could cap the size of accepted apport bug fix
<sinzui> He is not working on a fix; he was hoping that kiko could find a work around.
<flacoste> Rinchen: while we work on a fix
<flacoste> danilos: no, it's really a memory problem when parsing big apport upload
<danilos> flacoste: ok
<flacoste> danilos: an innefenciy in the python email module
<flacoste> wow, that was badly spelled!
<Rinchen> flacoste, I guess either way the apport attachments will not get posted so perhaps we should.  We should let distro know about this as I'm sure that there will be no feedback other than "error" when the user looks at apport.
<flacoste> which is probably what they are getting right now :-)
<flacoste> intellectronica: could the bugs team patch this??
<intellectronica> flacoste: technically, i think it's doable. i have to think and discuss more whether this is the appropriate solution
<flacoste> intellectronica: it's a workaround to prevent us core-dumping
<flacoste> the proper fix is to have a better parser that doesn't crash
<danilos> fwiw, apport eats all of my memory when trying to get core dumps for big programs (like evolution or epiphany), and then just dies as well, so maybe that's why there are not too many reports about this problem
<danilos> i.e. this needs to be closely coordinated with ubuntu guys
<intellectronica> flacoste: i really don't know enough about the problem
<flacoste> ok, i'll take it to Bjorn then
<matsubara> [ACTION] intellectronica to discuss app server core dump bug with Bugs team and try to find a quick workaround
<MootBot> ACTION received:  intellectronica to discuss app server core dump bug with Bugs team and try to find a quick workaround
<intellectronica> i do know that the ubuntu guys rely on the apport attachments, so we should consider anything that might affect them
<matsubara> ok, anything else on that matter?
<sinzui> intellectronica: barry was of the opinion that we should use a out-of-proc tool to read the data from the filesystem
<herb> matsubara: not from over here.
<herb> thanks for the update everyone
<matsubara> [ACTION] matsubara to find or file a new bug for the core dump issue and add info discussed today there, subscribe niemeyer, kiko and someone from ubuntu
<MootBot> ACTION received:  matsubara to find or file a new bug for the core dump issue and add info discussed today there, subscribe niemeyer, kiko and someone from ubuntu
<matsubara> thanks all
<matsubara> moving on
<matsubara> [topic] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> Nothing happening in DB land.
<stub> :-)
<matsubara> thanks stub
<matsubara> so that's it for today, anyone have anything else before I close up?
<rockstar> thanks matsubara
<flacoste> matsubara: subscribe Bjorn to the bug also
<Rinchen> thanks matsubara
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:27.
<matsubara> flacoste: will do. thanks for the reminder
#launchpad-meeting 2009-10-07
<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 reviewer's meeting.  who's here today?
<sinzui> me
<EdwinGrubbs> me
<intellectronica> me
<flacoste> me
<bac> me
<deryck> me
<noodles775> me
<barry> gary_poster danilos bigjools allenap jml BjornT ping
<bigjools> hi
<allenap> me, sorry
<gary_poster> me
<barry> [TOPIC] agenda
 * bigjools stabs Google calendar
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Action items
<barry>  * UI review call update
<barry>  * Careful with those drive-bys, they make reviewing unnecessarily harder [intellectronica]
<barry>    * How can we better incorporate drive-bys and other tech debt payoff into our development process? [barry]
<barry>  * Noodles and I (Edwin) discovered that we were using different guidelines for what goes into the view.label property.
<danilos> barry, in a sprint, won't be joining you (as will nobody from translations team), sorry
<barry>    * My method reduces the amount of redundancy between the <h1> and the breadcrumbs directly below it. For example:
<barry>      || '''Define upstream link''' <<BR>> Ubuntu >> 9.04 >> âmozilla-firefoxâ source package >> Define upstream link ||
<barry>    * Noodle's method could have better google foo, since it puts more relevant info in the <h1>. For example:
<barry>      || '''Define upstream link for mozilla-firefox in Ubuntu Jaunty''' <<BR>> Ubuntu >> 9.04 >> âmozilla-firefoxâ source package >> Define upstream link ||
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry>  
<barry> danilos: cool, thanks
<abentley> me
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<danilos> +1 on barries method of view.label definition :)
<danilos> uhm, "barry's" :)
 * danilos goes back to sprinting
<jml> barry, hi
<barry> as long as it's not berries :)
<barry> jml: hi!
<BjornT> me
<barry>  * gary_poster and barry will transfer review guidelines from the old wiki and old old wiki to the new wiki
<barry> we still suck
<gary_poster> oh we do!  It had been so long that I had forgotten I suck!
<barry> gary_poster: maybe we should admit defeat
<gary_poster> lol
<gary_poster> barry: we almost had Matt doing it
<gary_poster> barry: we just needed to tell him...something
<gary_poster> barry: I tried to do it but no longer had access for some reason
<barry> gary_poster: right!  i'll ping him on it and see if he can help out
<gary_poster> barry: cool
<barry> [TOPIC]  * UI review call update
<MootBot> New Topic:   * UI review call update
<gary_poster> action: barry to get matt to do the work he and gary were going to do ;-)
<barry> :)
<barry> i wonder if beuno is around?
<barry> intellectronica: can you give a quick summary of the meeting?
<intellectronica> sure
<intellectronica> two interesting items:
<intellectronica> 1. martin will start working with one or two ui reviewers towards graduating them
<intellectronica> as part of the process they will hopefully start collecting documentation of complete reviews
<intellectronica> 2. there's some concern about the timing of the upgrade to the latest version of YUI3
<intellectronica> ideally, we'd like to have that before the next LAZR-JS sprint, so that whatever we do there builds on the new codebase, but it's unclear whether that's realistic given the resources we have for that time
<sinzui> Does everyone know that beuno is writing the Web UI guidelines for all Canonical. He is using Launchpad as the basis, but when finalised, we may need to make changes.
<intellectronica> indeed
<intellectronica> finally, now that some ui reviewers will graduate, reviewers are welcome to join as mentees. talk to martin if you're interested
<barry> hi beuno !  intellectronica gave a good summary of the meeting.  do you have an eta for ui reviewer graduations?
<flacoste> intellectronica: regarding 2.
<flacoste> gary scheduled that for this cycle when Maris comes back
<flacoste> with help from salgado
<intellectronica> awesome!
<flacoste> so we should have lazr-js updated by the sprint
<beuno> I've talked to Gary about upgrading YUI3 before the sprint
<flacoste> also, Bjorn is finishing the buildout migration to lazr-js
<gary_poster> yes
<flacoste> which will allow us to upgrade lazr-js to YUI3 without affecting LP
<gary_poster> yeah those are the key bits.
<gary_poster> Then the sprint would be able to work on migrating Launchpad itself to YUI 3 and the new lazr-js
<gary_poster> (in part)
<barry> gary_poster, beuno can we also spend time on making it easier to add js to launchpad?  it's still a very painful process :/
<intellectronica> gary_poster: in the ui call, we discussed how that might not be the best use of sprint time
<beuno> barry, we will have 7 people from other teams, we *need* to make it easier
<intellectronica> maybe this is the wrong meeting for dicussing this stuff, though
<barry> beuno: great.  i really think this is critical for our success here
<barry> intellectronica: true.
<gary_poster> intellectronica: yeah maybe so :-) but ok, then we migrate Launchpad after the sprint
<intellectronica> :)
<barry> so.  intellectronica, beuno anything else re: the ui meeting this week?
<beuno> I will be working with noodles775
<gary_poster> barry, beuno, that's a discussion to have with BjornT also I suspect.
<beuno> to graduate him, so please send UI reviews his and my way these next 2 weeks
<barry> gary_poster: good pint
<abentley> intellectronica, beuno: I heard something about a new requirement to report ui work?
<intellectronica> report?
<beuno> report?
<gary_poster> report?  (just helping out)
<abentley> rockstar said something about us having to report when we were doing ui work.
<intellectronica> report to whom, and in what format?
<abentley> intellectronica: Report at a new meeting, IIRC.
<beuno> I asked rockstar what your team was up to, that's all
<intellectronica> i've never heard of this before
<abentley> beuno, intellectronica: maybe I got it wrong.  I'll ask him.
<intellectronica> ah ok, yes. in general we like to have a status round in those meetings so it's good if the team's representative knows the status of ui work for the week
<barry> intellectronica, beuno thanks.  let's move on...
<beuno> barry, did you get that about noodles775?
<barry> beuno: noodles775 is going to graduate, right?
<barry> beuno: or has he already graduated?
<noodles775> will start the process :)
<barry> noodles775: fantastic
<beuno> barry, I'm going to work with him these next 2 weeks, so please throw as many UI reviews at him as you can, and add me as well  :)
<barry> [AGREED] send your ui reviews to noodles775 and beuno so noodles775 can get graduated
<beuno> (within reason)
<MootBot> AGREED received:  send your ui reviews to noodles775 and beuno so noodles775 can get graduated
<barry> [TOPIC] drive-byes
<MootBot> New Topic:  drive-byes
<barry>  * Careful with those drive-bys, they make reviewing unnecessarily harder [intellectronica]
<barry>    * How can we better incorporate drive-bys and other tech debt payoff into our development process? [barry]
<barry>  
<barry> intellectronica: do you want to start?
<intellectronica> sure
<intellectronica> so, traditionally, we've encouraged people to do drive-by cleanups when working on unrelated branches
<intellectronica> but in reviews, i find that these cleanups actually make the review much less focused
<intellectronica> from a review pov, it would actually be much better if there were no unrelated cleanups in a branch
<intellectronica> so there's a trade-off here, and i wonder how to best get the right balanace
<barry> intellectronica: it's a great point.  i'm guilty of that.  and yet, how do we encourage more cleanups and tech debt payoff?
<barry> what do people think about trying an experiment?
<abentley> intellectronica: IME, bzr has the opposite problem, because it wants to avoid spurious changes.
<intellectronica> that's on the assumption that drive-by cleanups are in general a good thing. that's also something we should maybe re-examine
<sinzui> I favor landing drvie-bys in a first branch
<barry> where we rs pure drive-by branches?
<intellectronica> abentley: yes, i think avoiding spurious change is actually a desirable
<gary_poster> There's a silly but real issue:
<intellectronica> barry: so, we used to have that policy, and i think it got shot down for fear of abuse
<gary_poster> I usually set my editors to remove trailing whitespace
<barry> intellectronica: but was that fear warranted?
<gary_poster> I usually like this
<abentley> using pipeline or loom makes it easy to do drive-bys in a separate branch, then land the drive-by and the real branch at the same time.
<gary_poster> And I usually don't notice this
<gary_poster> Because it is automatic
<gary_poster> And happens when I do work on something else
<intellectronica> gary_poster: i think that's acceptable exception
<gary_poster> cool
<barry> gary_poster: i think that's the real issue for me.  drive-byes are exactly that.  you're working on something and you see something you could easily clean up right then and there.  looms/pipelines help, but not completely
<bac> abentley: so do you submit a drive-by diff after your main review?
<intellectronica> barry: but is that really a good thing to do? it is of course great to improve the codebase in general, but from the perspective of the branch you're working on, is the unrelated change really an improvement?
<abentley> bac: In this hypothetical, you'd submit them both at the same time, and then land the last pipe / top thread.
<abentley> bac: after both had been approved.
<gary_poster> I think pipelines will make it easier for me to do the non-whitespace cleanups
<barry> intellectronica: that's a great point, however i think if you don't jfdi then, it'll almost never happen.  maybe it's okay it never happens, but it seems like a wasted opportunity
<gary_poster> easier to do separately, I mean
<intellectronica> barry: honestly, i am undecided about that, but i surprised myself by thinking that there's at all a dilemma. maybe drive-bys aren't such an important thing after all
<barry> intellectronica: i'm not quite willing to go that far yet :)
<intellectronica> in a way, drive-bys are unscheduled work which you're doing at the (marginal) expense of more important work
<gary_poster> (the team lead meeting did celebrate the idea of "slack": time spent on tech debt both opportunistically and scheduled)
<abentley> intellectronica: If you look at it that way, it's easy to build up technical debt.
<barry> abentley: exactly, because such low priority issues are never scheduled
<intellectronica> abentley: au contraire. it forces you to schedule technical debt payments
<barry> intellectronica: but in practice...?
<BjornT> barry: how about always having a clean up-to-date branch. when see something that needs fixing, do the fix in the clean branch, get a quick review (showing a diff to the reviewer is enough), and merge it right-away?
<abentley> intellectronica: Perhaps we don't really disagree-- I thought you were saying that debt reduction was less important than other work.
<bigjools> pink.bikeshed.com
<BjornT> barry: that's way i always do, except that i generally create the new branch from scratch, since it's quick to do so.
<intellectronica> BjornT: yes, i think that's a good way to do it
<barry> BjornT: hmm.  sort of always having a tech debt branch laying around when you're working on the real bug.  clean things ujup there instead of your real branch?
<intellectronica> bigjools: we don't have to discuss tech debt and so on in detail. what i'd like is to get out of this meeting with a recommendation that people don't do unrelated drive-bys in the same branch
<BjornT> barry: yeah. you probably don't even to have that branch laying around, you can create it when you need it.
<bigjools> intellectronica: I think common sense should mostly prevail and if it's a simple one-liner then do it, otherwise leave it for a separate branch.
<barry> BjornT: i have stupid reasons why that might not work as well for me, but i'm going to think about it, and especially wrt to pipelines/looms
<BjornT> barry: i think the key here is that the review should be quick; the reviewers should give priority to drive-by diffs maybe.
<intellectronica> bigjools: true. but i've seen branches that are a third drive-by
<barry> intellectronica: i'm okay with that if we still find ways to encourage cleanups and other tech debt payments.  BjornT's idea, schedule slack, might hep
<sinzui> I often shelve the unwanted changes and unshelve in a new branch.
<abentley> sinzui: You mean "bzr shelve; bzr switch; bzr unshelve" ?
<intellectronica> barry: we could, like BjornT suggested, prioritize these reviews higher, or offer to review two branches one after the other if the developer went out of his way to do some cleanup work in another branch
<BjornT> barry: another thing i do frequently is to do the fix in the branch i'm working on, but then i merge that commit into a seperate branch, which i submit for review while working on completing the first branch
<barry> intellectronica, BjornT i think those are both great ideas
<sinzui> abently no, I am idiot. That sounds like what I want to do. I have been moving the shelve to the new branch
<barry> intellectronica: why don't you and i spend some time outside this meeting to formulate some guidelines and perhaps run an experiment?
<intellectronica> barry: works for me
<barry> [ACTION] intellectronica and barry to formulate guidelines/run an experiment for improving drive-by/tech debt payment
<MootBot> ACTION received:  intellectronica and barry to formulate guidelines/run an experiment for improving drive-by/tech debt payment
<barry> [TOPIC] * Noodles and I (Edwin) discovered that we were using different guidelines for what goes into the view.label property.
<barry>  
<MootBot> New Topic:  * Noodles and I (Edwin) discovered that we were using different guidelines for what goes into the view.label property.
<noodles775> barry: I sent an email out a few hours ago to lp-dev... so far it looks like the low-redundancy version that Edwin used is favoured :)
<barry> noodles775, EdwinGrubbs the floor is yours
<sinzui> barry: This is a chance for you to formalise you trivial experiment
<barry> noodles775: i way behind on my email today :(
<barry> sinzui: +1 :)
<noodles775> and danilos, the second option actually originated from a review of I did of translations pages (for jtv I think). I don't remember the page in the review, but here's an example:
<noodles775> https://translations.edge.launchpad.net/~danilo/+imports
<noodles775> With the first option the h1 would be 'Import queue'.
<noodles775> So barry, it might be worth discussing next week anyway (and end this meeting more quickly) ;)
<EdwinGrubbs> The main question is whether information is duplicated in the <h1> and the breadcrumbs, since the <h1> should give us better google juice.
<EdwinGrubbs> next week is fine
<barry> noodles775: sounds good!
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<danilos> noodles775, I still think it's nicer, +imports pages are a special case because they live on many contexts (product, distro, distroseries, person, sourcepackage), so it's hard to get them right
<barry> we have 7 minutes left.  does anybody have anything not on the agenda?
<danilos> anyway, left for next week when I hope I can participate, sorry for interruptions :)
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 09:40.
<barry> thanks everyone!
<abentley> Thanks barry.
<gary_poster> thank you barry
<noodles775> Thanks barry!
<barry> #startmeeting
<MootBot> Meeting started at 15:33. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<mwhudson> hi
<rockstar> ni!
<barry> hi!
<barry> welcome to our new earlier time
<barry> i guess i'll start with a review of ameu
<barry>  * barry will ask mrevell for help in converting the old wiki guidelines to the new dev wiki
<barry>  * beuno will work with noodles to get him ui graduated.   for the next 2 weeks, please send most of your ui reviews to them
<barry>  * talk to beuno if you're interested in becoming a ui mentat
<barry>  * intellectronica and barry will work out some guidelines for drive-by and tech debt payoff branches (contemporaneous drive-byes considered harmful)
<barry> (and we had some strategies to look at for improving drive-bys and tech debt)
<barry> that's it. is there anything you'd like to talk about?
<barry> rockstar, mwhudson ?
<mwhudson> i think the last bullet could use expansion
<mwhudson> "contemporaneous drive-byes considered harmful"
<mwhudson> ?
<barry> mwhudson: so, intellectronica pointed out how distracting drive-bys can be when reviewing a branch.  i think he observed one branch where 1/3 of the code change was tech debt.  hard to pick out the important stuff
<mwhudson> oh right yes
<barry> intellectronica even questioned whether drive-bys and the value they bring are worth the effort
<barry> i think they still are, so it's finding the right way to do them
<barry> some ideas:
<barry> * use bzr looms/pipelines to segregate the cleanups
<mwhudson> i think the cost of drive-bys to a review depends on how "easy" the review is
<barry> * use some of the schedule slack to do pure tech debt branches
<barry> (etc.)
<mwhudson> if it's a simple change to code you and the coder know well, it's no big deal
<barry> mwhudson: i usually don't mind them
<barry> i guess my goal is to make it even easier than it is now to clean up our code
<barry> how can we do that while not making reviewer lives hell?
<barry> mwhudson, rockstar any other thoughts for today?
<rockstar> barry, not from me.
<barry> mwhudson: ?
<mwhudson> oops, got taken away sorry
<mwhudson> nothing more from me
<mwhudson> barry: apart from
<barry> cool.
<barry> ...
<mwhudson> i totally support effort to keep a clean code base
<mwhudson> it's worth a lot, possibly more than one realises
<mwhudson> .
<barry> mwhudson: i completely agree!  thanks
<barry> #endmeeting
<MootBot> Meeting finished at 15:45.
#launchpad-meeting 2009-10-08
<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
<sinzui> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<stub> me
<matsubara> Chex, gary_poster, rockstar, bigjools, hi
<matsubara> allenap, hi
<gary_poster> me
<henninge-sprint> ignore me
<matsubara> translations are excused today because they're sprinting
<bigjools> me
<allenap> me
<Chex> me
<matsubara> ok, rockstar can join in later
<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> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> * matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
<matsubara> * matsubara to talk to gary about bug 436640
<matsubara> * Ursinha to talk to rockstar about failing update_preview_diffs script
<matsubara> * allenap to talk to Bugs team about bug 438985 and have it fixed.
<matsubara> * Chex to email the list about the automated LP cherry pick process
<ubottu> Launchpad bug 436640 in oops-tools "Add more info to DisconnectionErrors" [High,In progress] https://launchpad.net/bugs/436640
<ubottu> Launchpad bug 438985 in malone "Trying to make myself as bug supervisor of my project oopses" [High,In progress] https://launchpad.net/bugs/438985
<allenap> gmb is working on bug 438985 as of yesterday.
<allenap> He's not here today, so I don't know how that's going.
<matsubara>  I did talk to gary_poster about bug 436640 and I landed a fix for it yesterday.
<matsubara> but I still suck for not trawling the logs...
<gary_poster> yes, yay!
<matsubara> [action] * matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
<MootBot> ACTION received:  * matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
<Ursinha> I did talk to rockstar and abentley and they're already discussing that in another thread
<matsubara> thanks allenap and Ursinha
<matsubara> I think Francis emailed the list about the new CP process. Is that correct Chex?
<Chex> matsubara: yes I believe so, but the new process is on hold at the moment
<matsubara> Chex, right. that's fine. thanks
<matsubara> let's move on
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> OOPS-1374EA1128 for soyuz or foundations
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1374EA1128
 * bigjools looks
 * gary_poster does too
<matsubara> it's an api operation failing in some librarian thing
<bigjools> that's related to a soyuz bug
<bigjools> bug 443075
<ubottu> Launchpad bug 443075 in soyuz "security package unembargo is broken on edge" [High,In progress] https://launchpad.net/bugs/443075
<bigjools> and is in progress
<matsubara> bigjools, related in the sense that it'll be fixed when a fix for 443075 lands?
<bigjools> yes
<matsubara> cool. thanks
<bigjools> np
<matsubara> and now properly linked to the bug report :-)
<matsubara> allenap, can you confirm OOPS-1371EB1331 is the same as bug 394097
<matsubara> ?
 * allenap looks
<ubottu> Launchpad bug 394097 in malone "accessing message 0 of bug 371281 gives wrong return type of IMessage" [Undecided,New] https://launchpad.net/bugs/394097
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1371EB1331
<bigjools> matsubara: what is "properly linked?"
<rockstar> Sorry I'm late...
<matsubara> sinzui, do you know if barry succeeded in CP the expaterror fix?
<sinzui> he informed me that it was up to you to champion that since we know the problem does not affect users
<allenap> matsubara: Yes, they look the same.
<sinzui> matsubara: I believe it is on the CP request list
<matsubara> allenap, abel explains in bug 438671 it's a won't fix. so it means the OOPS is informational only?
<ubottu> Launchpad bug 438671 in checkbox "HWSubmissionMissingFields OOPS on +hwdb/+submit" [Undecided,Confirmed] https://launchpad.net/bugs/438671
<matsubara> thanks allenap
<matsubara> bigjools, linked the oops to the bug report. oops summaries will contain a link to the bug report from now on
<bigjools> ah
<bigjools> can anyone do that?
<matsubara> yep, anyone with access to lp-oops.canonical.com
<allenap> matsubara: ISTR that Abel mentioned that on a stand-up; yes these are informational only.
<gary_poster> matsubara: time to introduce "handling" ;-)
<matsubara> sinzui, if it's there, than it's all fine. thanks
<matsubara> gary_poster, yeah, I'm going to announce that :-)
<gary_poster> cool
<matsubara> so, I landed a new api to our ErrorReportingUtility yesterday which marks oops reports as informational only
<allenap> matsubara: Those OOPSes are more likely to indicate a bug in the client.
<matsubara> I'll email the devel list and let you know more details
<matsubara> [action] matsubara to email the devel list about the new api method
<MootBot> ACTION received:  matsubara to email the devel list about the new api method
<allenap> mars: It might be interesting to use the User-Agent in those OOPSes to file bugs against the clients, i.e. checkbox-gtk.
<matsubara> allenap, right. I'll file a bug to have those marked as informational only
<matsubara> [action] matsubara to file a bug to have the HWSubmissionMissingFields oopses as informational only (note to self: see bug 438671 for more details)
<MootBot> ACTION received:  matsubara to file a bug to have the HWSubmissionMissingFields oopses as informational only (note to self: see bug 438671 for more details)
<ubottu> Launchpad bug 438671 in checkbox "HWSubmissionMissingFields OOPS on +hwdb/+submit" [Undecided,Confirmed] https://launchpad.net/bugs/438671
<matsubara> scripts failures for this week:
<matsubara> the librarian-gc failed
<matsubara> on the 3rd and the 6th
<matsubara> stub, Chex: do you know anything about it? can you follow up on the failure email please?
<stub> This has now been fixed
<stub> The last run worked fine - required cherry picks have all been made.
<matsubara> cool. thanks stub
<matsubara> for the critical bugs, we have only one in progress, which is a translations bug.
<matsubara> all the others are fix committed
<matsubara> I think that's all for this section. thanks everyone
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara> Chex, ?
<Chex> hello everyone
<Chex> Here is our LOSA report for this week:
<Chex> - Automated LP Cherry Picks: The automated CP processing into PQM has been disabled for now due to Bug: 442934. We would appreciate to know the status of getting this issue addressed.
<Chex> - SplitIt setup: We have received the new hardware in the Datecentre, and we are in the process of
<Chex> configuring & setting up LP on these new systems now.
<Chex> - New "QA Info" column in the Incident Log: We have a new column in the incident log that the Dev's can
<Chex> fill in to document ways of fixing the production incidents we list.  We suggest that someone reviews the new
<Chex> items on the page and make comments on them at least once a week.
<Chex> - LP incidents of note: Codebrowse restarted many times as usual; CPs applied: CP 9638, 9646 to loganberry ;
<Chex>         CP 9588, 9610, 9621 to librarian2, xmlrpc-internal, bzrsyncd, mailman
<Chex> Does anyone have any questions or comments?
<gary_poster> Chex: flacoste is pretty interested in https://bugs.edge.launchpad.net/pqm/+bug/442934 too .  He has it in his to-do list to pursue.
<ubottu> Launchpad bug 442934 in pqm "unknown url type 'bzr+ssh://bazaar.launchpad.net/$user/$project/$branch;revno=$int'" [Undecided,New]
<matsubara> Chex, about the splitit setup, are we expecting any new oops ids? I glanced over the email about it and notice that there will be lots of new instances running
<matsubara> s/oops ids/oops prefixes/
<gary_poster> (I'm interested too, but he's going to do something about it :-) )
<allenap> Chex: Was that for lp-source-dependencies?
<stub> If I recall from the email conversation, that bug is on a feature we don't actually need to be using.
<stub> (because we have no need to freeze the revision of the dependencies branch being used).
<allenap> Chex: Because... what stub said.
<matsubara> rockstar, any news about the code browse issue?
<Chex> matsubara: not sure about the OOPS ids, but I believe we will need that. I will check on that for you
<rockstar> matsubara, not yet.
<matsubara> [action] chex to check the new oops prefixes added by the splitit setup and inform matsubara
<MootBot> ACTION received:  chex to check the new oops prefixes added by the splitit setup and inform matsubara
<mthaddon> matsubara: for new OOPS ids see the lp-production-configs trunk branch
<Chex> allenap: ok, I will check into that bug status, then. I am not sure of that issue myself.
<gary_poster> stub, allenap, Chex: we need bug 442934 for the branches in sourcecode
<ubottu> Launchpad bug 442934 in pqm "unknown url type 'bzr+ssh://bazaar.launchpad.net/$user/$project/$branch;revno=$int'" [Undecided,New] https://launchpad.net/bugs/442934
<matsubara> thanks mthaddon
<mthaddon> matsubara: can we 'unaction' that one from Chex?
<gary_poster> not for the buildout-related branch
<matsubara> [action] matsubara to ignore the previous Chex action and look in lp-production-configs for the new oops prefixes.
<MootBot> ACTION received:  matsubara to ignore the previous Chex action and look in lp-production-configs for the new oops prefixes.
<mthaddon> cool, thx
<matsubara> Chex, about the QA info column, do you have a handy link?
<Chex> matsubara: sure, I should have included that
<Chex> https://wiki.canonical.com/InformationInfrastructure/OSA/LPIncidentLog
<matsubara> thanks Chex
<matsubara> [action] all QA contacts to inform their teams about the new QA column and what they should do about it.
<MootBot> ACTION received:  all QA contacts to inform their teams about the new QA column and what they should do about it.
<matsubara> Chex, did you send an email about the new QA column to the list?
<Chex> matsubara: no I did not, but I can do that for you.
<matsubara> if not, it'd be great if you could send it and explain what you the losas expects there
<matsubara> thanks Chex
<Chex> matsubara: sure, no problem
<matsubara> [action] Chex to email the list about the new QA column in https://wiki.canonical.com/InformationInfrastructure/OSA/LPIncidentLog
<MootBot> ACTION received:  Chex to email the list about the new QA column in https://wiki.canonical.com/InformationInfrastructure/OSA/LPIncidentLog
<matsubara> let's move on
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> The database patch approval process has changed. Previously, they went through me and then had to get a second level of approval by Mark at a monthly meeting. Now they just need to be approved by both myself and jml. We should now be able to track everything with merge proposals and the system will be much less time sensitive, allowing reviews to happen throughout the cycle.
<stub> A new database replica is being brought online as I type. It will be left running as a replica for a few days to ensure it has no problems keeping up (it doesn't have much RAM). Assuming the burn in goes fine, it will become the master for the authdb replication set as part of the ongoing process to separate the authentication systems from Launchpad.
<stub> The databases will all need to be bounced soon to increase the maximum number of connections. We need to do this as we are bringing new appservers on line (per the results of the performance sprint in Montreal). Assuming tests on staging go well, we should be able to do this with no end-user noticeable effects as the database reconnection handling with handle the short outage just fine.
<stub> Bug #426823 is tracking the progress of getting Launchpad to run with PostgreSQL 8.4. At the moment, it looks like we will need to wait until 8.4.2 as we are tickling a PostgreSQL bug. This bug has been tracked down with upstream and a patch is available, but I'd prefer if we stuck to official releases than assembling our own package. We are also blocked by the release of Slony-I 1.2.17, assuming we don't want to move forward with using the
<ubottu> Launchpad bug 426823 in launchpad-foundations "Update to PostgreSQL 8.4" [Medium,In progress] https://launchpad.net/bugs/426823
<stub> There are still some test failures to address with PG 8.4. Some are ordering problems where we were incorrectly relying on database ordering, other issues might be more serious where we are obtaining different results than under 8.3. I may pass some of these onto the teams to see if something is broken under 8.4 or if the issue is benign.
<stub> oot.
<matsubara> questions for stub?
<matsubara> thanks stub
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> no new proposed item
<matsubara> anything else before I close?
<matsubara> 4
<matsubara> 3
<matsubara> 2
<matsubara> 1
<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:36.
<gary_poster> thanks matsubara!
<allenap> stub: I'm just catching up. One line got truncated, ends with "assuming we don't want to move forward with using th". Can you paste from there?
<stub> assuming we don't want to move forward with using the release candidate. I'll land the branch allowing people to run 'make schema' with PG 8.4, but I don't recommend anyone do this yet because the PG bug we are tickling is fairly pervasive and it will end in frustration.
<allenap> stub: Thanks :)
#launchpad-meeting 2010-10-13
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> show of hands
<gary_poster> me
<EdwinGrubbs> me
<mars> me
<abentley> me
<gmb> me
<deryck> me
 * mars pokes leonardr 
<leonardr> me
<mars> :)
<sinzui> me
<gary_poster> (bac's earlier poke--thank you--used leonard not leonardr fwiw)
<allenap> me
<jelmer> me
<bac> gary_poster: fixed, thanks
<gary_poster> np, ty
<bac> flacoste: ping
<bac> bigjools: ping
<flacoste> me
<bac> == Agenda ==
<bac>  * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
 * bigjools is here
<bac>  * Mentat update.
<bac>    * salgado (ui)
<bac>    * henninge (ui)
<bac>    * stevenk (code)
<bac>  * New topics
<bac>    * Survey on using the ArchitectureGuide in reviews.
<bac> so not much on the agenda so perhaps this will be brief
<bac> salgado: ping
<salgado> hi there
 * salgado needs to re-add this meeting to his calendar
<bac> [topic] outstanding actions
<MootBot> New Topic:  outstanding actions
<bac> [topic] * Sinzui to investigate making lint check for the Storm 'in' gotcha
<MootBot> New Topic:  * Sinzui to investigate making lint check for the Storm 'in' gotcha
<bac> sinzui: any progress last week on that?
<sinzui> Some progress. My effort always reports 5 sql issues instead of 0 storm issues
<sinzui> We could switch the 5 issues to storm and say the regex works
<bac> ok, we'll roll it over.  thanks for beginning the investigation.
<bac> [topic]  HenningE to add a note to the PSG about the use of any
<MootBot> New Topic:   HenningE to add a note to the PSG about the use of any
<bac> henning is not in the meeting today and i didn't think to look beforehand, so no new
<bac> [topic] * Mentat update.
<bac>    * salgado (ui)
<MootBot> New Topic:  * Mentat update.
<bac> salgado: you're the only mentat here.  getting any UI reviews?
<salgado> haven't done many reviews last week
<salgado> maybe because it was week 3?
<bac> salgado: i'll have one for you tomorrow
<salgado> ok, cool
<bac> stevenk was absent last week so i'm not sure how his mentoring is going
<bac> [topic] New topics
<MootBot> New Topic:  New topics
<bac> [topic]  Survey on using the ArchitectureGuide in reviews.
<MootBot> New Topic:   Survey on using the ArchitectureGuide in reviews.
<bac> this is really an old topic
<bac> but lifeless asked me to address it again here.
<bac> he's really interested to hear feedback on how incorporating the core values he outlined for our architecture guidelines are showing up in reviews
<sinzui> I think the document is really about architecture ideals. I agree with everything written
<bac> does anyone have any feedback?
<bac> sinzui: and do you find they are applicable as you're evaluating branches?
<sinzui> yes
<bac> i've not gone through reviews to see if reviewers are asking probing questions regarding scalability, query counts, etc
<abentley> bac: I think it needs to be taken with a huge chunk of salt-- while these are reasonable principles, I would like to see YAGNI and KISS there, to balance out scope-creep/premature-optimization tendencies.
<bac> abentley: those are good ideas.  and it is a wiki.  please add your ideas.
<bac> lifeless reports he's getting pressure from "management" to show how we're incorporating the architecture guidelines.
<bac> uh, flacoste, would you like to address that?
<flacoste> hehe
<flacoste> yeah, i'm the pressure :-)
<flacoste> one thing that he's proposed is to use metrics around these principles
<flacoste> i wondered if people had tried using them
<flacoste> at all
<flacoste> and if not, why
<flacoste> those metrics are tentative, but without feedback we cannot iterate over them
<bac> so i'm looking the metric over.  (follow along at https://dev.launchpad.net/ArchitectureGuide#Design%20metrics)
<bac> today i introduced a new test.  it is nowhere near 2 secs.
<bac> my reviewer didn't bring it up and neither did i.  so we fail.
<mars> flacoste, case studies and practice.  Also, introducing five new metrics at once sounds like a bit much.  Usually we only add one new review check-point a week, tops
<mars> So, "This weeks's (or month's) effort is to not write any new tests over 2 seconds.  Ask your reviewer to check"
<flacoste> that sounds sane
<mars> sane is good
<flacoste> should we do that?
<bac> mars: i agree. thanks for the suggestion
<gary_poster> +1 on mars point; that jibes with some hunch I couldn't put my finger on
<bac> flacoste: +1. i think the problem is one of just being overwhelmed
<leonardr> this is more a nitpick, but a value judgement like "expected to deal with <100 bug tracker types" is difficult to make ahead of time. "O(N) in the number of bug tracker types" is easier
<flacoste> leonardr: it's a wiki :-)
<flacoste> and there were no follow-ups to lifeless announcement of the guide and request for feedback
<flacoste> bac, can you follow-up with mars' plans and coordinate the results?
<bac> flacoste: i will
<flacoste> thanks!
<mars> for the room: https://dev.launchpad.net/ArchitectureGuide?action=subscribe
<gary_poster> (FWIW, I don't like the "it's a wiki" answers--thattoo much when someone owns the page/process like this.  That said, ack to flacoste's other point about a lock of follow-ups)
<gary_poster> argh, was in middle of edit
<bac> [action] bac and mars to come up with a plan for gently introducing new reviewer guidelines wrt the architecture document
<MootBot> ACTION received:  bac and mars to come up with a plan for gently introducing new reviewer guidelines wrt the architecture document
<gary_poster> ...I don't like the "it's a wiki" answers--that's the second one--too much...
<gary_poster> and s/lock/lack/
<flacoste> gary_poster: sending an email to the author with the suggestion is an alternative
<abentley> I think "it's a wiki" answers are actually wrong.  If we're adjusting review criteria, we should bring it up in the reviewer meeting.
<gary_poster> sure, +1, or a "suggestions" section on the bottom of a wiki
<gary_poster> yeah, that makes sense to me.
<gary_poster> (bring it up in the reviewer mtg, that is)
<gary_poster> though email works too
<leonardr> let me rephrase it as a non-nitpick: are we supposed to measure at what point scalability becomes a problem, or consider the performance characteristics in the abstract?
<bac> abentley: you are correct.  i didn't mean for it to stifle discussion.  at the same time, as the owner of the new idea you should be willing to edit the doc after the discussion is over
<leonardr> i think the latter is better on the yagni principle
<leonardr> and because the pieces of launchpad interact--if there are 100 bug tracker types there are probably a few million bugs
<gary_poster> I like the latter description too, but flacoste is after a measurement.  Perhaps multiple suggested measurements would be an option, but that has additional problems, for possibly not much of a solution
<gary_poster> (and I like measurements too)
<flacoste> i think it's the former actually measure at what point (scalability becomes a problem)
<flacoste> because a O(N) algorithm isn't a problem when you know the data set is small
<flacoste> so it really depends on the application
<flacoste> but sure, abstract analysis is useful in the analysis
<flacoste> but still, the key question to answer is: will this scale given our data set (and expected growth)
<bac> any other discussion on this one?
<bac> [topic] any other issues?
<MootBot> New Topic:  any other issues?
<leonardr> (i can go on, but it doesn't have to be part of the meeting)
<bac> leonardr: please do.  let's end the meeting, though, and people can stay and chat
<bac> #endmeeting
<MootBot> Meeting finished at 09:32.
<leonardr> ok
<mars> thanks bac
<leonardr> to me, "This component is expected to deal with < 100 bug tracker types", even if someone actually went and measured and found that 100 was the point where the problems started, doesn't say anything beyond "this algorithm is superlinear but we don't expect n to be very large"
<leonardr> for an algorithm that's superlinear in the number of bugs associated with a bugtask, or an algorithm that's o(n^2), i'd be more interested in an actual measurement
<jelmer> leonardr: As I understand it that's all it's meant to indicate, perhaps it's more useful to say that rather than mentioning (unfounded) estimates.
<flacoste> leonardr: i can agree with that
<leonardr> ok, i'll edit the wiki
#launchpad-meeting 2010-10-14
<mwhudson> hello
<bac> #startmeeting
<MootBot> Meeting started at 19:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> hi guys
 * rockstar  
 * StevenK waves
 * wallyworld__ waves back
<bac> [topic] outstanding action
<MootBot> New Topic:  outstanding action
<bac> [topic] Sinzui to investigate making lint check for the Storm 'in' gotcha
<MootBot> New Topic:  Sinzui to investigate making lint check for the Storm 'in' gotcha
<bac> last week we talked about using the Python 'in' operator with Storm and how it is Bad.  sinzui reports pretty good progress on changing lint to sniff these occurrences out.  yay.
<bac> [topic] HenningE to add a note to the PSG about the use of any
<MootBot> New Topic:  HenningE to add a note to the PSG about the use of any
<bac> 'any' and 'all
<bac> actually.  henning wasn't at the meeting so we don't know if he got around to it
<bac> [topic] Mentat update.
<MootBot> New Topic:  Mentat update.
<bac> stevenk, how is the mentoring process going?
<StevenK> Quite slowly, sadly. thumper was on holidays and I forgot I was OCR, so that didn't help/
<bac> StevenK: what is your day?
<StevenK> Wednesday AsiaPac
<bac> ok.  i'll try to throw my next branch at you.
<StevenK> Sounds good. :-)
<bac> StevenK: when you have spare time you can always pull branches off +activereviews
<StevenK> It's the spare time of that sentence that's getting me too.
<bac> hi lifeless
<bac> recall too that henning and salgado are UI review mentats.  please consider them first for your UI reviews.
<bac> and also note we lose noodles as a UI reviewer as he moves to ISD
<wallyworld__> does that mean we should explicitly specify those guys when requesting a review instead of leaving it up for grabs?
<bac> wallyworld__: yes, that would be good if you do
<lifeless> did I miss some context?
<mwhudson> lifeless: mentored reviewer progress
<lifeless> so bottlenecking on two folk makes me wary
<lifeless> could we just say that 'all nonUI reviewers are UI review mentees'
<lifeless> and then if you happen to have a mentee on a branch with UI stuff that the mentee doesn't feel capable on, they can call in a mentor?
<bac> well, if he were a mentee then by definition he'd have to call in a mentor to approve the branch
<bac> rockstar what have we said about moving everyone towards being UI reviewers?
<mwhudson> is bottlenecking on ui reviews a problem people are having?
<mwhudson> as someone who touches the lp ui about once a year, i have no idea :-)
<rockstar> bac, well, after chatting with sinzui, I think henninge can probably graduate.
<rockstar> bac, I think I was pushing for everyone being a javascript reviewer first.
<bac> rockstar and i think salgado must be close
<lifeless> I will admit that I've just ignored needing/not needing a UI review; but I suspect I'm a special case in that regard
<rockstar> bac, unfortunately, after my recent javascript work, I kinda want to go the other way now.  :)
<rockstar> lifeless, how are you a special case?
<lifeless> rockstar: either I've never made a UI change that needed a UI reviewer (and I don't know what triggers that clause)
<lifeless> rockstar: or noone has felt comfortable telling me they think a branch will need one
<rockstar> lifeless, usually, your reviewer should tell you.
<lifeless> rockstar: or I've had a UI reviewer by chance when I've needed one
<rockstar> bac, ideally, everyone is a everything reviewer.
<lifeless> I think we should just work on that basis
<rockstar> lifeless, unfortunately, I can't agree.
<lifeless> and if someone's review isn't catching what we care about, we act on that and help them improve
<lifeless> rockstar: why not?
<rockstar> lifeless, I think (currently) most people's reviews aren't catching what we care about.
<lifeless> rockstar: I agree. For /all/ review types.
<rockstar> lifeless, at the Epic two years ago, we made a big push to start doing more javascript.  Unfortunately, most people are avoiding that.
<wgrant> FWIW, I think reviews are at the moment fairly useless.
<wgrant> They mostly seem to check stylistic issues, but rarely anything functional.
<lifeless> last week we talked about what reviews should be doing; I'm working on a clear articulation of the issues I see there.
<rockstar> wgrant, yeah, that's what lifeless' arch guide is about.
<mwhudson> i find most of my review comments are insisting that comments are accurate and make sense
<mwhudson> i think this is still valuable though
 * rockstar has that in mind when he does reviews.
<lifeless> rockstar: cool
<lifeless> rockstar: so, I still don't understand your objection
<mwhudson> we suck at js?
<rockstar> mwhudson wins, methinks.
<lifeless> if most reviews are not getting at things we care about, it seems like to be one of a few things:
<bac> wgrant: do you feel the quality of reviews has gone down lately or have they always been superficial and mostly useless?
<lifeless>  - insufficient training / depth of knowledge / breadth of knowledge
<lifeless>  - fear of getting deep in
<lifeless>  - insufficient time to do the review well
<wgrant> bac: It hasn't changed lately.
<lifeless>  - ???
<lifeless>  - profit!
<wgrant> But, well, I haven't been around long.
<lifeless> bac: they weren't always superficial, but there were problems centred around having very large pieces of work arrive all at once with very poor internal structure
<mwhudson> lifeless: harking back to last week, i think an issue is that for the things we care about now, review is too late
<lifeless> the desired solution to that - smaller bits of work - has seemingly resulted in shallower reviews
<bac> lifeless: i was about to raise that issue
<lifeless> mwhudson: I don't think its too late per se.
<mwhudson> lifeless: your way of putting it makes a lot of sense too
<bac> smaller units of work mean it is harder to cohesively see the bigger effort
<lifeless> mwhudson: but it sure is hard if the incoming branch has *lots* of room to improve :)
<mwhudson> 8 small reviews do not, in some sense, make up a good review of the one large feature they all implement
<lifeless> right
<mwhudson> well hurrah, we all agree on this point :-)
<lifeless> and I'm not about to suggest that we go back to the good^Wbad ol' days
<mwhudson> it would be an interesting experiment: i wonder how much effort on general code quality the simple knowledge that you have to get your code through review has
<wallyworld__> would a solution be to have a larger unit of work split into smaller chunks, but insist on the one reviewer all the way through to keep the bigger picture aspects in mind?
<lifeless> effort? impact?
<bac> of course the problem is made worse when the n reviews for the n smaller branches are spread over n reviewers
<lifeless> mmm
<mwhudson> maybe i should try to find a CS lecturer to do this experiment...
<lifeless> so LP is small enough for one developer to whole a reasonable approximation of the entire system in their head.
<lifeless> and we have dedicated periods for review when folk don't have to be simultaneously cutting new code.
<StevenK> I think that's a fallacy
<StevenK> I have trouble keeping all of the bits I care about in my head, so I don't see how anyone could keep track of the whole of Launchpad, even to a reasonable approximation -- we also move far too quick for that
<lifeless> it may be false to say that all lp developers can do that.
<lifeless> StevenK: we move glacially.
<StevenK> As a whole, yes
<StevenK> Certainly aspects are changing quicker
<mwhudson> i think lp is a bit too big to hope for many people to understand how it all fits together
<StevenK> s/ly//
<lifeless> I'm going to take a second to put some thoughts together
<lifeless> ok
<lifeless> so here's the thing.
<lifeless> either the system is so big that we can no longer tell whats in it.
<lifeless> In which case I think we need a rule like drizzle had(has?) - no patch can make the codebase bigger. Smaller only. Fin.
<lifeless> Or the system isn't that big.
<mwhudson> hmm
<lifeless> In which case I think its reasonable to ask that reviewers be getting the big picture, looking for things that should have been refactored, things that will scale poorly, etc.
<mwhudson> partially baked thought, but
<mwhudson> it's not really size that's the thing to worry about, but complexity, and in particular, close coupling
<lifeless> mwhudson: inappropriate coupling for sure.... sometimes close is a benefit. Sometimes not ;)
<lifeless> mwhudson: cohesion + close-coupling are two metrics I would grab offhand for talking about complexity.
<bac> "inappropriate coupling" is new on the BBC, i think
<mwhudson> lifeless: i guess -- i mean stuff like when code developer A reviews code developer B's code and then breaks translations
<lifeless> mwhudson: yes, that sucks;
 * lifeless puts some more coal the mwhudson thinking bbq
<lifeless> s/the/ on the/
<mwhudson> :)
<mwhudson> as per usual in an unclear discussion, perhaps we need to ask "what is the problem here"
<mwhudson> most reviews are perfunctory: not /really/ a problem
<lifeless> mwhudson: its a problem
<mwhudson> reviews are wasting developer time and reducing velocity: that's a problem
<lifeless> that too
<lifeless> (sorry, didn't mean to break your flow; fingers-up)
<mwhudson> lifeless: or another way, perfunctory-ness is a problem, but it requires looking a layer in
<mwhudson> i recall back in 2007 when it would sometimes take days to get your code reviewed; it's a lot better than that now
<mwhudson> (unless you're jam :/)
<lifeless> mwhudson: now it takes days to land it :)
<mwhudson> yeah
<mwhudson> that's certainly a problem
 * mwhudson gets off the soapbox
<lifeless> so I think reviews that miss crucial things like 'will blow out the query count for the home page' are a problem.
<bac> mwhudson: the slowness to get reviews back then certainlly wasn't due to more thoroughness of the review
<mwhudson> bac: no, it was due to idiotic processes :)
<lifeless> and reviews that happily add a duplicate (nearly line for line) result set decorator likewise.
<bac> right
<lifeless> but we were talking UI and javascript
<lifeless> we have formalise the idea of:
<lifeless>  - code reviews
<lifeless>  - db reviews
<mwhudson> lifeless: for the latter, good code organization probably help
<lifeless>  - ui reviews
<mwhudson> s
<lifeless>  - javascript reviews
<lifeless> we have an idea of structural/architectural reviews which I've introduced as an element of code reviews.
<lifeless> as you say, a review that slows velocity and doesn't add compensating value is a problem.
<lifeless> are there other problems that folk would like to note, about reviews
<lifeless> I'll take that as a no
<lifeless> so for every *different* review type we require a change to go through we create a handoff
<lifeless> we've recently shifted the 'qa review' (typically self-inflicted) from being arbitrarily close to release to being a pipeline stall for everyone, for instance.
<lifeless> we've justified that by saying that the risk of a bad deployment outweighs the cost of having a stall
<lifeless> on all our review types, we don't prevent all issues entering the codebase (note that I'm not saying we -should-)
<lifeless> but if its a sliding scale (I think it is), why can't we get more folk involved in the reviews, training up the scale now ?
<bac> what do you mean by getting more people involved?
<lifeless> bac: Why can't stevenk, for instance, do a javascript review, and:
<lifeless>  - if he feels out of depth, punt (but watch the review to learn)
<bac> lifeless: that is exactly the process for JS
<lifeless> is it the same process for UI? I was told here by you that it wasn't...
<bac> it is not
<lifeless> why isn't it?
<bac> b/c historically UI changes were jealously guarded by our UI designer.
<lifeless> do we have a UI designer now ?
<bac> the review point was abused as the time for actually doing UI design
<bac> lifeless: no, we do not
<lifeless> then I think we should change this.
<lifeless> if we were to make it the same as JS; what risks would we face? What benefits would we get? we probably need to think about the risks reasonably closely.
<bac> we do have a small set of UI reviewers who are supposed to enforce not just a nicely designed UI for a given page but one that fits into the larger system
<lifeless> are UI changes qualitatively meeting that goal?
<lifeless> at a higher success rate per change than other sorts of changes in the system?
<bac> unmeasured
<lifeless> fwiw the feedback I hear is that the LP ui is confusing and strange
<wallyworld__> should ui changes/additions go through an approval process by ui gatekeepers at the *design* stage? using balsamic etc?
<mwhudson> it's probably better than it was though
<lifeless> my personal and professional opinion is that UI is driven by the entire stack.
<wallyworld__> +1 on the lp ui comment from lifeless
<lifeless> trying to make it nice at the top end is a world of pain.
<bac> wallyworld__:  i think that would be much better
<bac> guys i hate to duck out on a great conversation, but we are over time and i have another commitment
<lifeless> unless the defintion of UI is -extremely shallow-
<lifeless> wallyworld__: I may misunderstand but isn't balsamiq just a mockup tool?
<bac> feel free to stay and chat and i'll read the backlog
<wallyworld__> yes, but it can be used as a tool to help communicate ui design etc for approval
<lifeless> so this comes back to mwhudsons point about *when* we decide various things
<lifeless> do we decide to have a composite or inheritance in review or 'preimpl' or 'as we go'
<mars> wallyworld__, we set out, as a team, a process for using balsamiq for mockups - it's the easiest, fastest way to try and iterate upon and idea
<wallyworld__> yes, review time is way too late for lots of things
<lifeless> replace those terms with whatever ones make sense for e.g. db, javascript, language, etc etc
<mars> wallyworld__, and we really like to do mockups before writing code - Michael Nelson and his work on the packaging UI is an exemplar of the technique
<lifeless> wallyworld__: by way to late, do you mean 'it can feel very hard to change those things after doing some work on them'
<wallyworld__> i think we are saying the same thing with balsamic
<wallyworld__> the main point with mentioning balsamic is that i was trying to say we need to use various tools to communicate ui changes for approval *before* code is written
<lifeless> I'd like a better definition of 'too late'
<wallyworld__> "too late" = the cost of fixing issues becomes too great
<lifeless> wallyworld__: I think thats a pessimisation and we can do better; it adds handoffs and roundtrips that are poorly justified.
 * wallyworld__ thinks
<wallyworld__> it's all a balancing act. handoffs are bad but so is trying to fix stuff too late in the process
<lifeless> wallyworld__: I'm thinking -very- big picture here: approval meaning 'passes whatever criteria we as a team have decided on', and the topic being any of ui/js/python code/db/component choices/...
<lifeless> What I'd like to see is, broadly:
<lifeless>  - stop treating all changes as homogeneous (they aren't)
<lifeless>  - the amount of approval needed should vary with the impact of a mistake
<wallyworld__> i'd the the *timing* of approval should relate to the best place to identify and fix mistakes
<lifeless> mmm
<wallyworld__> i meant "i'd add..."
<lifeless> that leads to the BDUF set of issues
<lifeless> I'm entirely happy with the goal of having such discussions as needed to be move forward early
<lifeless> but approving before its done is a great way to fail to adapt to changing needs
<wallyworld__> doesn't have to mean BDUF....
<mars> lifeless, "BDUF"?
<lifeless> big design up front
<mars> ah, of course
<wallyworld__> we just need to be pragmatic and use our skills as experiences software engineers to do "what's right"
<lifeless> wallyworld__: lets set a goal: 4 hours to concieve and deliver *into production* a change.
<lifeless> wallyworld__: if you can fit preapprovals into that, I will happily tolerate them.
<wallyworld__> surely that 4hr window depends on the scope of the change?
<wallyworld__> and at the moment, that whole 4hrs would be consumed by the landing process :-(
<lifeless> wallyworld__: if you don't break things up into small pieces yes. And that comes back to the scaling points I made above.
<lifeless> wallyworld__: yes, but don't let currently problems drag you down :)
<wallyworld__> ah, but to have the small pieces to implement, you often need to have the bigger picture all sorted so that it can be chunked up
<wallyworld__> and you often need approval/review of the bigger picture design
<wallyworld__> before it is to be split up into units of work
<lifeless> wallyworld__: well, wearing my TA hat, I can say that I won't approve things at that level: I will discuss and collaborate, and reject things that are clearly problematic.
<wallyworld__> well that's review rather than approval. so long as those biiger picture things are collaborative and have more than one set of eyes on them
<lifeless> wallyworld__: but I'm not interested in saying 'this is definitely ok' for 2 months work - I think its a poor idea (and lots of literature on estimating work, and the overal XP/agile community agree AFAICT)
<wallyworld__> +1. see my previous comment
<wallyworld__> you just want to stop any obvious failings before they have a chance to go too far
<lifeless> right
<wallyworld__> and perhaps ask some pertinant "have you thought about this or that questions"
<lifeless> I've said it before, I'd be delighted to see much more design traffic on the list.
<wallyworld__> to minimise the chances of issues down the track
<lifeless> designs seem to be happening largely in very private discussions and then we hit the 'its hard to change this now' complaint at review time
<mwhudson> yeah, it can be hard to get a response to this
<wallyworld__> i agree that's bad and we should encourage a culture where that doesn't happen
<lifeless> mwhudson: 'this'?
<wallyworld__> perhaps people are scared to make a mistake or look bad in front of the entire list?
<mwhudson> lifeless: sorry, bad phrasing
<wallyworld__> so it's easier for them to do design stuff in a smaller group?
<lifeless> mwhudson: de nada, just couldn't bind it sensibly.
<mwhudson> lifeless: basically, design proposals to launchpad-dev are often greeted with a deafening silence
<lifeless> wallyworld__: look at what I do for instance; small stuff I JFDI, larger stuff I do a spike on / mail the list for discussion.
<mwhudson> maybe we need an "on call design opinion" as well as on call review
<wallyworld__> mwhudson: +1
<lifeless> mwhudson: studies on group intelligence suggest that the dominating ability to be 'smart' as a group is getting everyones opinion.
<lifeless> so -1 on on-call
<mwhudson> for example, i was the only person to respond in depth to one of lifeless
<mwhudson> ' design mails, and i'm not even on the team any more
<mwhudson> lifeless: put it another way
<lifeless> I think it would be great to use the OCR as a teddy bear, if thats what you meant
<mwhudson> back in the lean training, i remember advocating the idea that doing reviews was at least as important as doing your 'own' work
<mwhudson> argh, one more step back
<lifeless> it would be interesting to have everyone read every commit.
<mwhudson> hypothesis: people don't reply to design mail because they don't feel they have the time/energy to really dig into it and respond usefully
<lifeless> for a week.
<wallyworld__> mwhudson:  i'd like to provide more input but feel i need to learn the lp architecture a bit more first :-)
<lifeless> wallyworld__: please do, don't hold back.
<wallyworld__> be careful what you wish for :-D
<mwhudson> proposed solution: promote a culture where replying to design mail is considered a really good way of spending your time
<mars> mwhudson, did we not have the technical architecture group and [tech] (I think) mailing list tag for that?
<mwhudson> hence my analogy to reviews -- similar problems were held up wrt getting reviews done back in 2007
<wallyworld__> +1. atm i personally find it really hard to keep up with the volume of email and get my "core" work done
<mwhudson> i.e. not enough time
<lifeless> mars: the t-a-g is a design failure - it adds filtering to what should be a core dev responsibility
<mwhudson> ocr + cultural changes helped there
<mwhudson> on call design (ocd? :-p) may not be the thing here
<lifeless> I think the dominating driving factor though is test suite time.
<wgrant> mwhudson: Not enough time, or infrastructure issues (slow tests, third-time's-the-charm landing) making it ridiculously inefficient?
<mwhudson> but cultural change possibly
<lifeless> it more than anything else saps time and adds to the pressure to be *doing* not *talking*
<mwhudson> wgrant: hey, a 4 hour test suite gives you _masses_ of time to reply to design mails :-p
<wgrant> True, true.
<lifeless> mwhudson: I agree that cultural change is needed too; see for instance flacostes thread recently.
<mars> lifeless, I think one goal was to have a group of interested and capable experts from the LP team who could reply to design decisions.  The [tag] changed the social contract to be "must reply" for that group.
<wallyworld__> mwhudson: not when something fails and you burn time looking into why and find out it's not your stuff after all :-(
<mwhudson> lifeless: yes, making dev generally easier and smoother will help
<mwhudson> wallyworld__: yeah, i wasn't being very serious there
<lifeless> mars: I want input from the least experienced of our engineers as much as the most.
<wallyworld__> i know, just being mischievious
<lifeless> s/m.*$/aussie/
<lifeless> :)
 * wgrant stomps on lifeless.
<mwhudson> i need to duck out now too
<lifeless> me too; lunch calls
<lifeless> I'd like to highlight one really important bit that this discussion clarified for me.
<mars> lifeless, well, the group was to prevent the deafening silences mwhudson spoke of.  Anyone was free to opine in the thread
<lifeless> 'its too hard at review time' really means 'engineers find changing things at review time hard'
<StevenK> Personally, I don't find it hard.
<StevenK> It just sucks to rewrite something you just wrote.
<lifeless> pre-landing review is *entirely* capable of identifying ui glitches, js bugs, code structure issues, performance issues.
<wallyworld__> i'd rephrase as "it's too hard to fix a bad design issue onces it's already been coded"
<wgrant> it shouldn't happen at review time.
<lifeless> wallyworld__: the bit I object too is 'too hard'
<StevenK> And I should have brought this up at the meeting, but consistency!
<wgrant> It probably just needs to be easier to grab someone mid-implementation.
<StevenK> wgrant: Using *gasp* WIP MPs
<lifeless> wallyworld__: its *not* too hard.
 * StevenK glares at lifeless 
<lifeless> wallyworld__: its underdesirable that the *first time* an issue is encountered is *after a lot of work is done*
<wgrant> StevenK: Well, bouncing to Julian introduces far more latency than would generally be ideal.
<wallyworld__> lifeless: s/too hard/bad practice
<lifeless> wallyworld__: but we have *two* concerns
<lifeless> a) engineer efficiency
<lifeless> b) gatekeeping
<lifeless> actually
<wallyworld__> agreed. and i think we could consider more gatekeeping earlier in the development cycle
<lifeless> b) maintaining 'quality' of various aspects (code/perf/ui/schema/..)
<mars> lifeless, bingo
<lifeless> we can do many things to b:
<mars> lifeless, you forgot scheduling and time pressure
<lifeless> - split it up
<mars> sometimes people don't have time to change how they did things (I've gotten hard pushback on reviews for that before :(
<lifeless> - move it after landing in trunk
<lifeless> - make it optional
<mwhudson> for sure making development easier (faster more reliable pre-merge tests, daily rollouts) and reducing the cost of mistakes (feature flags!) will make everything else way better
<lifeless> - move all or some of it earlier in the dev cycle
 * mwhudson really disappears
<lifeless> but in terms of deciding what to do; I want us to have a *clear* vision of 4 hour dev cycles: two dev cycles a day.
<lifeless> Thats the LEAN inner loop.
<lifeless> we shouldn't do tings to b) that will interfere with reaching a 4 hour cycle time.
<wallyworld__> lifeless: for you that's 6 hours answering everyone's questions on irc and 2x 1hr dev cycles
<lifeless> wallyworld__: its the price I pay for this amazing job
<wgrant> But he's lifeless.
<StevenK> Haha
<wgrant> So that might even out.
<mars> wallyworld__, he's from the SCRUM camp :)
<wallyworld__> oh that explains a lot :-)
<lifeless> mars: not really ;)
<lifeless> mars: some of the scrum stuff is just nuts
<lifeless> ok, fooding, thanks for the awesome discussion.
<mars> lifeless, I meant in that you spend your time removing obstacles for other engineers so they can continue their work - the scrum master role
<mars> later
