#launchpad-meeting 2006-09-25
<poolie> hi hi
<ddaa> oho, I'm late
<ddaa> jamesh: lifeless: poolie: spiv: SteveA: MEETING STARTS
<poolie> ding ding ding
<ddaa> == Agenda ==
<ddaa> Next meeting 2006-10-02, 10:00-10:45 UTC.
<ddaa>  * roll call
<ddaa>  * production status
<ddaa>  * release finder
<ddaa>  * Python import
<ddaa>  * strategic plan
<ddaa>  * bzr-lp features
<ddaa>  * interesting bzr list threads
<SteveA> hi
<ddaa>  * advertising
<lifeless> hi
<ddaa>  * 1.0 targets
<ddaa>  * critical bugs
<ddaa>  * any other business
<ddaa> If you wish to change the time of the meeting or add/remove agenda items, say "bzzzt!".
<ddaa> If we are short on time, the "any other business" item will be automatically, dropped. So if you ''want'' to discuss something more, speak up now.
<jamesh> hi
<ddaa> == Roll call ==
<spiv> here
<ddaa> No excuse was given.
<SteveA> hi
<lifeless> ddaa: bw that did not hightlight the nick, if you want attendion I suggest one nic per line
<ddaa> lifeless: ack
<SteveA> sounds like an irssi bug to me
<ddaa> ACTION: lifeless fix irssi nick hilight bug for next week ;)
<SteveA> or at the least, a counter-intuitive policy decision
<ddaa> So, anybody has any extra agenda item for this meeting?
<ddaa> SteveA: poolie: maybe about the maybe-ex-Rotterdam sprint?
<SteveA> ddaa: everyone to use irssi for next week, so people are aware of its highlighting policies
<SteveA> I want to note that the rotterdam sprint will be in london
<jamesh> xchat should highlight things okay
<poolie> let's do that first
<poolie> ddaa: will that be OK with you?
<poolie> there are several bzr meetings coming up:
<ddaa> SteveA: well, okay, it's going to cost some money in train because of the shorter notice and because I bought non-exchangeable tickets for Rotterdam.
<poolie> ddaa: like 100EUR?
<SteveA> ddaa: yes.  do the best you can.  same dates, just london.
<ddaa> otherwise, the main issue with me is that I'm going to loose an opportunity to enjoy some .nl delicacy, but it's not really a work issue
<poolie> presumably not so much compared to flying to sgp
<ddaa> poolie: all taking into account, more probably like 250 euro, not much a biggie though.
<poolie> tim penhey will be joining Canonical working on launchpad-bazaar, starting on the 2nd october
<poolie> please make him welcome
<poolie> he'll be meeting in london with ddaa and steve to get into it
<poolie> then will be coming to singapore to meet with mark, robert, stub, and me
<ddaa> Should we get him into next week's meeting?
<poolie> then during november he'll be moving to NZ,
<poolie> he will resurface in early december - this implies he will not be in SF
<poolie> ddaa: good idea
<poolie> ACTION: mbp mail tim about next launchpad-bazaar meeting
<poolie> ddaa: one other item, 32/Bazaar
<ddaa> poolie: that's in the agenda already
<ddaa> okay, let's move on
<poolie> oh my mistake
<poolie> _thumper_: hi!
<jamesh> hi _thumper_ 
<SteveA> _thumper_: welcome to the bzr-launchpad coordination meeting, Tim.
<_thumper_> hi all
<poolie> thumper is Tim
<SteveA> the meeting is chaired by ddaa
<ddaa> Welcome Tim
<_thumper_> ddaa, Hi
<ddaa> So, this is our weekly meeting.
<SteveA> maybe some introductions are in order?
<poolie> please do
<SteveA> ddaa: you're the chair...
<ddaa> ddaa: so I'm the guy currently going crazy trying to drive the launchpad-bazaar work
<ddaa> SteveA is my manager, one of the two launchpad project managers with kiko
<lifeless> _thumper_: hi there, welcome onboard
<SteveA> ddaa: arguably, you were crazy before you got involved in launchpad-bazaar
<lifeless> SteveA: induitably
<jamesh> well, he is french
<ddaa> lifeless is test-driven development god and knows more than you ever want to about http and weird corner cases in VCS
<spiv> jamesh: I was thinking that, but I wasn't going to be the one to say it ;)
<lifeless> ddaa: also, I went to uni with _thumper_ 
<lifeless> 'with' meaning about 2 years behind
<_thumper_> ah, ok
<ddaa> jameh is our polyvalent mr fixit, with an uncanny talent for getting his brain around complicated problem
<_thumper_> now that might be why a face isn't leaping to mind
<jamesh> _thumper_: I think you met me, ddaa and SteveA in London
<lifeless> _thumper_: I dont have a clear picture of your face either. We'll fix that in singapore ;)
<ddaa> spiv does many thing, but here he's the guy who wrote the bazaar.launchpad.net sftp server, and is currently writing the bzr smart server
<ddaa> poolie you already know, he's the bzr Overmind.
<SteveA> jamesh is James Henstridge.  spiv is Andrew Bennetts, in case the irc nicks aren't clear.
<SteveA> lifeless is Robert Collins.
<_thumper_> SteveA, I've been using the  mouseover in Konversation :)
<SteveA> nice
<ddaa> I suggest we move on so for once this meeting might end not late.
<poolie> please do
<ddaa> though it looks already compromised...
<SteveA> we ended roughly on time last week I think
<ddaa> == Prodution status ==
<ddaa> Nothing new to report on production.
<ddaa> Tomorrow is LP production rollout. Will require a importd rollout because of the ProductSeries.import_branch schema change.
<ddaa>  * jamesh: put logging into the branch puller
<ddaa> jamesh: got news?
<jamesh> this is in the review queue now
<lifeless> _thumper_: http://www.mega-nerd.com/erikd/Img/codecon06-people.png
<lifeless> _thumper_: thats a recent (if scruffy ;)) picture of me
<ddaa> jamesh: do you think it's cherrypickable in production?
<SteveA> I can review that branch if you want
<jamesh> ddaa: should be.
<_thumper_> lifeless, which one?
<lifeless> _thumper_: haha
<jamesh> SteveA: thanks.  It isn't very complicated.
<ddaa> jamesh: can you arrange with stub to get it rolled out tomorrow, then?
<lifeless> _thumper_: didn't realise it was one big picture - the left most is me
<ddaa> after SteveA reviewed it, since he so helpfully volunteered.
<jamesh> ddaa: I'll make sure it is listed as a cherrypick request
<ddaa> thanks lots
<ddaa> == Product release finder ==
<ddaa>  * jamesh: report on PRF progress.
<ddaa>  * ddaa: start fixing +source
<ddaa> No progress on +source fixage last week.
<jamesh> no progress on product-release-finder this week.
<ddaa> jamesh: is that blocked on +source?
<jamesh> ddaa: the main issue is making it easier to enter release file globs.  If we leave the entry on +source, then it might be blocked.  If we move it to the product series +edit page then it isn't.
<ddaa> So, yeah, it's blocked on some UI fix.
<SteveA> I'm fine with you hacking what's needed into the UI
<ddaa> I think it should be a separate form, so we can make it clear what it's here for.
<SteveA> we can fix it later
<SteveA> the UI shoiuld never block things
<ddaa> I've got a discussion about 1.0 UI pending with mpt
<lifeless> jamesh: lets merge it 
<lifeless> jamesh: as SteveA says, UI should not block
<jamesh> ddaa: I think it would be good to focus the $series/+source on VCS imports, so I'd lean towards moving the item over to the main edit form 
<ddaa> so I think we can just do whatever work, we'll need to shuffle things around quite a bit anyway
<jamesh> which also means I'm not blocked on your work
<ddaa> okay
<ddaa> == Python import ==
<ddaa> Ran tarball based-import of Python last week. It failed because of a logic error in the handling of svn copy simultaneous with a delete of a part of the copied directory.
<ddaa> This problem (and maybe a few variations on the theme) is also the cause of most of the svn import failures. I started working on that as a top priority.
<ddaa> Already put up for review some test cleanups that will make it easier to use separate test repositories.
<ddaa> ACTION: fix critical issue blocking python, and check that it allows the import to complete.
<ddaa> could say more things about how python-subversion is horribly broken pile of crud, but it would be offtopic
<jamesh> are we still waiting on the bzr update in rocketfuel
<jamesh> ?
<ddaa> hhu
<ddaa> good question
<lifeless> hmm, I thought I tried to send that in
<ddaa> bzr upgrade blocked by test failure in supermirror scripts
<ddaa> in addition to the importd-smallfixes branch
<ddaa> so some additional fixage is needed before bzr>=0.9 can be landed
<ddaa> Who think he can tackle that?
<ddaa> More recent versions cause more failures, I remember at least bzr.dev (0.11) causes failures in cscvs as well.
<jamesh> I think it needs a simultaneous update of bzr and launchpad, doesn't it?
<ddaa> jamesh: yes
<ddaa> that's the importd-smallfixes branch
<ddaa> but it also need more fixes
<SteveA> ok
<SteveA> I'm getting confused
<SteveA> david, please summarize clearly the steps needed to get a new bzr into RF
<ddaa> 1. fix the failures in the launchpad test suite with bzr-0.9
<ddaa> that is, in addition to the fixes that are currently in ddaa/launchpad-importd
<ddaa> hu
<ddaa> currently in ddaa/launchpad/importd-smallfixes
<lifeless> I suggest just doing bzr 0.11 FWIW. we're at rc1
<SteveA> +1
<ddaa> then 2. fix new failures caused by 0.11 in cscvs
<jamesh> the launchpad test suite fixes use the bzrlib.urlutils module, which isn't available with the current version of bzr, so the simultaneous update is needed
<ddaa> 3. land new bzr simultaneously with ddaa/launchpad/importd-smallfixes, plus maybe other whatershed fixes
<ddaa> That's it.
<SteveA> in point 2., by "failures" you mean "failed imports" or "test failures2 ?
<ddaa> test failures
<SteveA> does that mean you want us to go to 0.9 and then to 0.11 ?
<SteveA> or can we go straight to 0.11 at step 3?
<ddaa> we can go straight to 0.11, I can work with bzr-0.9 in importd until then
<SteveA> ok
<SteveA> lifelses will do step 3
<SteveA> who will do steps 1 and 2?
<lifeless> !lifeless
<ddaa> I'd be interested in doing them, so I can get a bit more familiar with the supermirror code.
<lifeless> twelve minutes left in this meeting
<SteveA> thanks lifeless 
<poolie> let's take this to mail
<poolie> ?
<SteveA> ddaa: ok, let's talk about your workload after this meeting
<ddaa> ack
<SteveA> thanks, I now understand the steps involved
<ddaa> == strategic plan ==
<ddaa>  * mpool owns that agenda item
<poolie> thanks
<poolie> https://wiki.canonical.com/32/Bazaar
<poolie> this is almost approved by mark
<poolie> thanks very much to ddaa and robert for their comments
<jamesh> I added some small comments today.  Sorry for the delay
<poolie> i think i'm still waiting for some others here to read it, or tell me they did
<poolie> jamesh: thanks
<jamesh> it looks good
<ddaa> spiv said he read it and had nothing to add
<SteveA> poolie: you already have my comments
<poolie> _thumper_: you haven't been asked before, but i'd appreciate if you read that page
<spiv> ddaa: right
<_thumper_> poolie, just clicked on it
<poolie> i realize it references many things you probably won't be familiar with, you can ask me about them if you need to
<poolie> thanks
<poolie> spiv: thanks 
<poolie> ok then that's everyone i think, thanks v much
<ddaa> == bzr-lp features ==
<ddaa>  * mpool: report on bzr-lp features
<ddaa> poolie: it's your again!
<ddaa> poolie: what bzr-lp features are currently worked, what are the short term plans, what is blocking?
<poolie> spiv: can you tell us about supermirror smartserver?
<ddaa> that's in the 1.0 targets
<spiv> poolie: No work directly on that yet -- work should start on that shortly, after HTTP smart server/client is working.
<spiv> poolie: Probably will discuss it with you and lifeless in person tomorrow.
<poolie> ok
<ddaa> poolie: I guess you do not have much to talk about that this week
<ddaa> moving on
<poolie> not really
<poolie> jamesh: i think i saw something from you about fixing branch redirections
<poolie> ?
<lifeless> T -5
<SteveA> spiv/poolie: please mail a brief update to the launchpad list after you talk tomorrow.
<poolie> skip it
<ddaa> == Interesting bzr list threads ==
<ddaa> Let's skip that this week. Look for the minutes of the past couple of meeting for details of what this is about.
<spiv> SteveA: ok.
<ddaa> == Advertising ==
<ddaa>  * spiv: blog about similarities between SVN and bzr checkouts, in relation to Launchpad.
<lifeless> spiv: can you please update the SmartServer spec to have the current protocol and design decisions
<ddaa> spiv: I do not think you posted the draft last week
<lifeless> spiv: its aged.
<spiv> Right, it's here: https://devpad.canonical.com/~andrew/paste/fileywRJCw.html
<spiv> I'll also send mail about it after the meeting.
<spiv> lifeless: ok
<ddaa> ok
<jamesh> poolie: there was some talk about how lp: URIs should be handled on the launchpad list.  Also, tomorrow's rollout should have all the database changes needed to identify branches by product and series
<spiv> Comments welcome.
<ddaa> I have a few nitpicks in my bag left. I'll give you some.
<ddaa> == 1.0 targets ==
<ddaa> supermirror-smart-server: spiv: still looking on track for october 8th?
<ddaa> importd-bzr-native: ddaa: doing final cleanups and hct cruft collection. Currently prioritised out by python import fixage.
<ddaa> bzr-roundtrip-svn: not for 1.0
<ddaa> Pending action:
<ddaa>  * mpool: read up/tick off svn roundtripping discussion
<poolie> i did read it, will send mail
<spiv> ddaa: I think so, yes, although there's still lots to do.
<ddaa> poolie: I'd love your feedback on those discussion, they touche many important subjects like integrity checking, bzr copy, and forward compatibility for svn imports.
<ddaa> IMO just get the tranport-level rpc thingy up, with the lp glue would already be a remarkable achievement.
<ddaa> considering the extremely short timeline you had
<spiv> ddaa: right, that's what I'm aiming for.
<lifeless> I have to go and be ready for the next meeting
<lifeless> its now T-0
<ddaa> another late meeting
<ddaa> moving on
<lifeless> ddaa: I'm very interested in the hct stuff, I was hoping to update that for looms rather than us discarding it
<ddaa> lifeless: I've asked for your feedback about that some time ago
<ddaa> anyway, it has just been bitrotting since March
<lifeless> for the smart-server, I'm confident andrew and I can deliver, if we keep pairing : progress has been fast while pairing
<SteveA> the hct stuff is still in the source tree, in the not-used place
<jamesh> lifeless: the hctapi stuff is very out of date, and we'd want to do it differently now
<SteveA> so, it is easy to see the code and revitalize it, if you want to
<SteveA> but it is out of the way of general development
<ddaa> then, there is the sourcecode/hct tree, but that's another discussion
<jamesh> e.g. use xmlrpc.launchpad.net rather than the separate trebuchet server
<lifeless> SteveA: sure, I dont know enough about where scott put *what* to know whats important at the moment
<lifeless> all I know for sure is that sourcerer et all are bitrotting
<lifeless> hctapi is a small bit, and AIUI not significant in the grand scheme
<ddaa> Moving on, then.
<ddaa> == Important bugs ==
<ddaa> Last week, Steve asked me to pick a few important bugs to highlight. Here's my selection of the week. 
<ddaa>  * Related to +source
<ddaa> bug 2649: CVS branch details should not be editable or displayed.
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/2649
<ddaa> bug 46240: posting $series/+source yields a confusing warning
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/46240
<ddaa> bug 50569: the product series page does not allow entering source or ftp details for projects without SVN or VCS
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/50569
<ddaa>  * bug: 48813: Efficiently mirroring sftp hosted branches with minimal latency
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/48813
<ddaa>  * bug: 58889: Merged and abandoned branch should not appear in main branch listings
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/58889
<ddaa> jamesh: I take it you'll do 50569 this week to complete the PRF work.
<jamesh> ddaa: okay
<ddaa> I'll talk about which, if any, of those bugs I'll be working on this week later with SteveA.
<ddaa> That said, I think the agenda is complete.
<ddaa> running late, so no "any other business?"
<ddaa> MEETING CLOSED
<ddaa> Thanks you everybody for attending.
<ddaa> Offtopic ranting
<ddaa> This week-end I started some experimental branch to cleanup the libsvn binding of cscvs
<ddaa> I came to the conclusion that the alledgedly "complete" Python bindings of subversion were not only undocumented, but largely unusable because they do not seem to have any support for callback methods.
<ddaa> Which are pretty essential to many things, like setting log messages from the svn_client API
<ddaa> the cscvs and bzr-svn code seem to avoid the issue by talking repository-level operations directly
<ddaa> which involves hundreds of line of duplicated logic
<lifeless> ddaa: which python library were you playing with ?
<lifeless> python-svn or python-subversion ?
<ddaa> svn
<ddaa> python-subversion
<lifeless> IIRC that thats the swig bindings
<ddaa> pysvn is nice, but it's quite limited
<ddaa> yes
<lifeless> and its horrendously incomplete.
<spiv> Ugh, swig.
<lifeless> when I did the SVN module for cscvs, it did not even support doing a *commit*
<ddaa> The good news is that I finally managed to get it to commit with a python-provided log message callback
<ddaa> lifeless: it still does not
<ddaa> I'm considering the option of setting up a alternate binding (maybe called python-aversion?)
<ddaa> which is a basically an experimental fork of python-subversion, and hammer on that until it does all that cscvs needs
<ddaa> with feedback to the svn guys
<lifeless> so I'd suggest a different tack
<ddaa> It looks like swig would support that approach nicely.
<lifeless> pyrex
<lifeless> clean start
<ddaa> lifeless: I'm very much looking for something that could be merged upstream into subversion
<lifeless> swig is a good way to go blind, and much less satisfying than masturbation
<ddaa> and there is still a lot of work done in python-subversion, I am not keen at starting up from scratch
<ddaa> the biggest issue seems to be the lack of documentation, so it's very hard to figure out what is really unsupported, from what is just normal libsvn pain.
<ddaa> subversion has significant investment in swig, it's used for the ruby and perl bindings too.
<ddaa> so I think there's no choice here
<SteveA> there are good arguments for and against each of the options
<ddaa> lifeless: btw, python-subversion has much saner memory management now
<ddaa> you can essentially just ignore all the apr pool crap
<SteveA> we should come up with a short experiement to help us estimate what is the best course of action
<_thumper_> using swig for all bindings would also mean that python bindings are not likely to be pythonic
<SteveA> for example, for someone to spend a day writing throw-away pyrex bindings for it
<ddaa> I guess using it explicitly can still give performance improvements, but it's significantly better than it used to be.
<SteveA> and to spend a day extending the swig bindings in some way that we need
<SteveA> and comparing progress
<ddaa> SteveA: hu, libsvn is very large
<ddaa> this test would be very biased, because starting from scratch would give fast progress anyway
<lifeless> _thumper_: they have different swig rules for each language
<ddaa> _thumper_: I believe libsvn is made of the same stuff as the souls of the damned in hell.
<lifeless> _thumper_: I dont think they influence the pythonicness of the bindings much, beyond the swig-suck factor
<_thumper_> lifeless: so a different mapping file for each language?
<ddaa> so it's going to be painful either way, unless you put the work into thick bindings like pysvn, but then it would probably be better to extend pysvn.
<_thumper_> I have used swig before but for python and java
<lifeless> _thumper_: IIRC, yes. I haven't looked in 2 years though, so..
<SteveA> how many SVN calls does CSCVS need?
<SteveA> we don't need complete bindings.  we need bindings that cover what we need.
<ddaa> not many many
<ddaa> but the current code is probably much less efficient that it could be
<SteveA> so, depending how many different calls we need
<SteveA> pyrex may be a good solution
<SteveA> as we can do just the calls we need
<SteveA> and ensure they work well
<ddaa> but then it's an increased maintenance burden
<ddaa> SteveA: I agree there are good arguments for pyrex
<SteveA> maybe it would be a reduced maintenance burden
<SteveA> we need concrete figures
<SteveA> ddaa: can you think of a good way of finding out how many SVN API calls we use?
<ddaa> grep
<ddaa> :)
<SteveA> or instrumentation
<ddaa> grep is good enough, should be one hour of work at most
<ddaa> SteveA: if you have some time, we can talk about my tasks for this week now
<ddaa> then I have to lunch, then get a haircut so I do not look like a terrorrist on my USA-compliant passport.
<SteveA> ok
<SteveA> how's the arch removal stuff?
<SteveA> anything at all left to do there?
<ddaa> SteveA: it's just in the same status as when we last talked about
<ddaa> the ProductSeries.targetarch* patch needs to DBA-reviewed
<ddaa> then patch your looked at can be landed, with some additional cleanups to allow removal of pybaz friends from the dists config
<ddaa> duh, my grammar sucks
<ddaa> SteveA: that's all there is about arch removal.
<ddaa> then, there's hct, which is the big unknown
<ddaa> So my plan for this week is 1. work on python-blocker as soon as the current branches are reviewed 2. extra garbage collection in remove-gnuarch 3. bzr-0.10 compatibility fixes
<ddaa> BTW, I started using loom when working on cscvs, it's really cool.
<ddaa> oops
<ddaa> SteveA: do you have anything you would like to change in that priority list?
<ddaa> for python, my plan is to check the import completes as soon as I have the minimal fix, using a custom cscvs, and do my best to have rename support ASAP, to redo the import from scratch quickly
<SteveA> sorry -- call with mark
<SteveA> I'm back
<SteveA> maybe ping stu to see if he can do that DB review today
<SteveA> "extra garbage collection" means what?
<ddaa> removing references to pybaz etc. from lib/ symlinks and Makefiles
<SteveA> ok
<SteveA> not implementing a GC
<ddaa> moving hctapi.py out of the way
<ddaa> ROTFL
<ddaa> Do I have THAT much of a reputation for being sidetracked???
<SteveA> no comment
<ddaa> I take that as a yes.
<SteveA> ok, looks good
<SteveA> are there any bzr-0.11 compatibility things you can ask jamesh to do?
<ddaa> there can certainly be, but 1. I'd like to actually poke the supermirror code a bit, because I'm not familiar enough with it 2. the cscvs fix are better done by me because I am currently actively working on that code base
<SteveA> how about asking james to do that and have you review it?
<ddaa> watching is not same as doing
<SteveA> there are only so many hours in the week
<ddaa> If you think that's critical enough to warrant that, I'll do it.
<ddaa> but I do not see the urgency
<SteveA> I want you to be using the same bzr for importing as we're using in RF
<SteveA> otherwise...
<SteveA> well
<ddaa> well, if I have to choose between fixing bzr-0.10 compatibility and implementing svn rename support...
<SteveA> okay, so it means you can get on with a buildbot replacement sooner
<SteveA> the other thing jamesh can do is to look into what parts of SVN API we use
<SteveA> and try the experiment with pyrex
<ddaa> this would be interesting, but it was just a little skunk project
<ddaa> I do not mean to divert workforce on that, the current svn binding situation is not very aesthetic, but it's good enough
<SteveA> if it turns out you use just 10 API calls
<SteveA> then custom bindings would be a clear win
<SteveA> I'd like you to be able to start replacing buildbot sooner
<SteveA> rather than later
<ddaa> You have all my support for that plan.
<SteveA> and, getting jamesh to help with bzr updates will help make that sooner
<ddaa> then we have a deal
<ddaa> I'm looking forward to more deep-immersion coding
<ddaa> I think after all I may not have that much of a future in mgmt :)
<SteveA> ok.  please email james cc list about what's needed for bzr 0.11 compatibility
<ddaa> will do
<SteveA> and also, book your travel to london today
<SteveA> how will you travel?
<ddaa> train, as usual
<SteveA> ok
<ddaa> I'll do the booking right away
#launchpad-meeting 2008-09-23
<barry_> #startmeeting
<MootBot> Meeting started at 20:59. The chair is barry_.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry_> mootbot!
<barry_> hello everybody and welcome to this week's asiapac reviewers meeting
<barry_> who's here today?
<barry_> anybody?
<barry_> jml, mwhudson, thumper ping?
<jml> hi
<thumper> barry_: hi
<jml> I forgot it was Tuesday :)
 * thumper is somewhat busy with beuno
<barry_> jml: it's not, it's still monday :)
<mwhudson> hi
<jml> my mistake
<barry_> thumper: i can wait a little bit if you want
<thumper> barry_: yeah, but you can't wait for a week :)
<thumper> I'll just pop in and out
<barry_> :)
<barry_> cool.  btw, i will not be here next week.  do you want to skip the meeting or can one of you run it?
<barry_> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry_>  * Roll call
<barry_>  * Using ReST instead Moin for documentation -- flacoste  [<<Date(2008-09-22T10:17:00-0500)>>]
<barry_>  * Naming conventions for unit test methods. `testFooBar`, `test_fooBar` and `test_foo_bar` all exist. Recommend settling on `testFooBar` and only changing existing ones as encountered in normal work. -- jml [<<Date(2008-09-10T13:48:09+1000)>>]
<barry_>  * Reviewers remove requests from Pending Reviews when you start a review.  If you forget the next on-call reviewer may duplicate your work.  -- bac [<<Date(2008-09-16T10:07:09-0500)>>]
<barry_>  * If there's time, the old boring script
<barry_>    * Next meeting
<barry_>    * Action items
<barry_>    * Queue status
<barry_>    * Mentoring update
 * jml waits
<barry_> i'll let you guys sort it out for next week then :)
<barry_> [TOPIC]  * Using ReST instead Moin for documentation -- flacoste  [<<Date(2008-09-22T10:17:00-0500)>>]
<MootBot> New Topic:   * Using ReST instead Moin for documentation -- flacoste  [<<Date(2008-09-22T10:17:00-0500)>>]
<thumper> I really don't care about this one
<barry_> i haven't talked to flacoste about this yet, but i think this was brought up by gary
<barry_> gary wants to write doctests in reST
 * barry_ likes reST
<jml> barry_: given that we aren't actually publishing the documentation, I don't see that it matters too much.
<mwhudson> unless we're actually going to render the documentation and do something with it, i heartily don't care
<barry_> cool.  i just wanted to get your sense so i can communicate it accurately at the ameu meeting
<mwhudson> (rendering the documentation would probably be a good idea though)
<barry_> sounds like a resounding -0/+0
<jml> barry_: can we change the doc standard so it's 78 cols all the way through?
<mwhudson> barry_: well, it's a bit more negative than that, as it would be a lot of work
 * jml is half kidding
<barry_> jml: i've been wanting to do that since i started
<mwhudson> .oO(not that i edit doctests much...)
<jml> barry_: 72 for text and 78 for Python seems like make-work to me.
<barry_> mwhudson: i wouldn't propose to rewrite existing docs just to reformat them.  do it as general cleanup
<jml> barry_: but that's probably a separate agendum :)
<barry_> jml: why do you think i avoid friday reviews?  sinzui is the only one who cares about that :)
<barry_> jml: but now sinzui is team leader and not doing reviews, so there ya go :)
<jml> heh heh
<mwhudson> barry_: still more work than seems worth it unless there are other benefits
<barry_> jml: i will put it on the agenda for wednesday
<barry_> [ACTION] barry put 78 column consistency in doctests on agenda for ameu
<MootBot> ACTION received:  barry put 78 column consistency in doctests on agenda for ameu
<barry_> mwhudson: ok, thanks.  gotcha
<jml> cool.
 * jml agrees with mwhudson
<barry_> [TOPIC]  * Naming conventions for unit test methods. `testFooBar`, `test_fooBar` and `test_foo_bar` all exist. Recommend settling on `testFooBar` and only changing existing ones as encountered in normal work. -- jml [<<Date(2008-09-10T13:48:09+1000)>>]
<MootBot> New Topic:   * Naming conventions for unit test methods. `testFooBar`, `test_fooBar` and `test_foo_bar` all exist. Recommend settling on `testFooBar` and only changing existing ones as encountered in normal work. -- jml [<<Date(2008-09-10T13:48:09+1000)>>]
<jml> I had a look at the AMEU minutes.
<barry_> jml: we talked about this in ameu, but you hadn't had time to state your position yet
<jml> it seems they settled on test_<identifier>_qualifying_comments
<barry_> jml: right, are you okay with that? or disagree?
<jml> I assume that tests without identifiers just get pep8'd?
<barry_> yep
<jml> barry_: I'm cool with it.
<barry_> jml: cool
<jml> barry_: I basically just wanted a standard -- every module I use is different.
<barry_> jml: right, agreed!
<mwhudson> hooray
<barry_> [TOPIC]  * Reviewers remove requests from Pending Reviews when you start a review.  If you forget the next on-call reviewer may duplicate your work.  -- bac [<<Date(2008-09-16T10:07:09-0500)>>]
<MootBot> New Topic:   * Reviewers remove requests from Pending Reviews when you start a review.  If you forget the next on-call reviewer may duplicate your work.  -- bac [<<Date(2008-09-16T10:07:09-0500)>>]
<barry_> i think this one's just a heads up.  several people did multiple reviews
<jml> oh that's right, we still have a wiki page :)
<mwhudson> "what is this Pending Reviews you speak of" ?
<barry_> :)
<mwhudson> i guess it's worth making the point
 * barry_ looks to thumper and beuno
<jml> barry_: incidentally... https://code.edge.launchpad.net/~launchpad/launchpad/trunk
<thumper> sure
<thumper> jml: shhh
<thumper> ;-)
 * jml needs to read over that "actually using Launchpad for reviews doesn't work" email
 * thumper too
<barry_> jml: whoa
<thumper> barry_: FYI, beuno and I are making reviews rock in LP
<barry_> i can has branches on lp?
<barry_> thumper, beuno i am very excited to see the results
<jml> on the sly, yes.
<beuno> barry_, it's very promising  :)
<jml> barry_: although make sure you upgrade everything (branches and repos) to 1.6
<beuno> it should make the workflow almost natural
<barry_> jml: cool.  eta for switching to?
<thumper> barry_: also use bzr 1.7 or later
<barry_> beuno: eta?
<thumper> barry_: and the scanner will choke somewhat until mwhudson's branch is cherrypicked
<mwhudson> i guess we could switch in maybe a week?
<jml> barry_: there are a few patches we need to land.
<jml> depending on how the cherry blossoms fall
<beuno> barry_, it depends on thumper's speed and availability, but we should ahve something submitable after this week
<barry_> after mwhudson branch is cherrypicked?  if we could do it on or before epic, that would be fantastic
<mwhudson> that should be possible for sure
<thumper> barry_: within a day or two for production is my guess
<barry_> wow. it would be fantastic if we can dogfood all this, kill off devpad branches and PR at epic
 * thumper hopes too
 * beuno hopes three
<thumper> I do have two weeks leave between now and the epic
<barry_> cool.  that's about it from me.  queue update, mentor update, action items, blah blah blah
<barry_> anything from you guys?  anything you want me to bring up at ameu?
<mwhudson> nothing springs to mind
<jml> nope
<thumper> nada
<barry_> cool.  thanks guys.  see you all in 2 weeks.
<barry_> #endmeeting
<thumper> ok
<MootBot> Meeting finished at 21:24.
<thumper> later dude
<jml> barry_: see ya
#launchpad-meeting 2008-09-24
<gmb> Wheeeeee....
 * bigjools stretches and yawns
 * intellectronica sneezes
<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 reviewers meeting
<barry> who's here today?
<sinzui> me
<intellectronica> me
<gary_poster> me
<bigjools> me
<salgado> me
<mars> me
<gmb> me
 * barry knows that bac sends his apologies
<abentley> me
<BjornT> me
<barry> gary_poster: welcome!  we're going to make you a reviewer one of these days :)
<gary_poster> barry: heh, hi :-)
<flacoste> me
<EdwinGrubbs> me
<barry> cprov: ping
<cprov> cprov
<barry> danilo[home]__: ping
<cprov> err, *me*
<barry> rockstar: ping
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * mentor needed for mars -- barry
<barry>  * Using ReST instead Moin for documentation -- flacoste  [<<Date(2008-09-22T10:17:00-0500)>>]
<barry>  * Require testing of JavaScript (indeed, all UI) changes on multiple platforms (gmb).
<barry>  * 78 column limit okay in doctest narrative? -- barry
<barry>  * If there's time, the old boring script
<barry>    * Next meeting
<barry>    * Action items
<barry>    * Queue status
<barry>    * Mentoring update
<barry> [TOPIC] mentor needed for mars -- barry
<MootBot> New Topic:  mentor needed for mars -- barry
<gmb> barry: I'll do that.
<barry> gmb: fantastic, thanks
<barry> mars: please coordinate with gmb and join him on his on call day
<flacoste> gmb: when is your on-call day?
<mars> gmb, thanks, I look forward to working with you
<gmb> mars: Likewise.
<gmb> I'm on call on Thursday, but I can change that if necessary.
<gmb> Actually
<gmb> We have a glut of reviewers on Thursday
<gmb> Me, salgado, EdwinGrubbs...
<gmb> So maybe we should pick a different day.
<salgado> gmb, I've moved to Friday
<gmb> Ah.
<gmb> That shows how much attention I was paying
<bigjools> salgado is the new sinzui
<flacoste> mars: you might want to skip or only do a light day this week
<mars> gmb, ok, I'll look at the schedule
<barry> bigjools: :)
<intellectronica> gmb: i think bac mentioned that he wanted to take a break. maybe you can reaplce him when that happens?
<barry> bac_afk: is mentoring rockstar
<sinzui> bigjools: less stupid question of Fridays now
 * gmb looks at OCR...
<gmb> So, maybe Wednesday
<barry> monday euro is also open
<gmb> Especially with allenap being fatherly at the moment and all.
<gmb> Hmm...
<gmb> barry: Whatever your preference then. Monday works for me.
<barry> it would mean EdwinGrubbs would be the only eu/am reviewer on thursdays
<barry> mondays are fairly light usually, so gmb, mars let's keep you on euro thursdays for now
<gmb> So really, it makes no difference which day we're on.
<gmb> barry: Right, works for me.
<mars> ok
<barry> thanks! i'll update the relevant pages
<gmb> Ok.
<barry> [TOPIC]  * Using ReST instead Moin for documentation -- flacoste  [<<Date(2008-09-22T10:17:00-0500)>>]
<MootBot> New Topic:   * Using ReST instead Moin for documentation -- flacoste  [<<Date(2008-09-22T10:17:00-0500)>>]
<barry> flacoste: the floor is yours
<flacoste> ok, so I'd like to suggest we move back to using ReST as our standard doc format
<flacoste> especially in regards to doctests
<flacoste> the only thing we are using from Moin is the header style
<flacoste> and it doesn't give us anything
<flacoste> we can't process those files
<flacoste> moving to ReST will allow us to use the numerous tools that can process those
<sinzui> +1
<flacoste> we talked about separating documentation across the tree and linking it into a doc directory
<barry> +1
<gmb> +1
<flacoste> we could process those using Sphinx which is becoming a standard in the python world
<mars> +1, I want my syntax highlighting back :)
<abentley> +1.
<flacoste> any objections?
<BjornT> will we switch to ReST in the wiki as well?
<flacoste> should we?
<barry> can we?
<intellectronica> there's an advantage to using the same format for the many different text collections we've got
<flacoste> and does Moin supports it?
<BjornT> well, i'd hate having to know to different formats for docs
<abentley> flacoste: Moin supports it.
<barry> +1 then
<intellectronica> further more, it might make sense to coordinate this with other canonical projects, like landscape and bazaar
<abentley> flacoste: Perhaps not as well as Moin markup, but...
<BjornT> what kind of processing do we want, btw? i think that's important to think about, before we decide to switch
<BjornT> switching is expensive
<flacoste> hmm, it's not
<flacoste> JFDI
<flacoste> we don't need to convert anything
<sinzui> I think formatdoctest.py can switch the headers after a small change to the header rule.
<flacoste> we didn't when we settled on Moin heading style
<flacoste> and we don't really use Moin
<flacoste> only it's heading style
<abentley> intellectronica: Bazaar uses ReST everywhere except in the Wiki.  (Where it *sometimes* uses ReST.)
<barry> rs=barry for any formatdoctest.py generated pure cleanup branches
<sinzui> We can switch during the Epic
<intellectronica> abentley: thanks. i guess that supports the idea of moving to rst
<flacoste> we have some packages that we intend to distribute on the cheeseshop
<flacoste> waddlib, launchpadlib
<flacoste> having the doc in ReST will allow the documentation to integrate nicely with the Cheeseshop
<flacoste> gary_poster: am I making this up, or did I understand that correclty?
<barry> flacoste: can you update https://launchpad.canonical.com/TestsStyleGuide and email the ml?
<flacoste> barry: i will
<gary_poster> flacoste: :-) yes, the main page for a project is in ReST
<mars> flacoste, PyPi likes ReST
 * abentley wonders if it would be a good idea to make ReST the default on the new launchpad wiki.
<barry> [ACTION] flacoste will update https://launchpad.canonical.com/TestsStyleGuide and email the ml, re: use reST in doctests
<MootBot> ACTION received:  flacoste will update https://launchpad.canonical.com/TestsStyleGuide and email the ml, re: use reST in doctests
<flacoste> barry: am I doing a wiki policy also
<flacoste> i think we can postpone that one
<flacoste> just doctests
<barry> flacoste: great, thanks
<flacoste> another issue is docstrings,
<flacoste> we currently use epydoc markup on those
<mars> flacoste, isn't epydoc based on ReST?
<flacoste> i think it is, but it uses different fields syntax
<BjornT> flacoste: are you going to mail the list for discussing this, or to inform about a decision?
<mars> that's optional, IIRC.  @foo: is the same as :foo:
<barry> mars: correct
<abentley> err, I've been using ReST in my docstrings.
<flacoste> for doctest, it seems that we nearly have consensus
<flacoste> BjornT: ^^^
<barry> btw, asiapac is cool with this
<flacoste> BjornT: i would ask for discussion regarding the wiki
<abentley> ":param foo: frob the thurbleforp", etc.
<flacoste> barry: did I understand correctly that action?
<BjornT> flacoste: well, i still would like to see a list of use cases. many voted +1 just because we could use tools to process the files. i would like to know a bit more what we want to gain from switching.
<barry> flacoste: i'm not sure, what do you think the action says? :)
<flacoste> BjornT: build an HTML documentation
<BjornT> i don't think this is something that should be decided in a meeting, without having a proper discussion
<flacoste> also
<flacoste> remember that our Moin use doesn't give us anything
<BjornT> flacoste: and you're confident that's impossible using moin?
<flacoste> yes, because we aren't using proper moin
<flacoste> processing the python example looks like crap
<flacoste> gary tried it
<BjornT> flacoste: what would it look like? can we maybe make a small change to make it interpret >>> specially?
<flacoste> i don't want to hack moin
<flacoste> the main argument is that there are standard tools in the python world
<flacoste> to do this
<flacoste> and now we aren't compatible with anything
<BjornT> i'd still like to see some examples of what we want to do (like links to existing documentation, and so on)
<flacoste> neither Moin, nor ReST
<gary_poster> BjornT: OK one sec
<gary_poster> simple ReST page on PyPI
<gary_poster> http://pypi.python.org/pypi/zc.async
<MootBot> LINK received:  http://pypi.python.org/pypi/zc.async
<rockstar> me
<gary_poster> ReST docs to html generated by Sphinx
<gary_poster> http://packages.python.org/zc.async/1.5.0/
<MootBot> LINK received:  http://packages.python.org/zc.async/1.5.0/
<BjornT> and i'd like to postpone the decision, since i think a bit more than a few minutes is needed to evaluate this
<barry> BjornT: okay.  flacoste please just email the list, we'll postpone final decision until after that discussion happens
<sinzui> Well we are using mwhudson's generated documentation right now
<gary_poster> BjornT: one more, trying to be helpful: http://sphinx.pocoo.org/
<BjornT> gary_poster: could you also convert one of our doctests, and generate something for it?
<flacoste> sinzui: that's generated using docstrings, we are talking about processing the doctest files here
<sinzui> sorry
<flacoste> gary_poster: converting launchpadlib would be good
<gary_poster> BjornT: um, let me talk that over with flacoste and you out-of-meeting so I know what you mean.  oh, ok.
<flacoste> barry: ok, we will cook an example and discuss it with the list
<barry> flacoste: thanks!  anything else on this topic?
<barry> [TOPIC]  * Require testing of JavaScript (indeed, all UI) changes on multiple platforms (gmb).
<MootBot> New Topic:   * Require testing of JavaScript (indeed, all UI) changes on multiple platforms (gmb).
<barry> gmb: the floor is yours
<gmb> So.
<gmb> Bug 273401 is a wonderful thing
<ubottu> Launchpad bug 273401 in malone "Regression: Can't add bug comment using IE6" [Critical,Fix committed] https://launchpad.net/bugs/273401
<gmb> And was caused by an errant comma in some Javascript.
<gmb> However, it didn't occur on Firefox
<sinzui> I think jslint may have caught that problem
<gmb> Because Firefox's JS engine is quite permissive.
<mars> gmb, we discussed that today.  Foundations has a solution - JavaScript lint should catch it.
<gmb> mars: Brilliant.
<mars> and we will be adding Lint this cycle
<gmb> Even so, I wonder if we shouldn't make a point of testing JS changes more thoroughly in > 1 browser.
<mars> err, we will be add DE-lint tools this cycle :)
<flacoste> mars: well, as a stretch goal
<gmb> (And by that I mean significantly different browsers, so Geko, something WebKitty, IE, etc)
<abentley> That said, I think it would be a really good idea to have unittests of our JS functionality.
<intellectronica> lint would be awesome. still, it doesn't mean that we shouldn't require testing on important platforms
<gmb> abentley: Well that would be the ideal, yes.
<flacoste> abentley: we are also working on that this cycle
<gmb> Btw, according to jslint, launchpad.js is very, er, linty.
<flacoste> lint integration is part of that objective
<intellectronica> gmb, abentley: is this something we could have unit tested?
<sinzui> gmb: it is not lying
<intellectronica> i think that for JS pagetesting is much more important than unit testing
<gmb> intellectronica: Well, it's something that would have made any unit test break, assuming that the testing engine was strict about syntax.
<flacoste> intellectronica: most unit testing allows you to do "pagetesting"
<intellectronica> well, if it's a syntax thing then lint should be enough
<flacoste> simulate DOM events
<abentley> intellectronica: Yes, I believe so.
<intellectronica> flacoste: is it so? i thought meaningful pagetesting for dynamic html / js / ajax really requires actually having a browser working
<intellectronica> (so something like selenium)
<abentley> intellectronica: Yes, something like selenium is what I meant.
<flacoste> intellectronica: it only needs a JS interpreter supporting DOME
<flacoste> which you get in a browser
<rockstar> flacoste, intellectronica, yui has a pretty good testing framework.
<flacoste> but there are various ways to do it
<mars> rockstar, yes, and we will also be looking at Doh
<intellectronica> rockstar: yeah, that would definitely be a good start
<flacoste> depending on the unit testing framework we use
<mars> there are a number of things to consider, like CLI usage, and PQM integration
<mars> that's all part of the Foundations js testing story for this cycle
<flacoste> anyway, we don't need to discuss that here
<barry> cool, thanks.  so we'll wait for foundations work this cycle?
<intellectronica> so, what i think we do need to discuss is how we can make reviews catch more problems with JS and DHTML
<intellectronica> i think gmb's idea of requiring testing on many platforms is good
<flacoste> JS training for reviewers... oh wait...
<barry> intellectronica: yes, guidelines for reviewing js would be most appreciated
<barry> intellectronica: it would help if we had access to a few vm's with such browsers on them
<barry> intellectronica: but also, there's a page with the os's that people have
<intellectronica> barry: well, i haven't looked at this particular problem, but if it's a syntax error than obviously we can't make a guidance to check every syntactical construct separatetly...
<mars> intellectronica, to be honest, I think the lint tools will do most of the heavy lifting for now.  Reviewers will need more in-depth JS knowledge to spot things like scoping issues.
<mars> intellectronica, however, reviewing JavaScript best practices would help
<intellectronica> mars: yes, i agree. i think that we should encourage reviewers to involve someone who feels more comfortable with js if they are concerned that they may have not covered everything
<salgado> barry, matsubara can do that for us using browsershots
<mars> this issue wouldn't have happened if the link had been coded soundly to start with
<barry> mars: most bugs are like that <wink>
<intellectronica> slowly we'll build JS proficiency anyway, especially after the epic
<barry> salgado: should that be a requirement for ui involving js?
<salgado> maybe for all UI changes?
<intellectronica> salgado: ideally, but that could slow us down considerably, which would be a shame
<intellectronica> lot's of branches touch on some UI
<barry> maybe.  if so, it has to be done by the dev as part of their branch submission
<barry> intellectronica: right
<salgado> or as part of QA on edge?
<salgado> s/edge/staging
<barry> salgado: hmm, interesting
 * barry feels like the discussion has run out of steam
<barry> seems like we have no actions out of this, except wait for foundations and epic
<barry> so...
<mars> barry, I can add some links to the JavaScript review page
<barry> mars: thanks,that would be helpful
<mars> (we do have a JS review page, right?)
<barry> well, we have a JS style guide page
<intellectronica> mars: we have a style guide. i think that's about it
<mars> ok, that works
<mars> no '#' links!
<barry> [ACTION] mars to add some links to the js style guide page to help reviewers
<MootBot> ACTION received:  mars to add some links to the js style guide page to help reviewers
<barry> 3 minutes left... one more (hopefully) quick topic
<barry> [TOPIC]  * 78 column limit okay in doctest narrative? -- barry
<MootBot> New Topic:   * 78 column limit okay in doctest narrative? -- barry
<sinzui> What was the 78 column ruling?
<barry> this was actually brought up by jml in asiapac
<barry> but i also would like to relax the 72 column limit and just allow 78 columns everywhere in a doctest
<barry> what say ye?
<bigjools> +1
<sinzui> +1
<flacoste> -1
<abentley> +1
<flacoste> mainly for esthetic reason
<rockstar> +1
<flacoste> and quoting is easier
<abentley> I say 79, dammit!
<flacoste> nah!
<bigjools> it's a PITA to
<bigjools> oo0ps
<flacoste> 79 is very bad
<barry> abentley: well i like 79 too :)
<flacoste> because it wraps very badly when reviewing
<bigjools> it's a PITA to wrap differently for text vs code
<intellectronica> i don't care that much, but, what's the motivation for this?
<barry> flacoste: jml's point, which i agree with, is that it's just more work to deal with and think about and doesn't really buy us that much
<salgado> why did we change to 72 in the first place?  I can't remember
<BjornT> -1. it's easier to read 72 characters
<flacoste> because we use that for code comments
<flacoste> and makes wrapping easier
<sinzui> intellectronica: The original argument for 72 is that it is easier to read. Bogus! English is 45-60 character line length
<barry> flacoste: how does it make wrapping easier?
<flacoste> hmm, quoting!
<sinzui> intellectronica: so 78 is not really work than 72.
<salgado> flacoste, we don't use that for code comments.  at least not as a policy
<bigjools> very subjective arguments so far
<abentley> flacoste: A width of < 80 is already pretty constraining.
<intellectronica> sinzui: i mean the argument for extending to 78
<flacoste> bigjools: the PITA is also subjective :-)
<sinzui> intellectronica: I think no one likes my reviews
 * bigjools is amazed at how heated opinions can get for trivial things
<barry> btw, the point is to have one and only one column width for our files
<intellectronica> +-0 who cares
<flacoste> bigjools: bikeshedding :-)
<bigjools> flacoste: that's not subjective, it IS a PITA for me :)
<flacoste> lol
<sinzui> bigjools: I agree. That I why a wrote a tool to do all trivial formatting of doctests
<flacoste> we have 4 +1, 2 -1 and 1 +0
<sinzui> bigjools: A tool that reports a problem about a trivial aspect of code is pointless unless it also offers to fix it
<bigjools> ideally, bazaar would reformat submissions so I don't have to even think about it
<barry> and three +1's from asiapac iirc
 * barry just wants one fill column dammit!
<bigjools> time is ovah
<flacoste> barry: time to use your presidential power here :-)
<bigjools> chuckle
<barry> mwah ha ha!
<sinzui> Anyone who wants to wrap at 72 may, he just does not have the right to complain about narrative that wraps at 78
<flacoste> you two objectives from Launchpad veterans, just dimiss the old people and go with the younger generation
<barry> ok, i think 78 is OK but not required.  ifyou want to wrap to 72, np, but 78 for code + docs is fine too
<flacoste> s/you/& have/
<barry> sinzui: exactly
<barry> :)
<flacoste> barry: that's too complex a rule
<flacoste> barry: wrap at 78
<flacoste> that's easy
<sinzui> flacoste: this is the purging of SteveA style I think
<barry> works for me.  wrap at 78
<bigjools> what?!  SteveA has style?
<barry> time's up.  sorry for going over folks
<barry> #endmeeting
<MootBot> Meeting finished at 09:51.
<barry> thanks everybody, have a great day
<intellectronica> thanks barry
<bigjools> thanks!
<mars> interesting lesson in group dynamics...
<sinzui> bigjools: wrap narrative at 72 characters, use moin headers instead of RST.
<barry> lol
<sinzui> it's true
<barry> everybody pile on bigjools for breaking the rules
 * bigjools raises shields
#launchpad-meeting 2008-09-25
<mrevell> #t/nick mrevell-lunch
<mrevell> damn
<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
<bigjools> me
<matsubara> so, who is here today?
<matsubara> me
<matsubara> flacoste, Ursinha, Rinchen,?
<flacoste> me
<Ursinha> me
<bigjools> cprov, ping
<cprov> pong
<cprov> me
<herb> me
<matsubara> we're missing, code
<matsubara> rockstar: ?
<intellectronica> me
<flacoste> i'm Foundations and the DBA report
<matsubara> Ursinha: who's the qa contact for rosetta?
<matsubara> danilo[home]__: ?
<danilos> me
<Ursinha> danilo[home]__, ping
<matsubara> ah hinding there
<matsubara> ok, so we're missing code
<danilos> matsubara: right, danilo[home]__ is, surprisingly, my account at home :)
<matsubara> let's move on then
<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>  * Sysadmin requests (Rinchen)
<matsubara> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<matsubara> next meeting, same time next week? ok for everyone?
<flacoste> yep
<Rinchen> me
<rockstar> matsubara, here
<flacoste> stub should be able to make it
<matsubara> Rinchen, rockstar: noted. thanks
<flacoste> he had a previous engagement tonight
<Ursinha> flacoste, nice
<matsubara> great
<rockstar> I forgot that we were doing this earlier.
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>  * stub to patch our fti regexp to avoid OOPSes (bug 174368) and discuss a proper fix with jtv
<ubottu> Launchpad bug 174368 in launchpad-foundations "Search query triggering error in tsearch" [Undecided,Confirmed] https://launchpad.net/bugs/174368
<flacoste> matsubara: that's not started
<Ursinha> a hanging bug
<flacoste> honestly, i don't think it's high priority
<matsubara> hmm shall I keep bring it up during this meeting?
<flacoste> it mostly trigger an OOPS when somebody tries spamming one of our search fields
<flacoste> well deserved imho
<flacoste> :-)
<Ursinha> :)
<matsubara> :-)
<Ursinha> matsubara, well, guess not so
<flacoste> but you might have a different opinion?
<matsubara> I'd like to have it targeted to a milestone at least
<Ursinha> yes
<matsubara> so we won't keep pushing oops bugs to the end of the queue
<bigjools> well, if it's acceptable it should not be an OOPS should it?
<flacoste> it's not acceptable
<flacoste> there is some rare, but legitimate query that are affected by it
<matsubara> it's important that we fix OOPS bugs, even if they affect a few users
<danilos> targeting to a milestone doesn't mean much if there is no real dedication to finish it in a certain timeframe
<flacoste> yepp
<Ursinha> danilos, indeed
<danilos> some bugs, like this one, for example, are not known how much they might take to solve (it might be a bunch of different things)
<flacoste> i'll keep it on our radar
<matsubara> well, that's the point of targeting it, isn't it? you set a deadline to fix it
<flacoste> and try to get to it at the end of the cycle
<matsubara> all right. thanks flacoste
<matsubara> I take it off from the actions from last meeting
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<matsubara> Today's oops report is about bugs 271561, 273363
<ubottu> Launchpad bug 271561 in launchpad-bazaar "OOPS calling __repr__ in xmlrpc method" [Undecided,New] https://launchpad.net/bugs/271561
<ubottu> Launchpad bug 273363 in launchpad-foundations "'LaunchpadDatabasePolicy' object has no attribute 'read_only' in xmlrpc server" [Undecided,New] https://launchpad.net/bugs/273363
<matsubara> rockstar, any news about #271561?
<matsubara> that's been happening at least once a day and I didn't see any progress in the bug report.
<rockstar> matsubara, it's being worked on, that's all I know about it.
<matsubara> flacoste, do you think bug 273363 might be related to bug 271902?
<ubottu> Launchpad bug 271902 in launchpad-foundations "db_policy equals None causing OOPS" [High,In progress] https://launchpad.net/bugs/271902
<sinzui> Edwin has a fix for tno attribute 'read_only' I beleive
<flacoste> matsubara: stub has a fix in review for that one
<flacoste> and yes, they are dupped
<flacoste> sinzui?
<matsubara> sinzui and flacoste you might want to coordinate who will fix it then? :-)
<flacoste> well, it's assigned to stuart
<matsubara> but I guess that's on stub's turf
<sinzui> 273363 is assigned to Edwin
<flacoste> lol
<matsubara> the other one is assigned to EdwinGrubb
<flacoste> well, stuart has a branch fixing both in review
<sinzui> It is caused by Edwins fix to the cookie issue with feeds
<flacoste> i'll speak to Edwin
<matsubara> rockstar: can you assign it to the devel fixing that issue and change the status to in progress?
<flacoste> matsubara: can you dup it?
<matsubara> flacoste: sure
<rockstar> matsubara, sure.
<matsubara> thanks guys.
<Ursinha> ok
<matsubara> Ursinha: stage is yours
<Ursinha> one critical, bug 273489
<ubottu> Launchpad bug 273489 in rosetta "Remaining Intrepid template approvals" [Critical,In progress] https://launchpad.net/bugs/273489
<Ursinha> danilos, i've sent one email to jtv yesterday, to get more details on the problem
<danilos> right
<Ursinha> can you help me with that after the meeting?
<danilos> this has basically been 'fix committed'
<danilos> we are now importing all the Intrepid templates
<Ursinha> right
<matsubara> I also have one soyuz critical as well. yesterday cprov identified an oops that affected 60 or so PPA's
<danilos> and this morning there were around 13K files left to import (yesterday afternoon around 18K)
<danilos> so, this should be completely fixed in two days at most
<matsubara> cprov: can we expect a IR for that one? I presume no bug was filed and things were already fixed, right?
<Ursinha> danilos, great, thanks
<cprov> matsubara: and it was fixed at that time as well, which a production update query.
<bigjools> it was only edge that was affected
<Ursinha> matsubara, which bug is it?
<matsubara> so, no code change needed?
<cprov> matsubara: no
<danilos> Ursinha: ping me after the meeting for more details, but right after the meeting, I am likely to get out soon
<matsubara> Ursinha: no bug reported for that one
<cprov> matsubara: as I said, we just had to rush the data migration.
<matsubara> cprov: ok. so, Rinchen asked about doing an IR for that.
<Ursinha> matsubara, are we going to file one?
<Rinchen> Did file a critical bug for that?
<Rinchen> so, if we didn't file a bug....
<matsubara> no, I can file one, but it's kinda pointless, isn't it? since the problem is fixed
<Rinchen> matsubara, only in the sense that we fixed the problem, not what caused the problem
<matsubara> and there'll be no code change
<bigjools> it's not a bug, it's an edge rollout issue
<Rinchen> so let's start please with a write up to the dev list about what happened and how to prevent it and not do an IR
<Rinchen> is that acceptable to everyone?
<bigjools> cprov already did that last night
<cprov> Rinchen: yes, email already sent.
<Rinchen> ok, thanks. I've been searching for it but haven't found it yet. :-(
<Rinchen> I'll keep looking.
<Rinchen> Thanks!
<Rinchen> and thanks for resolving it quickly last nigiht
<matsubara> thanks
<matsubara> moving on
<Ursinha> thanks guys
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> * 2008-09-19 - Updated 2.1.9 to r7035. This update included planned downtime. The service was down for approximately an hour.
<herb> * During the week we've had a few app servers die and leave core files. flacoste was investigating.
<herb> * 2008-09-23 - Cherry pick r7058 and r7064 to the scripts server and bzrsyncd server respectively.
<herb> * 2008-09-24 - Cherry pick r7066 and r7072 to lpnet*, update edge* to r7072.
<flacoste> herb: so i investigated the core files
<herb> flacoste: any update on the dying app servers?
<herb> cool
<flacoste> unfortunately, the stack track is pretty useless
<herb> boo
<flacoste> seems like accessing corrupted memory
<flacoste> things that barry and mwhudson said we could consider is running the appserver
<flacoste> using python2.4-dbg
<flacoste> which has some more debugging stuff in it
<flacoste> but it requires that the packages we are using also have a -dbg build
<flacoste> and are three times slower
<flacoste> another interesting thing
<herb> that's less than ideal.
<flacoste> is the stack trace posted by jtv
<flacoste> that occured in one of his script
<flacoste> it seems to point to a zope or storm problem
<flacoste> in the case of zope, the landscape team has a fixed for it
<flacoste> we should get it by moving to zope 3.4 (which we are going to attempt next week)
<flacoste> but it wasn't clear from the discussion i overheard if it looked like the same problem they experienced
<flacoste> another hypothesis made it a problem with the Storm C extensions
<flacoste> it's a good working hypothesis that the script and app server death is related to the same symptom
<flacoste> the fact that we have a better stack trace in the script case is probably due to the fact that it runs single-threaded
<herb> ok. short of running with all -dbg packages is there anything we can do to help isolate the problem?
<flacoste> so next step is to follow-up on the jtv, gustavo, barry discussion
<flacoste> and see what conclusions was there
<flacoste> and if there is something we can try from there
<flacoste> one last thing
<flacoste> i gave mthaddon the command to extract a stacktrace from a core file
<flacoste> that's really the only thing we need or can do with it
<mthaddon> https://launchpad.canonical.com/OSA/HowTo/BacktraceFromCoredump
<flacoste> so you could just save the stack trace instead of the whole core files
<flacoste> mthaddon: awesome!
<herb> flacoste: ok. cool.
<flacoste> EOT unless there are questions
<herb> that's it from the LOSAs unless there are any questions.
<matsubara> cool. thanks for the thoroughly explanation flacoste
<matsubara> and thanks herb, mthaddon!
<matsubara> [TOPIC] * DBA report (DBA contact)
<MootBot> New Topic:  * DBA report (DBA contact)
<flacoste> Nothing unusual I'm aware of on the production database.
<flacoste> Replication testing scheduled this week using demo.launchpad.net as
<flacoste> per discussions with Francis. Turn off the monitoring if it was
<flacoste> switched back on.
<flacoste> Assuming demo.launchpad.net testing doesn't push us back to the
<flacoste> drawing board, I want to have a replication version of the  staging
<flacoste> rollout scripts ready for next cycle, which should involve some
<flacoste> testing this cycle to ensure they actually work.
<flacoste> Schedule is to have the production Launchpad database replicated as
<flacoste> part of the 2.1.11 release. Staging running replicated for the whole
<flacoste> cycle should give enough experience for signoff from everyone. There
<flacoste> should be no unusual downtime requirements. I will need to be around
<flacoste> for the rollout though.
<flacoste> The new DB baseline doesn't affect production or staging.
<flacoste> mthaddon, herb: stuart will send you over notes on the changes this means for the staging roll-out process
<flacoste> i can take questions
<mthaddon> flacoste, great, thx
<herb> flacoste: ok.  when should we expect notes?
<flacoste> not before the end of next week i think
<flacoste> it will take that much time to test on demo
<flacoste> and then upgrade the staging scripts
<herb> flacoste: at a high level how will this change the rollout process?
<matsubara> flacoste: can Ursinha and I help with the testing somehow?
<flacoste> the restoration of the DB
<flacoste> matsubara: i don't think so, at this stage it's not about QA, but more about seeing performance
<flacoste> matsubara: i'll talk to stuart and forward the offer, i might be mistaken
<flacoste> herb: we'll be having a replicated DB (so a master and a slave) on staging
<matsubara> flacoste: okie. tell him to ping/email us if he needs something
<flacoste> so this affects how the DB sync is done
<herb> flacoste: ok
<herb> flacoste: thanks
<matsubara> all right. thanks flacoste
<matsubara> [TOPIC] * Sysadmin requests (Rinchen)
<MootBot> New Topic:  * Sysadmin requests (Rinchen)
<Rinchen> Hi!
<Rinchen> Is anyone blocked on an RT or have any that are becoming urgent?
<matsubara> I have one RT #31795, which I'd like to suggest priority ~80
<Rinchen> Does anyone thing this section of the meeting is worthwhile?
<rockstar> Rinchen, it might if me had an RT...
<Rinchen> :-)
<rockstar> s/me/we
<danilos> Rinchen: I guess we are free to raise RT tickets with you and our team leads whenever we want anyway
<bigjools> I think it is worthwhile
<Rinchen> matsubara, ok, will look into that
<intellectronica> maybe we should make it possible for people to add an RT-related item to the agenda before the meeting, if they have one, but skip the section if no-one does
<matsubara> Rinchen: thank you
<bigjools> if nothing else it acts as a memory jog
<danilos> intellectronica: +1
<matsubara> intellectronica: I like that
<Rinchen> danilos, intellectronica - yeah, that was my point.  If others find it helpful though, I'm happy to continue it.
<Rinchen> it's not like it's a hard thing to do :-D
<Rinchen> I'll let matsubara and Ursinha make the call.
<Rinchen> Any other tickets?
<Rinchen> ok, if you do have something, please ping me!
<Rinchen> thanks matsubara
<matsubara> ok, let's experiment with intellectronica suggestion for awhile then. I'll update MeetingAgenda page to reflect that
<matsubara> thank you Rinchen
<matsubara> anything else before I close?
<matsubara> all right
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<matsubara> actually the log part is a lie
<flacoste> thzx!
<matsubara> but thanks!
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:35.
<danilos> thanks all, matsubara especially for running the meeting :)
<matsubara> np
<intellectronica> thanks, matsubara
<Ursinha> thanks matsubara
#launchpad-meeting 2009-09-23
<barry> #startmeeting
<MootBot> Meeting started at 09:01. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everyone and welcome to this week's ameu reviewers meeting.  who's here today?
<danilos> me
<bigjools> me
<barry> wow
<bigjools> everyone must be busy with something else, can't think what
<intellectronica> me
<barry> intellectronica, gary_poster cprov salgado sinzui noodles775 jml allenap EdwinGrubbs rockstar bac ping
<noodles775> me
<jml> hi
<cprov> me
<salgado> me
<bac> barry: apologies
<gary_poster> me
<barry> no worries
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Action items
<barry>  * UI review call update
<barry>  * Linked artifacts (e.g. screenshots) from bugs and merge proposals should not disappear [bac]
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry>  
<barry> [TOPIC] * Action items
<MootBot> New Topic:  * Action items
<barry>  * gary_poster and barry will transfer review guidelines from the old wiki and old old wiki to the new wiki
<barry> postponed until after 3.0
<gary_poster> bah :-)
<EdwinGrubbs> me
<barry>  * cprov to update guidelines to clarify how code sensitive to env changes should be written
<cprov> barry: shhh, sorry again
<barry> cprov: no worries
<barry> [TOPIC]  * UI review call update
<MootBot> New Topic:   * UI review call update
<barry> beuno: hi!  would you like to say a few words here?
<flacoste> me
<bigjools> doesn't look like it :)
<barry> it doesn't ;)
<barry> anyway...
<henninge> me ;)
<barry> [TOPIC]  * Linked artifacts (e.g. screenshots) from bugs and merge proposals should not disappear [bac]
<MootBot> New Topic:   * Linked artifacts (e.g. screenshots) from bugs and merge proposals should not disappear [bac]
<bac> hi
<beuno> barry, hi
<beuno> me
<bac> doing QA i found screenshot links where the item was no longer there.  very frustrating.  that is all.
<beuno> I love you guys
<barry> beuno: :)
<beuno> and you've done an amazing job at 3.0
<intellectronica> bac: best to always use an upload, then?
<beuno> UI reviews went so well, I want them to be done everywhere else
<bac> intellectronica: probably.  or just don't prematurely purge on rookery.
<barry> bac: agreed!  i would also strongly urge people to file a bug, link that bug to your branch, and include demo/qa plan in your cover letter.  as i'm qa'ing things this week i find it very difficult when those things are missing
<barry> beuno: things are looking good, are they not? :)
<jml> also, we should allow attachments on merge proposals.
<beuno> barry, yes. There are a few "critical" issues on major pages
<barry> jml: +1
<beuno> like the bug page, mps and branch index
<beuno> some of them have been addressed
<beuno> and some of them, we won't have time
<beuno> lesson of the day:  don't levae the biggest pages last
<jml> which, of course, means that the merge proposals page should use the same attachment infrastructure as bugs.
<barry> beuno: we're going to have to cp them after the release
<barry> bac has basically said "keep qa'ing but if you find something, it's too late now"
<intellectronica> jml: there are various opportunities to share infrastructure that we should consider now
<beuno> barry, right, it's fixable
<beuno> in general, it's an awesome launchpad
<beuno> all tempaltes have been converted
 * barry is just amazed we actually converted all 375 templates
<beuno> even with me sneaking away for 2 weeks
<jml> barry, me too!
<beuno> you guys rocked the house
<jml> intellectronica, very much so. MPs already use bugs comment infrastructure, largely.
<barry> beuno: can we do a post-mortem after 3.0 is released, and maybe when you're done sprinting, etc. to evaluate the 3.0 process?  and also to think about what needs to be done post-3.0 and what's on the plate for 4.0?
<barry> beuno: it would be great to evaluate what we just did before we leap headfirst into 4.0
<beuno> barry, absolutely
<barry> great!
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<barry> that's everything on the agenda, does anybody else have anything for today?
<flacoste> barry, beuno: we are putting a 3.0 retrospective at the TL meeting
<jml> barry, nope.
<beuno> flacoste, perfect
<barry> jml: i think you're right, so...
<barry> #endmeeting
<MootBot> Meeting finished at 09:16.
<flacoste> barry: ideally, TL would be able to do a retrospective with their team
<flacoste> before then
<barry> thanks everyone and have a happy qa day
<flacoste> but i'm not sure it's practical
<barry> flacoste: isn't the tl next week?
<flacoste> barry: it is
<flacoste> but sinzui is sprinting this week for example
<flacoste> the southern hemisphere has basically a day less in this week
<flacoste> etc.
<flacoste> we are releasing
<barry> flacoste: exactly :)
<barry> anyway... see you back at the ranch
<barry> #startmeeting
<MootBot> Meeting started at 17:30. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello and welcome to this week's asiapac reviewers meeting.  who's here today?
<mwhudson> i am!
<thumper> hey
<wgrant> moi
<thumper> barry: rockstar may be lying down
<barry> excellent
<barry> thumper: cool
<barry> thumper, mwhudson y'know your evil plan to increase the number of antipodeans is backfiring
<thumper> why?
<barry> jml
<barry> ;)
<barry> anyway...
<barry> not much happened in ameu
<mwhudson> the plan hadn't really got far enough that you could call it evil...
<barry> bac requested that folks keep their screen shots around long enough to do qa.  some screen shots were not attached to the bug, but instead were on rookery, and got deleted
<thumper> I'd like to be able to add attachments to a code review
<barry> it's recommended to attach them to the bug, or at least keep them around until the end of the cycle
<barry> thumper: that came up too
 * thumper adds it to the wish list
<thumper> barry: you can attach them to the mail
<thumper> barry: and we could link them on the UI
<bac> barry:  you woke me up for that?  lies back down to monitor the release
<barry> thumper: yep!
<thumper> barry: the images are stored in the librarian (I think)
<thumper> barry: I'll test
<barry> cool, thanks
<thumper> perhaps not today
<barry> thumper: in the original mp request is probably the most important
<barry> the only other thing from ameu is: lp 3.0 is awesome and beuno loves you
<barry> that's all i have.  what's up with you?
<wgrant> I can no longer complain about the lack of public ec2test.
<barry> wgrant: we have that now?
<mwhudson> well, he does
<mwhudson> it's not actually 'public' yet
<barry> mwhudson: cool
<mwhudson> because i need to land ec2test changes
<thumper> I don't have anything review specific to bring up
<mwhudson> i guess we could mention that review diffs will be a bit different post rollout?
<thumper> perhaps
<barry> mwhudson: how so?
<thumper> pushing will cause the diff to be updated
<mwhudson> they'll update on push
<mwhudson> and they're merge --preview diffs, not diff -r ancestor: diffs
<mwhudson> (so you can get conflicts)
<mwhudson> thumper: are the old diffs kept around?
<thumper> kinda
<thumper> not really
<thumper> yet
<barry> updates are nice
<mwhudson> thumper: there was this idea of linking a code review comment to the diff it applied to, i guess that's not done yet?
<thumper> there is
<thumper> but that is a db patch
<mwhudson> right
<barry> mwhudson: what's the reason behind the merge --preview diffs?  to be explicit about conflicts?
<thumper> that is the only way we can get reasonable diffs
<thumper> barry: because if you merge the target
<mwhudson> barry: conflictyness seems interesting to the reviewer
<thumper> barry: you don't want the merged details in the diff
<barry> thanks.  how does this affect support for dependent branches?
<mwhudson> another thing, jml has this half-written branch that will pull all the details for an ec2 test run from the merge proposal
<thumper> heh
<thumper> well
<thumper> right now they aren't really supported
<thumper> abentley is working on fixing the dependant branch support
<thumper> being renamed to "prerequisite branch"
<mwhudson> which i think will be a useful improvement
<thumper> mwhudson: including commit message?
<mwhudson> thumper: i presume so
<barry> mwhudson: where useful == awesome
<thumper> barry: part of this would be to get LP to somehow work well with pipes
<thumper> barry: have you used bzr-pipelines yet?
<thumper> barry: IMO if you like looms, you'll love pipelines
<barry> thumper: i keep meaning to.  i know they are the official goodness to use instead of looms
<thumper> barry: they just work better with LP as they are branch based
<barry> honestly though, i haven't had many branch stacks during these last two cycles
<thumper> :)
<jml> including commit message.
<jml> it assembles the [r=...] gunk from the mp
<jml> and takes the actual text of the commit message from the mp too
<jml> (but iirc, you can override it)
<barry> jml: my last commit message is usually meaningless, e.g. 'pick some lint' or 'merge rf'
<thumper> barry: the proposal has a commit message field
<thumper> barry: not set very often right now. tarmac uses it
<barry> i'll have to start using that.  i've basically ignored the Subject: field until now
<barry> but it all sounds cool
<thumper> barry: it isn't the subject
<barry> thumper: isn't that last commit message stuffed into the subject in a 'bzr send'?  or is that something else?
<thumper> barry: we don't do anything with that subject
<barry> thumper: that's why i've started to ignore it
<thumper> barry: but the commit message is a different bit
<barry> i have one other thing i'd like to ask y'all
<thumper> shoot
<barry> is this time still the best for the asiapac meetings?
<thumper> still good for me
<thumper> although we change next week
<thumper> daylight savings kicks in
 * thumper thinks
<thumper> so becomes one hour later
<barry> personally, i wouldn't mind moving it earlier by an hour (or more) but i want to make sure we continue to meet at a good time for you
<thumper> I'm fine with this time
<barry> thumper: you just blew my mind
<thumper> could be fine an hour earlier too as of next week
<barry> so that means 2130 utc?
<thumper> mwhudson: got any preference?
<thumper> barry: yes
 * mwhudson blinks his attention back, sorry about that
<mwhudson> 2130 utc next week is 0930 local?
<mwhudson> that's fine with me
<barry> i'll probably bitch and moan again by 01-nov when we fall out of daylight savings, but for now that would be great
<thumper> mwhudson: 2130 utc next week is 1030 local
<thumper> mwhudson: daylight savings sunday
<mwhudson> oh right
<mwhudson> that's completely fine
<barry> great!  2130 it is
<barry> that's all for me
<mwhudson> another hour earlier would be ok, though risks bumping into our standup
<thumper> barry: well, in nov it would be another hour earlier for you
<thumper> barry: which would make it what?
<mwhudson> an hour earlier than that would be ok, though that's getting a little early here (0830)
<barry> thumper: i think it would make it 1630 for me which would be perfect
<thumper> mwhudson: I was talking about US going out of daylight savings
<mwhudson> thumper: i'm just being general
<mwhudson> thumper: now jml is off, we can go earlier, is the basic summary
<thumper> right
<barry> right
<thumper> we could do 20:30 utc
<barry> 2130 should be fine now and after 01-nov
<barry> if not, it's good to know we can push it a bit, but probably not necessary
<barry> anyway...
<barry> anything else guys?
<thumper> what about 2100 ?
<thumper> barry: it used to collide withour standup
<thumper> barry: but we moved that
<barry> thumper: ah cool.  2100 is fine too
<thumper> mwhudson: 2100?
<mwhudson> thumper: yes, fine
<thumper> barry, mwhudson: sold!
<barry> beauty
<barry> thanks guys... i think we're done!
<barry> #endmeeting
<MootBot> Meeting finished at 17:55.
<thumper> thanks barry
<barry> cheers
#launchpad-meeting 2009-09-24
<Ursinha> OOPS-1362EA10197
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1362EA10197
<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
<bigjools> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<rockstar> ni!
<bac> me
<stub> me
<gary_poster> me
<EdwinGrubbs> me, sitting in for sinzui
<matsubara> Ursinha, Chex: hi
<Ursinha> me
 * Chex is here
<matsubara> danilos, are you joining us?
<Ursinha> matsubara, flaky internet
<matsubara> allenap, hi
<danilos> me
<danilos> matsubara: yes
<allenap> me
<matsubara> danilos, shall I make you the default translations person for the LP prod meeting?
<mbarnett> me?
<gary_poster> you!
<matsubara> hi mbarnett
<matsubara> welcome :-)
<mbarnett>  :)
<matsubara> ok, everyone is here
<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>     * barry to continue debug on bug 403606 after finishing 3.0 UI stuff
<matsubara>     * matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<danilos> matsubara: yes
<matsubara> I still suck, haven't done that one.
<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
<matsubara> EdwinGrubbs, I'll keep the action item for barry in the list since 3.0 crazyness is not over yet :-)
<matsubara> [action] * barry to continue debug on bug 403606 after finishing 3.0 UI stuff
<MootBot> ACTION received:  * barry to continue debug on bug 403606 after finishing 3.0 UI stuff
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<matsubara> [action] matsubara to update translations qa contact on meeting agenda page
<MootBot> ACTION received:  matsubara to update translations qa contact on meeting agenda page
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> Ursinha, go ahead
<matsubara> hmm Ursinha was having connectivity problems before the meeting
<danilos> ok, so, let me take over for what I can
<danilos> bac is doing a great job with managing release of 3.0 and any critical bugs
<danilos> what we've seen is already listed on https://dev.launchpad.net/CurrentRolloutBlockers
<bac> thanks.  getting lots of good help.
<danilos> we have noticed increased timeouts on production DBs, due to postgres restart
<danilos> for more details, Ursinha will have to fill us in
<matsubara> we had a bunch of disconnection errors as well
<danilos> matsubara: around the time of rollout or? (because that'd be expected if so)
<matsubara> danilos, not sure, Ursinha just sms'ed me and asked me to bring it up
<matsubara> but I take the increase on those are due to the rollout, yes
<matsubara> so, Ursinha and I will keep looking for the new oopses that happened since the rollout
<danilos> matsubara: I suggest we get more detailed input from Ursula when she shows up back online, but go on with the meeting for now; for what we know, all critical issues are being taken care of, and we are hoping for a re-rollout tonight
<matsubara> and let each affected team about them and add them to the CRB page
<danilos> matsubara: thanks matsubara, that'd be great
<matsubara> we had some script failures as well related to the rollout
<matsubara> and another one unrelated which bigjools already replied to
<matsubara> (which is the packagediffs thing)
<matsubara> we have 6 critical bugs
<bigjools> fixed in the rollout
<matsubara> 2 fix committed, 3 in progress and one triaged
<matsubara> danilos, the one triaged is in rosetta. what's up? are you expecting to land code for that one for the second rollout?
<matsubara> bac, do you have a time for the second rollout?
<danilos> matsubara: it's in progress
<matsubara> thanks bigjools
<matsubara> danilos, I mean bug 435891
<ubottu> Launchpad bug 435891 in rosetta "recent update broke the urls used in launchpad integration" [Critical,Triaged] https://launchpad.net/bugs/435891
<danilos> matsubara: it's in progress
<bac> matsubara: we anticipate a second roll out.  perhaps later today, though no decision has been made yet.
<matsubara> danilos, it's not what LP says :-)
<danilos> matsubara: it's what I say :)
<danilos> bug 435891 is in progress :)
<matsubara> danilos, I trust you to beat LP and make it behave :-)
<matsubara> thanks danilos
<danilos> the other in-progress one is almost landed (in pqm)
<flacoste> matsubara: Disconnection errors
<flacoste> about them
<flacoste> do you know if they happened before or after the roll-out?
<flacoste> if they happened before/during the roll-out they are expected
<flacoste> we had a bug, now fixed, that logged DisconnectionError as regular OOPS
<bac> are you in the production meeting?
<flacoste> where it should be logged as a soft oops
<danilos> bac: yes, this is the production meeting
<bac> sorry, wrong window
<flacoste> so DisconnectionError logged after the roll-out are a problem
<matsubara> flacoste, after the meeting I'll generate a new summary to find that out.
<flacoste> ones before or during it (when running with unfixed code) is not a problem
<matsubara> [action] matsubara to generate new oops summary including oopses only for after the rollout
<MootBot> ACTION received:  matsubara to generate new oops summary including oopses only for after the rollout
<flacoste> matsubara, bac: we can determine the second roll-out time after we have that report
<bac> matsubara: i was just made aware of bug 435628 that the bugs team is working on for a re-roll
<matsubara> I'll defer the answer to bac
<ubottu> Launchpad bug 435628 in malone "Attempting to file a bug on an Ubuntu source packages OOPSes when bug filing is disabled" [High,Triaged] https://launchpad.net/bugs/435628
<stub> barry was going to look at annotating those oopses so we can tell if they where DisconnectionErrors returned to users, or just part of the normal reconnection workflow.
<bac> matsubara: i agree with flacoste that we can make a decision after getting your report
<matsubara> all right
<stub> erm... gary... not barry
<gary_poster> :-)
<matsubara> heh
<matsubara> ok, I think that's all for this section
<matsubara> let's move on
<matsubara> thanks everyone!
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Chex> HI everyone, brief LOSA report this week.
<Chex> - LP 3.0 rollout: The rollout dominated Launchpad work this week. Briefly, things went fairly well, we
<Chex> observed a number of items in the rollout process that are being addressed.  We have emailed out the
<Chex> full report today.
<Chex> And that it for us, unless anyone has questions?
<gary_poster> three cheers for losas. :-)
<matsubara> thanks Chex
<mthaddon> gary_poster: I think you mean three *beers* for each losa...
<gary_poster> lol, yeah, probably more appreciated
<mthaddon> :)
 * stub raises a glass and says 'cheers'
 * Chex drinks to that
<danilos> so, drunken DB report comes next? :)
<matsubara> let's go to the bar, err, move on
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<drunken_master> Database update seems to have gone smoothly apart from Bug #435674 being discovered. This will have caused a short hang of the SSO servers, but it was probably quick and hopefully nobody noticed.
<danilos> :)
<drunken_master> After the update, I needed to do some data migration. That increased replication lag, putting extra load on the master db. All done now and load is back to normal. This will have contributed to timeouts, so you may wants to attribute timeouts before 1200 UTC to this.
<drunken_master> The appservers where observed in the wild basing their decision to use the slave database on how lagged that particular slave is, not how lagged the cluster is as a whole. This means that building new slave databases will no longer stop the appservers going into master-only mode.
<rockstar> :)
<ubottu> Launchpad bug 435674 in launchpad-foundations "fti.py wants to lock all replication sets" [High,Triaged] https://launchpad.net/bugs/435674
<drunken_master> oot.
<gary_poster> lol
<mbarnett> heh
<danilos> thanks for the update drunken_master, always appreciated
<matsubara> thanks stub
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> no proposed items
<matsubara> anything else before I close?
<matsubara> hi Ursinha
<matsubara> just in time :-)
<Ursinha> I just want to say sorry
<Ursinha> and congrats to all lp team because LP 3.0 rocks
<Ursinha> :)
<matsubara> indeed!
<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:27.
<gary_poster> thank you!
#launchpad-meeting 2010-09-29
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<flacoste> me
<noodles775> me
<henninge> me
<EdwinGrubbs> me
<allenap> me
<sinzui> me
<adeuring> me
<gmb> me
<danilos> mi
<jelmer> me
<abentley> me
<bac> welcome back flacoste!
<flacoste> thanks
<bac> [topic] * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>   * canonical.launchpad is still deprecated, sinzui
<MootBot> New Topic:  * Agenda
<bac>   * branch size metric
<bac>  * Mentat update.
<bac>  * Peanut gallery
<bac> EdwinGrubbs: ping
<deryck> me
<EdwinGrubbs> me, again
<bac> EdwinGrubbs, sorry
<bac> :(
<mars> me
<leonardr> m
<leonardr> e
<bac> [topic] Outstanding actions
<MootBot> New Topic:  Outstanding actions
<bac> * bac and lifeless to chat about branch size.
<bac> done.  we'll discuss it later
<bac> nothing else outstanding.  \o/
<bac> [topic] * canonical.launchpad is still deprecated, sinzui
<MootBot> New Topic:  * canonical.launchpad is still deprecated, sinzui
<bac> can you elaborate, sinzui?
<sinzui> Reviewer, please challenge developer to move code out of c.l instead of making changes in it
<sinzui> No developer should be adding new code to it
<sinzui> c.l is in a bad state at the moment...
<sinzui> no one claims ownership of the code in it...it needs owners
<sinzui> c.l contributes to our cyclic import problem. you will not be happy until c.l is gone
<henninge> Also, elimiate any import from canonical.launchpad.interfaces when you see one!
<mars> sinzui, +1.  Also, it is easy to split the branch to keep the size down if you use bzr pipes
 * sinzui has a branch that fixes all zcml
<henninge> mostly in doctests, I think
<henninge> oh yeah, and zcml
<sinzui> mars, You probably need to split the branch
<sinzui> I think most of the work now involves moving classes, not modules
<sinzui> But look at interfaces and database. Some team must own it, otherwise, lets talk about deleting it
 * sinzui eyes account
<bac> thanks sinzui
<wgrant> Why aren't c.l.i and c.l.d imports lint?
<sinzui> no one has written an extension to report that.
<sinzui> It might be easier to get people to commit to just fixing all the import over the next two weeks
<sinzui> I have nothing more to say
<bac> sinzui: why don't y'all discuss that at the TL meeting and see if the teams can schedule the work?
<noodles775> I think teams other than code/translations need to add lp/app/interfaces/webservice.py before we can remove c.l.i?
<wgrant> That's true.
<wgrant> And rather unobvious.
<sinzui> I have had four failed branches to remove c.l.i
<sinzui> soyuz and registry are in a death spiral
<wgrant> sinzui: Circular imports galore?
<sinzui> wgrant, yes
<wgrant> :(
<bac> [topic] * branch size metric
<MootBot> New Topic:  * branch size metric
<sinzui> I am now trying to remove chunks by theme like lp.<model> or all zcml
<bac> a few weeks ago in the asiapac meeting we started discussing the metric we use for branch sizes.  currently we use 800 lines of diff.
<bac> lifeless made the argument that this is a "bad surrogate" for managing branch focus and complexity, which is what we really want to control
<bac> so is the 800 line rule still useful and valid?  we used to have severe problems with branches being too large but as a team we seem to have trained ourselves out of that bad habit
<danilos> I find the rule is still working fine as a checkpoint, and we should keep it
<sinzui> I think 2000 lines of mechanical changes made by a find and replace is easier to review than a branch that changes things for 5 very different reasons
<mars> bac, imho yes, the rule is a valid rule of thumb.  It still applies broadly, and for some operations, we all know when it can be bent
<mars> sinzui, exactly
<abentley> sinzui: I think it's a good guideline, but sensible people know when to ignore it.
<bac> sinzui: that is basically the argument.  focus is more important than size
<flacoste> i agree with mars
<sinzui> I think 4 hours is a good checkpoint
<deryck> is there something someone wants to do that the 800 line limit prevents?  Or does lifeless see a better way to manage scope?
 * bac hides
<abentley> sinzui: you mean, after 4 hours of work, we should submit something for review?
<mars> bac, also, there is research that shows that code reviews over 400 lines get difficult.  I treat 400 as ideal, 800 as a hard limit for green-field code.  the 800 line diff rule fits into a "400 lines of change plus context"
<sinzui> abentley, maybe. If the branch has something that is valuable and landable
<bac> lifeless's argument is that diff size is a silly measure.  800 lines of deletes is very different than an 500 line contiguous addition which is different from a bunch of scattered one line changes.
<deryck> bac, but is there an alternate proposal for what is a good measure?  or just a request to drop the requirement?
<abentley> bac: my argument is that there's nothing that's reasonably easy to check that won't be silly.
<bac> there was an experimental one deryck
<danilos> 800 limit is simple, above all... we shouldn't be spending too much time wondering if can get our branches reviewed; 800 line limit is for us to stop and think if we go above it
<mars> bac, true, but we all know the difference, don't we?  The reviewee always says "This is huge, but it's deletes, so please don't lynch me"
<bac> in order to control focus, robert suggested a branch that takes more than 2-3 major discussion points to describe (in the MP for example) is probably too unfocused
<danilos> (i.e. it's just a signal that we might be doing something wrong: i.e. you are solving several things with one branch, etc.)
<gmb> bac: But not everyone writes a good MP :)
<bac> gmb: don't i know it!  :)
<deryck> yeah, I agree with gmb, that only indicates language facility, not coding focus :-)
<gmb> Line count at least gives us reviewers something to fall back to and say "Er, that's a bit on the large side..."
<allenap> The 800 line limit makes me think about the focus of the branch, and puts a lid on things in case they do get a bit unfocused.
<danilos> bac, sometimes I describe the background for a branch in more than a few points, to assist translations-unaware reviewer :)
<sinzui> The implementation meeting should be setting scope and what issues a branch needs to solve
<bac> danilos: but those aren't describing the core changes
 * sinzui often has a separate branch for drive-by fixes
<mars> bac, so would we like to see, say, instead of a 600-line 2 topic branch, two 300-line one-topic dependent branches?
<bac> mars: ideally, yes
<mars> If so, may I suggest the 400 line soft limit again?  more than 800 lines is a burden on the reivewer, but more than 400 means you may have to split topics
<bac> mars: well that is how this discussion got started
<bac> mars: rockstar brought up the idea of dropping the limit to 400
<mars> ~400 lines will speed the review and is likely to keep it topical
<bigjools> mauve.bikeshed.com
<deryck> bac, so is the concern that 800 doesn't really limit scope, or that 800 is too constricting for some work?
<bac> personally he found it more manageable and more productive
<mars> bigjools, hehe, I have research from IBM to prove it :)
<mars> it was C++, mind you
<danilos> I, honestly, don't see how 400 is any better than 800... except that it will be hard to live with in some cases (I had new tests take around 400 lines for some very intricate methods)
<bac> deryck: the argument is the 800 limit is wobbly, often ignored, and never was a good indicator and that rules have cost.  a bad rule should be removed or replaced with a good rule;
<deryck> ok
<deryck> so by that, any line limit is a bad rule, right?
 * bigjools doesn't see why this has to be so bureaucratic
<bac> this topic is not pressing, but i wanted us to talk about it
<bac> i think it is better discussed in person, so i'll put it on the schedule for dallas
<danilos> 800-line-limit rule is cheap compared to any other, and I agree we should not be spending too much of our time on discussing it
<mars> bac, it sounds like many people liked the 800-line rule as a guideline.  Do people feel it was ignored?
<deryck> I think there needs to be a really great counter proposal to make this a useful discussion.
<danilos> deryck, +1
<mars> deryck, yes
<henninge> mars: I don't.
<henninge> deryck: yes, that's what's missing here.
<mars> henninge, you don't like it?  Or you don't follow it? :)
<bac> [action] move discussion of branch size/complexity to the epic --bac
<MootBot> ACTION received:  move discussion of branch size/complexity to the epic --bac
<henninge> mars: ;-) I don't feel it was ignored.
<henninge> bac: +1
<henninge> but only if there is a good aleternative to discuss.
<bac> [topic] mentoring update
<MootBot> New Topic:  mentoring update
<danilos> "It's going to be an Epic discussion!"
 * bac forgets who here is being mentored
<bac> salgado, how is it going?
 * henninge is UI mentat
<danilos> henninge, salgado as UI reviewers
<salgado> bac, I'm enjoying it!
<bac> henninge: getting any UI reviews?
<salgado> and getting plenty of requests
<bac> great
<henninge> bac: yes, I have
<bac> salgado is the anti-beuno when it comes to screen real estate
<henninge> been getting some.
 * sinzui has an 800px wide browser like most lp users
<bac> so, as a reminder, throw your UI reviews to those to first if you can
<bac> and save up some code reviews for stevenk if possible
<bac> [topic] anything else?
<MootBot> New Topic:  anything else?
<abentley> bac, yes: line breaks.
<sinzui> http://browsersize.googlelabs.com/ <- https://launchpad.net
<MootBot> LINK received:  http://browsersize.googlelabs.com/ <- https://launchpad.net
<abentley> I thought the rules for where we should put newlines were clear, and specified in PEP8, but it seems like that really only covers method definitions.
<abentley> For example, I thought we were supposed to have a blank line between class variable declarations, but I can't find a rule for that.
<abentley> Do we have rules about this?  Should we?
<bac> abentley: if you didn't find it in https://dev.launchpad.net/PythonStyleGuide then i guess we do not
<bac> abentley: have you seen lots of inconsistency?
<abentley> Are there any rules that people have been following that we should codify?
<henninge> I have not been putting new lines between class attributes consistently.
<henninge> In interfaces, yes, but in test cases, no.
<abentley> Okay, I guess I'll just ignore that in reviews.
 * henninge has not changed an interface in a long time ...
<bac> abentley: thanks for bringing it up but it doesn't seem to be a huge problem people are seeing.
<bac> any other topic?
<bac> 3
<bac> 2
<bac> 1
<bac> #endmeeting
<MootBot> Meeting finished at 09:39.
<henninge> thanks bac! ;)
<bac> thanks all
<mars> thanks bac
#launchpad-meeting 2010-09-30
* bac changed the topic of #launchpad-meeting to: Launchpad Meeting Grounds | Channel logs: http://irclogs.ubuntu.com/ | Weekly meetings: https://dev.launchpad.net/IRCMeetings | Lost in time? date -u
<bac> thumper, rockstar, mwhudson, StevenK:  my apologies but i'm not going to be able to be here in an hour for the meeting
<mwhudson> hi
<mwhudson> is there much to discuss?
<bac> mwhudson: no, not really
 * rockstar  
<sinzui> Assuming everyone agrees that it is a crime to put something in canonical.launchpad
