#launchpad-meeting 2006-10-16
<SteveA> goedemorgen
<ddaa> Good morning gentlemans and gentlemans
<ddaa> or gentlemen
<spiv> Good evening.
<ddaa> well, not ladies in any case
<ddaa> Da Sydney crew appears to be away
<ddaa> ha
<poolie> hullo
<_thumper_> speak of the devil
<ddaa> okay, all required attendance now present
<poolie> it's just the pointy hair :)
<ddaa> hair?
<ddaa> == Agenda ==
<ddaa> Next meeting Monday 23 October 1000 UTC - 1045 UTC.
<ddaa>  * roll call
<ddaa>  * production status
<ddaa>  * 1.0 targets
<ddaa>  * release finder
<ddaa>  * Python import
<ddaa>  * Debian svn server load
<ddaa>  * Cscvs and pyrex
<ddaa>  * Sprint report
<ddaa>  * SpecBranch status
<ddaa>  * bzr-lp features
<ddaa>  * forwarding bzr list emails
<ddaa>  * advertising
<ddaa>  * highlighted 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.
<poolie> add: 'agenda items for singapore', if that's not covered by 'bzr-lp features'
<ddaa> == Roll call ==
<ddaa> Sorry for missing the meeting last week without warning. 
<ddaa> No excuse was given for this week.
<_thumper_> here
<poolie> here
<ddaa> poolie: well, basically bzr-lp features is your soap-box, so it's okay
<poolie> ok
<spiv> here
<SteveA> hi
<ddaa> jamesh: hello?
<ddaa> jamesh appears missing
<poolie> moving on...
<ddaa> == Prodution status ==
<ddaa> Nothing new to report on production, as far as I know. Did anybody has something to report from last week?
* ddaa goes oblivious to the world when on a sprint
<jamesh> ddaa: here
<SteveA> the only issue is the debian server load, which there is an item for later
<poolie> next...
<jamesh> ddaa: stub said he'd be doing a rollout this week, which will put the $productseries/+source form improvements live
<jamesh> and have everything in place to run product-release-finder in production
<jamesh> (finally)
<poolie> jamesh: what will that do?
<poolie> i mean, what will be seen under /+source
<_thumper_> jamesh: could you point me to the changes?
<ddaa> jamesh: offtopic, but good news
<_thumper_> later is fine
<ddaa> jamesh: please pay attention to the agenda
<ddaa> == 1.0 targets ==
<ddaa> supermirror-smart-server: spiv: delivery status? New estimated delivery date? What was done recently, what will be done next?
<ddaa> importd-bzr-native: was marked as delivered, further cleanups (removing baz deps completely from Launchpad) was deemed out of scope for this spec.
<ddaa> bzr-roundtrip-svn: not for 1.0
<ddaa>  * mpool: read up/tick off svn roundtripping discussion
<jamesh> ddaa: I thought a production rollout would be related to that agenda item
<ddaa> jamesh: mh, okay, will clarify. It's about reporting issues with the production systems. There are normally specific agenda items to mention rollouts.
<ddaa> spiv: how the smart server going those days
<spiv> ddaa: I'm still working on the HTTP smart server -- the code is basically written, but there are some issues raised in reviews that need to be addressed before it can be merged to bzr.dev.
<SteveA> meta note: it may be a more efficient meeting (less overhead) to have fewer items each with a wider scope
<_thumper_> SteveA: agreed
<ddaa> spiv: what's next, and what's the current ETA for deployment if any?
<poolie> ddaa: no comments from me on bzr-svn roundstripping
<spiv> This work includes a WSGI application, and documentation showing how to run it with FastCGI in Apache.
<_thumper_> smart server for devpad?
<ddaa> poolie: need more information ato find the threads discussing that?
<poolie> ddaa: is it "mutating history in subversion and bazaar"?
<spiv> For the supermirror, the only missing piece is translating the public URLs to the database-id directories on disk.
<poolie> if there's something in particular you want my input on, forward it to me
<ddaa> poolie: that and one or two other threads started at about the same time
<SteveA> fastcgi?
<spiv> But that should be very easy to hook in.
<SteveA> is that the one with the funny licence?
<SteveA> if so, the sysadmins don't like running it
<spiv> Hmm.
<ddaa> poolie: I guess I should summarise them and start new threads then
<SteveA> spiv: check with the admins what cgi flavours they prefer
<spiv> Well, maybe I can look into to WSGI + mod_python or something instead.
<spiv> In theory, WSGI means I don't have to care too much... ah, theories :)
<spiv> SteveA: will do.  Thanks for the heads up.
<ddaa> spiv: before I get asked again, it would be nice of you to update the spec page on Launchpad, and maybe give an ETA
<SteveA> please keep the spec implementation status + whiteboard up to date
<spiv> I'll recheck the spec metadata... it looked accurate last time I checked about a week ago.
<SteveA> it really helps with planning for 1.0, and also to cope with the distributed nature of our development
<poolie> ddaa: i'll read it now and send you mail
<spiv> (the spec itself is in need of a lot of effort to bring it up to date with reality though :(  )
<SteveA> the whiteboard is a good place to put explanation about what is needed still in implementation or deployment
<ddaa> that's fine, the spec is irrelevant now that there's code
<spiv> Ok, I'll pay particular attention to the whiteboard.
<ddaa> moving on
<ddaa> poolie: thanks
<ddaa> == Product release finder ==
<ddaa>  * jamesh: report on PRF progress. Was complete and pending review two weeks ago.
<jamesh> was merged, and the revision stub is rolling out contains the last round of fixes
<ddaa> Since then, jamesh basically rewrote all of the $series/+source web ui
<jamesh> so we should be able to run it in production this week
<ddaa> Okay, I take you'll be in charge of babysitting the cronscript/daemon whatever
<SteveA> that's great.  I'm looking forward to seeing an improved +source page
<jamesh> SteveA: you can see it on staging right now
<ddaa> this a new production subsystem, so we'll need to clarify ownership
<ddaa> jamesh: TTY and SteveA about that later this week,
<ddaa> == Python import ==
<ddaa>  * ddaa: status of Python blocker cscvs bug
<ddaa>  * jamesh: bzr-0.11 rocketfuel landing
<ddaa> python: the new cscvs logic was done before the sprint. Currently pending review. This week, will test to confirm that it fixes the python import (continuing from last failure point).
<ddaa> bzr-0.11: was fully landed (launchpad, cscvs, bzr, removal of bzrtools) in the past couple of weeks.
<ddaa> jamesh: is that correct?
<jamesh> yep
<jamesh> I removed bzrtools and gnarly from the dists config too
<ddaa> hello Rob, you're late
<poolie> ddaa: his attendence is optional
<poolie> so don't be snarky, if you were
<ddaa> I know
<ddaa> I do not even know what this word means
<poolie> nevermind
<_thumper_> next...
<ddaa> but sorry for offending people
<ddaa> I cannot help it you know, I'm french ;)
<ddaa> == Debian svn server load ==
<ddaa> Mithrandir (Tollef Fog Heen) reports that Wichert Akkerman is unhappy about the svn.debian.org load coming from russkaya (one of the importd-autotest slaves).
<ddaa> > 1gb of traffic in a day is insane if the normal load is 30mb
<ddaa> I do not see off-hand what would have caused that since I did not touch importd recently (meaning autotest should not have done anything in the past couple of weeks at least) and most of our debian imports are now in production (on neumayer or galapagos).
<ddaa> Some stats:
<ddaa> https://devpad.canonical.com/~andrew/paste/file996I60.html
<_thumper_> rogue process?
<_thumper_> something not killed properly?
<ddaa> unlikely to cause load on remote servers
<ddaa> but worth checking
<_thumper_> could if the process was in a loop downloading stuff
<ddaa> this sort of loop never happened
<poolie> ddaa: so what are we going to do now?
<lifeless> did I miss anything I should care about ?
<poolie> ddaa: is there no log of what's retrieved?
<poolie> lifeless: not really
<poolie> would be interested to hear from you about the debian svn server load thing though
<jamesh> would their access logs give some indication of what was being hit?
<poolie> jamesh: possibly, but i don't think svn normally logs requests
<ddaa> poolie: nope, no log of network activity. But I can narrow down what buildbot knows it has run on russkaya recently from those imports
<poolie> however, from their point of view the problem is solved: they firewalled us
<jamesh> poolie: ah.  it is going through svn:// so they wouldn't get apache access logs.
<poolie> it is *our* obligation not to do this
<ddaa> what's weird, is that they never complained before
<lifeless> one possibility is a single freakingly big import
<_thumper_> maybe they just noticed
<ddaa> and now they do it, although there should be now load at all from russkaya recently
<lifeless> i.e.
<lifeless> 'please give me all the branches of x.org'
<lifeless> which is gb's of data
<poolie> ddaa: it seems to me that we should log what we crawl...
<ddaa> https://devpad.canonical.com/~andrew/paste/file996I60.html
<ddaa> lifeless: no such thing in the autotest stuff afaict
<_thumper_> gee, the linux kernel is big isn't it?
<poolie> ddaa: yes you keep posting that url but what are we supposed to infer from it?
<jamesh> svn://svn.debian.org/devscripts <- that'll get every branch and tag
<jamesh> similar for svn://svn.debian.org/debconf
<lifeless> yup
<ddaa> jamesh: thank you
<lifeless> thats what I was thinking of
<lifeless> that sort of thing
<ddaa> poolie: supposed to find the error, what jamesh just did
<ddaa> the pb is that we do what our users tell us
<poolie> ddaa: so the importer doesn't detect the common ancestry between the tags?
<ddaa> no way around that...
<spiv> It seems like a difficult way to find the error, though.  Is there a query that can tell us what the recent activity is?
<ddaa> tags?
<poolie> it gets them all?
<ddaa> ancestry?
<ddaa> poolie: you are assuming that svn is meaningful about tags... it is not
<poolie> it doesn't expose the CoW data at all?
<jamesh> poolie: there is no way (other than convention) to tell if a URL is for a branch or the entire repository
<_thumper_> a tag is svn is just a branch
<poolie> jamesh, tim: yes, i know
<ddaa> let's move on, poolie we can discuss how svn is shit later
<lifeless> _thumper_: a tag is not a branch, thats the problem :(
<ddaa> jamesh: thanks for the sharp eye, that will help
<lifeless> _thumper_: its a copy is all
<spiv> Well, it seems that we probably want to at least warn if someone attempts to import an SVN directory with "trunk", "branches" and "tags" subdirectories.
<spiv> Because almost certainly that's not going to do what they want.
<ddaa> spiv: we've got no useful warning system
<poolie> spiv: that would probably solve most of the cases
<ddaa> but that's a good point otherwise
<poolie> ddaa: do you seriously mean if i enter the base url of a repo it will pull everything, similarly to checking out the whole thing?
<ddaa> let's follow-up on mailing list, there are good ideas flying around
<spiv> If warning isn't an option, I'd settle for "refuse to do it all".
<spiv> s/all/at all/
<jamesh> spiv: or warn if the URL they enter doesn't contain a segment named "trunk", "branches" or "tags"
<ddaa> poolie: there's an bug that prevents it, but svn does not allow us to figure out if it's a error or not
<lifeless> poolie: yes, because we cant tell the difference reliably
<spiv> jamesh: that's a good idea
<lifeless> poolie: same as ddoing a svn checkout of the base
<jamesh> maybe even error out
<poolie> lifeless: wow
<poolie> ok
<ddaa> GUYS -> MAILING LIST
<ddaa> == Cscvs and pyrex == 
<ddaa> SteveA said: for pyrex, say what you've done so far, what benefit it's had, what would need doing if this became "official"
<ddaa> sorry had no time to prepare a paste
<ddaa> I have an experimental branch,
<ddaa> that implements libsvn bindings for cscvs using pyrex
<ddaa> to replace python-subversion and pysvn
<ddaa> So far, done almost all that's needed by the Repository and WorkingTree classes
<ddaa> that does not include the critical code paths for the import process
<SteveA> (on hammering servers, I wonder if we can pipe our svn connections through some kind of per host accounting, so at least we know how much we're hammering different hosts, and maybe give it a limit, at the network layer)
<SteveA> (if there's something off-the-shelf for this, would be nice)
<ddaa> benefit: saner code, single entry point into libsvn, fixing memory leaks, removing bug in import functionality (used for tests)
<spiv> SteveA: (perhaps trickled?)
<ddaa> other planned benefit: good API use to reduce server load
<ddaa> like turning three session for every file change into a single query
<ddaa> and n such queries by session
<SteveA> I want feedback / review from someone here as to whether ddaa's work is in an appropriate direction for our mainline
<SteveA> considering the cost to change over, and to maintain this long term
<SteveA> any volunteers?
<ddaa> will upload shortly and put as work-in-progress on pendingreviews
<SteveA> existing familiarity with pyrex a bonus :-)
<poolie> ddaa: i know some of the libsvn bindings actually don't expose all the interesting functions
<poolie> is that a goal of this too?
<poolie> or can you reach all of them from one of the existing wrappers?
<ddaa> poolie: libsvn swig bindings are broken and crippled
<ddaa> the goal of the pyrex stuff is to be functional but strictly limited in scope to what cscvs needs
<jamesh> poolie: I think the aim is a specialised binding
<ddaa> the advantage is ability to talk to the C library directly
<ddaa> okay, moving on, now that everybody is aware of the stuff
<SteveA> well
<ddaa> note: it's just a personal experiment at this point
<SteveA> I'm still looking for a volunteer to look over what you've done
<ddaa> I do not see any.
<SteveA> _thumper_: interested?
<jamesh> I guess I can take a look at it -- I've done a bit of cscvs and Subversion stuff
<_thumper_> SteveA, could do, but no experience with pyrex or familiarity with the other libs
<jamesh> unless _thumper_ wants to
<_thumper_> but could give it a go
<ddaa> I think jamesh would be better for the time being
<_thumper_> jamesh: how about you a first on this, and I'll look over it too
<jamesh> _thumper_: sounds good
<ddaa> as _thumper_ is going to be away for a while soon
<SteveA> ok, thanks
<ddaa> okay, jamesh, you are volunteered :)
<ddaa> == Sprint report ==
<ddaa> _thumper_: care to do it?
<_thumper_> could do
<_thumper_> early in the week it was more getting familiarity with the moving parts
<_thumper_> around bazaar integration with launchpad
<_thumper_> big picture stuff#
<_thumper_> started looking at specs and branches
<_thumper_> a few small bug fixes were put up for review
<ddaa> (note: progress report on spec-branch is next agenda item)
<_thumper_> didn't get anything on to pqm last week, but should do over the next day or two
<_thumper_> it was good to get to meet SteveA and ddaa in person for a significant duration
<SteveA> _thumper_: feel free to submit a trivial "whitespace / docstring only" change to check pqm is working
<_thumper_> rather than just interview
<lifeless> _thumper_: update your branch 
<lifeless> _thumper_: your merge request is broken, you need to change the /home/warthogs/archives/ to /code/
<_thumper_> I'm more comfortable now with the general codebase and approach
<_thumper_> lifeless: ok
<_thumper_> that's pretty much it
<ddaa> so, it looks like the sprint was a success
<_thumper_> oh, one other thing
<_thumper_> created an informational spec for launchpad-bazaar called science fiction
<_thumper_> talked through with mark on the weekend and he liked it
<SteveA> nice
<_thumper_> others should read
<SteveA> URL please
<ddaa> https://features.launchpad.net/products/launchpad-bazaar/+spec/science-fiction
<_thumper_> beaten to it
<ddaa> Thank you.
<_thumper_> although mark suggested a menu item under Help (download this code)
<ddaa> The help menu is going to look like the lp action menu before we had facets
<ddaa> But let the ubuntu guys deal with the sanity of this.
<ddaa> == SpecBranch status ==
<ddaa> So, last week _thumper_ started implementing linking of specs and branches
<_thumper_> poolie suggested a text relation for a branch so could briefly say what the branch is for
<_thumper_> expecially when linking multiple branches to a spec
<_thumper_> has merit I think
<ddaa> Plain-text, good.
<ddaa> We can be more descriptive later when usage patterns emerge.
<_thumper_> so, database table done, pending update
<_thumper_> interface classes and content object done
<_thumper_> just some page stuff now
<_thumper_> my work for this week
<SteveA> tests?
<poolie> tim will be in sgp next week, and away on hiatus after that
<_thumper_> SteveA, yes we need tests
<_thumper_> back for work first Monday in Dec
<ddaa> lifeless: please indoctrinate thumper into TDD at the first opportunity :)
<SteveA> the tests may be written before the code.  I'm keen on seeing people try out writing page tests using testbrowser as acceptance tests of the whole UI
<SteveA> before the code is written
<SteveA> I think this may be feasible, and valuable
<ddaa> SteveA++
<_thumper_> agreed
<SteveA> but also, everyone should be familiar with the TDD finer-grained approach to modifying tests before writing code.
<jamesh> I just reported https://launchpad.net/products/launchpad-bazaar/+bug/66383 about catching Subversion URIs that probably cover more than one branch
<SteveA> cacheing?
<SteveA> or catching?
<jamesh> (from previous discussion)
<spiv> catching, I assume.
<jamesh> SteveA: catching
<ddaa> catching
<SteveA> thanks
<poolie> i'm writing a summary to the list
* ddaa will reply with reports of real-world bogosity
<SteveA> jamesh: very clear bug report.  thanks.
<poolie> should that bug be marked security-related?
<poolie> since there is potential for mischief
<SteveA> I guess.  We're offering the world the ability to DOS svn server
<SteveA> s
<ddaa> poolie: makes sense
<poolie> can end users add branch urls through the web site without canonical intervention?
<SteveA> certainly critical
<jamesh> poolie: yes
<poolie> jamesh: make it so! :)
<SteveA> poolie: as senior representative of the importd infrastructure, would you lead the diplomacy on this one?
<poolie> SteveA: yes
<SteveA> we've been rather rude to debian (in a technical sense), and because of that, and also because they're debian, they're due a nice response
* ddaa sighs
<SteveA> thanks poolie 
<poolie> yes, i know
<poolie> i think we should work out what happened and what we're going to do, and then tell them
<ddaa> == bzr-lp features ==
<ddaa>  * mpool: report on bzr-lp features
<ddaa> Redirection from .bzr below launchpad web page was cherrypicked in production. I think I saw jamesh blog about it, but did not update https://help.launchpad.net/BazaarLinks.
<ddaa> That means that efficient http redirect handling is no longer
<ddaa> needed for Launcphad.
<ddaa> poolie: talk about singapore now
<poolie> as we were supposed to do for account creation (but perhaps did not?)
<ddaa> meeting will brutally cut off in 5 mins for reviewers meeting
<poolie> tim, lifeless, stub, mbp, mark are meeting in sinagpore next week
<poolie> to plan bzr lp features
<poolie> if you have stuff you think is not getting the attention it should,
<poolie> tell me before friday
<poolie> ddaa: for example, you need to tell me more about cscvs if you want it to be on the agenda
<poolie> that's all, next
<ddaa> nothing essential left
<ddaa> jamesh: please update BazaarLinks when blogging
<jamesh> for what it is worth, serving branchreferences could could be used to prototype the lp:/// URI scheme
<ddaa> so people like me and SteveA can find your good stuff easily when asked
<ddaa> jamesh++
<ddaa> Meeting closed then.
<SteveA> this kind of linkage stuff could go on some bazaar homepage in launchpad too
<ddaa> Reviewers, have a break before your next meeting.
<SteveA> thanks for keeping the meeting on track ddaa
<jamesh> ddaa: added the link for my article and spiv's one too
<ddaa> jamesh: thank you
<SteveA> ddaa, poolie: ping
<poolie> still ehre
<ddaa> pong
<SteveA> ddaa: poolie and I were just talking about the "accidental DOS attack" thing
<ddaa> ultimately, we either manually review everything, or allow users to break stuff
<SteveA> I'd like it to be your top priority, fixing it and ensuring it can't happen again
<SteveA> even if this means creating a few OOPSes or database constraint violations for a while
<SteveA> I'd rather an import not work, or 20 imports not work
<ddaa> though we can certainly reduce the opportunity for mistakes...
<SteveA> than one upstream get hammered
<SteveA> I think poolie agrees here
<poolie> yes, i certainly do
<SteveA> so, what's the plan?
<poolie> i'm going to send mail now
<poolie> ddaa: please reply and correct it :-)
<poolie> and let's work out what we're going to do
<ddaa> naming conventions vary so wildly that I do not think we can do anything reliable
<poolie> ddaa: this is a fairly major problem, but we can also think of it as practice for more serious potential problems as we grow
<ddaa> we can narrow the window a bit with heuristics, and give a knob to allow JFDI with admin action...
<poolie> ddaa: JFDI on having some protection against this
<ddaa> some protection yes
<poolie> i'd like to, by the end of this week, be able to type those urls in, or something similar
<poolie> and have it not clobber the server
<poolie> do you think that's reasonable?
<ddaa> Should be fairly easy to stick a failsafe into the system. We just need to come up with a heuristic that is actually useful.
<ddaa> dunno, maybe something like "if it only contains dirs, or is at the top of the repo"
<poolie> ddaa: can you do a query to find out how many urls do or don't have /trunk/ in their url?
<poolie> i'd expect it's 99%
<jamesh> if cscvs finds a directory in the SVN branch that contains a "trunk" subdir and at least one of "branches", "releases" or "tags" then something is probably wrong
<ddaa> there are many projects out that that do
<ddaa> 'trunk/product'
<spiv> ddaa: but that's "ok"
<spiv> ddaa: in that the probable error there is grabbing too little, rather than far too much.,
<ddaa> where there can be dozens of products, kde for example does things like that
<spiv> So while the import of "trunk/product" might not be correct, it at least isn't going to be a DoS.
<jamesh> ddaa: I mean once we've accepted a SVN URI, check what's inside that tree.
<ddaa> I'm saying that what jamesh propose will not figure out that importing "trunk" is wrong.
<spiv> (incidentally, it's nice that this sort of problem just doesn't occur with bzr's model)
<jamesh> ddaa: the idea is to catch the case where we are probably importing too much
<ddaa> let's have this discussion on ML
<spiv> ddaa: Oh, I see what you're saying, I misunderstood you to be referring to "trunk/product" inside the URL given to us.
<ddaa> I'll do something, anything, this week, as it can be an improvement
<ddaa> can only be an improvement
<ddaa> but it's the sort of problem where there are completely wrong obvious solutions
<ddaa> so ML is better for discussing it
<poolie> ddaa: at least in that case we will only download all the products
<poolie> which might be wrong, but at least will be only about as much data as getting them individually
<ddaa> what I said about anything being an improvement
<ddaa> would you _really_ want to accept importing this: http://websvn.kde.org/trunk/
<ddaa> and it's only the most pathologic example I can come up with off hand
<ddaa> and there are cases where importing the whole repo is actually the correct thing and what the user really means
<poolie> ddaa: is importd down at the moment?
<ddaa> nope
<ddaa> but no worry
<poolie> is it going to keep pulling those branches?
<ddaa> nope
<poolie> why not?
<ddaa> they have testfailed, it takes explicit action to start them again
<poolie> and why did they testfail?
* ddaa tries to find the bogus imports again
<ddaa> not obvious, for example devscript import has not run recently
<ddaa> probably one of the various bugs that the new svn logic code is fixing
<poolie> ddaa, can you please, today, look through and make sure that anything which may be in this class is disabled?
<poolie> and also make sure that if someone tries to restart them it will not happen
<ddaa> poolie: of 273 productseries with svnrepository set, 212 have trunk in it
<ddaa> the only persons who has got the power to restart those imports are launchpad admins, lifeless and I.
<ddaa> there's no need to take further action, just need to remember _not_ to ever use the "start all imports that match a regexp" functionality in the buildbot ui.
<ddaa> and I'm the only one that's supposed to do this sort of shit anyway, because lifeless is way busy with other things
<lifeless> yup
<lifeless> I occasionally will run a single test
<lifeless> for an interested project, but thats all
<lifeless> and never put something into production, I consider ddaa authoritative for that
<ddaa> so, if shit happens again it's either because I was dumb, or because it's new user input.
<ddaa> or because a launchpad admin did something dumb
<ddaa> https://devpad.canonical.com/~andrew/paste/fileOMOl9z.html
<ddaa> poolie: ^ all svnrepos that do not have trunk in them
<ddaa> importstatus = 3: testfailed
<ddaa> imporstatus = 2: autotest (new user input, surprise, it's bogus! no way!)
<ddaa> importstatus = 6: in production
<ddaa> 2 of the 6 in production appears bogus in terms of not matching the intended use
<ddaa> https://svn.sourceforge.net/svnroot/comix was a case where checking the full repo is actually the correct thing to do
<ddaa> something to do with users not reading documentation and stuff like that
<jamesh> if people have a weird setup, requring an admin to approve a test isn't a bad thing
<ddaa> sure
<ddaa> anyway, in those cases I just ask (politely) "fix your repo, dumbass"
<ddaa> "you may actually have a use for branches one day. Yes branches in svn are just directories. No, you've got nowhere to put them until you fix the layout of your repo"
<ddaa> more politely of course
* ddaa -> lunch
<jamesh> ddaa: they don't need to fix the layout of their repo -- just get Launchpad to import their repo and start using Bazaar instead
<ddaa> I do not do combined sale
<ddaa> if people ask for x, I do not try to force feed them y
<ddaa> I guess I'll never make a career in sales
<ddaa> mh... devscripts is owned by registry
<ddaa> legacy from the oh-so-good-idea imports death march
<_thumper_> ping ddaa
<ddaa> _thumper_: pong
<_thumper_> ./tests.py lib pagetests.branches doesn't run any tests
<_thumper_> I get Total: 0 tests, ...
<ddaa> mh
<_thumper_> wtf?
<_thumper_> do I need some pre-test make step?
<ddaa> https://launchpad.canonical.com/LaunchpadHackingFAQ#head-b454516710233a7eee2eb4b44d7bc6e4a97e04a3
<ddaa> i think there are two issues there
<ddaa> one is that you said "lib" instead of "canonical"
<ddaa> lib is not a python module
<_thumper_> I was just doing what the README said
<ddaa> the other is that pagetests are a bit spethial
<ddaa> well, try doing what the wiki says and fix the readme...
<ddaa> in-tree documentation tends to be even more outdated than wiki pages
<_thumper_> ta
<ddaa> I think this readme was not updated since we went to zope 3.2 (if that's what we're using now)
<ddaa> during some zope upgrade the test.py usage changed in subtle ways
<jamesh> _thumper_: re running page tests: the incantation I use is "./test.py -vv --test=pagetests/branches"
<jamesh> _thumper_: I've got a branch that actually updates the pagetests/README.txt too ...
<_thumper_> jamesh: thanks
<_thumper_> does yours have a problem tearing down the db layer?
<jamesh> haven't noticed a problem like that recently
<_thumper_> hmm...
<_thumper_> I've just been pleasently surprised by gnupg-agent
<_thumper_> the only thing needed was to uncomment the # use-agent part of gpg.conf
<jamesh> just use gnome-gpg :)
<_thumper_> nah, kde person
<jamesh> we'll have to fix that ...
<_thumper_> I'm allergic to gnomes
<_thumper_> gives me hives
#launchpad-meeting 2008-10-13
<mrevell> hi
#launchpad-meeting 2008-10-14
<barry> #startmeeting
<MootBot> Meeting started at 21:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello and welcome to this week's asiapac reviewer's meeting.  who's here today?
<barry> jml, mwhudson, thumper ping
<jml> barry: hi!
<mwhudson> wow
<barry> hi!
<barry> mwhudson: yeah ;)
<jml> barry: you've caught mwhudson and I in the middle of QA.
<jml> barry: but let's do the dance.
<barry> jml: i'm sure it'll be short
<jml> :)
<barry> i have no new agenda items, and nothing that interesting for action items or queue status
<barry> so let me just ask you guys how things are going :)
<mwhudson> ok i guess
<jml> things are going pretty good.
<mwhudson> i'm still hardly reviewing any !code branches
<jml> one thing that's worth talking about is meeting time.
<barry> mwhudson: yeah, do you have any ideas about what we can do about that?
<jml> (because DST is hitting us and leaving you)
<barry> jml: i'm open to changing the time
<jml> barry: you should move to Australia.
<barry> jml: we'll see nov 4th
<jml> barry: that would solve the !code problem :)
<barry> btw, we leave dst on 2-nov
<mwhudson> barry: dunno, i'll be overlapping more with the us people as the dst things happen
<jml> *nod*
<jml> barry: meeting time is whatever is better for you.
<jml> barry: it's 3pm in NZ right now and 1pm here, so there's a lot of leeway for an earlier meeting.
<mwhudson> so i guess i could/should make sure that i get involved with reviews on, say, thursday mornings
<barry> 10pm local time is not too bad, but i haven't worked out what that will be for you after the clock dance
<barry> so after 2-nov i'll be utc-5, what will you be?
<jml> UTC+11 and UTC+13
<mwhudson> same as now
<jml> same as now
 * jml adds uselessly
<barry> lol
<barry> so it means that after 2-nov we'll be meeting nz 4pm and jml 2pm? or do i have that backward ;)
<mwhudson> that's right
<mwhudson> er
<mwhudson> no
<mwhudson> ah heck, too hard for me
 * barry has brain hurty
<jml> barry: http://timeanddate.com/worldclock/meetingtime.html?month=11&day=12&year=2008&p1=263&p2=264&p3=240&p4=-1&iv=0
<mwhudson> thanks jml :)
<barry> jml: yeah, thanks! :)
<barry> utc 0300 would probably work for me
<mwhudson> fine with me
<jml> Fine by me too.
<barry> [AGREED] after 2-nov we'll switch to 0300 utc
<MootBot> AGREED received:  after 2-nov we'll switch to 0300 utc
<barry> mwhudson: let's brainstorm about getting you !code reviews at epic
 * jml too
<mwhudson> barry: ok
<jml> barry: the issue also goes in the other direction.
<barry> jml: right, on both oints
<barry> points even
<jml> cool.
<barry> cool.
<jml> that's it from me.
<barry> mwhudson: anything?
<jml> oh, there is an awesome branch that improves the code review ui, but it failed to land for 2.1.10.
<barry> jml: :(
<jml> keep watching edge though.
<barry> jml: that's all i watch :)
<jml> :)
<barry> my email-any-user branch failed to land (3 times i might add)
<jml> :(
<mwhudson> my bzr merges kept disappearing!
<barry> jml: watch edge! :)
<jml> barry: this failure was entirely due to the branch being so big that the conflicts became unmanageable.
<mwhudson> (i guess i should chase that with the losas...()
 * barry sighs
<barry> well, i guess that's it
<barry> #endmeeting
<MootBot> Meeting finished at 21:16.
<jml> barry: cool. thanks.
<barry> thanks guys and i'll see you in a few days
<jml> barry: I look forward to it :)
<barry> mao!
<mwhudson> see you soon!
<jml> I had forgotten about mao
<thumper> crap
<thumper> DST
<mwhudson> hi thumper
#launchpad-meeting 2008-10-15
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everybody and welcome to this week's reviewers meeting.  who's here today?
<intellectronica> me
<bigjools> me
<gmb> me
<sinzui> me
<allenap> me
<bac> me
<salgado> me
<flacoste> me
<cprov> me
<EdwinGrubbs> me
<barry> BjornT_ danilos ping
<danilos> me
<danilos> (I have my reminder set for an hour earlier, and then always miss out the real beginning; with DST soon to be off, I should be a regular :))
<barry> mars: rockstar ping
<BjornT_> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * If there's time, the old boring script
<barry>    * Next meeting
<barry>      * f2f at epic?
<barry>    * Action items
<barry>    * Queue status
<barry>    * Mentoring update
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<danilos> corner of Kings Cross and...
<barry> since we'll all be in london the next two weeks, i propose we suspend the irc meetings and try to find a time to meet f2f
<danilos> +1
<bigjools> danilos: are you planning on kerb crawling then? :)
<barry> we can talk about things to make the meetings better, improve pollination w/asiapac, ways to improve review process, etc
<abentley> barry: +1
<gmb> +1
<intellectronica> +1
<sinzui> +1
<gmb> bigjools: Either that or he'll be getting mugged, depending on whom he encounters first.
<bigjools> gmb: the pimp or the ho
<barry> ouch
<barry> :)
<danilos> gmb: I am going for an attempted robbery, i.e. someone should try to rob me :)
<gmb> bigjools: Mind you, danilos  is a big fella, he should be safe.
<gmb> Hah.
<gmb> danilos: My point exactly ;)
<barry> [AGREED] suspend next two weeks irc in favor of f2f in london
<MootBot> AGREED received:  suspend next two weeks irc in favor of f2f in london
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * flacoste and foundations to look into techniques for eliminating back-patching of schema types (avoiding circular imports)
<flacoste> carry over
<barry> done
<barry>  * barry will move the preimp discussion to the ml
<barry> i suck and propose we just any related issues over at epic
<barry>  * flacoste to take discussion of rest v. moin to ml
<barry> flacoste: any word on gary's experiment?
<intellectronica> when you push things to the epic, it's probably a good idea to try and actually schedule it. from what i saw there's a pretty dense plan
<flacoste> gary is progressing
<flacoste> he should be finished today
<barry> intellectronica: good oint
<flacoste> and we will send an email to the list then
<barry> flacoste: excellent, thanks
<barry> [ACTION] barry will schedule reveiwers meeting at epic
<MootBot> ACTION received:  barry will schedule reveiwers meeting at epic
<barry>  * rockstar to take discussion of adding launchpadlib tests for exposed api to ml
 * barry pokes rockstar
<intellectronica> fwiw i just got another bug in today which only happens with lplib and which tests like this would have caught ;)
<barry> oh well, let's move on then ;)
<barry>  * abentley to investigate current code coverage tools for lp tests
<abentley> I looked at the existing stuff, and it seems like the opposite of what I want.
<abentley> I want to know if the tests run by a test command exercise all new code.
<abentley> The existing work is about determining which tests exercise a given line of code.
<danilos> abentley: at what granularity?
<danilos> abentley: so, method or line of code for the opposite direction as well?
<abentley> danilos: Ideally, just yes/no granularity.  Either the changes are properly tested or they're not.
<abentley> So the obvious implementation is: run the tests with coverage calculation, determine which lines are new, make sure they're covered.
<barry> abentley: tho iwbn to know which lines /aren't/ covered
<abentley> barry: Sure.
<barry> abentley: any thoughts on putting something like this together?
<abentley> barry: You mean, am I willing to do it?
<barry> abentley: jfdi, man!
<abentley> barry: I guess I could hack on it on review day.
<BjornT_> abentley: in what way does --coverage do the opposite of you want? it seems to tell you which lines are tested, and which aren't. that should be the first step in what you want, isn't it?
<abentley> BjornT_: I'm not saying --coverage does.
<BjornT_> abentley: oh. you said the existing tools did the opposite. i assumed you meant --coverage.
<abentley> BjornT_: I was talking about launchpad-specific work that someone did that I was pointed at last week.
<BjornT_> ah, right
<barry> abentley: well if you have time, i think it would be a useful tool
<barry> anyway, that's all i have for today.  does anybody have topics not on the agenda?
<abentley> BjornT_: https://launchpad.canonical.com/TestsFromChanges
<barry> okay then, thanks everyone and see you next time in london!
<barry> #endmeeting
<MootBot> Meeting finished at 09:27.
<bigjools> see y'all in The Smoke
<jml> hi
<mwhudson> barry isn't here :)
#launchpad-meeting 2008-10-16
<danilos> me
<matsubara> #startmeeting
<MootBot> Meeting started at 10:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<sinzui> me
<matsubara> who's here today?
<stub> yo
<danilos> me
<flacoste> me
<matsubara> bigjools, intellectronica, rockstar, Ursinha ?
<bigjools> meeeee
<Ursinha> me
<matsubara> hmm I think rockstar is flying to London, isn't he?
<flacoste> yep
<matsubara> ok, let's move on without Code and Bugs
<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>  * QA Stats of the week
<matsubara> [topic] next meeting
<MootBot> New Topic:  next meeting
<matsubara> so, no meeting next week?
<Ursinha> matsubara, will be live!
<danilos> or live meeting?
<mpt> We'll do it live!
<bigjools> oh man
<bigjools> our secret identities will be blown
<matsubara> forgot the LOSA
<stub> You mean I have to wear pants??
<matsubara> herb: around?
<herb> me
<Ursinha> lol
<danilos> stub: that's never been necessary for live meetings
<matsubara> ok, will any of the LOSAs attending the Epic?
 * sinzui will still be in his jim-jams
<danilos> matsubara: I don't think the timezone suits them :)
<herb> matsubara: I don't think so, no.
<danilos> herb: really?
<herb> danilos: I know I'm not.
<matsubara> ok, we can have the meeting there then and ask one of the LOSAs to join us
<herb> I'm fairly certain spm isn't.  That only leaves mthaddon and he hasn't mentioned anything to me about it.
<matsubara> i guess he's not going by his reply to mwhudson_ climbing email
<flacoste> mthaddon isn't coming
<flacoste> matsubara: right
<matsubara> we'll sort it out there and let you know herb
<matsubara> [topic] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> * Ursinha to keep an eye on OOPSes regarding bug 277129, to confirm that the bug is really fixed.
<ubottu> Launchpad bug 277129 in launchpad-foundations "OOPS when attempting to render a timeout page" [High,Fix committed] https://launchpad.net/bugs/277129
<flacoste> actually
<flacoste> that fix was only deployed to staging
<Ursinha> yes
<flacoste> so that watch was meaningless
<Ursinha> yes again
<flacoste> i can say now that it is fix
<flacoste> fixed
<flacoste> but that we have a fall-out for it :-)
<flacoste> the DoomedTransaction OOPS you saw this morning
<matsubara> the other two items are for intellectronica
<flacoste> and that gary is working on
<matsubara> and another item for me, which i did (matsubara to find or file a new bug for the core dump issue and add info discussed today there, subscribe niemeyer, kiko and someone from ubuntu
<matsubara> )
<matsubara> thanks flacoste
<flacoste> good progress has been made on that one
<flacoste> it was in reviewed last time i checked
<matsubara> great
<matsubara> I guess I'm not receiving notifications for it
<matsubara> maybe I forgot to subscribe myself
<matsubara> anyway, moving on
<flacoste> i,m not sure there was progress report on the bug
<matsubara> flacoste: hmm, I'll update it after the meeting then.
<matsubara> [action] matsubara update core dump bug with progress made last week
<MootBot> ACTION received:  matsubara update core dump bug with progress made last week
<matsubara> thanks
<matsubara> [topic] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<herb> flacoste, matsubara what was the bug number for that so I can subscribe myself?
<matsubara> Ursinha: floor is yours
<matsubara> herb: let me look
<Ursinha> okay
<Ursinha> 7 bugs, not sure if it'll be pointless but will list all them anyway
<Ursinha> 3 for foundations: bug 284458, 284418, 284403
<ubottu> Launchpad bug 284458 in launchpad-foundations "API NotFoundErrors should be converted to NotFound" [Undecided,New] https://launchpad.net/bugs/284458
<ubottu> Launchpad bug 284418 in launchpad-foundations "oops reports not displaying the whole traceback" [High,Triaged] https://launchpad.net/bugs/284418
<ubottu> Launchpad bug 284403 in launchpad-foundations "DoomedTransaction OOPS in +specworkload page" [High,Triaged] https://launchpad.net/bugs/284403
<Ursinha> 1 for shipit: 284448, salgado already told that it's only caused when users handcraft URLs, need to set priority on it
<Ursinha> 1 for translations: 284429
<Ursinha> 1 for soyuz: 264319
<Ursinha> oops
<Ursinha> bug 284448
<ubottu> Launchpad bug 284448 in shipit "Custom 404 page for shipit" [Undecided,New] https://launchpad.net/bugs/284448
<Ursinha> bug 284429
<ubottu> Launchpad bug 284429 in rosetta "NotOneError raised while uploading a translation file" [Undecided,New] https://launchpad.net/bugs/284429
<Ursinha> bug 264319
<ubottu> Launchpad bug 264319 in soyuz "Broken link in breadcrumbs for source packages" [High,Triaged] https://launchpad.net/bugs/264319
<Ursinha> 1 for bugs: bug 186262
<ubottu> Launchpad bug 186262 in malone "+filebug pages time out" [High,Confirmed] https://launchpad.net/bugs/186262
<bigjools> I'll take 264319
<matsubara> flacoste: can you comment on 284458?
<Ursinha> bigjools, thanks
<danilos> Ursinha: we'll look into 284429
<matsubara> the other two from foundations are being diagnosed/addressed already
<Ursinha> danilos, thanks
<flacoste> matsubara: that's a bug for SOyuz
<danilos> Ursinha: jtv was looking at it just before he left
<flacoste> it's not API code
<flacoste> it's soyuz code invoked through the API
<bigjools> flacoste: is it just a case of returning a different exception?
<flacoste> yep
<flacoste> bigjools: NotFound
<bigjools> ok, easy
<matsubara> flacoste: right, I thought the NotFoundError was a generic thing
<bigjools> I got that one too Ursinha
<flacoste> not in this case
<matsubara> all right, thanks flacoste
<Ursinha> bigjools, ok, I'll take not
<Ursinha> bigjools, do you want me to assign it to you?
<bigjools> Ursinha: I'll do it right now when I target it
<flacoste> 284418 is something to fix when we deploy
<flacoste> i assigned it to canonical-losas
<Ursinha> bigjools, ok, thanks
<flacoste> i think Tom is the one who would fix it
<matsubara> herb: bug 95822
<ubottu> Launchpad bug 95822 in apport "Malone  connection generates an "Internal Server Error" on large file attachments" [Medium,Confirmed] https://launchpad.net/bugs/95822
<herb> matsubara: thanks.
<flacoste> (we need to remove the .pyc after renaming the directory and before starting the app server)
<flacoste> gary is handling 284403
<flacoste> and that's the fall-out from the fix to the timeout-related exception
<matsubara> I guess that's all Ursinha ?
<Ursinha> salgado, what about bug 284448?
<ubottu> Launchpad bug 284448 in shipit "Custom 404 page for shipit" [Undecided,Triaged] https://launchpad.net/bugs/284448
<sinzui> I'm not certain about the priority
<matsubara> Ursinha: salgado already said it's low priority and he's not supposed to attend this meeting :-)
<Ursinha> matsubara, old habit :) I'll set the bug to low
<Ursinha> sinzui, why?
<sinzui> It interferes with bookmarks. We should be redirecting in the example given.
<sinzui> The 404 page is needed, but the users who have used shipit.edubuntu should know they can access their information at shipit.ubuntu
<Ursinha> sinzui, can you set the proper priority on that, please?
<sinzui> I'm not certain how many users the problem really affect to know whether we should be redirecting
<sinzui> Ursinha: I think seeing the frequency of oopses help me to know the priority
<Ursinha> sinzui, so we should keep it low and see if it happens more often?
<matsubara> Ursinha: bring it up again if the OOPS count for that one increases too much
<Ursinha> ok, I'll feed the bug with more oopses if they happen
<Ursinha> and bring it here
<Ursinha> there's only the bugs' bug left
<sinzui> Ursinha: I would definitely make it high if this happens almost every day...but I think in this case the problem is that the user need to get to shipit.ubuntu
<matsubara> sinzui: so far we had like 3 OOPSes, so doesn't seem to happen often
<matsubara> intellectronica: around?
<Ursinha> intellectronica, bug 186262
<intellectronica> matsubara: yes
<Ursinha> intellectronica, hi :)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/186262/+text)
<Ursinha> oh my
<Ursinha> intellectronica, https://launchpad.net/bugs/186262
<ubottu> Launchpad bug 186262 in malone "+filebug pages time out" [High,Confirmed]
<intellectronica> ouch
<intellectronica> wow, this is quite old, is it a comeback?
<matsubara> intellectronica: yeah, looks like. mthaddon tried to file a bug recently and got a timeout
<sinzui> Is it really High if the bug is old?
<Ursinha> intellectronica, yes, it seems
<Ursinha> I've seen it lately
<Ursinha> the oopses, that is
<intellectronica> Ursinha: ok, assigning to myself and will investigate
<mthaddon> matsubara, I know someone else got it recently too (a non-canonical employee)
<Ursinha> intellectronica, ok, thanks
<Ursinha> nothing else from me, then
<intellectronica> Ursinha: is this something that happens consistently?
<Ursinha> intellectronica, I was able to reproduce
<matsubara> intellectronica: yes, depending on what you use as the bug summary
<intellectronica> anyway, we can discuss later
<matsubara> and it's workaroundable
<matsubara> so, I guess that's why people are not complaining so loudly :-)
<matsubara> thanks for taking it intellectronica
<matsubara> we have only 1 critical bug which is fix committed
<Ursinha> no critical bugs, also, besides one fix committed
<matsubara> actually should be fix released by now
<Ursinha> thanks guys, you can move on matsubara
<matsubara> thanks everyone
<matsubara> [topic] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> * Monday (2008-10-13): Did a cherry pick to lpnet* to update the shipit pages for intrepid.
<herb> * Last night (2008-10-16): Rolled out 2.1.10
<herb> * Over the last week we've had to restart codebrowse 7 times because it was unresponsive.
<matsubara> very well executed rollout, btw. Congrats! 21 min downtime only
<herb> I'll look into whether or not there are any bugs filed for the codebrowse issue.  if not I'll take care of that after the meething.
<matsubara> [action] herb to find or file a bug about codebrowse being unresponsive and needing restarts
<MootBot> ACTION received:  herb to find or file a bug about codebrowse being unresponsive and needing restarts
<herb> matsubara: lifeless and mthaddon worked out a change in procedure.  really seemed to help
<mthaddon> we've actually had a 21 minutes rollout before (1.2.4), but I definitely agree the new rollout method is much better and quicker)
<matsubara> herb: indeed. the only downside is that oops reports are less informative now, but flacoste will email you guys about it
<flacoste> that's done
<matsubara> cool
<matsubara> anything else for herb?
<flacoste> are we having a re-roll?
<herb> I haven't heard anything about that.
<herb> doesn't mean we aren't
<flacoste> matsubara, Ursinha?
<flacoste> what's your feeling?
<flacoste> personnally, candidate for it would only be for the DoomedTransaction problem
<mthaddon> OOPS reports less informative?
<matsubara> flacoste: it'd be nice to have the oops thing fixed and I guess we don't need to re-roll for that, right?
<flacoste> matsubara: just restart
<mthaddon> is this because we make build in another directory, or unrelated?
<matsubara> the other issues so far don't look that critical
<flacoste> mthaddon: it is, i sent you an email about it
<matsubara> in any case we'll be checking the oops summaries the whole day, and if anything comes up, we'll let you know
<flacoste> DoomedTransaction problem is the ghost of the old timeout problem
<flacoste> so would happen as often as it
<mthaddon> flacoste, ok, see the email here
<flacoste> we could cherry-pick the fix
<flacoste> or re-roll
<Ursinha> flacoste, well, so far I guess that only a CP would be enough
<flacoste> since we are still in r-c
<flacoste> mode
<flacoste> i think it's easier for the LOSA to do a re-roll than a CP
<flacoste> mthaddon, herb: is that right?
<sinzui> flacoste: the old timeout problem as in bug #244957?
<ubottu> Bug 244957 on http://launchpad.net/bugs/244957 is private
<herb> it's easier on pqm. :)
<herb> if we re-roll we don't need to run the test suite on the release+patch.
<flacoste> matsubara: no as in bug 277129
<ubottu> Launchpad bug 277129 in launchpad-foundations "OOPS when attempting to render a timeout page" [High,Fix committed] https://launchpad.net/bugs/277129
<matsubara> sinzui: ^
<flacoste> herb, mthaddon: what time would be good for a re-roll today?
<mthaddon> flacoste, any time is fine - re-roll to where?
<flacoste> app-servers
<mthaddon> flacoste, yeah, anytime is fine
<stub> After the fix exists might be best though
<flacoste> :-)
<mthaddon> flacoste, sooner the better, but really no difference
<mthaddon> and what he said :)
<flacoste> so unless anything else comes up, we can target a re-roll after gary's land his fix
<matsubara> deal
<flacoste> which should happen later this afternoon
<matsubara> so, anything else for LOSAs?
<matsubara> thanks herb, mthaddon
<matsubara> moving on
<matsubara> [topic] * DBA report (DBA contact)
<MootBot> New Topic:  * DBA report (DBA contact)
<stub> Load on the db seems to have decreased a little after the rollout, although it is too early to tell for sure. Hopefully this is a sign of good work and not broken systems :)
<stub> The replicated staging db rebuild work has been done and awaiting review. I don't see any problems getting this landed and switched on Monday, time in London permitting.
<stub> Also in London, we need to find time with Mark to discuss some of the db design that was bounced this cycle (bzr Job system, milestone/productrelease linking).
<stub> fini.
<matsubara> all right. any questions for stub?
<danilos> what are you wearing?
<danilos> uhm, wrong channel
<danilos> ;)
<matsubara> heh
<matsubara> thanks stub
<matsubara> [topic] * QA Stats of the week
<MootBot> New Topic:  * QA Stats of the week
<Ursinha> :)
<matsubara> so this is a new section, and I have no stats for this week
<matsubara> but the idea is to bring up some number about triage and needstesting items from the current week and last week
<matsubara> kinda show how we're progressing during the cycle
<matsubara> what you guys think? keep, bag, change?
<danilos> sounds nice, not sure how you are going to present it live :)
<danilos> maybe using a drawing board?
<Ursinha> danilos, never heard of ascii-art? :)
<matsubara> that's all from me.
<danilos> Ursinha: ascii-art is going to be a long stretch during Epic, though I'd like to see him try :)
<matsubara> danilos: I'll come up with a way :-)
<matsubara> or probably postpone it to the next IRC meeting :-)
<danilos> ok, thanks
<matsubara> ok, anything else before I close?
<Ursinha> not from me
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:44.
<danilos> thank you as well, bye bye :)
<matsubara> just in time
#launchpad-meeting 2008-10-17
<flacoste> ok, i got my test running...
<flacoste> this was a really silly error :-(
<mwhudson> flacoste: ??
<mwhudson> mischan?
<flacoste> yes :-)
#launchpad-meeting 2009-10-14
<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.  who's here today?
<allenap> me
<noodles775> me
<EdwinGrubbs> me
<gmb> me
<intellectronica> me
<bac> me
<barry> gary_poster leonardr bigjools salgado sinzui BjornT  ping
<sinzui> me
<salgado> me
<gary_poster> me and hiya
 * sinzui is still having problems with that cat
<leonardr> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Action items
<barry>  * UI review call update
<barry>  * ''Adding a check for pop-up help to reviews [mrevell]''
<barry>  * Test dependencies in setup.py [gary]
<barry>  * "Have you added pop-up help? If not, why not?" [mrevell, barry]
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry> [TOPIC] * Action items
<MootBot> New Topic:  * Action items
<barry>  * barry to get with mrevell on guidelines migration from old wiki to new
<adeuring> me
<barry> i have not done that, but i've pinged mrevell-lunch about it so maybe we'll actually chat about it today ;)
<barry>  * intellectronica and barry to draft guidelines for drive-by cleanups
<barry> also not done, but i have a little more information
<barry> so i've been trying to use bzr-pipelines, which seem pretty cool (in a similar way as looms, but better).  i do think they can help with drive-bys
<barry> but they aren't a perfect solution, mostly because diff'ing sometimes gets things wrong-ish
<barry> or at least not quite what you want
<barry> i was working on a branch, then realized i had some drive byes i should get independently reviewed
<barry> i created a lower pipe and merge -i 'd the changes into that branch
<barry> then i got the main branch reviewed and ask for a look at the drive byes in the same mp
<barry> this seemed to work well, except...
<barry> sometimes chunks produced by merge -i contained both drive by and substantive differences
<barry> in that case i just left them in the main branch
<barry> EOT.  any thoughts, comments?
<gary_poster> +1 on pipeline
<barry> gary_poster: have you used them?
<gary_poster> +1 on getting the pipeline tweaked for what we need
<abentley> Oh, that was an unfortunate time to walk in.  Guess I'll read the notes.
<barry> abentley: hi.  i was just relating my experience with pipelines wrt drive-byes
<gary_poster> I've read about them.  I've used looms.  pipelines look good.  I like abentley. ;-)
<barry> :-D
<barry> abentley: out of context, but... <barry> sometimes chunks produced by merge -i contained both drive by and
<barry>         substantive differences
<barry> abentley: i don't know what if anything can be done about that
<abentley> merge -i into something already containing the drive-bys?
<barry> abentley: no, sorry.  merging into a new pipe
<barry> abentley: i'll try to post this to the mailing list, it's fine to respond there instead
<abentley> barry: So this is just wanting better than per-hunk granularity.  I have a branch for that.
<barry> abentley: oh!  yes, and once again, you rock
<gary_poster> see? :-)
<barry> :-D
<barry> abentley: thanks.  let's move on then...
<barry>  * ''Adding a check for pop-up help to reviews [mrevell]''
<barry> mrevell-lunch: are you around?
<barry> i guess not
<barry> anyway, my understanding of this is that mrevell-lunch wants us to ask about adding pop-up help when reviewing a branch
<barry> he says it's easy to add
<barry> i'll leave this on the agenda for now though in case he wants to say more
<barry>  * Test dependencies in setup.py [gary]
<barry> gary_poster: you're up
<gary_poster> I sent an email Oct 8 about "test what you fly, fly what you test".  The subject was "Including test dependencies in our package releases," sent to the launchpad-dev list.  It only started getting replies yesterday (thanks barry!).
<gary_poster> I won't repeat it here unless someone requests it.  It would be nice to have a consensus that what I proposed is our expected/desired approach for our standalone libraries.
<gary_poster> I'm hopeful it is not contentious, since the only concrete reply was Barry's, which seemed to agree with me.  Maybe we can agree now, or maybe we can give the email another week for replies, and then declare it policy.
<gary_poster> Thoughts?
 * barry only thought is that gary_poster types fast
<gary_poster> :-)
<abentley> gary_poster: In the absence of a recognized test-dependencies concept, I'm all for it.
<barry> me too
<gary_poster> abentley, we can do that.  setuptools and/or distutils has that support.  So perhaps there's room for contention afterall.
<gary_poster> after all
<sinzui> In my latest release for another project, is did this because the user are willing to provide good debugging information if you remove the barriers
<jml> +1 to more contention.
<gary_poster> heh
 * jml relurks
<sinzui> s/is/I/
<abentley> gary_poster: So, it worries me that we might depend on something without having deliberately chosen to.
<abentley> gary_poster: But it's more of a theoretical thing.
<gary_poster> abentley: "we" the user of the library, or "we" the creator of the library?  Not quite sure I understand
<abentley> gary_poster: We the user of the library.
<sinzui> gary_poster: I think the problem here is the dependency can be large, or complex. In my case, I  had to use fakes to make the test deps portable. I do not think we want to do this. (but man, is the test fast!)
<abentley> gary_poster: For example, I'd be scared if Mocker was a real dependency of Launchpad.
<abentley> gary_poster: But if it was a test dependency, that would be fine.
<barry> abentley: how would that work in practical terms?  when would the dependencies get pulled in?
<gary_poster> abentley: I can understand that from a theoretical perspective.  From a practical perspective, if we regard automated tests as our primary tool for quality (as opposed to, say, manual QA) then I don't see a way around it
<gary_poster> that is
<gary_poster> I don't see a reasonable way to guarantee that Mocker is a test dependency and not a "real" dependency
<abentley> barry: Sorry, I didn't even know setuptools supported test dependecies.  I certainly don't know how they work.
<gary_poster> You said "But it's more of a theoretical thing," so does that mean we are on at least similar pages?
<abentley> gary_poster: Yes, it's more of a niggle than a real concern.
<gary_poster> cool
<gary_poster> and understood
<barry> gary_poster, abentley thanks.  for now, i think we're agreed including the test dependency (in the usual case) is about the best we can do
<gary_poster> cool
<barry> mrevell: is !away.  mrevell do you want to have a word about pop-up help?
<mrevell> Hi barry, sorry I had to run out. Yes, I'd love to please if that's okay.
<mrevell> My apologies.
<barry> mrevell: no worries, and the floor is yours
<mrevell> I'd like to propose that a check for in-line help be added to code reviews. Maybe it should be ui reviews.
<mrevell> I think that when we add a new
<mrevell> feature/page we should consider whether everything on that page is self-evident to our less-experienced users.
<mrevell> If not, we should consider adding in-line help using the pop-up system. I'd be more than happy to write that help or review any help.
<mrevell> Any thoughts?
<barry> mrevell: +1
<mrevell> Great :) Heh.
<barry> mrevell: i had a review last week (maybe bac's branch?) where i asked for a popup help.  mrevell tell them how easy it is to add such help <wink>
<mrevell> barry: Ah yes, it is very easy indeed.
<mrevell> All you have to do is add an HTML file in the right place (there's a template and there are instructions at
<mrevell> https://dev.launchpad.net/PopUpHelp)
<mrevell> and then place a link in your page with a target of "help"
<mrevell> that automatically brings in the JS to create the pop-up and call in your help page in that pop-up.
<mrevell> So, I'd like to say that I see this as a real priority for my time so if you need my help or review or whatever when producing pop-up help, please do ask me.
<sinzui> I have used this. It is very easy to create help
<mrevell> Or suggest that the person whose branch you're reviewing contact me.
<barry> mrevell: how would you like to flesh out https://dev.launchpad.net/DeveloperDocumentation/UserInterfaceChecklist which is linked off of https://dev.launchpad.net/StyleGuides but empty?
<mrevell> barry: I'll do that! Thanks very much everyone.
<barry> mrevell: thanks!
<barry> [ACTION] mrevell to flesh out UserInterfaceChecklist
<MootBot> ACTION received:  mrevell to flesh out UserInterfaceChecklist
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<barry> that's all i have for today.  do you have anything on your mind?
<abentley> Does anyone else find they're creating a lot of HTML fragment URLs?
<intellectronica> yeah
<intellectronica> well, i did in the past, but there's plans for more of them
<abentley> I think it would be nice if we could retrieve particular IDs as HTML, or maybe address views directly.
<abentley> By particular ids, I mean HTML IDs.
<intellectronica> abentley: what do you mean by 'retrieve particular IDs'?
<noodles775> mrevell: there might be some overlap between that UI checklist page above and https://dev.launchpad.net/UI/Reviews
<intellectronica> ah, you mean addressing an element within a page on the server?
<abentley> So where you have <body><p id='lobster>I am a lobster</p></body>, you could retrieve just the lobster.
<intellectronica> abentley: how will you use that?
<barry> noodles775, abentley maybe that link should just be updated?
<intellectronica> in all the cases i've used fragments it was to load separately complex pages. rendering the entire page for each fragment would not work for me
<noodles775> barry, mrevell - yep.
<abentley> intellectronica: There's a page that displays a comment, but I need the comment's HTML fragment, so I'd retrieve just that.
<intellectronica> abentley: surely, rendering all the comments just to get one of them doesn't make much sense
<intellectronica> or are you suggesting somehow only rendering the requested fragment?
<abentley> intellectronica: Right, but as I said, there's a page that displays a comment, not all of them.
<intellectronica> abentley: also, for this particular use case, you should use the api
<intellectronica> ah right, missed that
<intellectronica> abentley: have you seen how it's done for bug comments?
<intellectronica> b.t.w this isn't really a reviews-related topic, is it?
<abentley> intellectronica: Yes, and that approach was the first thing I tried.
<intellectronica> abentley: i remember from the list thread that you didn't like having to have a retrieve operation subsequent to posting, but assuming that's fixed, why not continue with this approach?
<abentley> intellectronica: The approach I'm continuing with is retrieving an HTML fragment.
<abentley> intellectronica: So I have to create a URL for the fragment to live at.
<intellectronica> abentley: but why are you using that approach? ideally we should do things the same way across LP
<abentley> intellectronica: I'
<abentley> intellectronica: I'm using that approach because it works, and the bugs approach did not.
<barry> abentley, intellectronica i do think we're leaving the realm of reviewer topics, so let's continue this on-list
<abentley> barry: Okay.
<mrevell> noodles775: Did you just kill the UIChecklist page?
<intellectronica> abentley: what didn't work about it? maybe we should aim at fixing whatever that was rather than create another way of doing things?
<intellectronica> barry: yeah, sorry
<abentley> intellectronica: This is hardly another way of doing things.
<barry> no worries
<barry> do we have any other topics for today?
<noodles775> mrevell: nope? didn't touch it... just pointed out that https://dev.launchpad.net/UI/Reviews has lots of this info. barry said earlier that the other page was empty?
<mrevell> noodles775: Ah, yeah, it seems to be.
<mrevell> I'll pop in a redirect
<barry> okay, i think we're done
<barry> #endmeeting
<MootBot> Meeting finished at 09:40.
<barry> thanks everybody!
<intellectronica> thanks barry
<mwhudson> hi
<barry> #startmeeting
<rockstar> ni!
<MootBot> Meeting started at 16:01. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi!
<barry> how are things going today?
<rockstar> Good.
<mwhudson> yes, not bad so far
<barry> i've been playing with pipelines a lot lately
<barry> they seem very cool, once i sorta wrapped my head around lightweight checkouts
<rockstar> barry, awesome.  abentley and I have talked a few times about how to make them better with launchpad.  Ideas are welcome.
<barry> rockstar: very cool.  i'm working on some notes and i've filed one bug so far
<barry> the python2.5/2.6 sprint is going well.  we're making lots of progress.  i think we might actually finish 2.5 migration this week
<barry> which would give us all next week to do 2.6
<mwhudson> barry: _awesome_
<barry> mwhudson: yeah.  i am /highly/ motivated to get this done :)
<barry> and we're getting excellent community participation from maxb and simon-o
<barry> so let's see. at ameu we talked about including test dependencies (gary's test what you fly, fly what you test)
<barry> we talked about popup help
<barry> and we talked about html fragments (which i think abentley emailed the list about)
<barry> any of that interesting?  do you have anything else you want to talk about?
<mwhudson> the problem with test dependencies kinda boils down to "zope'
<mwhudson> s packaging is ridiculous" doesn't it?
<barry> yeah ;)
<barry> mwhudson: did you know lazr.restful pulls in zodb3?!
<mwhudson> barry: only because you've mentioned it a few tiems
<barry> :)  it just amazes me
<rockstar> I think abentley's discussion, since it's on the list, should continue on the list, but I have things to say about it.
<mwhudson> yeah, i don't have any thing to bring up i think
<barry> rockstar: +1
<barry> cool.  if there's nothing else, shall we call it?
<rockstar> barry, sure.
<barry> cool.  thanks guys
<barry> #endmeeting
<MootBot> Meeting finished at 16:11.
#launchpad-meeting 2009-10-15
<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
<rockstar> ni!
<danilos> me
<adeuring> me
<adeuring> (allenap is sick)
<danilos> (or "coo", if anyone knows about kin dza dza ;)
<matsubara> gary_poster, Chex, bigjools: hi
<mbarnett> hello
<matsubara> sinzui, hi
<gary_poster> me
<gary_poster> and hi
<matsubara> :-)
<sinzui> me
<mbarnett> me
<matsubara> apologies from Stuart and Ursula
<bigjools> me
<Chex> hello
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara>  * DBA report (stub)
<matsubara>  * Proposed items
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> * matsubara to trawl logs related to high load on edge on 2009-09-09 ~1830UTC and ping Chex about it
<matsubara> * matsubara to email the devel list about the new ErrorReportingUtility method
<matsubara>     * done
<matsubara> * matsubara to file a bug to have the HWSubmissionMissingFields oopses as informational only (note to self: see bug 438671 for more details)
<matsubara>     * filed https://bugs.edge.launchpad.net/malone/+bug/446660
<ubottu> Launchpad bug 438671 in checkbox "HWSubmissionMissingFields OOPS on +hwdb/+submit" [Undecided,Confirmed] https://launchpad.net/bugs/438671
<matsubara> * matsubara to look in lp-production-configs for the new oops prefixes.
<ubottu> Launchpad bug 446660 in malone "HWSubmissionMissingFields exceptions should be updated to be informational only" [High,Triaged]
<matsubara> * all QA contacts to inform their teams about the new QA column and what they should do about it.
<matsubara> * Chex to email the list about the new QA column in https://wiki.canonical.com/InformationInfrastructure/OSA/LPIncidentLog
<matsubara> I still haven't checked the high load logs. Chex or mthaddon, did you notice high loads after the 2009-09-09?
<Chex> matsubara: we still have been seeing some high loads, yes
<matsubara> I did look the new prefixes on lp-productions-configs. I need to update oops-tools to recognize those
<matsubara> I also noticed that some oops prefixes will conflict with existing ones, so I need to sort that out with...
<matsubara> losas I guess
<matsubara> [action] matsubara to file a bug on oops-tools to recognize new oops prefixes and sort out conflicting prefixes with losas
<MootBot> ACTION received:  matsubara to file a bug on oops-tools to recognize new oops prefixes and sort out conflicting prefixes with losas
<matsubara> Chex, re: the high load, could you take on the task of analysing the logs? my idea was to correlate information from the app servers logs with the apache logs and see if that could shed some light.
<matsubara> mthaddon emailed the list about the new QA column, so everyone, read it and spread the word to your teams, please.
<Chex> Chex: yes sure, I can look at that.
<danilos> matsubara: it has just been discussed in the TL call as well, flacoste will champion the process
<Chex> matsubara: ^^  I mean..
<danilos> matsubara: (about QA Info column on LP incident log)
<matsubara> Chex, cool, thanks a lot. ping me if you need any info on that
<matsubara> danilos, cool. thanks!
<matsubara> [action] Chex to check app server logs and apache logs to see if it can shed any light in the high load issue.
<MootBot> ACTION received:  Chex to check app server logs and apache logs to see if it can shed any light in the high load issue.
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> we're seeing a bunch on DisconnectionErrors which are not informational only
<matsubara> which means, the Retry mechanism is not enough for those cases.
<gary_poster> matsubara: are these the ones on the xmlrpc server?
<gary_poster> or something else?
<matsubara> gary_poster, yes, most of them on xmlrpc server
<matsubara> but there are a few, like OOPS-1383I246, in login.launchpad.net
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1383I246
<gary_poster> matsubara: right.  I investigated and could not duplicate the ones in the xmlrpc server.  Kicking the xmlrpc server made them go away.  There's a bug number which I can get in a moment.  After discussing with flacoste, I think the best we can hope for is to figure out a way to add more diagnostic information should the problem happen again
<matsubara> gary_poster, ok, I take this is a foundations taks then. let me know the bug number please (or I'll file a new one for the more diagnostic info needed issue, if that's not what the bug you mentioned is about)
<gary_poster> bug 450593 .   Stuart has a follow up: check with losas if there were any unusual activity ATM
<ubottu> Launchpad bug 450593 in launchpad-foundations "Lots of DisconnectionErrors on xmlrpc server - staging" [Undecided,New] https://launchpad.net/bugs/450593
<gary_poster> I think a comment saying that we should address by adding diagnostic information in case there is a repeat would be sufficient.  I'll do that.
<matsubara> thanks gary_poster
<matsubara> apart from that we have a bunch of oopses that will need fixing given the new zero oops policy.
<matsubara> Ursula will keep an eye on those for now and let the teams lead which ones are happening more frequently
<matsubara> we had some script failures last week
<matsubara> the main one seems to be the branch-puller which was already discussed in the list
<matsubara> checkwatches failed on the 13th, but since no other email came out, I assume it was a blip. adeuring, can you confirm?
<adeuring> matsubara: erm, I have no idea...
<matsubara> and the product-release finder and update-cache failed to run on the 14th
<adeuring> matsubara: I'll ask Graham
<matsubara> sinzui, do you know what's up with the product release finder script?
<matsubara> who's owns the update-cache script?
<matsubara> s/'s//
<matsubara> thanks adeuring
<gary_poster> I don't know; looking
<matsubara> [action] adeuring to check with gmb about checkwatches failure
<MootBot> ACTION received:  adeuring to check with gmb about checkwatches failure
<sinzui> matsubara: No, but I think the issue is not that it failed, bu that a long process prevented it from running
<matsubara> sinzui, right, that'd explain. could you check that's the root cause and reply to the list?
<sinzui> matsubara: okay
<matsubara> maybe the update-cache failure happened for the same reason
<gary_poster> matsubara: I don't see an update-cache script in the LP tree.  (I do see variants like update-download-cache)
<matsubara> just a reminder to everyone, if a script fails and your team owns that script, please reply to the failure email saying that someone is taking a look at it.
<matsubara> gary_poster, all I see is: "The script 'update-cache' didn't run on 'loganberry' between 2009-10-14 04:00:08 and 2009-10-14 22:00:08 (last seen 2009-10-13 11:36:51.345188)" not sure which script that one is monitoring.
<matsubara> for the critical bugs section, we have 4 bugs, 3 fix committed and 1 in progress
<matsubara> danilos, the one in progress is assigned to henning but he's on vacation
<matsubara> is it really critical?
<danilos> matsubara: I'd have to check, sorry for not being on top of this
<gary_poster> (I also looked for update-cache in lp-production-configs.  not there either.)
<matsubara> gary_poster, I think it's cronscripts/update-pkgcache.py. IIRC, the losas script monitoring tool uses the script name defined in LaunchpadCronScript
<matsubara> [action] danilos to check bug 438039, assess if it's really critical. if it's is, land a fix, if it's not, update the importance
<MootBot> ACTION received:  danilos to check bug 438039, assess if it's really critical. if it's is, land a fix, if it's not, update the importance
<ubottu> Launchpad bug 438039 in rosetta "bzr branch import script oopses sometimes" [Critical,In progress] https://launchpad.net/bugs/438039
<gary_poster> matsubara: oh ok, thanks.  that script is either the one salgado was talking about that he owns, or something for soyuz, seems to me.
<bigjools> it's traditionally maintained by soyuz
<gary_poster> bigjools: ok, thanks
<bigjools> but in the new world order it could be registry
<matsubara> bigjools, can you confirm that update-cache failure described in the "Subject: Scripts failed to run: loganberry:productreleasefinder, loganberry:update-cache" refers to the update-pckg.py and reply back to the email sent to the list?
<matsubara> ok, you just did :-)
<bigjools> it doesn't look like update-packagecache
<bigjools> errr ah it is
<matsubara> bigjools, it's the only script that has update-cache string in cronscripts/
<bigjools> sorry got confused by seeing productreleasefinder
<matsubara> [action] bigjools to investigate update-cache failure and reply back to the list
<MootBot> ACTION received:  bigjools to investigate update-cache failure and reply back to the list
<matsubara> bigjools, you might want to coordinate with sinzui since he'll check the product release failure one and suspects it might have failed because of a long running process
<bigjools> matsubara: is there an oops?
<sinzui> only an email that it did not run
<matsubara> bigjools, nope
<bigjools> and it was a one-off?
<sinzui> bigjools: it did not start, and that is 99% of the time the fault of a long running process
<bigjools> ok
 * sinzui really does not think about the issue until it happens two days in a row
<bigjools> and me
<matsubara> sinzui, perhaps the script monitoring should have such a feature
<matsubara> but anyway, sorry for taking so long on this section
<matsubara> thanks eveyrone
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Chex> hello everyone
<gary_poster> hi
<Chex> sorry, notes failure:
<Chex> - LP Ship-it progress:
<Chex> ; LP shipit is live on the new servers
<Chex> ; Nigel Pugh is now in charge of approving CPs to those servers
<Chex> ; We are still working on the new front-ends for LP Login and LP itself
<Chex> - Buildd-manager DB restart issue/bugs: Bugs 451351 & 451349 have been
<ubottu> Launchpad bug 451351 in soyuz "buildd-manager doesn't give us a good way of determining it's in a failed state" [High,Triaged] https://launchpad.net/bugs/451351
<Chex> filed to address this issue, any movement to fix this problem?
<Chex> - QA column in Incident Log: Tom sent a email to LP list on Oct 12, has
<Chex> anyone reviewed the email and have comments/concerns about it?
<matsubara> Chex, are oops reports from those new servers going to be rsync'ed to devpad? such oopses are supposed to be included in LP oops summaries?
<Chex> LP Incidents of note: ; Applied: CP 9660 to lpnet, CP 9679 to lpnet
<Chex>     ; Small LP outage (8 mins) : App servers (and
<Chex>          librarians) didn't reconnect & had to be restarted after LP DBs
<Chex> were restarted: Bug filed: 451093
<Chex> and thats our report for this week. sorry for the troubles there
<bigjools> Chex: I am looking into 451351 but don't expect anything soon, it's a hard problem
<Chex> matsubara: I am not sure on the status of oops summaries on the new servers, I will check on that
<matsubara> Chex, cool, thanks.
<Chex> bigjools: ok, thanks, just looking for status of progress.
<matsubara> Chex, danilos mentioned that QA column things was discussed today in the TL meeting and flacoste will champion the process.
<Chex> matsubara: ok, that is great to hear.
<matsubara> Chex, thanks for the report
<matsubara> let me move on as we are overdue
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<matsubara> The new replica to become the master for the authentication service has been taken offline, as the hardware was showing signs of strain keeping up with Launchpad's write load. The hardware is being beefed up to cope. The alternative is to just put the authdb replication set on this server and have the authentication service appservers connect to the main launchpad databases for the data they need to pull from the lpmain repl
<matsubara> ication set.
<matsubara> Nothing else to report.
<matsubara> that came from Stuart. any questions about dba's report?
<matsubara> ok, I'll take that as a no :-)
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> no new proposed items
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<matsubara> sorry for overrunning
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:51.
<gary_poster> thanks matsubara
#launchpad-meeting 2010-10-20
<rockstar> #startmeeting
<MootBot> rockstar, There is already a meeting in progress.
<rockstar> Why is there already a meeting in progress?
<rockstar> #endmeeting
<rockstar> #startmeeting
<MootBot> rockstar, There is already a meeting in progress.
<gary_poster> heh
<rockstar> Alright, so MootBot sucks.
<sinzui> I think someone need to pull HAL's memory
<rockstar> Hi everyone.  I'm chairing today's reviewer's meeting since bac is travelling the world this week.
<rockstar> Who's here?
<adeuring1> me
<gary_poster> me
<henninge> ,e
<sinzui> me
<henninge> me, even
<abentley> me
<salgado> me
<rockstar> 6 people huh?
<gary_poster> I pinged leonardr and mars
<abentley> rockstar: I can pretend to be two people, if you like.
<leonardr> me
<sinzui> EdwinGrubbs, meeting?
<allenap> me
<rockstar> abentley, if you were on another team, that might help.  As it stands, you're usually the only code guy here anyway.  :)
<gary_poster> ...and there were eight...
<deryck> me
<flacoste> me
<not-abentley> me
<mars> me
<gary_poster> heh
<rockstar> Alright, let's not sit and wait for the folks who couldn't remember the meeting that happens at the same time every week.
<rockstar> Here's the past actions from last week
<rockstar> Sinzui to investigate making lint check for the Storm 'in' gotcha
<rockstar> HenningE to add a note to the PSG about the use of any
<sinzui> No progress yet
<rockstar> I suspect bac didn't finish that past action, but that henninge knows what it ends with.
<henninge> I did that
<rockstar> bac to work with mars regarding a slow introduction of new reviewer points regarding the ArchitectureGuide. (undone)
<jelmer> me
<rockstar> henninge, hooray! You get a gold star.
<henninge> rockstar: it's about the "any" function ;-)
<rockstar> henninge, ah, okay. Well, I guess it was a finished statement.  :)
<rockstar> Okay, we're 1 for 3 on finishing items.
<rockstar> Mentat report!
<rockstar> So, I talked with bac and sinzui about this, but I think it's high time henninge graduates as a UI reviewer.
<rockstar> salgado, how's mentat life?
 * henninge is excited!
<salgado> going fine so far
<rockstar> Okay.  I guess that's it for that part of the agenda.
<rockstar> New items
<rockstar> Make all reviewers a UI mentat similar to the way we do javascript reviews. (lifeless)
<abentley> rockstar: do not want.
<rockstar> So, this is not new.  It has been entirely acceptable to get UI reviews from two non-UI reviewers.  It's been that way since the 3.0 work.
<rockstar> It's just a PITA to get wrangle more people to do UI reviews.
<rockstar> abentley, I am curious why you don't want to be a UI reviewer.
<mars> rockstar, do, as in, become a reviewer?
<jelmer> rockstar: As I understand it it's ok to get two UI reviews from UI mentats, not necessarily from non-UI reviewers.
<sinzui> Its a PITA to get people who want to become a full UI reviewer
<sinzui> there isnt a queue for this
<rockstar> sinzui, yes, that's true too.
<abentley> rockstar: I don't want to go through another training process, I don't want to have to do more reviews.
<sinzui> We supposed that the JS/UI team would all becomes reviewers. Most scared to the four winds when the meeting was abandoned
<rockstar> jelmer, we've kinda strayed from it, but during the 3.0 work, we needed UI reviews A LOT, and so everyone became a "mentat"
<abentley> rockstar: I don't think that I have especially good visual design skills.
<rockstar> sinzui, they were scaring that way before the meeting was abandoned.
<rockstar> abentley, and you have no desire to develop good visual design skills?
<jelmer> rockstar: I didn't know that, thanks.
<abentley> rockstar: there are many things more important to me than that.
<mars> sounds fair
<sinzui> abentley, While I do not know your skills, I have raised a similar point with beuno. Most of use were hired for code design skills, not UI design
<rockstar> Anyone else have opinions?  I can bring these thoughts up in the AsiaPac meeting as well.
<mars> rockstar, the way I do it now is I say "You need a UI review - as rockstar or sinzui"
<mars> rockstar, will that process change?
<mars> how will people's expectations for UI reviews change?
<rockstar> mars, yeah, that's a good question.
<mars> how will the way they ask for them change, and will they expect something different from their reviewer in return?
<rockstar> The 3.0 UI still wasn't consistent.  The mentat/mentee process makes it so that we at least get a *ahem* "trickle down" affect.
<mars> different from their currently-code-only reviewer
<mars> rockstar, so you are asking, if everyone became a UI mentee, would quality suffer?
<mars> since the current process is a self-selecting one
<rockstar> mars, I'm not asking anything.  I'm "facilitating."
<gary_poster> :-)
<sinzui> mars, 3.0 did suffer by the 2-person-yes rule
<sinzui> We landed dozens of pages without breadcrumbs and we did not discover that until weeks later
<sinzui> I favour 2-person approval, but I think we still need some review to ensure we are not codifying convention as rules
<mars> rockstar, do you know what lifeless' goal was in proposing this?
<rockstar> mars, I think he wants every reviewer to be able to do any review.
<rockstar> I started to propose a similar javascript review process, but I still don't feel like we, as a team, have a good understanding of javascript, so I backed off.
<mars> ok, so
<gary_poster> well, I assume he wants to get a higher throughput on our landing process
<gary_poster> and guesses that this would help
<rockstar> gary_poster, yeah, exactly.
<mars> right
<rockstar> Especially since there are no antipodean UI reviewers currently.
<henninge> but will it help our UI quality?
<gary_poster> ah, that's a big deal
<sinzui> I do not think every engineer can be a UI reviewer.
<mars> so it is just a way to do a light check-up, and defer the "qualified" review until later
<mars> and you can land in the meantime
<gary_poster> "can be" is a big statement, but I agree with sinzui's sentiment, if not the wording
<deryck> if not for abilities as much as lack of desire to learn ;)
<rockstar> Alright, I'll take this discussion to the AsiaPac meeting and see what happens.
<gary_poster> right deryck :-)
<rockstar> Peanut gallery, for anyone who wishes to throw peanuts.
 * gary_poster eats a peanut instead
<henninge> Are we on 2.6. now or not?
<mars> no
<gary_poster> I'll ask the losas about the pqm machine
<gary_poster> that's the last hold out
<rockstar> Awesome.
<rockstar> Anything else?
<rockstar> 5
<rockstar> 4
<rockstar> 3
<bigjools> 6
<rockstar> 2
<rockstar> 1
<henninge> 7?
<rockstar> Okay, that's a wrap.  Thanks for coming everyone!
<mars> thanks rockstar
<henninge> rockstar: Thank you!
<jelmer> thanks Paul
<gary_poster> thank you
#launchpad-meeting 2010-10-21
<rockstar> thumper, lifeless, wgrant, reviewer's meeting?
<StevenK> Not even me ... :-(
<rockstar> StevenK, I just grabbed a handful of names.
<thumper> here
<thumper> just
<thumper> rockstar: I think that bac can't make it today
<thumper> I saw the wiki page updated with an apology
<rockstar> thumper, yeah, I'm chairing both meetings today.
<thumper> ok
<rockstar> Except Mootbot is stupid, so we don't get Mootbot for the meeting.
<rockstar> Okay, so I took lifeless's proposal to make everyone a UI reviewer to the AMEU meeting this morning.
<thumper> rockstar: why not?
<rockstar> It was met with weeping and wailing, and nashing of teeth.
<rockstar> #startmeeting
<MootBot> rockstar, There is already a meeting in progress.
<rockstar> ^^ That's why.
<thumper> heh
<thumper> ok
<rockstar> Many reviewers don't WANT to be UI reviewers as well, and many feel like we need to get a better understanding of what "good UI" is before new people are reviewers.
<thumper> I agree with that
<rockstar> Anyone else want to chime in?  StevenK maybe?
<StevenK> I also agree with that
<rockstar> Okay, so the motion is basically tabled for now then.
<thumper> s/tabled/floored/
<thumper> :)
<rockstar> :)
<rockstar> That's it from the AMEU meeting.  Anyone have anything here?
<StevenK> Nope
<thumper> nope
<rockstar> Alright. Great meeting.
 * rockstar wanders off to take a shower and not smell terrible anymore.
