#launchpad-meeting 2006-07-10
<ddaa> Meeting in two minutes
<ddaa> MEETING STARTS
<ddaa> Luckily there's no .it in this meeting.
<ddaa> * roll call
<ddaa> * SFTP and knit advertising
<ddaa> * vcs-import knits
<ddaa> * branch scanner latency
<ddaa> * cscvs/bzr-native
<ddaa> * supermirror branch browser
<ddaa> * private branches
<ddaa> * critical bugs
<ddaa> * pending sysadmin tasks
<ddaa> * any other business
<ddaa> Hu
<ddaa> That is the Bazaar meeting, for all things Launchpad and Bazaar, of course.
<SteveA> Hu
<ddaa> * Roll call!
<SteveA> hi
<ddaa> jamesh: lifeless: spiv: ping
<ddaa> mpool: #launchpad-meeting
<ddaa> argh
<ddaa> Sorry, the infra guys are late.
<SteveA> we're almost done with the infrastructure meeting
<SteveA> so don't wait
<jamesh> I'm here
<ddaa> Okay, so 'vrybuddy's here except mpool.
<spiv> here
<ddaa> * SFTP and knit advertising
<ddaa> After the initial blog entry, I planned to blog about
<ddaa> - team shared  branches
<ddaa> - using checkouts (aka bound branches)
<ddaa> I have no time for that, I'd like somebody to write a blog about that, and I'll link from ddaa.net.
<mpool> hi there
<ddaa> Anybody volunteers for blogging about team-shared branches on launchpad.net and using heavy checkouts on them?
<SteveA> ddaa: did you tell jdub about your initial blog entry?
<ddaa> Not personally, I think. But I posted to the warthogs@ mailing list.
<SteveA> ddaa: do contact jdub personally
<jamesh> I mentioned your first blog entry in my blog
<SteveA> although it is good that you also mailed warthogs
<mpool> ddaa: is there a plan to do anything else about it beyond blogging?
<ddaa> ACTION: ddaa to tell jdub
<ddaa> mpool: mh... that's a good question. Probably, when we have something good we could put that on launchpad.net/bazaar
<ddaa> but ATM blogging seems like a good way to get the stuff written in the first place
<jamesh> I could write an article about team shared branches if no one else is
<SteveA> jamesh: that would be most cool
<ddaa> jamesh: I think you win that one :)
<jamesh> I'll send a draft through to the list before hand
<mpool> we should make sure to get at least something small and more formal onto the site
<mpool> even if it's just "branches can be hosted here, see <a>ddaa's blog"
<lifeless> I dont think formal matters
<ddaa> mpool: https://launchpad.net/bazaar
<lifeless> I think discoverable matters
<mpool> agree
<lifeless> whereever there is a 'branch' there should be a emblem for help or something, which if followed will educate
<mpool> ddaa, that looks good
<ddaa> There is work to link to that branch from interesting bug pages in one of my bazaar-ui branches.
<lifeless> ddaa: just land it!
<ddaa> But it's part of the "controversial" stuff that I never got around comitting. And that frankly I'd rather not dust off right now (largely because of context switching).
<SteveA> then give it to someone else to land
<SteveA> don't just sit on it
<SteveA> it is wasted work in that case
<SteveA> why do you say "controversial" ?
<ddaa> mpt had comments, I thought they were good comments, but you asked me to postpone acting on it for two weeks, about two months ago
<ddaa> good UI takes time
<ddaa> that we lack
<lifeless> we had a meeting
<SteveA> we also agreed that with UI stuff, just fucking land it
<lifeless> of review team
<lifeless> and then lp team
<ddaa> https://chinstrap.ubuntu.com/~jamesh/pending-reviews/david/launchpad/bazaar-ui/full-diff
<lifeless> where we said 'ui stuff LAND first, review SECOND'
<lifeless> as in, code review only, not ui review.
<SteveA> if it doesn't land, it has wasted your time in doing the code, and the reviewers' time in reviewing UI and code
<ddaa> it's conflicted, some of mpt comments still need addressing, it's unfinished work dangit
<SteveA> mpt's comments can be addressed later, and lifeless and I have just said
<SteveA> lifeless more eloquently than I
<SteveA> but I win the award for the most creative use of the word "fuck" in a serious launchpad meeting
<lifeless> fuck you
<lifeless> :)
<ddaa> So, somebody please merge david/launchpad/bazaar-ui
<SteveA> spiv: do you have time to do this?
<spiv> I think so.
<spiv> It doesn't look outrageously large...
<spiv> I'll let you know if I don't :)
<mpool> ddaa: add mpt's comments to a todo list
<ddaa> mpool: you mean a bug?
<mpool> either a bug, or just your personal list of things to do
<SteveA> spiv: ta
<ddaa> ACTION: spiv to try landing david/launchpad/bazaar-ui/
<ddaa> ACTION: ddaa to file a bug with mpt comments about ui
<ddaa> pff
<ddaa> cat comments > /dev/null :(
<ddaa> Moving on.
<ddaa> * vcs-imports knits
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/49449
<ddaa> Rolled out new bzrlib to importd. Will process some outstanding VCS import request
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/52313
<ddaa> that will hopefully allow me to check that new importd branches are indeed published in knits.
<ddaa> I think conversion of existing branches could be done by importd, before pushing to escudero. Plan to do sometimes after finishing bzr-native.
<ddaa> ACTION: ddaa to file bug about converting existing vcs-import branches to knits.
<ddaa> If you think that converting vcs-imports to knits is very important and urgent, please scream now.
<jamesh> I sent you a summary of which vcs-imports branches were being used, to give an idea of which ones would be a priority
<ddaa> jamesh: AFAICT, that means the use of system is near-zero
<ddaa> except for Kamion and a couple other ubuntu guys
<jamesh> well, we don't exactly advertise it
<ddaa> which is find, since it is not exactly painless
<jamesh> the idea was just to put the branches people are using at the head of the conversion queue
<ddaa> jamesh: considering the level of use the system is seeing, I think having a separate conversion process is too much work.
<ddaa> better to get the thing churn conversions for one week and be done with it
<jamesh> ddaa: I wasn't suggesting a separate process -- the suggestion was to tweak the ordering
<ddaa> that infra will also be useful for future conversions, hopefully at that point we'll have better system and we'll be able to just plug in more slave for this sort of load peaks.
<lifeless> focus please
<lifeless> conversions are not the most important thing to do
<lifeless> (given the usage stats)
<ddaa> right, so let's move on
<lifeless> new branches are knits already. So lets move on.
<ddaa> * branch scanner latency
<ddaa> Jamesh has merged out a patch to let the branch puller record more information, and let the branch scanner use it to save uncessary work. However, it broke the branch scanner on rollout.
<ddaa> Jamesh has a branch in review to fix the breakage, and move the bzrsync code and tests out of lib/importd. So it will use the normal test runner and get proper Zope utility setup.
<ddaa> No other comment there, jamesh appears to be on top of the situation. Thanks.
<ddaa> * cscvs/bzr-native
<ddaa> ddaa will put a branch for review that uses bzr in all CVS-based tests. Still need one (subversion tests) or two (shell tests?) more iterations of test refactoring after that.
<ddaa> No other comment there, either.
<ddaa> * supermirror branch browser [spiv] 
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/49991
<ddaa> Hi spiv. How is that going? Anything blocking you?
<lifeless> I think the shell tests can be nuked now
<ddaa> lifeless: okay, I'll check whether they do something more than the unittests (which have less than complete coverage for some cvs stuff)
<spiv> ddaa: no progress at all, I've got a note to talk to Steve about it, but until today he was at EP.
<ddaa> cool, hopefully you'll get some of SteveA's time soon :)
<SteveA> spiv: what do you need from me?
<spiv> SteveA: I can't recall what I had in mind originally, to be honest.  Basically a pre-impl call, though.
<SteveA> spiv: okay.  today or tomorrow is good for me.
<ddaa> * private branches
<ddaa> In an unexpected move, lifeless specced out private branches
<ddaa> https://launchpad.net/products/launchpad-bazaar/+spec/private-branches
<ddaa> I am still supposed to review that. Will try to do Tuesday or Wednesday.
<ddaa> ACTION: ddaa ro reviews spec/private-branches
<spiv> SteveA: I may ping you after review team meeting, depending on when I make dinner, otherwise tomorrow.
<ddaa> everybody else here more than welcome to review it too
<SteveA> spiv: ok
<spiv> Is it acceptable to put feedback on the end of the wiki page, or is there a facility in the spec system I should use?
<SteveA> private branches are important so that we can get launchpad and other internal projects using "The Bazaar" features in launchpad
<lifeless> wiki page - reviewer questions area
<SteveA> spiv: put it in the wiki page at the end
<spiv> Ok.
<SteveA> it should be "reviewer comments"
<ddaa> Anybody else interested in reviewing and not having a review request already?
<ddaa> okay, moving on
<SteveA> i'll read it
<ddaa> * critical bugs
<ddaa> Four critical bugs on launcpad-bazaar:
<ddaa> - bug 31308: Cannot set branch associated to a product series. https://launchpad.net/products/launchpad-bazaar/+bug/31308
<ddaa> Talked about that in Vilnius. Three states for a productseries: nothing, vcs import, native branch. That requires a spec to define the behaviour for all the possible transitions. Lifeless said he would do it.
<ddaa> lifeless are you still hot?
<SteveA> but i was present during its conception
<SteveA> <spiv> It doesn't look outrageously large...
* ddaa pokes lifeless with a stick
<ddaa> it looks lifeless...
<lifeless> sorry
<lifeless> ELYNNE
<ddaa> There's nobody else I think is familiar enough with the corner cases of that issue.
<lifeless> yes, Iw ill be doing the spec for that
<ddaa> ACTION: lifeless to spec for bug 37897
<ddaa> - bug 37897: renaming project, product or series breaks vcs imports https://launchpad.net/products/launchpad-bazaar/+bug/37897
<ddaa> Talked about that in Vilnius. Will add importd_slave column in ProductSeries to record which importd system currently own the persistent data. Existing records will be inited using the current job-name-hashing logic. New records will be given to slave with the least jobs. Simple interim measure.
<ddaa> ACTION: ddaa to spec short term and long term fix for that bug in excruciating detail
<ddaa> I still need hands to implement that in the short term.
<ddaa> Want to do it since it's overlaps with the bzr-native and importd-ng roadmaps.
<ddaa> (which I reckon are only in my head, and somewhat fuzzy)
<ddaa> Thought lifeless certainly has some very strong opinions on that too :)
<ddaa> - bug 51130: cannot use +admin on a branch I own https://launchpad.net/products/launchpad-bazaar/+bug/51130
<ddaa> I suggest:
<ddaa> + edit Branch.name and Branch.product on branch/+edit
<ddaa> + edit Branch.owner on branch/+reassign (like product), call the action link "Change Owner" or something, but _not_ "Change Maintainer" as it is currently on the product page. 
<ddaa> If you like that, I'll comment on the bug and try to get somebody to do it. That should be fairly easy.
<ddaa> Does everybody like that plan?
<ddaa> The rational for +reassign, is that it's something the user cannot undo, and that it is a very rare operation. It should be hard to do by mistake.
<mpool> (lookng)
<ddaa> Should be a good place to make team-shared branches discoverable, too.
<mpool> ddaa: that sounds reasonable
<mpool> is there any decision on changing the url, or is that a different bug?
<ddaa> changing what url?
<mpool> or does that remain under +admin
<mpool> changing the real url of the branch
<ddaa> that's currently under +edit AFAIK
<lifeless> I think all the fields the user can edit should be in +edit
<ddaa> no bug here that I'm aware of
<lifeless> and admin only fields in +admin
<mpool> ok
<ddaa> lifeless: sure, branch/+admin will go away too.
<lifeless> but this is nikeshedding
<ddaa> okay
<ddaa> * pending sysadmin tasks?
<spiv> lifeless: not reebokshedding? ;)
<lifeless> what matters is letting users change fields they should be able to.
<ddaa> lifeless: the way we present that functionality matters a lot too.
<ddaa> Nobody is blocked on sysadmining?
<lifeless> I have a new item for end of meeting
<ddaa> Cool
<ddaa> * Any other business?
<jamesh> I've got the cscvs support for Subversion symlinks up for review
<jamesh> so that should fix some imports once landed
<ddaa> mh
<ddaa> I'm on vacation from tuesday to monday
<ddaa> So I'll likely look at it and roll it out next week.
<jamesh> It hasn't been reviewed yet, but I can delay landing it til you look over it if you'd prefer.
<ddaa> jamesh: please get it reviewed
<ddaa> I just want to sanity check the code for logic holes
<ddaa> but I trust that I will find nothing to complain about.
<jamesh> ddaa: I wasn't planning on taking it off the queue.  Just asking if you wanted me to delay landing it after review
<mpool> i'm planning to write some braindump specs for 
<ddaa> jamesh: nope please land it ASAP
<mpool> branch viewing, review on launchpad and so on
<ddaa> jamesh: thank you for asking
<jamesh> ddaa: okay.
<mpool> just to start making plans for future features and so we can prioritise them
<mpool> should have something for folks to read in the next week or two 
<mpool> just an advance warning
<ddaa> sounds useful, along with private branches that will make a useful roadmap
<ddaa> mpool: if you feel like it, I'd love a spec about email subscription to branches
<ddaa> that's a cool feature we've been promising forever
<lifeless> ok guys.
<lifeless> this meeting is now late. and I have another in 9 minutes
<ddaa> lifeless: you said you had something to add
<lifeless> I'm going to jump in now with my new item
<lifeless> which is, these meetings should be about decisions not planning
<mpool> ddaa: that'd be good
<lifeless> I'd really like to see us move discussion about solutions, about whether things are right or wrong, to the usual channels: specs, the lp mailing list, bugs.
<mpool> lifeless: ok - and do what here?
<lifeless> mpool: Status of tasks; assignment of tasks; 
<lifeless> changes in policy; changes in priority that needs dispersement ot the team.
<ddaa> ACTION: mpool to braindump specs for branch viewing, reviews, email subscription, and so on
<ddaa> ACTION: jamesh get svn-symlinks reviewed and landed
<ddaa> ACTION: ddaa to sanity check svn-symlinks and roll out
<lifeless> the reason being that we can literally spend 2 hours talking over a feature, holding 6 people here, when in fact, its fine grained ui tweaks best discussed in a small group with mpt. Or best mocked up and tested.
<lifeless> etc etc
<mpool> sure
<SteveA> ACTION: ddaa, to set up a wiki page for this meeting's agenda
<SteveA> and write the agenda on it
<SteveA> that gives other an opportunity to comment whether the agenda is actually appropriate for everyone
<ddaa> lifeless: okay, I'll refrain from "does everybody agree" sort of question in the future
<lifeless> ddaa: if it needs consensus, then perhaps do this:
<lifeless> 1) assign everyone a task to review the 'thing'
<ddaa> SteveA: well, the agenda is usually carried over from one week to the next with only minor changes
<lifeless> 2) the next week, the thing is reviewed, or not and it continues on.
<SteveA> ddaa: good.  then the wiki page will require little maintenance
<ddaa> SteveA: okay, I see what you mean.
<ddaa> lifeless: okay
<ddaa> 5
<ddaa> 4
<spiv> ddaa: A wiki page also gives a place to register apologies, e.g. if someone is on leave.
<ddaa> 3
<ddaa> 2
<ddaa> 1
<ddaa> MEETING ENDS
<ddaa> thank you everybody, sorry for being late
<ddaa> you can now run to the reviewers meeting
<SteveA> hi danilos 
<carlos_> hi
<danilos> hi SteveA, carlos_
<SteveA> hi carlos
<SteveA> okay, let's go
<SteveA> I was away at a conference last week
<SteveA> so I'm a little behind the times
<danilos> ok
<SteveA> so, first of all, carlos, please say a few things about what you've been working on this past week or so
<SteveA> and what's coming up next
<SteveA> danilos: how long do you have here?
<danilos> SteveA: well, 20 minutes or so: don't want to be late since it takes me at least 30 minutes to get to the embassy
<carlos> Last week I did some work on translation migrations from breezy to dapper and edgy opening to be translated
<SteveA> (I'm going to play a little dumb... will explain why shortly)
<SteveA> carlos: so, what's the benefit of that?
<carlos> well, that will make us to have all translations from breezy applied to dapper
<carlos> and also, get edgy open to translate with exactly the same status we have in dapper
<danilos> (a guess: to help me get a feel for what is it I am actually going to be working on? :)
<SteveA> is that done on a string-by-string basis?
<carlos> yes
<SteveA> okay, cool
<SteveA> so, what happens to the new messages in a POT?
<SteveA> (that's one reason.  another is that we should all be always ready to explain *why* we're doing a particular piece of work.  and to explain it clearly.)
<carlos> if we got a new translation for dapper, we don't change that translation, we only change the ones that are still using the translations from upstream
<carlos> or empty ones
<SteveA> (and carlos is doing a pretty good job at that here.)
<SteveA> ok
<carlos> that's a workaround until we implement the TranslationReviews and MulticastTranslations specs
<SteveA> is the migration all done?
<SteveA> or is there still more work to do on it?
<danilos> (ok, sounds perfectly reasonable)
<carlos> as Andrew already stated with the preimplementation call report
<SteveA> i'm behind on reading that email
<carlos> SteveA: I did most of the migration already. I had a small problem with duplicate rows, but that's already fixed (talking about edgy opening)
<carlos> SteveA: the breezy -> dapper path is only started atm
<carlos> SteveA: yeah.
<SteveA> are you continuing with this migration work?
<carlos> yes
<SteveA> ok
<SteveA> so, for stuff that danilo can do, I can think of three options
<danilos> can I chip in with some questions, or should I hold them for later?
<SteveA> 1. danilo can help you out with this
<SteveA> 2. danilo can work on some other feature
<SteveA> 3. danilo can choose some outstanding rosetta bugs to work on
<danilos> ah, ok, there you go in involving me as well
<SteveA> I propose 3 for now
<carlos> I think 3. is also a good start
<danilos> sounds fine to me as well
<SteveA> ok.
<SteveA> do we have time to pick off some bugs now?
<SteveA> like, to choose them from the list
<carlos> we have a lot of small bugs/features to implement that could help you to understand a bit better how launchpad/rosetta works
<danilos> I think so
<carlos> https://launchpad.net/products/rosetta/+bugs
<carlos> that's the list of bugs on Rosetta
<danilos> was just heading there; though, my request for account hasn't been responded to yet
<SteveA> what kind of account?
<SteveA> chinstrap?
<danilos> yup
<SteveA> what's the RT number?
<danilos> and email alias (not that it's that important)
<danilos> hum, haven't received anything: maybe my email setup is broken
<SteveA> did you mail RT?
<carlos> you should get a confirmation email
<danilos> yup, as outlined on https://wiki.canonical.com/NewStaffTasks
<SteveA> but, no need for chinstrap access to get started
<SteveA> all you need is the bzr branch data
<carlos> I could provide you a copy
<danilos> also, none of my mailing list subscriptions got approved yet
<SteveA> for example, carlos could tar up rocketfuel-built
<danilos> ah, ok, great
<SteveA> and stick it on chinstrap's public_html
<danilos> yeah, and I've already installed launchpad-dependencies
<SteveA> for you to download
<danilos> sure, that's no problem then
<SteveA> but do check out your email configuration
<carlos> I think this bug would be a good start. It's quite trivial: https://launchpad.net/products/rosetta/+bug/1788
<SteveA> you can put bug fix diffs into a pastebing
<SteveA> pastebin
<SteveA> on chinstrap
<SteveA> and add that to the pending reviews page
<SteveA> until you have a chinstrap accoiunt
<carlos> danilos: do you know the pastebin url on chinstrap?
<carlos> danilos: https://chinstrap.ubuntu.com/~dsilvers/paste/
<danilos> hum, I am not yet sure what "pastebin" is?
<carlos> danilos: it's a kind of clipboard using the web
<danilos> yeah, already looking at the link
<carlos> so you can 'paste' something there and will get a URL to paste on IRC so other people can see the information you want to share
<carlos> that one on chinstrap is protected with a password so we can use it for confidential data
<SteveA> ok
<SteveA> I think we're sorted.  Danilo, ask on irc about anything you need in the code.
<danilos> yeah, ok, so "pastebin" it is
<SteveA> We'll talk tomorrow and see how things are going.
<SteveA> check that you have an RT request in for the chinstrap account
<danilos> no problem, I'll work with carlos and #launchpad
<carlos> danilos: I will prepare now a tarball of rocketfuel and send you the URL to download it
<SteveA> when I have the RT number, I can check how that's going with the admins
<danilos> btw, #launchpad-dev seems to be empty even if it's mentioned in the wiki?
<SteveA> that is out of date
<SteveA> please update the wiki page you found that on
<carlos> danilos: we just use #launchpad
<danilos> RT ID #13702 (just resent it now)
<SteveA> danilos: you mean you send a new request
<SteveA> and got back that RT number?
<danilos> yup
<danilos> the previous ones ended up without response
<danilos> but I changed my mail set-up, maybe that caused the problem
<danilos> ok, I'll be updating https://wiki.canonical.com/MessagingSystems and removing references to #launchpad-dev; I'll also remove the "users" bit describing "#launchpad" if that's correct?
<danilos> woops, I guess #launchpad is actually for users as well, and no password?
<SteveA> and carlos, please recommend 8 bugs for danilo to do 
<carlos> danilos: #launchpad is for users and developers, yes
<carlos> SteveA: ok
<danilos> carlos: can you also prepare a tarball for me to download once I get back from embassy?
<danilos> or in the morning at the latest
<SteveA> karl said your account will be sorted pretty soon.  i expect in the next day or so.
<danilos> SteveA: ok, thanks
<carlos> danilos: I'm doing it atm
<SteveA> cool.  let's talk tomorrow and see how things are going.
<SteveA> good luck at the embassy, danilo
<danilos> ok, great; I am off to the embassy now, just email me to danilo@kvota.net whatever needs emailing for the time being :)
<carlos> yeah, good luck!
<danilos> thanks SteveA
<flacoste> hi
<SteveA> hi
<SteveA> so, I read the spec
<SteveA> and these are good thoughts of refactoring
<flacoste> kiko and you spoke of caveats?
<SteveA> I would point out that IDistribution shouldn't extend ITicketTarget
<SteveA> but, according to our current conventions, Distribution should implement both ITicketTarget and IDistribution
<SteveA> that's a minor point
<SteveA> on to the other general issues
<SteveA> launchpad started off using lots of components, like this
<SteveA> and until recently, we were using this pattern in rosetta for IRosettaStats
<flacoste> you're talking about adapters?
<SteveA> to experienced zope people such as you and me, using a bunch of components like this is easy to understand
<SteveA> yes, an adapter is a kind of component
<SteveA> but to some of the more junior developers, and to Mark, it was confusing -- the functionality for a particular thing was split across many files, many places to look, much to understand to maintain things
<SteveA> so, Mark refactored the code into much larger classes / units of functionality
<SteveA> this had a good effect, and a bad effect
<flacoste> interesting, this is exactly the problems I mentioned in my spec...
<SteveA> the good effect was that more of the developers on launchpad got to understand more of the code, so better shared ownership of all the code
<SteveA> right -- see, complexity and amount of things to look at can be seen in different ways
<flacoste> indeed
<SteveA> number of components / amount of responsibility per component / amount of "glue" binding the components / amount of explicit vs implicit glue
<SteveA> so, this brings us to the situation today
<SteveA> I think we went too far in the "big clumps of things" direction
<SteveA> so I want us to go back in the other direction a bit
<SteveA> but before we do so, I want to fix a number of things about how we use Zope and the component architecture
<SteveA> to do with defining interfaces and adapters, and hooking these things up
<SteveA> this is consistent with the direction of zope3
<SteveA> but I want us to get there earlier than zope3 will
<flacoste> what are those number of things?
<SteveA> when we have less overhead in the "glue" and in registering adapters, and defining interfaces, and doing security
<SteveA> then there will be less cost in dividing things into smaller units
<SteveA> so we'll be able to afford slightly smaller units
<SteveA> and so get some of those benefits, without the costs we'd pay today
<flacoste> i'm not familiar with the way security is hooked in launchpad, so I guess i'm not yet able to evaluate the cost of this glue
<SteveA> things like, for making a change in distribution:
<SteveA>  - edit interface
<SteveA>  - edit tests
<SteveA>  - edit zcml perhaps
<SteveA>  - edit security adapters perhaps
<SteveA> or, to write a new content object
<SteveA>  - write interface
<SteveA>   - write tests
<SteveA>  - write implementation
<SteveA>  - write zcml
<SteveA>  - write security
<SteveA> these things don't sound like much, but they use up too many of the "working memory slots" a person has
<SteveA> some people have more than others -- some people are accustomed to keeping many things on the go at once
<SteveA> others work much better with fewer things to keep in mind
<flacoste> how could this list be really shortened?
<SteveA>  - write tests
<SteveA>  - write implementation
<SteveA> and the security, interface and zcml is done unobtrusively and elegantly in the implementation
<flacoste> with a kind of declarative API?
<SteveA> now, we don't need to get all the way there to make better use of adapters or better patterns for xxxxTarget stuff
<SteveA> we have spec targets, bug targets, support targets
<SteveA> it is a common pattern
<SteveA> as you point out in that spec
<SteveA> and I think we will refactor launchpad like that
<SteveA> but not today. 
<flacoste> ok, message received :-)
<SteveA> I'd like you to help me with experiments in this direction in about two weeks
<SteveA> I have a mgt meeting in 1 week
<flacoste> that would be my pleasure!
<SteveA> then the week after that a rosetta/bzr sprint
<SteveA> then a week in vilnius
<SteveA> then the lazr sprint
<SteveA> in the week in vilnius, if there's time, we should look at this issue again
<SteveA> and work it into the lazr plans... if I have time
<SteveA> if not, it'l lhave to wait until after the lazr sprint
<flacoste> great! I'll refresh your memory on the 24th :-)
<SteveA> ok, cool
<SteveA> it's been a learning experience for me. on launchpad, seeing the different ways people think about components
<SteveA> and what different people find easier to maintain and understand
<flacoste> yes, I'm quite aware that simplicity and complexity is really a function of one's background
<flacoste> thanks for the background perspective
#launchpad-meeting 2006-07-16
* Starting logfile irclogs/launchpad-meeting.log
* Starting logfile irclogs/launchpad-meeting.log
* Starting logfile irclogs/launchpad-meeting.log
-ChanServ(ChanServ@services.)- You do not have channel operator access to [#canonical-ops] 
* #canonical-ops is desynced from zelazny.freenode.net at 12:53pm
#launchpad-meeting 2008-07-08
<barry> #startmeeting
<MootBot> Meeting started at 21:02. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hi everybody and welcome to this week's asiapac reviewers's meeting.  who's here today?
<barry> jml, mwhudson ping?
<jml> hi!
<jml> I'm here
<mwhudson> oh hi
<barry> hi!  any word from thumper?
<mwhudson> well, he's at guadec
<spiv> Hi
<barry> mwhudson: ah, right
<barry> spiv: hi!
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>   * cprov mentor, abentley mentor
<barry>  * Review process
<barry>   * Ensure that all outgoing http connections go through a proxy (intellectronica)
<barry>   * Ensure in database code that non-DB state is reset at transaction
<barry>   boundaries (flacoste)
<barry> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<barry> next week, same time and place?
<mwhudson> sure
<barry> that will likely be my last meeting until august
<mwhudson> hm
<mwhudson> would another time be more convenient for you?
<barry> mwhudson: probably not.  i'll be sprinting on the 22nd and camping on the 29th (for you, my 21st and 28th)
<barry> mwhudson: but would you like to chair those meetings instead?
<mwhudson> um, ok
<barry> [AGREED] mwhudson to chair last two asiapac meetings in july
<MootBot> AGREED received:  mwhudson to chair last two asiapac meetings in july
<barry> [TOPIC] Action items
<MootBot> New Topic:  Action items
<barry>  * mwhudson to start discussion on page test purpose
<mwhudson> um, yeah, sorry
<mwhudson> carry it forward, i do really mean to do this :)
<barry> mwhudson: np, but can you start that up before our montreal sprint?  i'm hoping we can actually jfdi on some things when we're up there
<mwhudson> barry: that's in two weeks time?
<barry> mwhudson: yep
<mwhudson> ok
<barry> mwhudson: awesome, thanks
<barry>  * thumper to submit a bug for moving ftests contents to tests
<barry> he's not here but i think this wasn't done
<mwhudson> i don't think so either
<barry> cool, we'll just carry it forward
<barry>  * barry to ask lifeless to summarize what he knows about the PQM Mysteries (e.g. autopacking bug losing branches)
<barry> i suck
<barry>  * jml to find out how divmodders test their javascript
<jml> barry: I emailed their list and got some interesting replies.
<jml> barry: I'll actually need to get my hands dirty to finish the exercise.
<jml> barry: and I haven't had a chance yet.
<barry> jml: cool.  this is another thing i'm hoping we attack in montreal, so any information you can provide before then will be great
<barry> [TOPIC]  * Queue status
<MootBot> New Topic:   * Queue status
<barry> nothing really from me on that.  anything from you guys?
<jml> barry: the summary is (from memory): JSUnit + subunit run in tests, boy we wish we had a well-tested fake DOM.
<jml> none from me.
<barry> jml: very interesting
<mwhudson> we still have a queue? :)
<barry> mwhudson: :)
<barry> 1.99 baby!
<jml> barry: i.e. they haven't actually changed it much since I set it up.
<barry> jml: ah.  are they having much success with it?
<jml> barry: I think so. They say the lack of integration tests is kind of forcing them to separate as much logic as possible.
<jml> which is kind of a pyrrhic victory
 * barry nods
<barry> jml: thanks for the feedback.  we're going to see a lot more js this next release and i think many of us are worried about testing (if we aren't already)
<jml> barry: anyway, I'll hack around with their stuff and send an email to the list.
<barry> jml: thanks!
 * barry skips the mentoring topic
<barry> [TOPIC]  * Review process
<MootBot> New Topic:   * Review process
<barry>   * Ensure that all outgoing http connections go through a proxy (intellectronica)
<barry> let me see if i can channel him
<mwhudson> ok, so this is a bit wrong
<barry> mwhudson: ?  (go ahead)
<mwhudson> a better summary would be 'be aware of the network environment your code will see in production'
<mwhudson> because, for example, on vostok you _don't_ have to go through a proxy
<barry> mwhudson: very good point.  do we have any kind of comprehensive description of the environment code will see on various machines?
<mwhudson> i don't know if it's because i spend a lot of time talking to the OSAs for one reason and another, but i do feel that i perhaps know more about the production systems than most developers
<jml> having shell access to some of the helps :)
<barry> mwhudson: i would dearly love to have a wiki page describing the prod system environments *for the developers and reviewers*
<mwhudson> there is https://devpad.canonical.com/~mthaddon/Launchpad_Production_System.png
<mwhudson> but it doesn't have outgoing connections
<mwhudson> jml: yeah, probably
<barry> mwhudson: right
<jml> barry: there's https://launchpad.canonical.com/LaunchpadProductionDocumentation linked to from https://devpad.canonical.com/~joey/
<jml> barry: I agree that more docs on the production systems would be a good thing.
<mwhudson> jml: right, and i've already found a bunch of out of date stuff on this :)
<mwhudson> (it doesn't have the new code import system on it)
<jml> barry: perhaps the solution is to incrementally improve the ones we have.
<jml> mwhudson: *nod* I saw that too :)
<Rinchen> (if you have changes, send them to Joey :-)
<barry> Rinchen: howdy!
<barry> Rinchen: do you think LaunchpadProductionDocumentation is the right place to capture this information?
<Rinchen> hi :-)
<barry> if so, i will send a message to the ml asking people to update it with what they know
<barry> if not, we can start another page
<Rinchen> probably.... but that page is "owned" by the LOSAs
<jml> Rinchen: hi
<Rinchen> so one thing we should do is ask them to fill in any holes we have
<barry> Rinchen: ah, then it's probably /not/ the right place.  i want a page that is for devs and reviewers
<Rinchen> the goal of the devpage page was to capture all of the more operational aspects in one place
<mwhudson> barry: i'm not sure that's a very meaningful distinction
<Rinchen> it depends really on what kinds of documentation you want captured
<jml> use cases!
<Rinchen> there is no reason that page can't be used by devs and reviewers for example
<barry> what i think would be useful would be special environmental considerations you need to know when writing code or reviewing code destined for some production machine
<barry> e.g. vostok can make outgoing connections
<barry> Rinchen: cool, if you tell me LPD is the right place, we'll use that!
<mwhudson> i think as a practical thing, launchpad devs do really need to know a fair bit about operational things
<Rinchen> from you said barry, yep that's the right place.
<barry> mwhudson: +1
<Rinchen> there is also a lot of config information that sinzui build into the config tests
<barry> Rinchen: cool
<mwhudson> at least in part because there are 30 devs and 3 OSAs
<spiv> mwhudson: I agree.  Developers can't ignore deployment reality, as much as they might like to :)
<Rinchen> it's like a whole config user guide in the tests
<Rinchen> barry, your other option would be a separate reviewer checklist
<barry> Rinchen: i think i'd like to keep it all in one place, ideally
<spiv> barry: +1 for one place
<barry> Rinchen: mind if i email the list asking to update that page with operational details for the dev & reviewer?
<Rinchen> then LPD is probably the right place.  I don't think the LOSAs would mind
<Rinchen> barry,  go4it
<mwhudson> maybe we could add "will the code be able to make the network connections it needs to make" and a link to LPD to the codereviewerchecklist
<Rinchen> you can probably just email the losas and ask them
<barry> mwhudson: +1
<barry> Rinchen: +1
<barry> [ACTION] barry to email losas and devs about LPD page
<MootBot> ACTION received:  barry to email losas and devs about LPD page
<Rinchen> ok, I'm up by 2 so it's time to cash out while my luck is good. :-) Enjoy your meeting.
<barry> Rinchen: cheers!
<mwhudson> we should/could ask tom to include outgoing traffic on one of those diagrams
<barry> mwhudson: good idea
<barry>   * Ensure in database code that non-DB state is reset at transaction
<barry>   boundaries (flacoste)
<barry> i think i know what this is about, but it's a new item so i want to give flacoste a shot at it on wednesday
<barry> unless y'all have any comments about it?
<mwhudson> well, step 1 is "try not to have non-DB state" isn't it?
<barry> mwhudson: i would think so
<mwhudson> but i admit it had totally failed to occur to me that cachedproperty might muck around with this
<barry> yep
<barry> well, that's it from me.  anything from you guys?
<jml> umm one thing
<jml> why is review-submit checking for sampledata changes?
<jml> maybe it's something in my local set up, but I'm getting false positives all the time.
<barry> jml: that was added by sinzui as a defense against sampledata getting out of date
<barry> the problem is that it was /already/ out of date, so we need to land a branch to just fix the damn thing
<barry> i almost got to it today, but will probably do one tomorrow
<jml> what does "out of date" mean here?
<barry> jml: changes to the database not reflected in sampledata
<barry> i.e. a column gets added with no default
<barry> or, really, e.g. :)
<jml> barry: hmm. so it will flag the developer if they've been mucking around with their launchpad.dev?
<barry> jml: yep
<jml> barry: I don't think that's such a good idea.
<barry> jml: or at least, i think so
<barry> jml: the issue is that we've had problems with sampledata not matching the schema and this is suposed to prevent such breakage
<spiv> That sounds like something the test suite should check, rather than review-submit?
<jml> barry: I think the test suite is a better place to put such a check.
<spiv> jml: snap
<barry> it's currently a 'make lint'.  i don't remember exactly why it was done that way
<barry> i seem to remember the reasoning was sound at the time ;)
<jml> well, pylint already gives me enough false positives. having more checks that do so seems like a step backwards to me.
<spiv> Mail the list/sinzui about it?
<barry> spiv: +1
<jml> ok.
<barry> anything else?
<jml> nope
<barry> cool.  have a great week everybody!
<barry> #endmeeting
<MootBot> Meeting finished at 21:41.
<jml> barry: thanks
 * mwhudson disagrees with MootBot's clock
#launchpad-meeting 2008-07-09
<intellectronica> me
<barry> #startmeeting
<MootBot> Meeting started at 09:02. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> welcome everyone to this week's ameu reviewer's meeting.  who's here today?
<bigjools> me
<sinzui> me
<BjornT> me
<gmb> me
<allenap> me
<bac> me
<EdwinGrubbs> me
<schwuk> me
<flacoste> me
<flacoste> salgado is on holiday
<barry> cprov: ping
<cprov> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> == Agenda ==
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>   * Ensure in database code that non-DB state is reset at transaction
<barry>   boundaries (flacoste)
<barry>   * Security checks (should usually be avoided) in view code (intellectronica)
<barry> [TOPIC]  * Next meeting
<MootBot> New Topic:   * Next meeting
<barry> same time and place next week?  anybody know they will not be here?
<bigjools> cprov and I are sprinting, so may or may not make it
<intellectronica> i may be busy with the ubuntu sprint. don't know yet, but will update when i know the schedule for sure
<abentley> That would be fine with me.
<barry> cool.  if you're going to be away, please update the wiki page w/ apologies
<cprov> bigjools: we will have 30 minutes for the meeting, I'm sure.
<barry> [TOPIC]  * Action items
<MootBot> New Topic:   * Action items
<bigjools> cprov: almost certainly, but I am warning just in case!
<barry>  * barry to ask lifeless to summarize what he knows about the PQM Mysteries (e.g. autopacking bug losing branches)
<barry> done
<barry>  * barry to ask losas and devs to update LaunchpadProductionDocumentation on operation details of machines for devs
<barry> done
<barry> the other action items are for asiapacsters
<barry> [TOPIC]  * Queue status
<MootBot> New Topic:   * Queue status
<barry> everything looks fine to me.  any comments from y'all?
<sinzui> schwuk: intellectronica: bugtarget-hasbugs-1 is mege-conditional isn't it?
<schwuk> sinzui: that's how it was left.
<barry> leonardr: i'll note that pending-reviews has 55 conflicts (!) on your integration branch
<intellectronica> sinzui: it is, but i'm only going to land it when another branch is prepared. that's why i haven't removed it yet
<sinzui> someone, (schwuk) should update PR
<schwuk> sinzui: done
<barry> thanks
<bac> during my on-call shift i've started reminding people by name to clean up PendingReviews.  seems effective and well received.  perhaps others can do the same.
<barry> bac: +1
<barry> [TOPIC]  * Mentoring update
<MootBot> New Topic:   * Mentoring update
<barry> nothing from me here.  any comments?
<barry> [TOPIC]  * Review process
<MootBot> New Topic:   * Review process
<barry>   * Ensure in database code that non-DB state is reset at transaction
<barry>   boundaries (flacoste)
<barry> flacoste: the floor is yours
<flacoste> ok
<flacoste> so our move to storm changed a subtle semantic in the ORM
<flacoste> Storm does reuse instances across transactions
<flacoste> so a .get() after a transaction.commit() or abort() will return the same instance than previously
<flacoste> that wasn't the case with SQLObject
<flacoste> the instance is marked in a special way though so that all DB attributes will be fetched again
<flacoste> but non-DB attributes will hold the values from the last transaction
<flacoste> so be mindful of any non-DB attributes used on database objects
<flacoste> cachedproperty is an example of that
<flacoste> but there are other examples
<flacoste> objects that use non-DB attributes should provide a __storm_invalidate__ method
<flacoste> to reset these attributes
<flacoste> (it's called by storm on transaction boundaries)
<barry> flacoste: has cachedproperty been "fixed" to clear its cache on txn boundaries?
<flacoste> barry: no
<flacoste> i think i filed a bug about that, but i have to check
<flacoste> but iirc
<flacoste> we never used cachedproperty on DB object
<allenap> Does Storm do this as a performance optimisation?
<flacoste> yes
<barry> flacoste: thanks
<flacoste> and also as a convenience to the developer
<BjornT> flacoste: we do use cachedproperty on db objects
<flacoste> we do
<flacoste> ok
<barry> find lib/canonical/launchpad/database -name \*.py | xargs grep cachedproperty | wc -l
<barry> 57
<flacoste> wow
<flacoste> ok, i'll make sure to report and fix cachedproperty then
<flacoste> and maybe offer a wrapper for storm to easily create transaction-aware attribuets
<barry> [ACTION] flacoste to submit bug report on cachedproperty needing to __storm_invalidate__
<MootBot> ACTION received:  flacoste to submit bug report on cachedproperty needing to __storm_invalidate__
<flacoste> i'll also update the checklist with that info
<barry> flacoste: excellent, thanks
<flacoste> any questions? comments?
<barry>   * Security checks (should usually be avoided) in view code (intellectronica)
<barry> intellectronica: the floor is yours
<intellectronica> when we spot security checks in view code, it's a good idea to ask whether they really belong there
<flacoste> intellectronica: what kind of security checks are you talking about?
<flacoste> check_permission call?
<intellectronica> in most cases, it would be code to have them condified in the content object, and only called from the view
<flacoste> or security logic?
<intellectronica> flacoste: yes - stuff that relies on check_permission, and especially stuff the does more logic than that, for example by combining several calls to check_permission
<intellectronica> or a call to check_permission with some other stuff
<intellectronica> there are several reasons why i think this is important:
<flacoste> i can see several good reasons to call check_permission() in view code (to inform users or other forms of conditional action/display)
<abentley> An example of where I think it makes sense to check permission in view code is on the branch deletion page, where we show users what needs to be changed, and whether they can do it.
<bigjools> check_permission is already done in lots of browser code
<intellectronica> flacoste: true, but if the security check gets complicated, it would be good to have it in the content object and call it from there
<intellectronica> it's easier to test and easier to maintain when the predicate changes
<barry> intellectronica: maybe instead of adding these to content objects, we should register securitycheck adapters for them, and use that wherever it's necessary (e.g. browser code)?
<intellectronica> and most importantly, if we need to expose it from a different layer (the api, or a script, or whatever), we can reuse it
<intellectronica> barry: in some cases that's appropriate, in others less
<barry> i like keeping database code free from security checks because in some of my cases, what's appropriate in the browser isn't appropriate (or different) in the xmlrpc layer or web services layer
<intellectronica> i don't think that there's a rule that can be formulated. just that since i had to deal with this recently it opened my eyes and all of a sudden i see lots of places where this could become a problem
<intellectronica> barry: can you give an example?
<intellectronica> i'm asking, because i think that this it's quite rare for this to happen
<barry> intellectronica: i'd have to think of a specific example, sorry
 * barry could be misremembering too
<barry> intellectronica: could you outline the specific case where this came up?
<bigjools> don't the bug scripts already cope with lack of a user in zopeless mode?
<intellectronica> the case i've been dealing with is a check on setting various attributes of IBugTask (importance, for example), which was restricted using the browser
<allenap> So all the restrictions were worthless when you exposed IBugTask.importance in the API
<intellectronica> after moving this check to the content object (so that i can expose this object using the API safely) i discovered lots of places where we relied on ignoring the security check
<intellectronica> i'm sure that there are other cases, where restrictions hold in the browser code, but are being ignored elsewhere, and we just don't realise
<intellectronica> that's the main reason i think this is important
<bigjools> maybe we need another layer of code?  I'm not convinced that polluting content classes is right.
<BjornT> intellectronica: iirc, that was a bit different, though. the check was only done in browser code, and you needed to do the same check in the security checker, and from within the content class.
<intellectronica> in addition, it's much easier to check a security constraint or a method on a content object independently, than check through the view code
<barry> bigjools: hence my suggestion of adapters
<intellectronica> BjornT: indeed, but there are many cases like this, where we compound several predicates for the security check
<flacoste> ok, this is very particular
<bigjools> intellectronica: what places rely on ignoring the security check?
<intellectronica> BjornT: and i think this should be encapsulated somehow. in a security checker or if necessary, in the content class
<flacoste> and i agree with intellectronica that it is misplaced
<BjornT> right. but if you don't need to re-use the check from within the content class, you don't win much by adding an extra method.
<flacoste> but it's because the view is handling the mutation logic
<flacoste> that's not the place for that
<intellectronica> bigjools: i only know about the once pertaining to this change, and there are heaps of them. many scripts, for example
<bigjools> are the scripts able to log in as the right user?
<barry> do we usually have "a view" for whatever channel we're accessing/mutating the object through?  (i.e. xmlrpc, api, browser)?  if so, i wonder if the publishers could be hooked to provide that security checker adapter automatically
<cprov> bigjools: login(xxx)
<bigjools> cprov: exactly
<bigjools> so if we define the zope security adapter properly, is this moot?
<cprov> bigjools: as a predefined celebrity, though, not the right user in most of the cases
<flacoste> another difference
<BjornT> barry: well, we have the security policies
<flacoste> is that scripts usually use the PermissiveSecurityPolicy
<flacoste> which bypass all security checks
<bigjools> ew!
<barry> so.  intellectronica, what's the plan?  how do we resolve this?
<intellectronica> as i said, i don't think there's a rule hiding here, just something to pay attention to
<intellectronica> if you see check_permission(this) and check_permission(that) in browser code, ask whether this belongs elsewhere, for example
<barry> intellectronica: okay, but i think we need guidelines in the wiki so devs and reviewers can answer this question
<intellectronica> i can try to come up with something, but obviously it will need to be reviewed by more people
<intellectronica> i can add that and ask for comments
<barry> intellectronica: definitely... and thanks!
<barry> [ACTION] intellectronica to write up guidelines on check_permission in the wiki and email the ml for additional input
<MootBot> ACTION received:  intellectronica to write up guidelines on check_permission in the wiki and email the ml for additional input
<barry> anything else on this, or any other topic?  we have 4 minutes left
<barry> okay, thanks everybody
<barry> #endmeeting
<MootBot> Meeting finished at 09:43.
<bigjools> cheers all
<abentley> tx
#launchpad-meeting 2008-07-10
<warp10> Hi *
 * beuno pokes mrevell 
<mrevell> Hey beuno
<beuno> hey  :)
<beuno> will you be around in ~30 minutes?
<beuno> I want to grab Rinchen and mpt, and try to do something sensible with help
<mrevell> beuno: Sure, I'll be around for just about all of th rest of today.
<mrevell> something sensible?
<Rinchen> like make it work? :-)
<beuno> Rinchen, it already works, so it has that much sense now
<beuno> I just want it to be... well... better than average  :)
<beuno> but I have to wrap something up, and then, I'll start the flamewar
<mrevell> heh
 * beuno poked mrevell, Rinchen and mpt 
<beuno> *pokes
<beuno> so...  help
<mpt> hi
<beuno> this is what happens today:
<beuno> you click on something (ideally, an icon), and a div appears in the center of your screen
<beuno> 600*400px aprox
<beuno> and that embeds a URL in the iframe
<beuno> which, AFAIK, will be help.lp.net
<mpt> https://help.launchpad.net/SomeThing?action=print
<beuno> yes
<beuno> well
<beuno> embeding that has a few problems
<beuno> 1) if people click on a link, they'll navigate withing the iframe, which sucks terribly
<beuno> 2) we can't control very much how it's presented
<beuno> 3) we depend on an external site to load help
<beuno> 4) I hate iframes
<beuno> so, that's the first issue
<beuno> thoughts?
<mpt> (1a) We can't reach into the page with JS to make navigating do the right thing, because help.launchpad.net is a different domain so browsers won't give us permission to do that
<mpt> (There's also the reasons previously discussed when LaunchpadHelp was being written: (5) the help is routinely a week or six behind the actual interface, (6) the help doesn't update at the same time as a rollout. Neither of which are mrevell's fault at all, it's just emergent from the process.)
<mpt> mrevell?
<mpt> Rinchen?
<mrevell> mpt: I'm hoping that we can improve the process so that I'm involved much earlier in a feature's development, in order to provide UI and help text.
<mrevell> Also, my intention is to use specially written pages for the in-line help - so, perhaps /QuickHelp/BugSupervisor or something similar. I think we'd discussed that previously
<mpt> mrevell, right, the latter is what I was asking for an example of this morning
<mrevell> mpt: Yeah, although obviously we have none of that right now so I pulled out a page of what I imagine will be the upper range of the length we can expect.
<beuno> well, that mitigates the problem, but doesn't solve it
<beuno> we still have an external page
<beuno> no control over it
<beuno> we have to pull a lot of useless HTML to show a few characters
<beuno> external site, etc
<beuno> so, the solution to that would be to have the inline help in the code base
<beuno> make it simple for mrevell to update it
<beuno> but that would involve bzr to some extent
<beuno> that would solve all the problems above  :)
<mrevell> I'm happy to use bzr
<beuno> \o/
<mrevell> I've forwarded you both an email that Andrea Corbellini, a Launchpad doc team member, sent me, with some ideas on how to manage inline help.
<Rinchen> howdy, someone call?
<mpt> Rinchen, yes, please read the last 20 mins
<beuno> damn, Andrea really went great lengths to do the script...
<mpt> hmm
<mpt> Is that converting wikitext into HTML?
<beuno> it's...
<beuno> well, doing a lot of regex
<beuno> it guesses the HTML
<Rinchen> well, we could right a quick macro which looks for control sections  like  inlinehelp{{{  some help }}} and then call that
<beuno> not sure this is the right fit, and we definetly don't want to hit help.lp.net every time you need inline help
<Rinchen> so  ?=print-inlinehelp or something
<Rinchen> another option is just to put the help in a branch
<mrevell> Rinchen: I've sent you Andrea's email, as an FYI
<Rinchen> and I give mrevell access to the source code
<beuno> Rinchen, again, that will be a bit better, but won't solve the problem at large
<beuno> help branch would be great
<mrevell> Rinchen: Would we be limited to making changes at a roll-out?
<Rinchen> mrevell, yes
<Rinchen> mrevell, although edge would update when the db is not oepn
<Rinchen> open
<mrevell> right
<mpt> We allow cherrypicks for urgent bug fixes
<Rinchen> beuno, what would not be solved by bzr?
<Rinchen> <beuno> but that would involve bzr to some extent
<Rinchen> <beuno> that would solve all the problems above  :)
<Rinchen> I am con fuse ed
<mpt> Could we allow piggybacking cherrypicks for help text, on the grounds that changing help text is unlikely to cause bugs by itself?
<beuno> Rinchen, that would be the second issue, which doesn't change anybody's workflow, it's just a different wat of showing the help
<beuno> (I haven't presented that yet)
<Rinchen> in an ideal world, the help wiki does not exist.  LP is intuitive and where someone needs some extra hand-holding, we have that inside LP right where the user might need it
<mrevell> Is it technically difficult/undesirable to have a second bzr branch that's only for inline help and that I could push to outside of the normal roll-out process? If it's only text, like you say mpt, it's unlikely to introduce bugs.
<Rinchen> we could have the help text as sourcecode mpt
<Rinchen> still uses PQM but would allow it to be a separately managed branch
<mpt> If putting the help text under Bazaar's control is to solve (or reduce) the problem of help text being out of sync with the code, then it needs to be possible for a single commit to change both Launchpad code and help text.
<mpt> Is it possible to do that with sourcecode/?
<Rinchen> hmmm just wondering about that. Let's ask Francis
<Rinchen> asked on -code.  I think the answer is no
<Rinchen> I think it's either trunk or sourcecode but not both
<Rinchen> since the merge locations are different
<Rinchen> alternatively we can make a  lib/canonical/launchpad/help directory and just reference the help text out of there
<Rinchen> I'd very much like to have the help text as a separate file rather than having to edit code to change the help text
<Rinchen> will also make it easier to translate into another language when we decide to do that
<Rinchen>  (when/if ... that is)
<mrevell> And it'll reduce the possibility of me introducing errors into the code...
<beuno> yes, it should be in a seperate file, I don't see any reason for it not to
<mrevell> y'know obviously I'd be super careful etc
<beuno> a .py that can server specifically inline help
<beuno> or separate that into content + python that does serving magic
<beuno> so then we'd just request lp.net/inlinehelp?new_bug
<beuno> or something like that
<beuno> almost wouldn't have to change the current frontend at all for that  :)
<beuno> ok, so, if that can be done, leaving aside implementation details
<beuno> here's the second bit
<beuno> I think inline help should be placed next to what you're helping about
<Rinchen> ideally.
<Rinchen> that's the biggest problem with the help wiki at this point
<Rinchen> you have to go off and search for it
<beuno> a sort of bubble that clearly starts at the item you're refering to
<beuno> right now we just show it in the center
<beuno> which is less than ideal IMHO
<Rinchen> there's another issue where today we design help around an entire page or workflow
<Rinchen> rather than on a particular field or set of buttons on a particular page
<beuno> right, that should change
<Rinchen> I'm only in partial agreement there
<Rinchen> we still need to educate users on the overall flow
<beuno> also, there a few things that we discussed on the 3.0 UI sprint which makes this much more interesting
<Rinchen> How to get from A to D for example
<beuno> Rinchen, well, there is a few ideas on that
<mrevell> Yeah, I don't see the need for the user guide going away.
<beuno> the one I like the most
<beuno> is, the first time a user lands on a report a bug page
<mrevell> LP is far more complex than the average web app, so inline help has a really useful place but so does the user guide
<beuno> you popup inline help on each item that's relevent through the process
<beuno> so you hand-hold them to the end
<beuno> that can be repeated until the user thinks he's ready
<beuno> also, the same thing can be applied for frequent users which face new features
<beuno> so the actual global help is lp itself
<beuno> and not a page with screenshots
<beuno> of course, it's a long way to get there
<beuno> but having inline help short and to the point, clearly pointing at what the help is for, is a good start
<mpt> http://www.uxmatters.com/MT/archives/images/lw5-07_figure5.gif
 * Rinchen can just see the requests on -users and #launchpad now.  "How do I turn off these damn help bubbles?!?!
<mpt> http://www.uxmatters.com/MT/archives/images/lw5-07_figure8.gif
<Rinchen> yeah, I like the ballon help best
<beuno> Rinchen, well, just show them the first time a user goes through a process
<Rinchen> it takes less space than a collapsible area
<beuno> and then make it easy for them to see them again
<Rinchen> beuno, that doesn't work around here unfortunately
<mrevell> beuno: I like the idea but I'm concerned that our processes don't take in just one page
<Rinchen> beuno, we have LOTS of people who can't even unsubscribe from a mailing list which, in the footer, is a link to unsubscribe
<mrevell> I love the idea of having a prominent link to find out more about something that's new to the user but I'm not sure an automated run-through would be anything less than frustrating.
<mpt> I think the overall problem here is that in most parts of Launchpad, we're so far from the point where adding help is the best way to address any particular usability problem, that we don't have good examples of help text to work with
<mpt> so we're trying to imagine various presentations of text that doesn't exist yet :-)
<Rinchen> there is that too (both mpt and mrevell)
<Rinchen> The idea that I favour most is to have bubble help on anything that a user can change
<Rinchen> and then a distinct link to "find out more" which takes them to a users guide
<mrevell> When we've discussed the help spec in the past, the idea was always - AFAIK - to do our best to make 1. the UI intuitive, 2. the UI text sufficiently clear and 3. use help text on those parts of the page where you just can't get all the explanation into the UI text.
<beuno> right, that's all I think we can do today
<Rinchen> and that find out more could actually be in the bubble help for that mater
<mpt> So, one good example that could be written right now is what "Convert to question" means in a bug report
 * beuno has plans for the future
<mrevell> mpt: Yeah, a good example.
<mpt> because we can say quite confidently that adding explanatory text inline would be giving that link undue prominence
<mpt> so adding popup help of some form *is* the best way to make it more understandable
<mpt> So, maybe mrevell could write up a paragraph or two for that specific topic
<mpt> then we can use that as an example for the popup help?
<mrevell> Sure.
<mpt> then explore alternative ways of presenting it
 * Rinchen wonders if putting the popup help text would best be done in the interface definition.
<Rinchen> would existing in 1 place but could be served on multiple pages without duplication
<mpt> Rinchen, that might make it more difficult to make it context-sensitive (e.g. including the project name, or your Launchpad ID in bzr commands, etc)
<Rinchen> dunno mpt. we'd have that in the browser files when calling the page
<Rinchen> but it would certainly limit how much you could customize the text for a particular page
<Rinchen> I'm counting on the fact that it's a standard across the system so the definition and use doesn't change
<Rinchen> there's no reason we couldn't take the Interface help text and modify it on that particular page
<Rinchen> s/on/for
<Rinchen> but that does sound like too much work
<beuno> right.  You're subscribing to ${project} and will recieve notifications for ${bug title}
<beuno> doesn't seem *that* complicated
<beuno> some thought will have to go into each piece of help
<Rinchen> yeah, I was thinking about that beuno ... just encode substitution variables in the help text itself but there are issues then for anonymous users also because we might find that not all contexts have the variables defined
<Rinchen> that doesn't mean it won't work
<beuno> Rinchen, right. Start with public variables
<Rinchen> it just means we'd have to do some testing and ensure if there are cases we'd find them and make corrections
<beuno> and make the system more complex as you go
<Rinchen> if we want to tinker with the interfaces in any fashion whatsoever, we need to get a proposal written and get that out to the LP dev team for technical review
<beuno> cool, although I won't get to that this week, so that'll probably end up on mpt's side
 * beuno ducks
<mpt> -quack-
<Rinchen> so, do we have a plan then?
<Rinchen> beuno, you'll write up the concept?
<Rinchen> and perhaps pass it on to mpt and mrevell ?
<Rinchen> and for the new-comers.. context sensitive help in launchpad as bubbles :-)
<beuno> Rinchen, sure, I'll give it a go and pass it down
<beuno> I'll split it up into "what can be done now" and "what we can do the in the future"
<Rinchen> nifty.  I think the existing spec we have lacks implementation details..but admittedly I haven't read it since March
<beuno> the latter is something I'm suppose to work on anyways, if sabdfl answers my email soon  :)
<Rinchen> nifty thanks beuno
<statik> hewwo
<Rinchen> how D
<Rinchen> statik, did you let knmurphy in here? :-)
<Rinchen> someone go poke Francis please
<Rinchen> we're going to have a short meeting I think today
<Rinchen> a bunch of folks are attending conferences and such
<Rinchen> #startmeeting
<Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<MootBot> Meeting started at 13:01. The chair is Rinchen.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Rinchen> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<Rinchen> moo
<mpt> me
<adeuring> me
<mthaddon> me
<gmb> meow
<spm> me
<mars> me
<barry> me
<herb> woof
<bac> me
<salgado> me
<intellectronica> moi
<BjornT> me
<flacoste> me
<mrevell> me
<sinzui> me
<cprov-lunch> me
<leonardr> me
<statik> me
<Rinchen> I have apologies from kiko Steve  Diogo Schwuk Thumper Danilos Muharem
<jtv> me
<jtv> danilo's off this week
<Rinchen> ok, Releases Team is here
<EdwinGrubbs> me
<statik> lpcomm is here
<BjornT> allenap: ping
<bigjools> me
<flacoste> barry, mars: ping?
<barry> flacoste: i me'd before you got here :)
<mars> re-moo
<stub> me
<barry> mii
<jtv> à¸¡à¸µ
<flacoste> barry, mars: yeah, sorry :-)
<flacoste> Foundations is here
<Rinchen> looks like abently is also not here
<Rinchen> and soyuz is here
<Rinchen> great.. of we go
<Rinchen> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<allenap> me
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (sinzui)
<Rinchen>  * Critical Bugs (Rinchen)
<Rinchen>  * Bug tags
<Rinchen>  * Operations report (mthaddon/herb)
<Rinchen>  * DBA report (stub)
<Rinchen>  * Sysadmin requests (Rinchen)
<Rinchen>  * New packages required (salgado)
<Rinchen>  * A top user-affecting issue (mrevell)
<Rinchen>  * Doc Team report (mrevell)
<mthaddon> Rinchen, (mthaddon/herb/spm)
<Rinchen> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<mrevell> I won't be here next week. I shall appoint someone to take my place for the user-affecting issue.
<Rinchen> thanks mrevell
<Rinchen> next mtg is the 17th same time location
<Rinchen> anyone else know ahead of time they will be otherwise engaged?
<Rinchen> ok.
<Rinchen> [AGREED] Next meeting the 17th.  Apologies from mrevell
<MootBot> AGREED received:  Next meeting the 17th.  Apologies from mrevell
<Rinchen> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<Rinchen> none!
<Rinchen> [TOPIC] Oops report
<MootBot> New Topic:  Oops report
<Rinchen> we don't have a full report today
<Rinchen> sinzui, do you have anything in particular to discuss?
<Rinchen> thanks to sinzui for covering for matsubara this week
<sinzui> I'm standing in for matsubara. I'd like to bring 4 classes of opps to you attention. I don't think any are high priority, but they are dominating the reports I have seen this week:
<sinzui> https://bugs.edge.launchpad.net/launchpad/+bug/52574
<sinzui> https://bugs.edge.launchpad.net/launchpad/+bug/246591
<sinzui> https://bugs.edge.launchpad.net/launchpad/+bug/48464
<sinzui> https://bugs.edge.launchpad.net/launchpad/+bug/246932
<ubottu> Launchpad bug 52574 in zope3 "Surrogate error in Zope component architecture leading to an OOPS" [Undecided,Confirmed]
<ubottu> sinzui: Error: This bug is private
<ubottu> sinzui: Error: This bug is private
<ubottu> Launchpad bug 246932 in launchpad "global search oopses from incomplete XML" [Undecided,Confirmed]
<Rinchen> any takers on those?
<Rinchen> mars, perhaps on the last one: search ?
<Rinchen> flacoste, any idea on the zope item?
<gmb> I could take 48464, though I doubt I'd be able to get to it before the rollout.
<flacoste> Rinchen: not on the radar until we upgrade
<mars> Rinchen, sorry, my plate is full of 2.0
<Rinchen> gmb, that's ok.  I just like finding someone to investigate these further.
<sinzui> I'm not convinced that any of these oops are more important than our current work
<gmb> Rinchen: In that case, I'll look into it, but I don't think it's urgent.
<Rinchen> I agree
<Rinchen> thanks gmb
<Rinchen> sinzui, would you be so kind as to send the list above to matsubara via email please?
<sinzui> I will
<Rinchen> great thanks.
<Rinchen> Anything for sinzui or any other comments on the oopses above?
<Rinchen> ok then
<Rinchen> [TOPIC] Critical Bugs (Rinchen)
<MootBot> New Topic:  Critical Bugs (Rinchen)
<Rinchen> [LINK] https://bugs.edge.launchpad.net/launchpad/+bug/246524
<Rinchen> sinzui, thanks for working on this.  What's left to do on this one?
<MootBot> LINK received:  https://bugs.edge.launchpad.net/launchpad/+bug/246524
<ubottu> Rinchen: Error: This bug is private
<ubottu> MootBot: Error: This bug is private
<gmb> Hah.
<sinzui> I have a partial fix for this in review
<Rinchen> sinzui, k. I see there are some newer comments in the bug so thanks for that
<Rinchen> sinzui, need any assistance from anyone on this?
<sinzui> the user who was locked out this morning was from a differnent scenario, So I believe work needs to be done
<sinzui> I think the next branch will be easier/faster since I added test infrastructure
<Rinchen> ok, I'll leave this one in your capable hands then.  Thanks.
<Rinchen> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<Rinchen> we have one
<Rinchen> https://help.launchpad.net/TaggingLaunchpadBugs
<Rinchen> regression proposed by mpt
<Rinchen> mpt, I see what you are going for here but I'm not convinced by the evidence that it's sufficient to warrant a bug tag.
<Rinchen> Does anyone have any questions or comments on this proposed tag?
<Rinchen> Team leads?
<intellectronica> what use do you imagine for it?
<cprov-lunch> Rinchen: how do we track regressions currently ?
<intellectronica> it may be interesting for tracking, but otherwise i don't see how useful it is to tag regressions
<mpt> I explained the use on the wiki page
<cprov-lunch> Rinchen: well, I know we don't, but would it be good for us if we start doing it ?
<BjornT> i don't see much use of such a tag
<Rinchen> cprov-lunch, we don't currently other than in the description text or follow-on comments
<mpt> If Importance was reliably set for bugs, knowing that something was a regression would tend to increase its importance
<mpt> because all other things being equal, users are angrier about regressions than they are about other bugs that would otherwise be the same importance.
<mars> intellectronica, I thought it useful for tracking bad 2.0 UI changes
<barry> tags help find bugs, i'm not sure this tag helps in that case
<cprov> Rinchen: I would like to see some numbers, but I don't know if it's a valid use-case for a tag.
<mpt> The flaw in that argument is, that we don't currently reliably set Importance for bugs.
<BjornT> mpt: shouldn't the description make clear that it's a regression?
<Rinchen> We also at times create "regressions" when we change how things work... such as the UI
<mars> Rinchen, right
<mpt> BjornT, sure, but you could say that about almost all the tags we already have too.
<BjornT> mpt: except that, as barry said, tags are used to find bugs
<mpt> Ah, but the other tags we have are used for searching
<mpt> right, right
<mpt> good point
<jtv> In theory, a regression should be a test failure, not a bug.
<statik> i'm -1 on regressions, as it doesn't mean much without a lot of subjective interpretation
<Rinchen> I say regressions in quotes because to us it is a change that has been thought-out but users may not approve and call it a bug
<statik> where the other tags, like feeds or ui cannot really be debated when they apply :)
<mars> statik, good point
<BjornT> statik: well, ui can be debated :)
<mpt> jtv, in practice, there is much our tests don't test, including but not limited to CSS and JavaScript
<stub> So this is to work around us not setting Importance correctly. How come setting a tag is easier?
<Rinchen> Ok,  Based on the discussion, I'm going to declare this one, at this point in time, not approved.  Sorry mpt.  Please keep up the proposals though.  If you have more justification to this you can add it to the wiki page and propose it again
<mpt> ok
<Rinchen> [AGREED] regressions tag decline for now.
<MootBot> AGREED received:  regressions tag decline for now.
<Rinchen> mpt, please update the wiki.  thanks
<Rinchen> [TOPIC] Operations report (mthaddon/herb)
<MootBot> New Topic:  Operations report (mthaddon/herb)
<spm> Various application servers are dying and leaving a stale PID file: https://bugs.edge.launchpad.net/launchpad/+bug/247227
<ubottu> spm: Error: This bug is private
<spm> Had three Cherry Picks to lpnet*, scripts and codehosting: https://bugs.edge.launchpad.net/launchpad/+bug/224623
<ubottu> spm: Error: This bug is private
<spm> codebrowse has been migrated to a separate server
<spm> Been running a LOSA sprint in London this week
<spm> Librarian caching is live in production
<spm> Personal Note: I did greatly appreciate all the 4am well-wishes last week :-)
<spm> That's it from LOSA Land. Any questions from the channel?
<Rinchen> flacoste, can you spare someone to look at the pid file bug above?
<flacoste> Rinchen: i'll look at the logs
<Rinchen> thanks flacoste
<flacoste> and see if there is something
<Rinchen> [AGREED] flacoste to look at bug 247227 to see if there is any obvious reason for stale pid files
<MootBot> AGREED received:  flacoste to look at bug 247227 to see if there is any obvious reason for stale pid files
<ubottu> Rinchen: Bug 247227 on http://launchpad.net/bugs/247227 is private
<intellectronica> bad pidgin, bad
<ubottu> MootBot: Bug 247227 on http://launchpad.net/bugs/247227 is private
<Rinchen> anything else for spm...
<Rinchen> oh...
<Rinchen> and I'll update the agenda to include you spm :-)
<spm> Thanks Rinchen :-)
<Rinchen> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<stub> Load spikes on the database correspond to load spikes on the appservers where spiders hammer us, causing timeouts.
<stub> We currently have 8 cores on the db server. Assuming 50% of appserver time spent in Python and 50% waiting on DB queries and no batch processes, those 8 cores could service 16 simultaneous requests (this is an overestimate).
<stub> We currently have 8 lpnet appservers, for a total of 32 handler threads. We also have 4 edge servers another 16 handler threads. So even when the replica database goes online we still have way more appservers than we need that can drive way too many queries to the db causing timeouts.
<stub> I forgot to say thankyou to whoever thought of putting the max query counts for a page in the daily OOPS reports. These are pretty obviously prime targets to optimize and I believe the pages being shown up are being aggressively worked on.
<stub> Is demo free at the moment? I need to do some testing with real appservers and a real database but don't want to use staging to avoid screwing up QA.
<stub> oot.
<mthaddon> stub, https://launchpad.canonical.com/DemoUsers
<Rinchen> I believe demo is free stub.
<stub> I think so too - just double checking :)
<mthaddon> stub, demo is fairly out of date - pre-storm, for instance
<Rinchen> I don't know of any of the conferences this week which are using it
<bigjools> The Soyuz team is definitely aggressively working on those high query count pages
<mthaddon> stub, so let us know if you want it updated
<stub> I'll handle demo - I'll need to run my own branch
<mthaddon> okey doke
<Rinchen> mthaddon, can you please update the demousers page and add stub to it :-)
<Rinchen> any further questions for Stu?
<mthaddon> stub, how long should I put you down for? maybe you could add yerself? :)
<stub> I'll add myself
<mthaddon> merci
<Rinchen> thanks stub
<Rinchen> [TOPIC] Sysadmin requests (Rinchen)
<Rinchen> Is anyone blocked on an RT or have any that are becoming urgent?
<MootBot> New Topic:  Sysadmin requests (Rinchen)
<Rinchen> I'll take that as a no.
<Rinchen> [TOPCI] New packages required (salgado)
<Rinchen> heh
<salgado> anything for me this week?
<Rinchen> [TOPIC] New packages required (salgado)
<MootBot> New Topic:  New packages required (salgado)
<salgado> guess no
<stub> Should the dependencies contain version number requirements when packages come from sources other than hardy?
<stub> I suspect I wasn't the only one without the pqm repo listed
<Rinchen> and should we add the bzr ppa dependencies to it?
<Rinchen> dunno stub, we had a few email threads about this back when I added that :-)
<salgado> I've made it require specific versions when I was told a specific version was needed
<salgado> stub, what's this pqm repo?
<stub> :-)
<mthaddon> just what we were wondering :)
<stub> # The latest custom bzr-pqm package deb http://ppa.launchpad.net/jamesh/ubuntu hardy main
<salgado> well
<salgado> you need that for psycopg2
<Rinchen> See https://launchpad.canonical.com/NewLaunchpadder  for the full list currently recommended
<statik> salgado: btw i rewrote launchpad-dependencies a bit for my new project, and put it in a bzr branch using bzr-builddeb to build it, happy to share the branch with you if you are interested
<salgado> statik, will you maintain separate branches for each distro series?
<statik> salgado: nope, just using ppa copy functionality
<stub> Anyway - just wondering if it is worth putting > 0.92 for bzr-pqm, >= 2.0.8 (or whatever) for psycopg2 etc.
<salgado> stub, we do have that for psycopg
<salgado> 2
<salgado> statik, but that only works if you don't need to do any changes to the packages, I guess?
<cprov> salgado: to cope with changes across series you can use auto-ppa package from landscape.
<Rinchen> stub, I would support your proposal to add those since we need psycopg2
<Rinchen> salgado, your take on stub's proposal?
<salgado> Rinchen, we already do that: python-psycopg2 (>= 2.0.6+svn945~8.04)
<salgado> that's what launchpad-dependencies require
<statik> salgado: true, if i need different packages at some point i'll branch and have two series
<salgado> and to have that installed one needs jamesh's ppa in sources.list
<Rinchen> sure enough, ok then.
<Rinchen> anything else for salgado?
<Rinchen> thanks salgado
<salgado> thank you
<Rinchen> well, it's that time of the meeting.
<Rinchen> it's the mrevell show!
 * mrevell bows
<Rinchen> [TOPIC] A top user-affecting issue (mrevell)
<MootBot> New Topic:  A top user-affecting issue (mrevell)
<mrevell> Yo. Today I have a couple of issues. First off, I'd like to note that today we had another person asking for help as they couldn't log into their account. Are we waiting on the next roll-out for that to be solved fully?
<mrevell> I suppose that's a question for sinzui.
 * stub wonders where his psycopg2 came from
<Rinchen> <sinzui> I have a partial fix for this in review
<mrevell> thanks Rinchen
<salgado> mrevell, todays issue was something else
<intellectronica> fwiw, i think that this is something we should cp as soon as we've got a fix
<mrevell> salgado: Oh was it?
<salgado> intellectronica, +1
<Rinchen> Yep, I'm also +1 on a CP for this
<intellectronica> and/or proactively search for users that may be affected by these issues
<sinzui> mrevell: I suspect that the code that claims an account is not updating the account correctly.
<salgado> mrevell, it was.  currently we have 3 bugs, I think.  one for each view which doesn't update the account's status when they should
<mrevell> sinzui: Ah, I see. So, is the action still to ping you when someone has this problem? Or is that pointless if the script isn't working properly?
<sinzui> mrevell: I think so, if only to determine how the user discovered the problem
<sinzui> The fix always seems to be the same, but where the code should have set the account status is different.
<mrevell> Okay, thanks. I'll continue to make a noise about login problems, in that case, when they come up.
<salgado> sinzui, shall I file bugs for the two other views which are not setting the status?
<Rinchen> thanks mrevell. Any other questions for mrevell ?
<mrevell> Second issue comes from andrea-bs. He has asked if there's any chance of bug 3522 being solved - i.e. are we going to implement email notifications when someone requests blueprint feedback?
<ubottu> Launchpad bug 3522 in blueprint "Specification tracker does not handle review email" [Medium,Confirmed] https://launchpad.net/bugs/3522
<sinzui> salgado: please do
<salgado> will do
<flacoste> mrevell: eventually :-/
<mpt> Perhaps the feature should be hidden until it's implemented?
<flacoste> mrevell: but that may take a while, depending on whether blueprints are a 3.0 priority
<mrevell> mpt: That's quite tempting.
<mrevell> flacoste: Right, thanks. It's certainly something I'd value.
<mrevell> Thanks guys.
<mrevell> back to you Rinchen
<Rinchen> thanks mrevell. Any other questions for mrevell ?
<Rinchen> [TOPIC] Doc Team report (mrevell)
<MootBot> New Topic:  Doc Team report (mrevell)
<mrevell> Nothing to report from the doc team, other than my appreciation for andrea-bs' continuing enthusiasm and involvement!
<mrevell> I'm working to get the user guide and tour content ready for deployment this week.
<mrevell> That's all from me, thanks Rinchen.
<mrevell> Kinda the andrea-bs show, actually.
<Rinchen> and thanks to flacoste for putting in the new tour :-)
<andrea-bs> mrevell: thanks! :)
<mrevell> yes, thanks flacoste :)
<Rinchen> thanks mrevell
<Rinchen> well, look at this. The meeting ran the full length.
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
<Rinchen> #endmeeting
<MootBot> Meeting finished at 13:45.
<Rinchen> Thanks again
<jtv> Thanks Rinchen, and good night!
<mrevell> thanks rinchen.
<mrevell> gmb, rinchen, barry - see you later for the podcast recording
<intellectronica> thanks Rinchen
#launchpad-meeting 2009-07-08
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello and welcome to this week's ameu reviewers meeting.  who's here today?
<bigjools> me
<rockstar> ni!
<bac> me
<henninge> me
<allenap> me
<abentley> me
<mars> me
<noodles> yup
<sinzui> me
<BjornT> me
<EdwinGrubbs> me
<barry> intellectronica sends his apologies
<barry> adeuring: ping
<adeuring> me
<gmb> me
<barry> cprov, danilos ping
<cprov> me
<barry> gary_poster: ping
<barry> salgado: ping
<gary_poster> barry: thanks
<gary_poster> me
<salgado> me!
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Wednesday AMEU hard stop, barry
<barry>  * Action items
<barry>  * Mentoring update
<barry>  * Peanut gallery (anything not on the agenda)
<barry> i have a hard stop at 14:45 today.  hopefully we won't go that long anyway :)
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * adeuring to update wiki pages regarding `except Exception`, `KeyboardInterrupt` and `SystemExit`
<adeuring> done
<barry> adeuring: thanks!
<barry>  * gary_poster to take importfascist and rSP() discussion to ml
<gary_poster> nope.  I will bring new energy to the task. ;-)
<barry> gary_poster: cool.  keep it on the list then?
<gary_poster> y
<barry> +1
<danilos> me
<barry> intellectronica's not here today, so...
<barry> [TOPIC]  * Mentoring update
<MootBot> New Topic:   * Mentoring update
<barry> lessee, i think we're missing both deryck and leonardr
<barry> any word from their mentors?  how are things going?
<rockstar> barry, things is going well.
<barry> leonardr_: hi!
<gmb> Very well.
<leonardr_> hi barry
<gmb> Speaking of which...
<barry> rockstar: great, thanks for mentoring.  leonardr_ any comments, problems, feedback on reviewing?
<barry> gmb: what's up?
<gmb> barry: Oh, nothing, I just realised deryck wasn't here :)
<barry> :)
<barry> deryck: how's the reviewing going?
<gmb> barry: FTR, deryck's doing a fine job. He'll graduate in no time.
<deryck> barry, I think going well, if I could remember to show up for things. :)
<barry> gmb, deryck excellent
<barry> deryck: isn't it almost your eod? :)
<leonardr_> barry: i was hoping for some more interactive mentoring. on thursday i was reviewing a complicated branch and both rockstar and the person who submitted the branch were afk. i did the review but i don't think i learned as much from it as i could have
<deryck> barry, not quite. :)
<barry> leonardr_: you can always ping me if needed
<leonardr_> barry, ok, cool
<barry> anything else on mentoring?
<rockstar> leonardr_, I was afk?  Hm.  I don't remember that.  I'll make sure to be around.
<bigjools> leonardr_: if the submitter is not around, drop the review if you have questions
<rockstar> I don't think dropping the review is right.  I think you can respond without voting.
<barry> or just ask all those questions in the review!
<bigjools> if it was requested as an OCR, it goes to the back of the queue until that person shows up
<leonardr_> that's what i did. i did other reviews which were easier, and then i did this one
<bigjools> these are the rules we agreed on a long time ago
<barry> bigjools: +1
<leonardr_> and i asked my questions in the review
<bigjools> but leave a question in the review and mark it needs-reply
<leonardr_> the reason it was difficult is it took me a long time to understand the code well enough to formulate the questions
<rockstar> bigjools, hm, I guess you have different rules than I, but my team spans more timezones than yours.
<rockstar> leonardr_, was this cprov's branch?
<leonardr_> rockstar, yeah
<bac> we should reiterate that people requesting an OCR need to be around or negotiate their absense with the reviewer
<barry> leonardr_: that'll happen at first, don't worry about it too much
 * bigjools is shocked that cprov was not around :)
<rockstar> bac, why do they need to be around?
<bigjools> leonardr_: yeah, don't feel too bad about doing another review
<bigjools> instead of that one
<abentley> rockstar: OCR is supposed to be interactive.
<rockstar> leonardr_, I was around last week.  Remember, we got swamped?
<bac> rockstar: so the review can be interactive.  that was one of the principles of having OCR
<cprov> leonardr_: I thought it was perfectly fine to jump to another review when I was out
<barry> rockstar: they need to negotiate their absence with the reviewer, who might not want to take a particular branch if the submitter isn't around to answer questions in realtime
<bigjools> this is written up on the OCR page I thought
<rockstar> barry, okay, I think "negotiate with the reviewer" is better than "drop it until they come back"
<cprov> leonardr_: there was enough time for finishing the review while I was around, but you had problems with your account, remember ?
<leonardr_> cprov: i did
<barry> rockstar: right. but if the submitter just disappears, the reviewer has every right to move on
<bigjools> exactly
<leonardr_> i don't blame anyone for not being around at my convenience. and i did move on--i reviewed the other two branches in the queue before coming back
<rockstar> barry, yes, because it wasn't negotiated.  I'm happy with that.
<cprov> leonardr_: right, I think when something like this happens there isn't much you can do, abstain and move on, no worries.
<barry> cool
<barry> cprov: yep
<leonardr_> ok, in the future i'll abstain and do other work rather than bang my head against a branch all day
<barry> leonardr_: thanks for bringing this up
<leonardr_> np
<barry> [TOPIC]  * Peanut gallery (anything not on the agenda)
<MootBot> New Topic:   * Peanut gallery (anything not on the agenda)
<barry> does anybody have any other topics today?
<barry> that seems like a "no" :)
<henninge> barry: just to mention:
<barry> henninge: go ahead
<henninge> I changed my OCR slot to Monday Euro.
<rockstar> barry, do we have a policy on multiline list comprehensions?
 * bigjools thought of something
<barry> henninge: thanks.  did you update the wiki page?
<henninge> barry: yes
<barry> rockstar: i believe we do, in our python style guide
<barry> henninge: thanks!
<barry> bigjools: go ahead
<bigjools> ok
<salgado> leonardr_, another option is to use kiko's approach and ask tons of questions on the review.  once the developer answers them you can do a proper review
<bigjools> in a fix I made this week I had a hellish time dealing with code that was a mix of unicode and ascii strings
<bigjools> Bjorn had some interesting post-review points
<bigjools> but the upshot is that the code should be using unicode strings throughout, up until the point where you have to encode it as utf
<bigjools> is this enforceable?
<leonardr_> salgado, true
<bigjools> across LP I mean
<cprov> salgado: yes, that would work too, but unnecessarily binds the reviewer to the branch.
<rockstar> bigjools, it'd be nice.
<abentley> bigjools: In bzr, we often hold strings as utf-8-encoded bytes, for performance reasons.
<barry> when we're on python 2.6, i really want to add "from __future__ import unicode_literals" to the header of every file
<bigjools> abentley: interesting, how much of a performance hit is there?
<barry> (and absolute_import but that's a different issue)
<abentley> bigjools: dunno.  And I know that bzr manipulates a lot more data than your typical Launchpad page.
<bigjools> right
<barry> abentley: bzr is probably more byte-oriented than launchpad, which is more text oriented
<bigjools> it probably won't make much difference for us, we have bigger performance problems to worry about
<abentley> barry: Lots of things are defined as unicode, like filenames and revision-ids.
<barry> abentley: good point about filenames, didn't know about revids
<bigjools> the thing I was fixing were error messages in our upload processor, as soon as an ascii string formatter pulls in some unicode from the database, you're in trouble
<barry> i do think enforcing unicode literals will help, but it will probably expose places where we are being sloppy
<flacoste> barry: won't that means a 100,000 line diffs?
<bigjools> it might need a larger concentrated cross-team effort on it at some point
<flacoste> barry: to update the expected output of doctests?
<barry> flacoste: not if people are printing string values!
<flacoste> barry: they are not
<flacoste> barry: just grep for u' in the tests
<abentley> barry: Python's willingness to convert ascii-encoded str into unicode is convenient, but can mask problems later.
<barry> flacoste: it's our rule (now) but yeah there's legacy code
<barry> abentley: yep
<barry> anyway, we're not on python2.6 so it's kind of a moot discussion, but it should be a goal of ours to be explicit in our code whether we're talking strings or bytes
<barry> (where byte literals are defined with b'' prefix)
<barry> it won't be painless though ;)
<barry> anyway...
<barry> anything else on this or other topics for today?
<bigjools> my immediate question is, it might be worth trying to enforce unicode now in reviews to reduce the potential for more problems.  What do you think?
<barry> bigjools: possibly.  i hate to introduce more u'' prefixes when we can soon make them all go away
<barry> bigjools: otoh, we can probably convert module-by-module
<bigjools> I guarantee there will be lots of pain unless it's done all at once
<bigjools> but ok, let's move on
<barry> bigjools: which isn't to say you guarantee it will be painless if it is all done at once :)
<bigjools> there's relative levels of pain :)
<barry> :)
<barry> okay, anything else?
<barry> 5
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 09:29.
<barry> thanks everyone!
<abentley> barry: thanks yous
<gmb> Cheers barry
<bigjools> cheers
<mwhudson> barry: hello
<barry> #startmeeting
<MootBot> Meeting started at 17:35. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> mwhudson: hi
<barry> thumper: hi
<barry> jml: hi
<thumper> hi
<barry> well, not much to recap from ameu today
<barry> so i'll just open up the floor to anything you guys have
<thumper> I don't have anything
<mwhudson> oh
<mwhudson> me neither
<barry> mwhudson: record breaking
<barry> i guess we're done then :)
<thumper> w00t
<barry> #endmeeting
<MootBot> Meeting finished at 17:37.
 * mwhudson wonders what the relationship between number of attendees and length of meeting is
<mwhudson> i think it's not linear :)
<thumper> exponential
<barry> you don't even want to know how long the meeting is when i'm the only one there
 * barry -> more dinner
#launchpad-meeting 2009-07-09
<Ursinha> #startmeeting
<Ursinha> 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.
<MootBot> Meeting started at 10:00. The chair is Ursinha.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Ursinha> [TOPIC] Roll Call
<Ursinha> Apologies from matsubara, he's on leave today
<MootBot> New Topic:  Roll Call
<bigjools> me
<flacoste> me
<sinzui> me
<Ursinha> me
<Ursinha> of course
<Ursinha> rockstar, hi
<allenap> me
<herb> me
<rockstar> ni!
<Ursinha> hahaha
<Ursinha> henninge, hi!
<henninge> hi Ursinha!
<henninge> mi
<stub> moo
<Ursinha> so we're all here
<Ursinha> [TOPIC] Agenda
<Ursinha>  * Actions from last meeting
<Ursinha>  * Oops report & Critical Bugs & Broken scripts
<Ursinha>  * Operations report (mthaddon/herb/spm)
<Ursinha>  * DBA report (stub)
<MootBot> New Topic:  Agenda
<Ursinha> [TOPIC] * Actions from last meeting
<Ursinha> all items are okay, moving on
<MootBot> New Topic:  * Actions from last meeting
<Ursinha> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<Ursinha> we're also now going to talk about the scripts that are broken in this section
<Ursinha> we want to make sure that these errors are tracked and solved
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<Ursinha> I have five bugs, one critical bug and two broken scripts
<Ursinha> * OOPS report
<Ursinha> sinzui, I have bug 396585 and bug 396383, maybe they can be fixed together?
<Ursinha> flacoste, bug 397224 and bug 373837, this last one is targeted to 2.2.6
<Ursinha> since, we had some DisconnectionError oopses yesterday, I decided to mention the bug here
<Ursinha> rockstar, could you set the importance on bug 397220, please?
<ubottu> Launchpad bug 396585 in launchpad-registry "/projects/+review-licenses OOPSes with subscription date" [Low,Triaged] https://launchpad.net/bugs/396585
<ubottu> Launchpad bug 396383 in launchpad-foundations "date widget could be smarter, giving a date in format DDMMYYYY OOPSes" [Low,Triaged] https://launchpad.net/bugs/396383
<ubottu> Launchpad bug 397224 in launchpad-foundations "TraversalError in person page accessing openid_identity_url" [Undecided,New] https://launchpad.net/bugs/397224
<ubottu> Launchpad bug 373837 in launchpad-foundations "DisconnectionError should log a soft OOPS" [High,Triaged] https://launchpad.net/bugs/373837
<ubottu> Launchpad bug 397220 in launchpad-code "Better validation for project field in new code import form" [Undecided,Triaged] https://launchpad.net/bugs/397220
<Ursinha> thanks ubottu
<Ursinha> the ones for sinzui matsubara asked me to mention
<sinzui> Ursinha: I am not sure about either of these
<sinzui> Ursinha: the issue is somewhat deep. A foundational widget and the fact that we stupidly design schemes to use datetime stamps that no human will ever enter
<flacoste> Ursinha: the DisconnectionError soft oops, i'll move to 2.2.7 and see if we have time to fix it, the other one, i don't understand
<flacoste> Ursinha: i'll have a look at it and triage
<sinzui> Ursinha: there are a few bugs open about the datetime stamps. I think all of those should be worked on. It is database work. I do not want to engage in that level of work for the next 3 months
<Ursinha> sinzui, right
<Ursinha> flacoste, thanks
<Ursinha> [action] flacoste to take a look and triage bug 373837
<ubottu> Launchpad bug 373837 in launchpad-foundations "DisconnectionError should log a soft OOPS" [High,Triaged] https://launchpad.net/bugs/373837
<MootBot> ACTION received:  flacoste to take a look and triage bug 373837
<sinzui> Ursinha: The Launchpad date widget could be smarter. (which is why I changed the title) Note that the page that error came from has a date picker and states the expected format
<Ursinha> sinzui, indeed
<Ursinha> flacoste, and about the other one, the TraversalError one?
<flacoste> Ursinha: that's the one i'm going to look and triage
<Ursinha> flacoste, oh, I thought that would be the other one
<flacoste> Ursinha: the other one, I'm moving milestone and we'll see if we have time to fix it
<sinzui> Ursinha: so I think the oops is rightly classified as low. I'll look into fixing the date widget for another bug though, There are use cases where the default is the current date. The widget should show that
<flacoste> Ursinha: any particular reason to bring it here?
<Ursinha> [action] flacoste to take a look and triage bug 397224 and will move bug 373837 to 2.2.7 and see if it's possible to fix
<MootBot> ACTION received:  flacoste to take a look and triage bug 397224 and will move bug 373837 to 2.2.7 and see if it's possible to fix
<ubottu> Launchpad bug 397224 in launchpad-foundations "TraversalError in person page accessing openid_identity_url" [Undecided,New] https://launchpad.net/bugs/397224
<ubottu> Launchpad bug 373837 in launchpad-foundations "DisconnectionError should log a soft OOPS" [High,Triaged] https://launchpad.net/bugs/373837
<Ursinha> flacoste, we had some DisconnectionErrors yesterday and I saw this bug was targeted to an old milestone
<flacoste> well, that's unrelated :-)
<Ursinha> and it's a high bug
<flacoste> well, foundations have a lot of High bugs unfortunately :-(
<Ursinha> flacoste, I know :(
<bigjools> you need a High High :)
<flacoste> it's called Critical
<bigjools> no, it's somewhere between!
<flacoste> no, no
<Ursinha> rockstar, hi :) can you set the importance in that bug, please?
<flacoste> bigjools: there is critical, assigned High bugs and unassigned High bugs
<Ursinha> I agree with flacoste
<flacoste> Ursinha: so the DisconnetionError the 373837 bug are talking about are the ojnes we recover from
<flacoste> Ursinha: when you see them on the OOPS report, we didn't recover from it
<Ursinha> flacoste, hm, I see
<Ursinha> the ones we didn't recover, do we know why?
<flacoste> OOPS?
<flacoste> (i didn't look)
<Ursinha> flacoste, fetching one
<Ursinha> flacoste, OOPS-1285J112
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1285J112
 * Ursinha pokes the hell out of rockstar 
<rockstar> Ursinha, sorry.
<rockstar> Ursinha, I had done it when you asked.
<Ursinha> sinzui, I'll make notes in the bugs then (if you didn't already - you're too fast :))
<Ursinha> rockstar, thanks man
<flacoste> Ursinha: that disconnection error is weird
<flacoste> Ursinha: please file a bug about it
<Ursinha> don't go away, I have one critical bug for you
<Ursinha> flacoste, I will
<Ursinha> [action] Ursinha to file a bug about OOPS-1285J112 and tell flacoste
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1285J112
<MootBot> ACTION received:  Ursinha to file a bug about OOPS-1285J112 and tell flacoste
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1285J112
<Ursinha> right
<Ursinha> now I have one critical bug, that's code's
<rockstar> Ursinha, is it the ACF one?
<Ursinha> * Critical bugs
<Ursinha> rockstar, bug 390563 is critical but has no activity since 06-29, is it really critical
<Ursinha> tried to ask thumper yesterday about it but he was already gone, could you check this one with your team, please?
<ubottu> Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563
<Ursinha> I guess so
 * Ursinha looks
<Ursinha> after guessing what ACF means :)
<sinzui> Ursinha, flacoste: the datetime widget bug (while real) is not the bug in the oops as I read it. The restful marshaller expects a string, but the JSON serialized the numbers as numbers.
<rockstar> Ursinha, there have been multiple team discussions about it.
<Ursinha> rockstar, is that bug really critical?
<sinzui> ^ We should probably add that as an expected exception to let standard error messaging handle the issue
<Ursinha> sinzui, you may want to comment in the bug about it
<rockstar> Ursinha, so, yes, it's really critical, but we're dependent on bzr fixing it.
<rockstar> Ursinha, we may downgrade it for the sake of not misusing Critical.  We're still discussing it.
<Ursinha> rockstar, I'm going to write this in the bug, so anyone that reads the bug report will know what's going on
<Ursinha> rockstar, can you update the bug as soon as you have news, pretty please?
<rockstar> Ursinha, will do.
<Ursinha> thanks a lot rockstar
<Ursinha> sinzui, do you want me to do something in that bug?
<Ursinha> or maybe you want to discuss later
<sinzui> I just updated it. It is an easy fix that I will make today since I have the file open
<Ursinha> sinzui, great, thanks a lot
 * sinzui just needs to workout where the bug really belongs? launchpad-foundation or lazr.restful
<flacoste> leave it in foundations for now
<Ursinha> let me just introduce the broken scripts we have, one seems to be yours sinzui
<Ursinha> sinzui, productreleasefinder is having issues for quite some time, it's bug 394391
<Ursinha> could you take a look at this one? maybe change the importance
<ubottu> Launchpad bug 394391 in launchpad-registry "product-release-finder should make sane milestone names" [Low,Triaged] https://launchpad.net/bugs/394391
<Ursinha> also, I see that language-pack-exporter also failed to run, herb, henninge, do you know if that was expected?
<henninge> I don't.
<sinzui> Ursinha: I know how to fix that, and 3 other bugs. I am working on that on my own time
<herb> I don't know either.
<henninge> Ursinha: but it is a pretty long running script.
<henninge> Ursinha: which run was it? when?
<sinzui> Ursinha: I'm not certain it is not more important since it have been broken for 4 years and no one reported the bug before me
<henninge> It is not uncommon for the script to be interrupted.
<Ursinha> henninge, quoting the email: between 2009-07-07 17:00:04 and 2009-07-08 13:00:04
<sinzui> Ursinha: but in the big picture, fixing 99% of all product-release-finder errors is a big win for me so I have started a plan to fix the bugs
<Ursinha> sinzui, I see
 * henninge just realizes he doesn't know the current schedule for that script.
<Ursinha> sinzui, well, I think the important is that it's being fixed, not abandoned
<Ursinha> that's what I'm trying to achieve mentioning them
<sinzui> Ursinha: My team closed more than 40 low bugs last release. This is not forgotten there is a 30 point story attached to these PRF bugs
<henninge> Ursinha: But really that script is monitored by the Ubuntu guys and they complain if they miss a language pack ...
<Ursinha> gee
<henninge> ArneGoetje to be exact.
<Ursinha> henninge, monitored or maintained?
<herb> l-p-e runs every monday,tuesday,thursday friday
<herb> @2200 BST
<herb> mon,fri for jaunty
<herb> tue for intrepid
<henninge> herb: ah, was gonna ask that
<herb> thur for hardy
<Ursinha> herb, thanks for the info
 * Ursinha took notes
<henninge> Ursinha: so that is that was the intrepid run failing. Not critical.
<herb> the monday run finished at 0310 UTC on Tuesday
<Ursinha> sinzui, thanks for that
<Ursinha> henninge, right. if that keeps happening may I poke you? :)
<herb> and it does look like intrepid was the one the failed
<henninge> Ursinha: you may :)
<herb> but it ran successfully the previous week.
 * henninge looks forward to being poked by Ursinha because it will definietly happen ...
<Ursinha> [action] Ursinha to watch the lang-pack-exporter script and poke henninge if it fails again
<MootBot> ACTION received:  Ursinha to watch the lang-pack-exporter script and poke henninge if it fails again
<Ursinha> well, let's move on
<Ursinha> thank you all guys
<Ursinha> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> 2009-07-02 - Cherry picked r8700 to the scripts server.
<herb> 2009-07-07 - Cherry picked r8766 to the scripts server.
<herb> 2009-07-07 - Cherry picked r8729 to the importd slaves.
<herb> Other than these it's been a quiet week. No service interruptions, a handful of minor incidents reported and no outstanding cherry pick or query requests.
<Ursinha> herb, that's good to hear
<Ursinha> does anyone have anything for herb?
<Ursinha> hmm
<Ursinha> moving on then :)
<Ursinha> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> A few accounts had to be repaired, fallout from the dodgy data repair work performed last week. These gave me more clues to track down some unreported ones, which have also been fixed. Hopefully everything is correct now.
<stub> We will be testing the person pruner on staging, which should remove 90% of our Person records (which we can do because Account was split out of Person). When we run on production, it should have positive benefits throughout launchpad. The ValidPerson*Cache and TeamParticipation tables will shrink too, so three of our most common tables to join with will be much smaller. And lots of namespace will be freed up too.
<stub> Not much in the way of db patches this cycle. Should have reviews all sorted and things ready to land tomorrow.
<stub> oot.
<Ursinha> stub, do you know if all accounts that were reporting problems on feedback@ were fixed?
<stub> All that have been forwarded to me have been fixed.
<stub> I don't personally monitor feedback@
<Ursinha> okay, I'll check if there's any outstanding one
<Ursinha> thanks stub
<Ursinha> [action] Ursinha to check if all accounts requesting fix on feedback@ were fixed
<MootBot> ACTION received:  Ursinha to check if all accounts requesting fix on feedback@ were fixed
<Ursinha> anything else for stub?
<Ursinha> or
<Ursinha> anything else at all?
<Ursinha> 5
<Ursinha> 4
<Ursinha> 3
<Ursinha> 2
<Ursinha> 1
<Ursinha> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<Ursinha> #endmeeting
<MootBot> Meeting finished at 10:43.
<Ursinha> thanks a lot guys
<herb> thanks Ursinha
<allenap> Ursinha: Dammit, I had to go out for 1 minute and I missed the anything else bit! Rats :)
<allenap> I'll email the ml/
<Ursinha> allenap, oops :)
<allenap> Ursinha: Yep, my bad.
<Ursinha> allenap, I should've poked you, sorry
<allenap> Ursinha: No worries, I should have paid more attention.
#launchpad-meeting 2010-07-12
<leonardr> xsltproc ~/canonical/launchpadlib/ad-hoc-testing/src/launchpadlib/wadl-to-refhtml.xsl wadl-development-devel.xml > devel.html
#launchpad-meeting 2010-07-18
<Ursinha> OOPS-1660S153
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1660S153
