[15:00] <bac> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is bac.
[15:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:00] <bac> show of hands
[15:00] <gary_poster> me
[15:00] <EdwinGrubbs> me
[15:00] <mars> me
[15:00] <abentley> me
[15:00] <gmb> me
[15:00] <deryck> me
[15:01]  * mars pokes leonardr 
[15:01] <leonardr> me
[15:01] <mars> :)
[15:01] <sinzui> me
[15:02] <gary_poster> (bac's earlier poke--thank you--used leonard not leonardr fwiw)
[15:02] <allenap> me
[15:02] <jelmer> me
[15:02] <bac> gary_poster: fixed, thanks
[15:02] <gary_poster> np, ty
[15:02] <bac> flacoste: ping
[15:03] <bac> bigjools: ping
[15:03] <flacoste> me
[15:03] <bac> == Agenda ==
[15:03] <bac>  * Roll call
[15:03] <bac>  * Agenda
[15:03] <bac>  * Outstanding actions
[15:03]  * bigjools is here
[15:03] <bac>  * Mentat update.
[15:03] <bac>    * salgado (ui)
[15:03] <bac>    * henninge (ui)
[15:03] <bac>    * stevenk (code)
[15:03] <bac>  * New topics
[15:03] <bac>    * Survey on using the ArchitectureGuide in reviews.
[15:03] <bac> so not much on the agenda so perhaps this will be brief
[15:03] <bac> salgado: ping
[15:04] <salgado> hi there
[15:04]  * salgado needs to re-add this meeting to his calendar
[15:04] <bac> [topic] outstanding actions
[15:04] <MootBot> New Topic:  outstanding actions
[15:04] <bac> [topic] * Sinzui to investigate making lint check for the Storm 'in' gotcha
[15:04] <MootBot> New Topic:  * Sinzui to investigate making lint check for the Storm 'in' gotcha
[15:05] <bac> sinzui: any progress last week on that?
[15:05] <sinzui> Some progress. My effort always reports 5 sql issues instead of 0 storm issues
[15:06] <sinzui> We could switch the 5 issues to storm and say the regex works
[15:06] <bac> ok, we'll roll it over.  thanks for beginning the investigation.
[15:06] <bac> [topic]  HenningE to add a note to the PSG about the use of any
[15:06] <MootBot> New Topic:   HenningE to add a note to the PSG about the use of any
[15:07] <bac> henning is not in the meeting today and i didn't think to look beforehand, so no new
[15:07] <bac> [topic] * Mentat update.
[15:07] <bac>    * salgado (ui)
[15:07] <MootBot> New Topic:  * Mentat update.
[15:07] <bac> salgado: you're the only mentat here.  getting any UI reviews?
[15:07] <salgado> haven't done many reviews last week
[15:07] <salgado> maybe because it was week 3?
[15:07] <bac> salgado: i'll have one for you tomorrow
[15:07] <salgado> ok, cool
[15:08] <bac> stevenk was absent last week so i'm not sure how his mentoring is going
[15:08] <bac> [topic] New topics
[15:08] <MootBot> New Topic:  New topics
[15:08] <bac> [topic]  Survey on using the ArchitectureGuide in reviews.
[15:08] <MootBot> New Topic:   Survey on using the ArchitectureGuide in reviews.
[15:08] <bac> this is really an old topic
[15:08] <bac> but lifeless asked me to address it again here.
[15:09] <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
[15:09] <sinzui> I think the document is really about architecture ideals. I agree with everything written
[15:09] <bac> does anyone have any feedback?
[15:09] <bac> sinzui: and do you find they are applicable as you're evaluating branches?
[15:10] <sinzui> yes
[15:12] <bac> i've not gone through reviews to see if reviewers are asking probing questions regarding scalability, query counts, etc
[15:12] <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.
[15:13] <bac> abentley: those are good ideas.  and it is a wiki.  please add your ideas.
[15:14] <bac> lifeless reports he's getting pressure from "management" to show how we're incorporating the architecture guidelines.
[15:14] <bac> uh, flacoste, would you like to address that?
[15:14] <flacoste> hehe
[15:14] <flacoste> yeah, i'm the pressure :-)
[15:15] <flacoste> one thing that he's proposed is to use metrics around these principles
[15:15] <flacoste> i wondered if people had tried using them
[15:15] <flacoste> at all
[15:15] <flacoste> and if not, why
[15:15] <flacoste> those metrics are tentative, but without feedback we cannot iterate over them
[15:17] <bac> so i'm looking the metric over.  (follow along at https://dev.launchpad.net/ArchitectureGuide#Design%20metrics)
[15:18] <bac> today i introduced a new test.  it is nowhere near 2 secs.
[15:19] <bac> my reviewer didn't bring it up and neither did i.  so we fail.
[15:20] <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
[15:21] <mars> So, "This weeks's (or month's) effort is to not write any new tests over 2 seconds.  Ask your reviewer to check"
[15:21] <flacoste> that sounds sane
[15:21] <mars> sane is good
[15:21] <flacoste> should we do that?
[15:21] <bac> mars: i agree. thanks for the suggestion
[15:21] <gary_poster> +1 on mars point; that jibes with some hunch I couldn't put my finger on
[15:21] <bac> flacoste: +1. i think the problem is one of just being overwhelmed
[15:21] <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
[15:22] <flacoste> leonardr: it's a wiki :-)
[15:22] <flacoste> and there were no follow-ups to lifeless announcement of the guide and request for feedback
[15:22] <flacoste> bac, can you follow-up with mars' plans and coordinate the results?
[15:22] <bac> flacoste: i will
[15:22] <flacoste> thanks!
[15:23] <mars> for the room: https://dev.launchpad.net/ArchitectureGuide?action=subscribe
[15:23] <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)
[15:23] <gary_poster> argh, was in middle of edit
[15:23] <bac> [action] bac and mars to come up with a plan for gently introducing new reviewer guidelines wrt the architecture document
[15:23] <MootBot> ACTION received:  bac and mars to come up with a plan for gently introducing new reviewer guidelines wrt the architecture document
[15:23] <gary_poster> ...I don't like the "it's a wiki" answers--that's the second one--too much...
[15:24] <gary_poster> and s/lock/lack/
[15:24] <flacoste> gary_poster: sending an email to the author with the suggestion is an alternative
[15:25] <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.
[15:25] <gary_poster> sure, +1, or a "suggestions" section on the bottom of a wiki
[15:25] <gary_poster> yeah, that makes sense to me.
[15:25] <gary_poster> (bring it up in the reviewer mtg, that is)
[15:25] <gary_poster> though email works too
[15:25] <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?
[15:25] <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
[15:26] <leonardr> i think the latter is better on the yagni principle
[15:27] <leonardr> and because the pieces of launchpad interact--if there are 100 bug tracker types there are probably a few million bugs
[15:27] <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
[15:27] <gary_poster> (and I like measurements too)
[15:28] <flacoste> i think it's the former actually measure at what point (scalability becomes a problem)
[15:28] <flacoste> because a O(N) algorithm isn't a problem when you know the data set is small
[15:28] <flacoste> so it really depends on the application
[15:29] <flacoste> but sure, abstract analysis is useful in the analysis
[15:29] <flacoste> but still, the key question to answer is: will this scale given our data set (and expected growth)
[15:30] <bac> any other discussion on this one?
[15:31] <bac> [topic] any other issues?
[15:31] <MootBot> New Topic:  any other issues?
[15:31] <leonardr> (i can go on, but it doesn't have to be part of the meeting)
[15:32] <bac> leonardr: please do.  let's end the meeting, though, and people can stay and chat
[15:32] <bac> #endmeeting
[15:32] <MootBot> Meeting finished at 09:32.
[15:32] <leonardr> ok
[15:32] <mars> thanks bac
[15:33] <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"
[15:35] <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
[15:36] <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.
[15:38] <flacoste> leonardr: i can agree with that
[15:38] <leonardr> ok, i'll edit the wiki