#launchpad-meeting 2006-09-11
* Starting logfile irclogs/launchpad-meeting.log
<ddaa> Good.
<ddaa> spiv: welcome back
<spiv> ddaa: thanks.
<ddaa> how was the vacation?
<spiv> Fun.
<spiv> Also, I have stitches in the back of my head.
<ddaa> You finally had this neural plug implanted, eh?
<spiv> I proved it is possible to hit yourself in the back of your head with a snowboard that's still attached to your feet.
<ddaa> oh, yeah, it's quite feasible, those things are quite long
<spiv> 159cm in my case :)
* ddaa prefers alpine skiing
<ddaa> if only  because I really cannot use a snowboard, and it's frustrating because it can do rather well with a pair of skis
<ddaa> lifeless: SteveA: jamesh: ping
<ddaa> MEETING STARTS
<jamesh> knee boards aren't too bad
<jamesh> but they work better on water than snow
<ddaa> This is the "things with obscure names" meeting, and you all know what we are here for.
<lifeless> hi
<ddaa> Next meeting 2006-09-18, 10:00 UTC.
<ddaa> mpool will be on leave.
<ddaa>  * roll call
<ddaa>  * production status
<ddaa>  * advertising
<ddaa>  * importd batch progress
<ddaa>  * release finder
<ddaa>  * Python import
<ddaa>  * strategic plan
<ddaa>  * bzr-lp features
<ddaa>  * interesting bzr list threads
<ddaa>  * 1.0 targets
<ddaa>  * critical bugs
<ddaa>  * pending sysadmin tasks
<ddaa>  * any other business
<ddaa> If you wish to change the time of the meeting or add/remove agenda items, say "bzzzt!".
<ddaa> If we are short on time, the "any other business" item will be automatically, dropped. So if you ''want'' to discuss something more, speak up now.
<SteveA> hi
* SteveA reads agenda
<ddaa> == Roll call ==
<ddaa> mpool is on leave until September 19th.
<SteveA> please add "meeting in vilnius"
<ddaa> SteveA: ok
<ddaa> Everybody else has said hello already, so let's move on.
<ddaa> == Prodution status ==
<ddaa> Nothing to report.
<ddaa> That was easy.
<ddaa> spiv: it looks like things do not tend to crash and burn while _you_ are away
<spiv> Except me ;)
<ddaa> == Advertising ==
<ddaa> Last meeting actions:
<ddaa>  * spiv: blog about similarities between SVN and bzr checkouts, in relation to Launchpad.
<ddaa>  * ddaa: when rolled out, to blog about branch UI improvements.
<ddaa>  * unassigned: when rolled out, blog about --create-prefix not being needed anymore.
<ddaa>  * ddaa: link to existing launchpad-bazaar blog entries from help.launchpad.net, and link from the front page.
<ddaa> I did the latter: Blog entries linked from https://help.launchpad.net/BazaarLinks.
<jamesh> I did an entry about the third
<ddaa> I'm not sure it's worth blogging about about branch UI improvement since jamesh already mentioned them.
<ddaa> spiv: still looking forward to reading your stuff.
<lifeless> this week is possibly not the week for that for spiv
<lifeless> release freeze is in 1 week
<ddaa> No hurry.
<ddaa> I can nag again next week.
<SteveA> oh, there was something from last week.  ddaa, please add to agenda "things to do before you go on leave"
<ddaa> SteveA: ack
<spiv> Yeah, nag me again next week please.
<ddaa> So I'll drop all actions except for spiv's one.
<ddaa> == Importd batch progress ==
<ddaa> Last meeting actions:
<ddaa>  * ddaa: sort out what to do with BatchProgress with lifeless and mpool
<ddaa> I started that discussion. Lifeless suggests leaving the code in Launchpad, I still do not know how to ensure the provided API stays in sync with what bzrlib actually use.
<ddaa> lifeless: can you help me on that this week?
<SteveA> jamesh: what's the URL of your blog entry?
<lifeless> ddaa: probably not. Next week sure.
<jamesh> SteveA: http://blogs.gnome.org/view/jamesh/2006/09/06/0
<ddaa> SteveA: it's on https://help.launchpad.net/BazaarLinks
<jamesh> it was just a short one
<SteveA> ddaa: a test perhaps?
<SteveA> a test in launchpad that checks that the API works
<ddaa> SteveA: the problem is keeping those tests in sync with bzrlib, while it's not part of bzr
<SteveA> I don't see that as a problem
<ddaa> lifeless: okay, I can live with that delta in production for a while, if SteveA is happy with me doing that.
<SteveA> the tests will fail if they get out of sync, surely?
<SteveA> and so the test says "hello.  API not in sync.  do the work to make it in sync"
<lifeless> can we move on - no actions will be taken on that until next week regardless
<ddaa> SteveA: talk about that later, I think it more tricky than you appear to think.
<ddaa> == Release finder ==
<ddaa>  * jamesh: report on PRF progress.
<jamesh> My fixes went in last week.  Last I checked, PRF was still running today and hadn't crashed
<lifeless> sweet
<SteveA> product release finder?
* SteveA checks the "P"
<lifeless> 2 years after inception and it will be deployable
<jamesh> since it is an initial run, it has to do a fair bit of work and downloads
<lifeless> product release finder
<SteveA> thanks
<lifeless> ddaa: PLEASE stop abbreviating ithis
<ddaa> okay, then "release finder"
<lifeless> product release finder
<lifeless> we've had long threads about this
<jamesh> while it hasn't been run in production, it will make the staging nightly.sh quite slow since it will essentially be doing a first run every night
<ddaa> we still disagree
<SteveA> it's fine to abbreviate provided the first time you introduce it in a meeting or a text you say: ... the Product Release Finder (PRF)
<SteveA> then all is clear
<lifeless> ddaa: currently you have been outvoted, its not 'me vs you' - can you at least go with the majority and have the disagreement as a separate discussion 
<ddaa> SteveA: okay
<ddaa> lifeless: the first person to abbreviate it in IRC was not me.
<jamesh> So if we are happy with the results, I think we should do at least one run in production
<jamesh> so that we'll be seeing the incremental runtime of the program
<lifeless> jamesh: if it passes successfully, lets get a report of the productname : version : tarballs it found
<lifeless> jamesh: in tabular form. that will be easy to sanity check
<jamesh> okay
<lifeless> in fact, productname : series : version : tarball
<ddaa> sounds good, though I think something that people will ask very soon after will be ability to delete releases
<jamesh> ddaa: and the answer will be "no" :)
<ddaa> I think that's a bad answere to give users.
<jamesh> they might ask if they can fix the release dates though
<ddaa> bah... we could have a discussion about that, either users will make my point soon enough, or it's not worth the time, so I'll shut ip.
<ddaa> jamesh: good news, thank you
<ddaa> == Python import ==
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/56360
<ddaa>  * ddaa: report on Python import progress
<ddaa> The resolver errors were fixed. The Python import is now blocked on what appears to be a bzr bug in Testament.as_text_lines when file names contain non-ascii chars.
<ddaa> More details: At the revision of the failure, the svn repo adds files like "/python/trunk/Mac/Contrib/PyIDE-src/Scripts/Hack/Remove .pyc files". In Testament.as_text_lines, the expression [line.encode('utf-8') for line in r]  raises UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 74: ordinal not in range(128).
<SteveA> I think that's from ancient history
<lifeless> ddaa: is there a bug files for that ?
<ddaa> IOW, it's currently blocked on getting a more recent bzr in rocketfuel
<SteveA> I remember we saw something like that when we tried importing python with tla or baz
<lifeless> ddaa: I'm not sure that this bug is fixed in bzr.dev.
<lifeless> SteveA: not the same issue, please dont be distracted by it
<SteveA> ok
<lifeless> ddaa: can you please verify it is fixed by 0.10 ?
<ddaa> lifeless: I can run a smoke test to check.
<SteveA> from looking at the code, looks like "line" is accidentally ascii, then gets implicitly decoded to unicode in order to run .encode() on it
<ddaa> ACTION: ddaa to try reproducing this bug with bzr 0.10
<ddaa> and bzr.dev too
<lifeless> ddaa: thank you
<ddaa> moving on
<ddaa> == strategic plan ==
<ddaa>  * SteveA, ddaa, lifeless, jamesh: asked to review 32/Bazaar.
<ddaa> I think I did (though I do not remember for sure)
<jamesh> I haven't sent him comments yet
<ddaa> spiv: I think the same applies to you.
<lifeless> ddaa: I already reviewed it as it was written
<ddaa> ok
<spiv> I read it, but I don't have any comments to make.
<ddaa> SteveA: ?
<SteveA> not done yet
<lifeless> fun https://features.launchpad.net/products/bzr/+spec/bundle-piping
<ddaa> okay, no big rush, but jamesh and SteveA please make mpool happy before he comes back.
<ddaa> something like 9 days from now
<ddaa> == bzr-lp features ==
<ddaa>  * mpool: report on progress for bzr-lp features
<ddaa> mpool is on leave
<ddaa> does somebody want to speak for him?
<lifeless> nope
<lifeless> hurh hurh hurh
<jamesh> is that the lp:// URL stuff, or something else?
<ddaa> jamesh: both
<lifeless> theres a collection of stuff
<lifeless> which is all moving along piecemeal
<ddaa> as is this meeting
<ddaa> == Interesting bzr list threads ==
<ddaa> After discussion with SteveA about the difficulty of keeping up with the bzr mailing list to stay updated about interesting developments in the bzr community, I would like to ask the fine folks here to point me to "interesting" threads that happened in the past week.
<ddaa> My definition of interesting here is:
<ddaa>  * Design discussions
<ddaa>  * Discussion of new/future bzr features
<ddaa>  * Release management decisions
<ddaa>  * Discussions providing interesting insights into the needs of users
<ddaa>  * Anything related to Launchpad
<ddaa> That explicitly excludes "noise" like:
<ddaa>  * Simple code review
<ddaa>  * Discussion of internal implementation choices
<ddaa>  * Trivial user support
<lifeless> uhm
<jamesh> I've been pushing the working tree revision properties stuff through, which is a prerequisite for the AutomaticBugBranchLinks spec
<lifeless> wow, I have no idea how to generate that list trivially
<ddaa> jamesh: seen that, looks like good idea IMO
<lifeless> RM I've nothing to report on
<lifeless> nothing major has changed in the design philosophy
<ddaa> It's a bit of an experiment, but maybe guys here could take some notes with pertinent keywords (e.g. words in the subject of the emails)
<lifeless> new features have been creeping into 0.11 at quite a reasonable pace
<ddaa> Anyway, since it's the first time you read of that, let's just see if that gives something useful for next week's meeting.
<ddaa> == Things to do before you go on leave ==
<ddaa> SteveA: the stage is yours
<SteveA> thanks
<SteveA> so, iirc, there were some loose ends left around that we found out about in this meeting after spiv went on vacation
<SteveA> can anyone remember the details?
<lifeless> yes
<lifeless> push all branches
<ddaa> something about spiv branches not being pushed
<lifeless> send an email saying where its at
<SteveA> I'm going to put up a standard policy for "things to do before you go on vacation" -- a checklist
<SteveA> for the launchpad team
<SteveA> and I want to make sure it will cover the situation we had a short while ago
<SteveA> ok
<SteveA> so
<SteveA>  - push all branches
<spiv> A checklist would be really handy.
<SteveA>  - send an email about ongoing / outstanding issues
<SteveA>   including details of branches in progress
<lifeless> right, the situation was : Martin and I wanted to move the smart server forward, but could not because about 2 days work was not pushed
<SteveA> the idea being that others can continue where you left off
* ddaa has been pondering using bound branches to avoid forgetting to push
<lifeless> in this particular case, there is a bunch of uncommitted reorganisation going on which is fine - but it would have been good to have an rsync'd copy of that available
<SteveA> spiv: in this case, did it occur to you to do this kind of thing as you were preparing to leave on vacation?  I'm wondering how best to remind people
<SteveA> even if we have a checklist, it needs to be used
<spiv> I find before a holiday I tend to go "oh oops, I need to make sure I have StaffCalendar updated, make sure I have nothing still assigned in PendingReviews, oh I better make sure I have a holiday notice on my review queue, while I'm on the wiki fill in apologies for meetings...."
<SteveA> ah, so more things for the checklist
<SteveA> particularly for reviewers
<ddaa> SteveA: if the checklist includes some sort of report, it should be pretty easy to check for people who just completely forget.
<spiv> With the pushing in this case, I usually push work regularly, but as lifeless points out there was a lot of uncommitted state due to the nature of the work at that point.
<lifeless> reviewers need to put their leave in the reviews page
<lifeless> having things assigned in the reviews page is ok
<SteveA> ok
<lifeless> I will reassign if you put a 'I'm on leave' marker there - but an email to me would help
<SteveA> thanks for talking through this
<SteveA> I'll formulate a launchpad policy for this
<SteveA> ddaa: thanks, done
<ddaa> ACTION: SteveA to increase the bureaucracy of the Lauchpad team
<ddaa> ;)
<ddaa> == Meeting in Vilnius ==
<ddaa> SteveA: ?
<SteveA> tim penhey is joining us soon
<lifeless> cool
<SteveA> he'll report to mpool, work from NZ
<ddaa> That's cool!
<ddaa> ?
<SteveA> and he may stop over in sydney on his way to dunedin
<ddaa> Report to mpool?
<SteveA> or however you spell dunedin
<lifeless> he was a couple o years ahead of me at uni, small world syndrome
<SteveA> mpool will be taking a greater interest in how launchpad is used with bzr, once 1.0 is out
<SteveA> and, considering timezones too, this is a natural thing
<ddaa> SteveA: does that mean I'll be reporting to mpool too?
<SteveA> no
<SteveA> you'll stay reporting to me
<SteveA> and then you and tim will work together a lot
<SteveA> we'll see how it goes
<ddaa> Weird to have a pair with two different line managers.
<SteveA> not so weird
<lifeless> ddaa: I think locality of time zone is quite important
<SteveA> I sometimes coordinate with mdz a lot
<SteveA> but also, mpool and I do talk a lot
* ddaa remembers the section about Hybrid Organizations in the book he read recently
<lifeless> one of things that we had difficulty with was effective communication
<SteveA> and we talk with each other a lot too :-)
<lifeless> due to us being effectivelyt 12 hours out
<ddaa> Makes sense, after all.
<ddaa> So, what about Vilnius?
<SteveA> so, tim and I have talked about him coming to vilnius to get an introduction to bzr in launchpad
<SteveA> first week of october is one set of dates possible
<SteveA> ddaa: woiuld you be able to come then too?
<ddaa> I do not have anything specific planned.
<SteveA> another possibility is 2nd week of october
<ddaa> So, provisionally, yes.
<SteveA> and that might work out better for me, as host
<SteveA> I'll know after wednesday
<SteveA> ddaa: is either week okay with you?
<jamesh> mbp also posted about https://wiki.canonical.com/BazaarSprintSydney2006 last week
<ddaa> as far as I recall, yes. I'll start preparing Ewa to it.
<jamesh> is any coordination with that needed?
<lifeless> should not be
<lifeless> separate topics, codebases, agendas
<ddaa> lifeless++
<SteveA> jamesh: have you considered going to the sydney sprint?
<jamesh> SteveA: if it would be useful for me to go, then sure.
<lifeless> would you like to come ?
<lifeless> we want to be doing bzr code primarily during that time
<lifeless> smart server, dirstate, performance
<SteveA> I see various lp things on the agenda
<SteveA> if the lp things will be in one half of the week, james could go for that
<lifeless> its 2 weeks long
<SteveA> s/week/weeks/
<jamesh> the LP integration stuff looks interesting, and I've been doing a bit of work on that.  It would be interesting to see what the bzr folks think of our plans
<SteveA> anyway, doesn't need to be deicided in this meeting
<lifeless> there is LP stuff there
<SteveA> jamesh: one week on the lp/bzr stuff in that meeting is fine with me
<SteveA> sort it out with lifeless and mpool
<lifeless> because bzr/lp is the strategic overview
<lifeless> but I fully expect most of the time to be the detail of getting bzr to win vs hg
<jamesh> Launchpad as a compliment to Bazaar could definitely help there ...
<lifeless> yup
<SteveA> ddaa: anything else on the agenda?
<ddaa> that has been the plan for like... 11 months now?
<ddaa> == 1.0 targets ==
<ddaa> [skipping] 
<ddaa> == Critical bugs ==
<ddaa> Good news, worth showing off.
<ddaa> https://launchpad.net/bugs/31308 Cannot set branch associated to a product series.
<ddaa>  * Last meeting jamesh agreed to work on that. Jamesh, progress?
<lifeless> its in staging
<ddaa> https://launchpad.net/bugs/37897 renaming project, product or series breaks vcs imports. Fix released.
<ddaa>  * ddaa: report on deployment
<ddaa> https://launchpad.net/bugs/51130 cannot use +admin on a branch I own. Fix released.
<jamesh> I tried it out for some products I own, and it works nicely
<ddaa> importd-publish-source was deployed, squashing https://launchpad.net/bugs/37897. A few imports did not have a cscvs working tree and failed the transition:
<ddaa>  * silo (now on git), console-data (svn branch renamed), xrestop (now on git), libmusicbrainz and libtunepimp (now on svn). All these are obsolete and unfixable and are now STOPPED.
<ddaa>  * exe (https://launchpad.net/products/exe/trunk) also failed: their svn repo appears offline, the download instructions have not been updated, and I had no reply when asking on IRC (#exe on freenode). Marked the import STOPPED by lack of information needed to fix it.
<lifeless> theres a report on lp-users of a CVS repo that needs the host changed in lp
<ddaa> In other words, all our criticals will be fixed by the next rollou.
<ddaa> lifeless: thanks, will do today.
<ddaa> MEETING CLOSED
<ddaa> Sorry for the abrupt end, be we are overdue already.
<SteveA> ddaa: I'd like a voice call with you today.
<ddaa> sorry for forgetting to report last week
<ddaa> I was a bad boy.
<ddaa> What time would you like to voice?
<ddaa> A bit later in the afternoon would be nice, say between 1400 and 1600 UTC?
<SteveA> 1600 is way too late
<SteveA> 1400 is possible.  earlier is better for me
<ddaa> I'm concerned about coordinating lunch with Ewa, she's not well at all at the moment.
<ddaa> And out of the house right now.
<ddaa> SteveA: we can have voice in 30 mins if you want.
<ddaa> Just time for me to have a little break.
<SteveA> that's a very good time for me.  thanks
<SteveA> 30 mins past the next hour
<ddaa> That's 1130 UTC
<SteveA> lifeless: got time for a quick phone call?
* ddaa goes to the place
<lifeless> SteveA: after the review meeting
<SteveA> which is in 2 mins?
<lifeless> yes
<SteveA> ok, thanks
#launchpad-meeting 2006-09-14
<SteveA> ok
<SteveA> hi salgado 
<SteveA> hi flacoste 
<salgado> hello
<flacoste> hi
<SteveA> so, we have some specs
<flacoste> https://launchpad.canonical.com/LaunchpadI18n
<salgado> https://launchpad.canonical.com/LocalizedSupportTracker
<flacoste> https://launchpad.canonical.com/LocalizedLoginWorkflow
<salgado> https://launchpad.canonical.com/LocalizedSupportRequests
<salgado> this is team work
<flacoste> :-)
<SteveA> excellnet
<SteveA> and the purpose of this meeting is to answer what question exactly?
<salgado> which of these specs are going to be a 1.0 target
<flacoste> basically, is LocalizedLoginWorkflow still a 1.0 target?
<flacoste> or what part of LaunchpadI18n can be done for 1.0
<SteveA> ah -- note the typo
<SteveA> https://launchpad.canonical.com/LocalizedLoginWorfklow
<SteveA> Worfklow
<SteveA> it is klingon :-)
<salgado> heh
* salgado fixes
<SteveA> ok
<SteveA> next question... resources
<SteveA> what resources do we have to do any work we agree to today?
<SteveA> iow
<SteveA> what do you guys have on your 1.0 specs lists?
<salgado> I have person-creation-rationale, which I hope to finish by middle of next week
<flacoste> i have the support-tracker-workflow specification which is quite big and then support-trackwer-views and help pages for the support tracker
<salgado> then I have direct-person-creation, which has a blocker issue and is not even speced yet
<flacoste> SteveA: do we have a date for 1.0?
<SteveA> yes and no
<SteveA> let's say, mid to end oct
<flacoste> i think i can finish my 1.0 assigned spec in ~3 weeks
<SteveA> ok, well... that doesn't leave much resources to do this.
<flacoste> indeed, not very much
<SteveA> so, we have a couple of themes
<SteveA> 1. recording what language support requests are in
<SteveA> 2. internationalizing launchpad, and localizing at least the login and support parts
<SteveA> part 1 i'd say is a definite 1.0 thing
<flacoste> i would like to point out that the way the spec about #1 is worded, it relies on users being able to state which languages they support
<SteveA> which language they support?
<SteveA> you mean, for supporters?
<flacoste> exactly
<SteveA> or for people filing support requests?
<salgado> yeah, for support contacts, mainly
<SteveA> okay
<salgado> so, if I'm support contact of Launchpad, I want to receive only support requests on the languages that I speak
<SteveA> I see
<SteveA> that sounds very reasonable
<salgado> this is already possible, but not very "visible"
<salgado> (I'm assuming we're going to reuse the existent PersonLanguages table)
<SteveA> well, I think first of all yes
<SteveA> we might find that ability to translate is different from ability to answer support requests, for example
<SteveA> so there are differing language levels
<SteveA> but that can come later
<flacoste> another use of the person's languages is to select which requests to display in listing
<flacoste> The spec stated: "All code related to searching support requests will have to be changed to only display requests written in one of the user's preferred languages."
<SteveA> admins should be able to see it all, somehow
<SteveA> otherwise, I can imagine support problems
<salgado> flacoste, how hard will it be to do that?
<salgado> I think everybody should be able to see them all
<flacoste> salgado: well, it is not hard to implement, just another criteria on the searchTickets() method
<SteveA> or, get everyone to see them all
<SteveA> but show the language with them
<SteveA> I dont' know
<SteveA> we'll have to see what works best
<salgado> the biggest problem I can see is with tsearch2, as our stopwords and stemming algorithms are for english only, IIRC
<SteveA> so, to be totally honest, I don't see us making significant progress on internationalization before 1.0
<SteveA> I'd rather say "internationalization and localization is a 1.1 goal"
<SteveA> so, allow support requests to be filed in particular languages, and searched for in particular languages etc.
<SteveA> but put the internationalization off until we do it properly across all  launchpad
<SteveA> what do you guys think about that proposition?
<flacoste> salgado: yeah, you have a point about the tsearch2, for text search in non-english languages
<salgado> sounds good to me, but the we'll have even bigger problems with searching for tickets in languages other than english than we already have for searches in english
<SteveA> the stopwords and stemming should do no *harm* for other languages
<SteveA> they should just help english
<SteveA> which is still our main language
<SteveA> (unlike orkut, where portugese is the main language ;-) )
<flacoste> salgado: it would require some changes to the fti implementation to use the ticket's language for proper indexing (tsearch2 can support that)
<flacoste> but we can delay that for 1.1
<salgado> yeah, that sounds good
<salgado> so, https://launchpad.canonical.com/LocalizedSupportRequests is targeted at 1.0
<salgado> but the others aren't
<salgado> is that right?
<flacoste> i'm not sure about that
<flacoste> i'm not sure it will be really helpful to have a language attribute on the support requests without any other i18n support
<flacoste> it's not like we had lot of non-English support requests
<flacoste> there will be a lot of changes to the support tracker for 1.0, so it might be better not to add a half-baked feature to the lot
<flacoste> wouldn't look to good, imho
<SteveA> I don't see that it's half-baked
<flacoste> SteveA: sorry, that was too strong a word
<SteveA> I mean, if we add detection of an appropriate language from browser metadata, maybe it would be okay
<SteveA> so the appropriate langauge is detected by default
<SteveA> also, I'd like to note that we *can* do non-1.0 things after the 1.0 things are complete
<SteveA> so, we can say "full internationalization + localization of login is a goal right after 1.0"
<SteveA> and that doesn't mean the *release* of 1.0
<salgado> another problem I can see is that, if we give people the option to make a request in their native language, they'll prefer that, of course, but they may not get an answer because there's no support contact who speak that language
<SteveA> but the completion of 1.0 features
<SteveA> salgado: that's a bug in the spec, perhaps
<flacoste> "When there is no support contact that speaks the new request language,
<flacoste> the others get a small notification about the new request. The user
<flacoste> gets an informational message about the fact that no support contact
<flacoste> speaks his language.
<flacoste> "
<SteveA> ah, nice
<salgado> ooops
<SteveA> of course, for 1.0, that message is in english
<SteveA> so, depending on how 1.0 targets go, maybe we can get (for example) salgado and stub to do i18n
<flacoste> SteveA: the user will have to know some English in order to be able to post a support request in a non-English language, so that is probably not a problem
<SteveA> once their 1.0 tasks are complete
<flacoste> that makes sense, my idea is more that the localized-support-request should have a low 1.0 priority
<flacoste> SteveA, salgado: are we done here?
<SteveA> ok
<salgado> I think so
<SteveA> well, the 1.0 thing is more like
<SteveA> "here are the tasks by which people and management will be judged"
<SteveA> so I'm very happy to have these out of 1.0
<SteveA> but as a high priority for after 1.0
<flacoste> that's fine by me
<SteveA> that way, if we miss them, it's okay, but they get done as soon as possible after the stuff agreed for 1.0
<SteveA> so, do give them a high priority in the spec tracker
<SteveA> but just leave the support tracker one as 1.0
<salgado> okay. will do
* flacoste added some issues raised in the meeting to the Unresolved section of the spec
<flacoste> SteveA, salgado: thanks for the discussion
<salgado> thanks flacoste, SteveA!
<SteveA> ok, thanks guys
#launchpad-meeting 2006-09-15
* Starting logfile irclogs/launchpad-meeting.log
-ChanServ(ChanServ@services.)- You do not have channel operator access to [#canonical-ops] 
* #canonical-ops is desynced from brown.freenode.net at 06:02am
#launchpad-meeting 2008-09-09
<jml> hi
<barry_> hi
<barry_> #startmeeting
<MootBot> Meeting started at 21:00. The chair is barry_.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry_> yay mootbot!
<thumper> hi
<barry_> hello everybody and welcome to this week's asiapac reviewers meeting.  who's here today?
<thumper> I have the laptop in the kitchen :)
<jml> present and accounted for!
<mwhudson> hi
 * barry_ uses his laptop in front of the political shows :)
<barry_> == Agenda ==
<barry_>  * Roll call
<barry_>  * Next meeting
<barry_>  * Action items
<barry_>  * Queue status
<barry_>  * Mentoring update
<barry_>  * Review process
<barry_> [TOPIC] next meeting
<MootBot> New Topic:  next meeting
<barry_> week += 1?
<thumper> ya
<barry_> cool
<mwhudson> yeah
<barry_> [TOPIC] action items
<MootBot> New Topic:  action items
<barry_> i have none from last week
<barry_> [TOPIC] queue status
<MootBot> New Topic:  queue status
<barry_> doesn't look to bad to me.  any comments from y'all?
<mwhudson> i haven't looked at the queue in weeks :)
<barry_> :)
 * barry_ skips mentoring update
<barry_> [TOPIC] review process
<MootBot> New Topic:  review process
<jml> I'm all in favour of having one.
<barry_> we had a long discussion about pre-impl calls at the ameu meeting
<barry_> cprov and i need to email the list about it, but briefly:
<barry_> we'd like to include some new sections, such as the q/a plan, and an extended demo section
<barry_> (the latter which might go in a user story)
<jml> new sections in the cover letter?
<barry_> jml: probably for the q/a plan.  Rinchen will love that
<barry_> i'm not convinced the demo section shouldn't go in a user story doctest
<barry_> but we'll take the discussion to the ml
<mwhudson> barry_: as in, part of the branch?
<barry_> mwhudson: yep
<mwhudson> barry_: user stories are slow and fragile as a rule
<jml> barry_: ok.
<mwhudson> barry_: we want less slowness and less fragility in our tests, not more
<barry_> mwhudson: the way we do them, yes <wink>
<barry_> we want to move a lot of what is currently going in pagetests into faster view tests
<barry_> but those aren't user stories
<mwhudson> ok, then they're not stories :)
<barry_> bingo
 * thumper waits for the definition of a user story
<mwhudson> anyway, i'll save this for the list discussion
<jml> also, although I'm not sure it's relevant for these items, we should be aiming for faster turn-around of branches, and more paperwork can work against this.
<barry_> thumper: the way i think about it is almost exactly like an extended demo section.  usually one url doesn't cut it
<thumper> I tend to use more than one url when needed
<barry_> jml: i'm very keen on your thoughts about that.  both kiko and i feel there's too much overhead in our process
<barry_> especially for some types of branches
<mwhudson> part of this seems like it could be summarised by saying "make sure you and your reviewer both understand the intent of the branch"
<barry_> hence, kiko's push for post-landing reviews
<barry_> mwhudson: yep
 * jml isn't so sure about that one :)
 * barry_ isn't either
 * mwhudson is fairly sure about that one
<jml> but I'll think about it.
<jml> mwhudson: heh
<barry_> but i understand /why/ kiko is thinking about them
<jml> me too
<jml> I think the first thing we should do is get more lean-style metrics
<barry_> jml: what kind of metrics would you find helpful?
<jml> barry_: for branches, time from creation to review submit, time from review submit to review response, time from final response to landing etc.
<jml> barry_: things along the lines of the percentage value adding stuff that the Poppen*s got us to do.
 * barry_ nods
<jml> a lot of the info is already there in Launchpad, and we'll only get more as we dogfood.
<jml> anyway, this is probably another discussion.
<barry_> yep
<barry_> that's really all i have.  let me open up the floor to you guys.  anything you want to bring up?
 * mwhudson can't think of anything
<thumper> I don't really have anything either
<thumper> abentley is working towards review diffs
<barry_> i hope you guys still find these meetings helpful ;)
<barry_> thumper: rock
<jml> barry_: I do.
<barry_> jml: excellent
<thumper> I think it is important to have someone that is able to sync the two review groups
<thumper> barry_: so, are you still thinking of shifting to AU/NZ?
<barry_> we'll see on november 4th :)
<mwhudson> oh right, since my flight change i won
<thumper> I see the republicans are 4 points ahead in the polls (so says my local paper)
<mwhudson> t actually be in the us on the 2nd
 * barry_ feels ill
<barry_> mwhudson: that'll be fun
<thumper> barry_: I take it you are barraking for the democrates then?
<mwhudson> emma will be though
<barry_> i'm an independent, but yeah i don't think grampa simpson is the best thing for us
<barry_> annnyyywayyy.  thanks everybody!
<thumper> thanks barry_
<barry_> #endmeeting
<MootBot> Meeting finished at 21:20.
<barry_> have a good day everybody
<mwhudson> you too barry_
<jml> cya
#launchpad-meeting 2008-09-10
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everyone and welcome to this week's ameu reviewer's meeting.  who's here today?
<salgado> me
<flacoste> me
<BjornT> me
<abentley> me
<bac> me
<barry> danilos, EdwinGrubb, sinzui ping
<sinzui> me
<danilos> me
<EdwinGrubb> me
<barry> gmb: ping?
<gmb> me
 * sinzui sips lovely coffee
<gmb> barry: Oops, sorry.
<bigjools> me
<barry> cprov-afk: ping
<barry> anybody else missing?
<cprov-afk> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * The Kiko way to quick and easy reviews (barry, kiko)
<barry>  * Pre-implementation calls
<barry>  * If there's time, the old boring script
<barry>    * Next meeting
<barry>    * Action items
<barry>    * Queue status
<barry>    * Mentoring update
<barry> i want to try something different today
<barry> i want to talk about the fun stuff first, and then do the boring scripted stuff last if there's time.  any objections?
<barry> great!
<barry> :)
<barry> [TOPIC] quick and easy reviews
<MootBot> New Topic:  quick and easy reviews
<barry> did anybody /not/ get a chance to read the message i sent around this morning on this topic?
<bac> me
<abentley> me
<barry> (it's not a problem of course :)
<flacoste> better than that, i tried it out!
<barry> flacoste: excellent!  i'll ask you about your feedback in a bit
<barry> so let me try to summarize...
<barry> we want to make reviewing quick, easy, and fun
<barry> kiko, flacoste and i have been talking about this a bit so here are some key insights:
<barry> - reviews are a mediocre qa tool, but an excellent learning tool
<barry> - don't research, ask questions
<barry> - ask more questions
<barry> - improve your code scanning abilities; identify changes, ask a question and move on
<barry> - concentrate on stuff that looks weird.  if you see something that looks weird... ask a question!
<barry> there's more in the email but the goal is this:
<barry> medium sized branches should take around 15 minutes to review.  large branches no longer than 30 minutes
<barry> first let me ask flacoste to give his impressions, having been our trail blazer, then let's open this to some discussion...
<barry> flacoste: ?
<flacoste> i agree, it was fun and fast
<flacoste> well
<flacoste> it was a 2000 lines branch
<flacoste> so it still took 1.5h
<flacoste> but still
<barry> !
<flacoste> i'm looking forward to seeing stub's reply
<flacoste> but there was a lot of questions in there
 * barry spends that much time on an 800 line branch
<flacoste> and the trick is really that as soon as you stop and wonder...
<flacoste> write down a question
<barry> flacoste: great point: trust your gut.  i've been trying to train myself that if the question pops in my mind, don't suppress it
<barry> ask it
<barry> flacoste: anything else?
<flacoste> not really, it's that simple
<flacoste> but like i said this means that all initial reviews are needs-reply
<flacoste> which is fine, but i'll see how it unfolds
<barry> flacoste: thanks.  okay.  i'll open the floor for discussion
<abentley> I've found that people are slow to answer questions when doing on-call reviews.  The process just drags.
<abentley> Also, if the main purpose of reviews is QA, and they're a mediocre tool, are they worth it?
<sinzui> I have found developers more than happy to explain how I'm wrong during on-call reviews.
<bigjools> then go to the next review, that's the dev's problem not yours.  OCRs are meant for quick reviews.
<barry> bigjools: +1.  we want to reduce stall
<barry> and remember, it's the dev's responsibility to shepherd their branch, and to respond to questions
<bigjools> exactly
<barry> abentley: review is never going to make a branch perfect anyway
<flacoste> the main purpose of a review isn't QA
<gmb> We can't catch the majority of annoying bugs using reviews. We *can* prevent a lot of stupid bugs by doing them.
<abentley> barry: Yeah, but a sloppy review isn't even going to prevent the quality of launchpad's codebase from deteriorating.
<barry> abentley: kiko's insight is that reviews are for learning and questioning first.  it's by the process of questioning that the dev begins to re-examine some of the assumptions they've made
<flacoste> but to ensure some uniformity in code
<flacoste> and to improve the quality of the code
<flacoste> and also to spread knowledge around
<flacoste> that last point is probably the most important
<flacoste> a lot of ideas will cross-pollinate through reviews
<flacoste> where the reviewer will either learn a new technique by looking at the code
<flacoste> or will suggest an improvement that will make the dev learn a new pattern or technique
<barry> flacoste, gmb exactly
<gmb> Actually, I'd *really* like us to emphasise that reviews are not a bug prevention tool.
<bigjools> something that we do in Soyuz is a "pre-review" with a domain expert, it's just a quick look at the code to make sure it's doing what we all expect it to do before a real review
<barry> abentley: i think more emphasis on pre/mid-impls and continuous qa will do more to improve quality
<gmb> Because doing a review and trying to look for bugs makes life really, really hard for the reviewer, and hurts my brain.
<barry> bigjools: that's very interesting
<gmb> The checks for a review should be:
<bigjools> so maybe pre-review to look for bugs, main review for the big picture?
<gmb>  * Does the code do what it says it does (needs a domain expert sometimes)
<gmb>  * Is the code covered in tests
<gmb>  * If there's something weird, why is it weird?
<gmb>  * Does to code conform to our standards.
<abentley> gmb: bugs are hard to catch in review.  Lack of test coverage is easier.  Design flaws easier still.
<gmb> abentley: Right. Design flaws should be caught in the pre-imp.
<sinzui> gmb: I also look for: does the code reinvent what we already have?
<gmb> sinzui: That's not always easy if you don't know much about domain context though.
<abentley> gmb: IME, pre-imp focuses on "what", not "how".
<gmb> abentley: I always try to come to a pre-imp ready-to-code, which means I have tests, which means I have a design.
<sinzui> gmb: Reviewers can can see outside the domain, where common problems are solved.
<barry> gmb: though you /can/ sniff out refactoring potential even if you don't know specifically.  if in doubt... ask!
<gmb> True enough.
<gmb> And I confess I like weilding the YAGNI bat every once in a while.
<abentley> gmb: I don't.  And I don't agree that having tests means you have enough design to be sure there aren't design flaws.
<barry> abentley: it's not the reviewer's responsibility to uncover design flaws, imo, that's also way too late in the process
<kiko> abentley, sure, but what impact could that have on review? the most you can say "this code looks like crap. how can we improve it?"
<barry> kiko: and if so, ask that question and kick it out quickly
<bigjools> barry: but it's a useful backtop
<abentley> kiko: You can say "doing it that way will scale badly and fail in production.  Have you considered doing it this way?"
<kiko> abentley, sure, and that's insightful, but if it was me I would not even state, and just ask "how well will this scale in production, considering we have 1500 neutrinos being frobbed every run of the proton accelerator?"
<kiko> I always ask
<kiko> let the coder figure out the answer
<barry> bigjools: yes, but only as a sanity check.  iow, if it smells bad, it's the dev's burden of proof
<kiko> and TBH I don't care too much if it works or not -- I just care that I get a reasonable answer from the coder
<bigjools> barry: agreed
<barry> it makes them stop and think, and maybe identify holes in their own design or code
<barry> so anyway, i encourage you all to respond to the ml thread.  be critical and (yes you guessed it) ask question!
<barry> cprov-afk: has to leave early and sends his apologies
<barry> [TOPIC] pre-impls
<MootBot> New Topic:  pre-impls
<barry> i have just a few thoughts, which i'm going to put into an email after this meetingggg
<barry> so you're getting the raw brain dump :)
<barry> - we want to include beuno in pre-impls concerning u/i.  do a 3-way call with him to sanity check th eui
<barry> - is it okay to bounce branches that have no pre-impl?
<barry> - btw, a pre-impl can also be a mid-impl
<barry> - include the q/a plan in the cover letter (cprov's email which i havent' read yet)
<barry> - no pre-imp, no on-call review?
<barry> - one exception: cleanup branches.  do 'em fast, get 'em reviewed fast, land it... JFDI
<barry> that's it.  any comments?
<sinzui> When we do UI changes, do we include a sketch?
<BjornT> i think it's ok to bounce branches that have no pre-impl call, if they have design flaws. if not, no reason to bounce.
<barry> sinzui: are you a good artist? :)
<barry> BjornT: good point.  a lot depends (for me) on the cover letter.  if it's detailed enough that i understand the tradeoffs and design decisions, i might let it pass
<barry> if not, bounce and move on
<barry> sinzui: i'm not sure how beuno wants to work re: ui review prep.  we'll have to ask.  or do you mean in the cover letter?
<sinzui> barry: I write tests and implementation before I do a preimp. I image I would also be using ascii art to illustrate behaviour.
<sinzui> s/implementation/implementation examples/
<barry> sinzui: ah.  is that because you're trying to figure out how to attack the issue?
<barry> i ask because i try not to write anything before having the pre-imp, except notes & cover
<sinzui> barry: right. Only one implementation example ever worked by pasting it into the code as I recall.
<sinzui> barry: I use tests to set scope, judge the number of branches I need, and to establish ne APIs.
<barry> sinzui: i agree that all those thing make for a solidly researched branch
<sinzui> I suppose I am really doing a mid-imp since I may have the branch complete before I talk to someone.
<barry> sinzui: which is fine :)
<barry> okay, we have just a couple of minutes left.  as i said, i'll take this to the ml too
<barry> any comments on the new format?  i'm trying to get away from the old boring scripted meeting
<flacoste> works from now
<flacoste> but it's not like the old scripted one
<flacoste> was taking most of the meeting
<barry> flacoste: yeah, but i like the meat up front :)
<flacoste> it's just that the first common 10 minutes are at the end instead of the beginning
<barry> anyway, we're out of time, so thanks everybody!
<barry> #endmeeting
<MootBot> Meeting finished at 09:45.
#launchpad-meeting 2008-09-11
<Rinchen> hello mootbot
<Rinchen> feeling like working today?
<cprov-afk> noooo, what a surprise !
 * jtv checks the team calendar for "mootbot vacation"
<barry> Rinchen: it worked for me yesterday
<Rinchen> I spoke yesterday with seeker about it
<bigjools> did he spank the mootbot
<Rinchen> yeah
<Rinchen> the problem is that he's got very little time and it's written in eggdrop.  The plan is to convert it to python and run it as part of ubottu
<Rinchen> but that will likely take months
<kiko> Rinchen, we could run mootbot ourselves on EC2? :)
<rockstar> Geez. I didn't even think things were actually written in eggdrop.
<Rinchen> kiko, I've asked seeker for the source :-)
<kiko> rockstar, you volunteer you!!
<bigjools> how hard can it be to write our own
<rockstar> kiko, Ack!
 * rockstar cowers in the corner.
<Rinchen> kiko, I don't know if https://edge.launchpad.net/mootbot has the latest version or not
<kiko> rockstar, and after that you can work on cscvs!!
<Rinchen> bigjools, not hard me thinks
<rockstar> kiko, are you dooming me to a life of rough projects?
<Rinchen> bigjools, just takes time and we're all kinda short on that
<Rinchen> rockstar, not rough projects, educational ones!
<kiko> rockstar, if you fix a rough project a week it's only two weeks so far!
<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:00. The chair is Rinchen.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Rinchen> [TOPIC] Roll Call
<Rinchen> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<MootBot> New Topic:  Roll Call
<rockstar> me
<Rinchen> me
<bigjools> mini me
<beuno> me
<abentley> me
<gmb> Meeeeee
<adeuring> me
<salgado> me
<barry> him
<BjornT> me
<gmb> bigjools: So, that's just 'jools' then.
<jtv> me
<EdwinGrubbs> me
<mars> me
<kiko> pt
<sinzui> me
<matsubara> me
<bigjools> gmb: <golfclap>
<Rinchen> gmb, or "ools"
<cprov-afk> me
<bac> me
<Rinchen> Ursinha-lunch, mrevel - ping
<bigjools> mini jewels
<thumper> me
<Ursinha-lunch> me
<Ursinha-lunch> !
<BjornT> intellectronica: ping
<intellectronica> me
<BjornT> bugs team is here
<leonardr> me
<Rinchen> bigjools, murahem is away today?
<jtv> translations is just me today
<gmb> allenap's doing feathery things today, of course.
<gmb> Um...
<gmb> *fathery*
<bigjools> Rinchen: he's been excused for the ramadan month of September
<Rinchen> mrevel?
<Rinchen> bigjools, k
 * sinzui wonders what feathery things are if they are not bird.
<Rinchen> so soyuz is here
 * bigjools needs to invent some Flying Spaghetti Monsterism excuse
<flacoste> me
<thumper> code is here
<Rinchen> thanks BjornT and thumper
<abentley> bigjools: Pirate Appreciation Day
<flacoste> Foundations is here modulo stub
<bigjools> arr
<kiko> YARR
<Rinchen> Looks like releases is here minus mrevel who I'm sure will be along shortly and be very duly embarrassed for being tardy ;-)
<Rinchen> ok, let's get going
<bigjools> the sun is over the yardarm
<Rinchen> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report & Critical Bugs (matsubara/ursinha)
<Rinchen>  * Operations report (mthaddon/herb/spm)
<Rinchen>  * DBA report (stub)
<Rinchen>  * Sysadmin requests (Rinchen)
<Rinchen>  * New packages required (salgado)
<Rinchen>  * Keep status of Critical bugs up to date (flacoste)
<barry> abentley: 8 days and counting
<Rinchen> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<mrevel> me
<mrevel> sorry
<abentley> barry: pardon?
<Rinchen> Anyone not available next week?
<barry> abentley: http://www.talklikeapirate.com/
<Rinchen> ok so then we're all set
<Rinchen> [AGREED] Next meeting same time, same place, Sept 18th
<MootBot> AGREED received:  Next meeting same time, same place, Sept 18th
<Rinchen> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<Rinchen> we have a few
<Rinchen>  * matsubara to add a note in the MeetingAgenda page about disclosing private bugs that will be discussed during the meeting
<Rinchen>  * thumper to chase status of resolve_lp_path (bug 260206)
<Rinchen>  * barry to work on more refinements for MailingListAPIView (bug 259440)
<Rinchen>  * stub to fix bug on account merging raising db constraint (bug 263672)
<Rinchen>  * stub to patch our fti regexp to avoid OOPSes (bug 174368) and discuss a proper fix with jtv
<ubottu> Launchpad bug 260206 in launchpad-bazaar "resolve_lp_path oopses with ValueError" [Medium,Fix committed] https://launchpad.net/bugs/260206
<ubottu> Launchpad bug 259440 in launchpad-foundations "OOPS in MailingListAPIView" [Critical,Fix released] https://launchpad.net/bugs/259440
<ubottu> Launchpad bug 263672 in launchpad-foundations "account merging triggering database constraint" [High,Fix committed] https://launchpad.net/bugs/263672
<ubottu> Launchpad bug 174368 in launchpad-foundations "Search query triggering error in tsearch" [Undecided,Confirmed] https://launchpad.net/bugs/174368
<thumper> Rinchen: as you can see bug 260206 is fix-committed
<Ursinha-lunch> resolve_lp_path bug is fix committed
<Ursinha-lunch> :)
<barry> Rinchen: it's bug 269025 now
<ubottu> Launchpad bug 269025 in launchpad-foundations "Batch subscription information requests in XMLRPC" [Critical,Triaged] https://launchpad.net/bugs/269025
<Rinchen> thanks thumper and Ursinha-lunch
<Ursinha-lunch> bug 263672 is also fix committed
<Rinchen> thanks barry.  I don't need to track this as an action then so I'm removing it and we'll track is as a critical bug
 * Ursinha-lunch kicks ubottu 
<Rinchen> matsubara ?
<Rinchen> no stub...hmmm
 * kiko chuckles
<matsubara> Rinchen: yes?
<Rinchen> ok, I checked and matsubara's is completed
<kiko> so
<Rinchen> looks like stub has one but not the other completed
<kiko> I know that stub fixed one half of his todos there
<kiko> exactly
<Rinchen> so I'll keep stub's second one on the list then
 * kiko high Vs Rinchen 
<Ursinha> bug 174368 - i was going to talk with stub about it
<ubottu> Launchpad bug 174368 in launchpad-foundations "Search query triggering error in tsearch" [Undecided,Confirmed] https://launchpad.net/bugs/174368
<kiko> parfait
<Rinchen> right o
 * Rinchen looks up the mootbot syntax
<Rinchen> [ACTION]  stub to patch our fti regexp to avoid OOPSes (bug 174368) and discuss a proper fix with jtv
<MootBot> ACTION received:   stub to patch our fti regexp to avoid OOPSes (bug 174368) and discuss a proper fix with jtv
<jtv> Rinchen: we never got around to that.
<beuno> Rinchen, 15:00 < MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Rinchen> [TOPIC] Oops report & Critical Bugs (matsubara/ursinha)
<MootBot> New Topic:  Oops report & Critical Bugs (matsubara/ursinha)
<Ursinha> show time
<Ursinha> bugs for today: 254918,  268612, 260140, 268264
<Ursinha> for foundations
<Ursinha> bug 254918 (timeout in +addbranch): lifeless filed it
<ubottu> Bug 254918 on http://launchpad.net/bugs/254918 is private
<bigjools> can I add bug 268421
<ubottu> Bug 268421 on http://launchpad.net/bugs/268421 is private
<Ursinha> bigjools, i got one for you, bug 268612
<ubottu> Launchpad bug 268612 in launchpad "Security adapter results should be cached" [Undecided,New] https://launchpad.net/bugs/268612
<bigjools> too kind :)  it's in PQM right now
<Ursinha> bigjools, as that bug was a critical, guess matsubara will talk about that later
<Ursinha> cool, taking note
<Ursinha> the timeout in +addbranch, matsubara asked me to point it
<Ursinha> bug 254918
<bigjools> oh wait, 268612 is not critical
<ubottu> Bug 254918 on http://launchpad.net/bugs/254918 is private
<kiko> the first is a thumper one I guess..
<thumper> kiko: I looked at it, and I don't think so
<kiko> thumper, what do you think it is?
<Ursinha> bigjools, but 268421 is
<thumper> some weird publication issue
<thumper> not a simple code issue
<thumper> some retry, timeout, failure reporting issue
<matsubara> maybe foundations could add some input in the report.
<kiko> sounds good
<Ursinha> so
<Ursinha> anyone of foundations that want to add something to that?
<kiko> flacoste?
<flacoste> no
<kiko> heh
<Ursinha> salgado?
<salgado> am I allowed to say no as well?
<thumper> no
<kiko> salgado, no, you are not fixing mailman issues, so you have no trump card
<salgado> which bug is that, btw?
<kiko> http://launchpad.net/bugs/254918
<MootBot> LINK received:  http://launchpad.net/bugs/254918
<ubottu> Error: This bug is private
<Ursinha> bug 254918
<ubottu> Error: This bug is private
<Rinchen>  /culture_shift Please say "yes, I'd love to help!"  :-)
<ubottu> Bug 254918 on http://launchpad.net/bugs/254918 is private
<Ursinha> what do you say?
<salgado> it looks nasty
<flacoste> which one?
<salgado> I'll take it
<Ursinha> cool
<flacoste> #268421 is easy
<flacoste> well, kind of
<salgado> but they want to give me the other one
<Ursinha> flacoste, it's 254918
<kiko> flacoste, that one is for next month, we know already
<Ursinha> so cool
<Ursinha> moving on?
<Ursinha> bug 260140
<ubottu> Launchpad bug 260140 in launchpad-bazaar "revisions' rss feed timing out for some projects" [High,Fix committed] https://launchpad.net/bugs/260140
<matsubara> Ursinha: let's not block on 254918. salgado can give some input later in the report.
<kiko> Ursinha, is that still happening on edge?
<matsubara> and that issue doesn't happen often anyway
<Ursinha> kiko, no
<Ursinha> only in LP
<Ursinha> lpnet
<kiko> Ursinha, okay, let's arrange a CP for that revision onto lpnet then
<Ursinha> cool! that's what i was expecting
<Ursinha> great
<Ursinha> bug 268264
<ubottu> Launchpad bug 268264 in launchpad-bazaar "Listing +subscribedbranches by most interesting causes LP to crash" [Undecided,New] https://launchpad.net/bugs/268264
<Ursinha> need a person to this bug
<thumper> I'll take it for now
<Ursinha> it's a ugly bug
<flacoste> Ursinha: sorry, for jumping in, but has anybody been able to reproduce this?
<Ursinha> cool!
<Ursinha> flacoste, which one?
<flacoste> Ursinha: #254918
<rockstar> thumper, I did that initial branch.  Would you like me to look at it?
<thumper> rockstar: yes please
<salgado> flacoste, I bet no
<rockstar> thumper, I'm on it.
<flacoste> then i say ignore for now
<Ursinha> flacoste, i didn't, matsubara?
<salgado> I've seen something similar, though
<salgado> I'll have a quick look
<matsubara> Ursinha: nope.
<Ursinha> flacoste, so, no
<flacoste> salgado: then a very quick look :-)
<matsubara> Ursinha: just keep an eye for similar timeout OOPSes. if they start to happen more frequently add to the report and ask some input from foundations
<Ursinha> well, for me that's all, other bugs are critical and matsubara will talk about them
<salgado> flacoste, not the same thing I saw before.  I'll ignore it for now
<Ursinha> matsubara, sure, i'm watching
<matsubara> all right
<matsubara> so, here we go
<matsubara> We have 3 critical bugs not in progress yet. They are bugs 265067, 268421, 269025
<ubottu> Launchpad bug 265067 in launchpad-foundations "MailingListAPIView still oopsing" [Critical,Triaged] https://launchpad.net/bugs/265067
<ubottu> Bug 268421 on http://launchpad.net/bugs/268421 is private
<matsubara> barry, can I move 265067 and 269025 to in progress? Anything blocking you there?
<flacoste> spurious codehosting failures!!!
<barry> matsubara: see flacoste :)
<matsubara> flacoste, news about 268421? (you said that one is easy, cool!)
<Ursinha> matsubara, i guess he's working hard on that
<matsubara> Soyuz has two in progress, bugs 269021 and 269014. Any blockers there, cprov?
<barry> 269025 is in progress
<ubottu> Launchpad bug 269021 in soyuz "The PPA index page times out for private archives" [Critical,In progress] https://launchpad.net/bugs/269021
<ubottu> Launchpad bug 269014 in soyuz "sha256 checksums in release files for all gzipped files broken" [Critical,In progress] https://launchpad.net/bugs/269014
<bigjools> 1st one is in PQM
<barry> matsubara: 265067 is trying to land and get cb'd
<cprov-afk> I'm on the 2nd
<thumper> flacoste: we save them for the end of week 3
<matsubara> cprov-afk: what's it?
<cprov-afk> matsubara: a bug in python-apt in hardy that needs a workaround in soyuz
<kiko> cprov-afk, a funny bug too
<kiko> broken since 1903
<kiko> detected today
<bigjools> sounds like a beer commercial
<Ursinha> haha :)
<Rinchen> 1903? wow, that's like 105 coding years ago ;-)
<kiko> Rinchen the mathmatician
<kiko> kiko the speler
<bigjools> but not if you consider coding years are like dog years
<kiko> Rinchen, moving on
 * Rinchen checks the clock.
<matsubara> flacoste: by your previous comments, I guess you want to punt 268421 to salgado?
<salgado> eh?
<flacoste> matsubara: that might not be a bad idea  :-)
 * jijua77 is away: Away
<matsubara> salgado: if you're ok with (please, say yes). we can move on :-)
 * kiko pushes Rinchen 
<salgado> I won't have much time to look into that today
<Rinchen> matsubara, Ursinha - that's your signal to come to a closure :-)
<matsubara> well, it's critical, you need to drop everything to deal with or we need to drop the importance
<Ursinha> Rinchen, guess we have to have critical bugs assigned before that
<matsubara> s/with/with it/
<flacoste> well, there is critical and critical :-)
<matsubara> heh
<salgado> matsubara, right, but after this meeting I have my weekly 1-1 call with flacoste and there won't be much hours left for my day after that
<flacoste> matsubara: anyway, leave me assigned to it for now
<matsubara> well, since you guys will be talking, you can sort it out :-)
<matsubara> thanks flacoste and salgado
<Rinchen> anything else matsubara?
<matsubara> back to you Rinchen, sorry for the delay
<Rinchen> no worries, thanks matsubara and Ursinha
<Rinchen> [TOPIC] Operations report
<MootBot> New Topic:  Operations report
<Rinchen> I guess I have this one today
<Rinchen> â¢ Codebrowse still having some issues
<Rinchen> â¢ App servers still dying. Similar to codebrowse, not as often
<Rinchen> â¢ IO Sprinting in London all this week
<Rinchen> â¢ All the LOSA LP wiki pages are being moved to the LP wiki
<Rinchen> â¢ We're currently doing a bug report sprint to record all the
<Rinchen> funkies/manual tasks that should be in the UI
<Rinchen> â¢ Confirming that we don't have any more RF branches that can be hosted
<Rinchen> on LP itself???
<Rinchen> â¢ psycopg2 has been upgraded on all Prod servers
<Rinchen> â¢ That's it from the LOSA team unless there are any questions
<Rinchen>  
<Rinchen> There was an email thread about this as well
<Rinchen> My suggestion is to discuss these items there and move on with the meeting.
<Rinchen> Objections?
<matsubara> no
<Rinchen> ok.
<Rinchen> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<Rinchen> stub is missing again
<Rinchen> flacoste, I'll leave the DBA report to you
<flacoste> DBA report (proxied for stub who was abducted by Morpheus)
<flacoste> - DB patches landed.
<flacoste> - Some more late DB patch to review.
<flacoste> - Will investigate test-suite slow-down since the multiple store support landed.
<flacoste> EOT
<Rinchen> any status updates flacoste on the master slave project?
<flacoste> we will begin testing on demo once the replication scripts branch lands
<flacoste> review is in progress
<Rinchen> super
<flacoste> but the priority is the multiple-stores fall-out
<Rinchen> any questions for flacoste ?
<flacoste> since we are rolloing that out next week
<Rinchen> thanks flacoste
<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 have an RT in for bigjools' shared imap for community help rotation
<bigjools> woohoo
<kiko> phew! awesome!
 * beuno has the ticket to update help.lp.net and news.lp.net
<Rinchen> anyone else blocked on anything, especially for the roll-out next week?
<beuno> since before I started
<beuno> still not urgent though
<beuno> https://rt.admin.canonical.com/Ticket/Display.html
<kiko> beuno, the help thing?
<mrevel> Rinchen: 28196 - spam plugin - would be nice but so old not urgent
<beuno> ehm
<Rinchen> beuno, I spoke with elmo about giving the LOSAs access to do that. He's going to see what can be done.
<matsubara> beuno: out of curiosity, what needs updating there?
<kiko> Rinchen, can we get the help wiki finally updated?
<beuno> Rinchen, yes
<beuno> https://rt.admin.canonical.com/Ticket/Display.html?id=31420
<beuno> kiko, yes
<beuno> matsubara, the themes
<beuno> I have branches for both
<Rinchen> in theory, the LOSAs should be able to do help.l.n  but they don't have access to news.l.n
<matsubara> beuno: okie, thanks
<Rinchen> beuno, can you please email the losa email addy and see if they can take the ticket for help.l.n?
<Rinchen> Tom has done roll-outs there before so I know they have access
<beuno> Rinchen, will do. We still need news though
<Rinchen> maybe they can do it as a training exercise since they are in London
<Rinchen> ok, thanks.
<beuno> thanks Rinchen
<Rinchen> [TOPIC] New packages required (salgado)
<MootBot> New Topic:  New packages required (salgado)
 * henninge has to run but hopes that everybody will take it easy on jtv
<salgado> what's it for me this week?
<Rinchen> ok then. thanks salgado
<salgado> I've just emailed the LOSAs to know what version of psycopg2 they're using now.  we want to use the same for development
<salgado> btw
<salgado> thanks Rinchen
<Rinchen> good move
<Rinchen> [TOPIC] Keep status of Critical bugs up to date (flacoste)
<MootBot> New Topic:  Keep status of Critical bugs up to date (flacoste)
<flacoste> yeah
<flacoste> so it's important when we work on Critical bugs
<flacoste> especially public ones
<flacoste> to add a comment at least daily to inform of progress
<flacoste> in the mailing list time out
<flacoste> for example
<flacoste> there were no comments posted for nearly one week
<flacoste> although we did progress and work on it everyday
<Rinchen> no comments gives the community the impression that nobody is working on the problem
<flacoste> and that progress was communicated internally
<flacoste> through our standup notes
<flacoste> but for people external to the team, it just looks like we are twiddling our thumbs :-)
<flacoste> that's all, any comments?
<flacoste> +1, -1
<bigjools> +1
<Rinchen> +1
<Ursinha> +1
<beuno> +1
<matsubara> +1
<barry> flacoste: +1.  when can we have a "still working on it" button? :)
<jtv> barry++
<cprov-afk> +1
<Rinchen> The hard part is just trying to remember to actually comment on it.
<barry> flacoste: or do you spell that launchpadlib+pythongoo ?
<kiko> Rinchen, once a day sending an email to a bug number isn't that hard..
<flacoste> barry: actually, that's right!
<barry> Rinchen: if we can do it through the api, then cron's your bff
<Rinchen> kiko, I agree. Remembering to do that though isn't always easy
<thumper> +1
<Rinchen> anyway, thanks flacoste
 * barry starts a-hackin'
<Rinchen> we have one tiny late edition to the agenda
<Rinchen>  
<Rinchen> [TOPIC] Changes to this meeting! (kiko)
<MootBot> New Topic:  Changes to this meeting! (kiko)
<kiko> Rinchen, maybe emailing bug numbers should be easier...
<kiko> anyway
<kiko> ***********************
<kiko> howdy everybody
<kiko> if you look at your clocks, there's 1 minute left of meeting
<thumper> 0
<kiko> and I don't mean just this week's
<kiko> I hope you enjoyed it
<kiko> because it's the last week we will run the meeting with this audience and in this format
<mrevell> Oooh, we're witnessing history.
<kiko> from now on, the thursday meetings are disbanded
<jtv> gasp
<Ursinha> oh my
 * bigjools boggles
<barry> :-o
<gmb> THE SKY IS FALLING...
<Rinchen> but, there is a but
<Rinchen> :-)
<kiko> jeroen and stub don't have to be (pretend they are?) zombies any more
<barry> we fear change
<gmb> *drumroll*
<kiko> we'll be having a Production meeting
<kiko> which will be run by joey's dynamic duo
<Rinchen> Ursinha, matsubara ^^
<Ursinha> hahaha
<Ursinha> cool
 * mrevell is Alf the butler
<Ursinha> lol
<rockstar> mrevell, wasn't Alf an alien?
<kiko> attendees will be releases, LOSAs and each team's QA contact
<bigjools> mrevell: lol
<intellectronica> what's a team's qa contact?
 * abentley pictures an orange, pig-nosed alien butler.
<kiko> you are encouraged to come if there is some production issue that you are concerned about
<kiko> intellectronica, it's a role which will be established by next wednesday by your team lead <wink>
<sinzui> mrevell: You must have been strategically shaven that last time I saw you
 * kiko agrees with abentley 
<rockstar> http://en.wikipedia.org/wiki/ALF_(TV_series)
<MootBot> LINK received:  http://en.wikipedia.org/wiki/ALF_(TV_series)
<kiko> and that's all the news. cancel the item out of your agenda. cherish the memories. and look forward to more meaty, less washy meetings.
<intellectronica> kiko: can team members take turns?
<mrevell> Dynamic duo ... Batman and Robin ... which leaves me as Alfred Pennyworth
<gmb> intellectronica: +1
<bigjools> does this mean that Ursinha and matsubara have to wear capes?
<flacoste> kiko: when does it play?
<kiko> flacoste, right now. this was the last meeting.
<Ursinha> bigjools, i don't want to be robin
<bigjools> who does!
<matsubara> I'm not wearing my underwear over my pants
<Ursinha> lol
<gmb> mrevell: Which makes you Michael Caine, by current reckoning.
<Rinchen> mrevell, I guess that means I'm Commissioner Gordon then?
<kiko> mrevell, you are above and beyond these crude QA fanatics
<intellectronica> matsubara: please do next time
<matsubara> but it'd be cool to drive the batmobile!
<mrevell> Heh
<flacoste> kiko: when will the production meeting be held, and where?
<bigjools> matsubara: so you have to go change then?  /me ducks
<kiko> flacoste, that's for us to decide. I suggest the same time and place, but different attendees.
<flacoste> ok
<kiko> it was nice while it landed
<kiko> but 35 people is too much for a meeting
<rockstar> matsubara, Robin never drove the Batmobile
<kiko> it was also nice while it LASTED
 * bigjools applauds
<Rinchen> and it's a bit of a disruption during the week
<rockstar> He had that motorcycle.
<salgado> rockstar, just like the one matsubara has
<Rinchen> This of course means your daily team standups become even more valuable.
<kiko> rockstar, I think he didn't have a proper driver's license
<rockstar> kiko, so it was 49CC moped then?
<Rinchen> If you need something brought up, you can attend the production meeting or pass it to your QA contact
<Ursinha> kiko, matsubara has the license to drive motorcycles, i don't
<kiko> rockstar, I think he was an illegal
<kiko> exactly what Rinchen said
<kiko> stay tuned for the official announcement on-list
<kiko> and teamleads, look at your inboxes tonight :)
<rockstar> kiko, "an illegal" in my country is an illegal immigrant
<kiko> Rinchen, that's my item
<matsubara> salgado: my bike is much better than robin's
<Rinchen> [AGREED] This is the last, ever, weekly Team IRC Meeting. History hath been made.
<MootBot> AGREED received:  This is the last, ever, weekly Team IRC Meeting. History hath been made.
<sinzui> What, prey tell, was legal in a story about a vigilante?
<rockstar> +1 sinzui
<mrevell> I'
<mrevell> oops
<kiko> thanks Rinchen
<Rinchen> and with that, I bid you all, adieu
<bigjools> but not goodbye
<rockstar> But I seem to fool like Batman and Robin were All-American
<salgado> matsubara, you know... that's just your opinion, man
<mrevell> thanks all and god speed
<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:52.
<matsubara> salgado: I feel scammed. you previously owned it!
<Ursinha> hahahahah now i got the joke
<salgado> and I loved it, but it's nothing compared to robin's
<rockstar> Robin's had guns on it and stuff.
<rockstar> I think you have to live in the Southern U.S. to get away with that these days.
<bigjools> yeehaw
<salgado> rockstar, or any country in the southern hemisphere (with very few exceptions)
<rockstar> salgado,  I lived in Guyana for a year.  I've seen something similar.
<rockstar> Although it was usually a pedal bike
<kiko> rockstar, guyana! ah, right, I remember now!
#launchpad-meeting 2009-09-09
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everybody and welcome to this week's ameu reviewer's meeting.  who's here today?
<noodles775> me
<henninge> me
<bac> me
<danilos> me
<barry> gmb sends his apologies
<bigjools> me
<adeuring> me
<flacoste> me
<henninge> jtv has better things^W^W^W cannot be here either ...
<henninge> ;)
<barry> henninge: thanks :)
<barry> flacoste, gary_poster, salgado, cprov, allenap, mars, sinzui ping
<salgado> me
<cprov> me
<sinzui> me
<flacoste> re-me
<allenap> me
<gary_poster> me
<barry> flacoste: oops!
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<flacoste> barry: that's ok, you are used to pinging me
<barry>  * Roll call
<barry>  * Action items
<barry>  * UI review call update
<barry>  * `__iter__()` in model objects? [cprov, barry]
<barry>  * mkstemp()/open() combination leaks file-descriptors [cprov]
<barry>  * Guidelines changes for tests checking systems pre-requisites (specific umasks, app configurations) [maxb, cprov]
<barry>  * Invalid markup; The <script> tag requires a close tag (Do not: <script type="text/javascript" src="..."/>) [Curtis]
<barry>  * 4-space indents for CSS styles [barry]
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry> flacoste: :)
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * gary_poster and barry will transfer review guidelines from the old wiki and old old wiki to the new wiki
<barry> we suck
<gary_poster> yup, joint suckage
<barry> gary_poster: that sounds icky :)
<gary_poster> heh, yeah, I thought that after I read it too
<barry> [TOPIC]  * UI review call update
<MootBot> New Topic:   * UI review call update
<barry> gary_poster: let's get together later today to plan that out
<gary_poster> +1
<barry> i was not on the ui review call because of the us holiday.  was anybody here on that call, and was anything interesting discussed?
<noodles775> barry: it was canceled as there was only intellectronica jtv and myself.
<barry> noodles775: cool, thanks
<barry> [TOPIC]  * `__iter__()` in model objects? [cprov, barry]
<MootBot> New Topic:   * `__iter__()` in model objects? [cprov, barry]
<barry> cprov: do you remember what this one was about?
<intellectronica> me too
<cprov> barry: well, it's about the how confusing it is to read code that iterate over a distroseries and get distroarchseries ;)
<barry> cprov: so, it being more readable to do something like "for das in ds.distro_arch_series:" than "for das in ds"?
<bigjools> are you saying __iter__ should be confined to collections?
<cprov> bigjools: being more radical, I think we should never need __iter__ in content classes.
<bigjools> that's what I mean :)
<barry> bigjools: i was going to say, object's that have only one natural iteration, but i think your rule is better
<cprov> bigjools: iterate of a multiple-join (ish) property.
<cprov> s/of/over, sorry.
<barry> cprov: i think +1.  you'll never be confused by naming the property explicitly.  i can only think that maybe it would be okay for IFnordSet to have an __iter__ that iterates over IFnords
<sinzui> I agree
<cprov> agreed
<barry> beauty.  any objections?
<barry> 5...4...3...2...1
<barry> [TOPIC]  * mkstemp()/open() combination leaks file-descriptors [cprov]
<MootBot> New Topic:   * mkstemp()/open() combination leaks file-descriptors [cprov]
<barry> (got a few for cprov today :)
<cprov> barry: everyone know mkstemp returns and open file descriptor, right ?
 * barry does
<flacoste> fire
<cprov> barry: and if it is not bound to the file you open afterwards it won't be automatically released by python.
<cprov> when you close the file.
<flacoste> why use mkstemp?
<flacoste> i usually prefer creating a temporary directory
<flacoste> and creating files in it
<flacoste> and removing the directory at end of test
<flacoste> using addCleanup
<barry> flacoste: yes, and if you need a tempfile and don't want to hassle with a directory, you should probably close the fd right after mkstemp() and reopen the file name with open()
<cprov> flacoste: that's a good point for testing use-cases
<cprov> flacoste: soyuz uses temp files in production workflows as well.
<barry> <cough>with-statement</cough> :)
<bigjools> how's that python2.6 readiness coming along then barry? :)
 * barry looks at gary_poster and flacoste 
<gary_poster> it's coming. :-) 2.5 first
<wgrant> The 2.5 status is actually pretty good.
<wgrant> Mostly benign failures.
<bigjools> then let's JFDI
<barry> my new machine arrives today (hopefully) and i'm going straight to karmic.  i'll be itchin' and bitchin' for 2.6 :)
<cprov> anyway, the message I was trying to pass is: be aware of msktemp() ... open() callsites. They should be mkstemp()...os.close(fd)
<allenap> barry: Or use os.fdopen().
<sinzui> benign failures? Does it apologise before going belly up?
<barry> allenap: yep; though i almost always want the filename for various purposes
<barry> cprov: +1, thanks.  so, when you're reviewing code, watch out for mkstemp(), mkdtemp(), open() or anything else that acquires external resources.  ask your dev "are you properly releasing this resource, and if so, where?"
<allenap> barry: I think you get that with fdopen though? It returns a file object for the fd, and the second element of the tuple returned from mkstemp() is the filename.
<barry> allenap: yep, if you want the file object and the filename
<barry> cprov: thanks for this topic.  i have one more for ya
<barry> [TOPIC]  * Guidelines changes for tests checking systems pre-requisites (specific umasks, app configurations) [maxb, cprov]
<MootBot> New Topic:   * Guidelines changes for tests checking systems pre-requisites (specific umasks, app configurations) [maxb, cprov]
<cprov> IIRC, it was specifically about our test suite running on system with use a non-default umask (022)
<wgrant> (and the devscripts config issue)
<cprov> in lp.archivepublisher there as few tests that check files permission
<barry> cprov: well, that's under user control, right?  or does our test suite set the umask?  are you aware of specific umask failures in our test suite?  i remember fixing a bunch of those when i first came on board because i use umask 0002
<cprov> barry: I don't remember exactly which tests failed for maxb. Do you run the test suite locally frequently ?
 * maxb waves
<maxb> and reads scrollback
<barry> cprov: i can't get through the whole thing on my current dev box.  we'll see about my new one (drive faster fedex!)
<maxb> barry: umask 0002 currently breaks some (one?) soyuz test
<barry> in general though, i would say that any test that is umask sensitive is broken
<wgrant> There is only one.
<barry> maxb: is there a bug on that?  imo, it's a broken test
<maxb> The point of the action item is to suggest that the test guidelines should stipulate either that tests should set the appropriate environment, or should check and error clearly if they can't
<cprov> barry: right, I agreed, the test should adjust umask to the expected value.
<maxb> I don't think there's a bug at present, /me scribbles note
<barry> maxb, cprov +1
<sinzui> the tests or the code should set the mask? if there is a test for the mask, I believe the code should set it
<barry> so, as you review branches, be aware of code that might be sensitive to environmental issues, and question whether the tests are fragile because of that
<barry> sinzui: agreed
<barry> cprov, maxb thanks for bringing this up.  anything else on this topic?
<cprov> barry: possibly, there is a pending change in our guideline.
<cprov> barry: we use to rely on a pristine ubuntu env for testing and deploying LP
<cprov> barry: from what we've discussed code sensitive to environment changes should set/ensure the expected configurations now.
<barry> cprov: but umask is really part of the user env, not ubuntu env
<flacoste> and even relying on a prisitine ubuntu env is broken
<cprov> barry: right, extent ubuntu env to 'default ubuntu user env'
<maxb> Relying on a pristine environment to run the testsuite is developer-unfriendly
<flacoste> exactly
<barry> cprov: would you take an action item to update our guidelines with this change?
<cprov> right, and that's the change that should be included in our guidelines.
<cprov> barry: yes, sure.
<barry> cprov: great, thanks.
<barry> [ACTION] cprov to update guidelines to clarify how code sensitive to env changes should be written
<MootBot> ACTION received:  cprov to update guidelines to clarify how code sensitive to env changes should be written
<barry> thanks again for bringing this up
<barry> [TOPIC]  * Invalid markup; The <script> tag requires a close tag (Do not: <script type="text/javascript" src="..."/>) [Curtis]
<MootBot> New Topic:   * Invalid markup; The <script> tag requires a close tag (Do not: <script type="text/javascript" src="..."/>) [Curtis]
<sinzui> The HTML 4.x spec requires that the script element have a close tag.
<sinzui> Do not do this: <script type="text/javascript" src="..."/> because the template will not fix our mistake
<sinzui> I saw the compact form in the DSP index and added the issue to todays agenda
<intellectronica> can we lint for this?
<sinzui> two hours later cprov reported that half the content of the apge was missing. I closed the tag and made it work
<sinzui> intellectronica: We need a HTML processor
 * sinzui is writing one
<intellectronica> we currently use xmllint, but we miss the opportunity to automatically discover things that are html
<sinzui> We use a bastardised version my navellint script that I wrote 7 years ago
<noodles775> wont a standard (x)html validator pick that up? (and help us get all our pages valid?)
<sinzui> I am now using an all python script that has a HTML validator
<noodles775> :)
<sinzui> noodles775: comtact is always correct for XML. this is an issue of schema/DTD validity
<sinzui> noodles775: and this is really hard given that PT is generating  HTML, it is not HTML
<noodles775> sinzui: yes, but I thought the w3c xhhtml validator pointed ... ah, ok.
<noodles775> So we could validate pages as part of our stories - but that's a separate topic I guess.
<sinzui> We know this has not happened often because Forefox hates it. The issue was fixed within a day of it landing.
<sinzui> noodles775: That is not a story though.
<barry> sinzui: is it just the <script> tag or other tags too?
<sinzui> We have a checker that runs over stanging
<noodles775> True (just convenient given we've rendered the content)
<sinzui> <script> is the only one that comes to mind.
<sinzui> noodles775: I do not
<barry> cool
<sinzui> noodles775: I render content in view tests. stories just hop from link to link and verify messages that the user sees
<noodles775> sinzui: yes - I don't mean that you output the content in the story (urgh), just that the time taken to render the content has already happened when you call click().
<sinzui> noodles775: another way of putting the issue is that users do not look at the source, we only care about the test that is seen and the links that are traversed
<noodles775> Yes, I agree - it's not the place for validation.
<intellectronica> i really don't think we should do validation in tests. that's what lint is fo
<sinzui> noodles775: given that content/markup is conditional in most templates, that does is using luck to test
<barry> we also often get false positives when linting our pts
<flacoste> we could have a builder runs the test suite in validation mode
<noodles775> intellectronica: sure, but if we wanted to do that, it would mean that lint would need render templates. It would be easier to simply run an external validator over lp.net, I think.
<sinzui> intellectronica: I agree. We want to trust the template engine makes sane markup. that requires up to create sane templates. This is really an issue where HTML 4.x is not XML.
<barry> folks.  we're out of time.  i don't think we'll solve this here, although let's keep sinzui's specific recommendation in mind.  we can talk more about pt validation on list
<sinzui> There is also the issue were we do this: <p></p>; which is also invalid. a <p> must contain content
<barry> #endmeeting
<MootBot> Meeting finished at 09:46.
<intellectronica> thanks barry
<barry> thanks everyone and apologies for going over
<deryck> thanks barry
#launchpad-meeting 2009-09-10
<barry> #startmeeting
<MootBot> Meeting started at 18:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> jml, rockstar, mwhudson hi!
<mwhudson> barry: hello
<rockstar> Hi barry
<jml> hi
<barry> so, shall i do a quick update from ameu?
<jml> yes please
<barry> there was no ui meeting on monday, so nothing to report there
<barry> * `__iter__()` in model objects?
<barry> we agreed that __iter__ should be avoided except in the case of IFnordSets iterating over IFnords
<barry> i should say "except possibly"
<barry> no mandate, but it's okay
<jml> what was the reasoning?
<barry> for things that aren't naturally collections, it's hard to know from looking at the call site what you're iterating over
<barry> cprov had a specific example that came up in a review and __iter__() just made things harder to understand
<barry> * mkstemp()/open() combination leaks file-descriptors
<barry> reviewers have to watch out for these calls when the code does not clearly close the open fd they return
<rockstar> Ah yes.  I reviewed a fix for this last week.
<barry> general call for questioning the opening/leaking of resources
<barry> when you see it in a review, make sure that the resource is being closed
<jml> barry, one nice workaround in test code is to have a wrapper method that calls mkstemp and then calls addCleanup appropriately
<jml> and then returns what mkstemp returns
<barry> jml: right.  that was brought up (or something along those lines)
<jml> naturally, that won't stop prod leaks
<barry> flacoste suggested using mkdtemp  and then creating files as needed in the directory, blowing the whole dir away in the cleanup
<jml> I tend to do that.
<barry> yep
<barry> * Guidelines changes for tests checking systems pre-requisites (specific umasks, app configurations)
<barry> this came up because maxb got bit by a umask sensitivity in the tests
<barry> and i remembered fixing a bunch of these ages ago when i first joined
<barry> (cause my umask isn't 022)
<barry> the general rule is, if the code requires a specific umask, then put it in the code and test for it, otherwise fiddle the umask in the test
<barry> the general guideline is, don't assume the user env is the default ubuntu user env
<jml> ok.
<mwhudson> i guess the hard part is that most of the time you won't realize you're depending on the umask
<mwhudson> but it's a good principle i guess
<barry> mwhudson: right.  i think in general we're pretty good right now.  maxb found one failing test in archives which was checking a file perm, and thus relying on umask
<mwhudson> oh right
<barry> * Invalid markup; The <script> tag requires a close tag (Do not: <script type="text/javascript" src="..."/>)
<maxb> the other aspect was invocations of devscripts tools which could be affected by ~/.devscripts. I'm going to do some grepping and liberally sprinkle --no-conf around
<jml> well, the more likely mistake is code that fails because it implicitly relies on a umask and is not tested
<barry> maxb: ah, i didn't know about that one
<jml> maxb, I didn't know about that _directory_
 * barry neither
 * mwhudson either
<mwhudson> maxb: tell us, what does it do? :)
<mwhudson> barry: shouldn't invalid <script> tags be caught by make lint?
<maxb> directory? ~/.devscripts is a conf file for tweaking the behaviour of the devscripts tools
<mwhudson> oh right
<maxb> when you tweak the behaviour of dch.... the tests get a bit upset :-)
<jml> oh right.
<barry> mwhudson: problem is, our lint only checks the templates, not the generated html
<mwhudson> barry: oh yes
<mwhudson> barry: and we have to generate <script> tags in strange ways because TAL*(&(*&(*&)(*
<jml> so!
<barry> right.  curtis gave some good background on what we do now, and what he hopes to do later.  there was some discussion about validating the html in the tests, which nobody much liked, validating on staging (or was it edge), etc.  no resolution for what we'd eventually like to do
<barry> so reviewers just have to watch out for that
<barry> and empty <p></p> which apparently ain't kosher either
<barry> that's it for ameu update
<jml> yay
<mwhudson> barry: is chameleon brain dead in the same way in this respect?
<jml> barry, one thing on the __iter__ guidelines.
<barry> mwhudson: didn't come up, and i don't know
<barry> jml: k
<mwhudson> jml: operator overloading is evil, don't do it?
 * mwhudson hopes
<jml> barry, I'd prefer it if we wrote that up as "don't use __iter__ for things that aren't obviously collections"
<jml> mwhudson, operator overloading is great.
<barry> jml: that's how bigjools worded it, which seemed perfect to me
<jml> barry, cool.
<mwhudson> jml: when correctly applied, yes
<jml> barry, I was a little worried about restricting it to IFooSet or whatever.
<mwhudson> branch_set[id] was not a good application :)
<barry> so.  i will now open the floor to y'all.  anything on your mind today?
<jml> mwhudson, agreed.
 * jml does
<barry> jml: ga-head
<jml> two things
<jml> the first is that I don't know the canonical page to get code review policy from...
<jml> is https://dev.launchpad.net/StyleGuides is ?
<jml> if so, it's a lot of stuff
<jml> the second is that I've been telling people to use the cover letter template as checklist, and not feel obliged to fill in every section.
<jml> which may have been overstepping the mark
<barry> jml: #1 do you mean canonical page for our coding guidelines, or for requesting reviews?
<jml> barry, guidelines
<jml> barry, what I have to look at as a reviewer / patch submitter to see if a patch passes.
<barry> yeah, that's the page, although gary and i have an action item we suck at to migrate stuff on the internal wiki (and old old internal wiki) into here.  it would be nice to find some time to clean those pages up too, but don't hold your breaht
<barry> er, breath
<mwhudson> barry: go go go!
<mwhudson> :)
<jml> barry, I understand the difficulty
<jml> and it sure is a tedious task
<barry> jml: but i understand the need to clarify and make concise.  seems like a general problem with wiki info (he says nearly completing this month's chr penance)
<jml> but at the rate we are accruing legislation, I'd be quite surprised if any reviewer had everything in their head...
 * barry does :)
<jml> barry, problem is, how can we tell :)
<barry> jml: just ask me :)
<jml> haha
<barry> but that's a joke.  i really don't either
<barry> jml: i wouldn't be surprised to see a lot of stuff slip through, but at least if either the dev or reviewer remembers, they have a place to look
<mwhudson> barry: can i call you at 4am to ask for clarification?
<barry> mwhudson: sure.  your 4am
<mwhudson> barry: :)
<barry> :)
<jml> barry, having those pages cleaned up would be great.
<barry> jml: seriously though, i'm very sympathetic, i just don't have a good answer
<jml> np
 * mwhudson hands barry a +1 sword of crap deletion
<jml> the other thing was the cover letter
<barry> cover letter, right!  do you use the lpreview-body bzr plugin?
<jml> no, I don't.
<jml> but also, I don't tell other people to do so.
<barry> it's pretty simple, but it gives you a standard template in the mailer of you choice, and i do think it's a good idea to fill everything out
<barry> it's also not hard
<jml> I agree with the spirit of it
<barry> jml: but... ?
<jml> but I don't feel like telling community contributors to fill out another form before I review their patch
<jml> and I'm happy enough if people demonstrate that they've thought about each of the items on https://dev.launchpad.net/QuickCoverLetterTemplate
<barry> jml: that's a good point.  we get paid to do menial tasks :)
<mwhudson> i think the point is that the reviewee gets the information to the reviewer
<mwhudson> the cover letter template is a handy checklist, no more
<jml> mwhudson, thank you :)
<jml> barry, what he said.
<mwhudson> checklists are great, btw
<rockstar> Just mentioning you've thought about it should suffice.
 * jml loves checklists
<barry> agreed!  i'm all for streamlining the process, especially for community contributors
 * rockstar can't use lpreview-body in his hardy chroot
<jml> barry, as for me, I like using the web ui, just so I can be using the web ui :)
<mwhudson> sounds like resounding agreement
<jml> yay
 * jml is done
<barry> yep.  though i do have to say that when i'm reviewing i find a filled out cover letter to be very helpful.  tbh, when i'm submitting a branch too
<barry> there might also be a difference between the ameu workflow and asiapac workflow, as in how interactive you can be, how big the queue is, etc.
<barry> so i say, use what works for you
<jml> +1
<mwhudson> i think we should certainly recommend the cover letter
<barry> mwhudson: i'd go a little further.  if you're queuing up for +activereviews, a cover letter is much more important.  if you're doing a highly interactive one, much less so
<mwhudson> barry: right
<barry> as you say, the important thing is to communicate the info, however that happens
<jml> btw
<jml> putting it out there
<jml> a flagon of $BEVERAGE to whoever makes a tool that submits a branch to Launchpad via ec2test based only on the MP page.
<barry> tarmac?
<rockstar> jml, you mean like Tarmac?
<jml> rockstar, I don't know!
<rockstar> I'm sure we could probably do something like that.
<rockstar> jml, let's talk after this.
<mwhudson> jml: get rockstar to do it, he won't ask for a flagon of single malt
<barry> rockstar: is a switch to tarmac in the cards after 3.0?
<rockstar> barry, well, lp-oops is using it, and some ubuone folks.  We're working out kinks still.
<mwhudson> abentley asked in today's call what PQM still does for us
<rockstar> abentley broke Tarmac by changing the API - another hint that we need a versioned API.
<mwhudson> over and above us just merging and pushing
<barry> mwhudson: that's easy.  it crashes and obfuscates
<rockstar> :)
<jml> it checks for db changes in devel
<jml> it enforces the testfix thing
<rockstar> We can do this all very easily in Tarmac.
<jml> (whether that is _for_ us or _against_ us is an open question)
<rockstar> If all we're doing is merging, I'm not even sure why PQM does a build at all.
<barry> testfix thing: hopefully much more transparently than pqm
<barry> pqm does /not/ run in 5 minutes
<rockstar> I think Tarmac will be a lot more useful when we have merge queues.
<barry> btw, did someone make ec2 --headless detach more quickly recently?
<jml> not I.
<mwhudson> barry: a new AMI for ec2test will help a lot there
<mwhudson> barry: i intend to do that today
<barry> fantastic.  it did not seem to take 45m the last time i used it (more like 5-10 which was a pleasant surprise)
<barry> could have been luck i s'pose
<mwhudson> two things are very variable
<mwhudson> 1) instance launch time
<jml> rockstar, what I want is "submit https://code.edge.launchpad.net/~wgrant/launchpad/whatever/+merge/212", for it to take the commit message, target branch and reviewer info and submit it to ec2test.
<mwhudson> 2) make schema time
<jml> rockstar, tarmac's README implies it does something else.
<mwhudson> (making schema before detaching is insane, but...)
<barry> mwhudson: yep.  would be nice to detach asap
<rockstar> jml, yea, like I said, we should talk after the meeting.  I'm sure my documentation skills are pure suckage.
<mwhudson> barry: i hope to get to that before I run out of BE time
 * jml assumed that it was after the meeting :)
<barry> rockstar: use sphinx
<mwhudson> (or sanity, whichever comes first)
<barry> jml: yes.  i think we're done.  any objections?
<mwhudson> nope
<rockstar> Nope.
<barry> #endmeeting
<MootBot> Meeting finished at 18:44.
<barry> thanks guys.  i'm off to dinner
<rockstar> jml, okay, so Tarmac.
<rockstar> Tarmac is just a script that goes out to find Approved merge proposals against a branch (currently only the development focus) and merges them automatically.
<rockstar> There are plugins to be hooked into it that can do all sorts of things.
<rockstar> I'm curious to know what the README tells you.
<jml> rockstar, that it's focused on projects, basically
<jml> I'm just looking at the README in trunk
<rockstar> Well, it is now.  My plan is that 0.3 is less about project development focus and more about branches.
<jml> rockstar, I don't want auto-landing, I want to store all the information that's in my head about how to land branches in some sort of computer program
<rockstar> jml, well, we can use the functionality from Tarmac, and maybe even just make it a Tarmac plugin.
<rockstar> I think we can easily do it.  Even something like the old Atomic PQM analyzer would be nice.
<jml> rockstar, what would using tarmac give me that launchpadlib doesn't?
<rockstar> jml, well, tarmac is implemented using launchpadlib, so most of the code is already written.
<rockstar> I'm just saying we give tarmac another task.  That's another goal of 0.3
<rockstar> I want Tarmac to be able to deal with all sorts of things related to landing a branch, whatever it is.
<rockstar> Many tools > one tool.
<rockstar> That's my goal anyway: suite of landing tools.
<rockstar> So you're free to implement something else, but I'm free to steal it.  :)
<jml> sure :)
<wgrant> What was APA? I've seen references to it, but nothing about what it does/did.
<jml> wgrant, I can't even remember what it did :
<jml> I think maybe it looked ahead in the pqm queue for failures
<wgrant> Ah.
<rockstar> wgrant, it used to grab all the branches in the PQM queue, make a super branch out of them, and test it in ec2
<rockstar> 'Twas quite nice in Week3
<Ursinha> OOPS-1347F129
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1347F129
<matsubara> #startmeeting
<MootBot> Meeting started at 10:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<bigjools> me
<gary_poster> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<intellectronica> me
<rockstar> ni!
<Ursinha> meee
<matsubara> sinzui, Chex, danilos: hi
<Chex> me
<sinzui> me
<sinzui> matsubara: sorry, I was reading the scrollback
<mbarnett> late me
<danilos> me
<matsubara> stub and danilos can join in later. let's move
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara>  * DBA report (stub)
<matsubara>  * Proposed items
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>     * barry to continue debug on bug 403606 after finishing 3.0 UI stuff
<matsubara>     * intellectronica to take a look or find someone to take a look on bug 408738 after finishing 3.0 UI stuff
<matsubara>     * ursinha to keep an eye on timeouts for person +branches pages and report back if the CP solved the issue or further action is needed
<matsubara>         * The timeouts are gone
<matsubara>     * matsubara to file a bug for OOPS-1342EA107 (ValueError using the api) and chase someone to fix it
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<ubottu> Launchpad bug 408738 in malone "OOPS when rendering bug activity" [High,Triaged] https://launchpad.net/bugs/408738
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1342EA107
<matsubara>         * Filed bug 423880 and assigned to leonardr
<ubottu> Launchpad bug 423880 in launchpad-foundations "ValueError: Invalid boundary in multipart form using the API on bug and branch merge proposal objects" [High,Triaged] https://launchpad.net/bugs/423880
<matsubara>     * ursinha to chase jtv about CP to fix rosetta-poimport script failure
<matsubara>         * The fix is in devel, but no CP will be requested because according to jtv it's unlikely that the problem hits us hard before 3.0. The script stopped failing as well.
<matsubara>     * chex to trawl logs and add request that caused 500 error to bug 422960
<matsubara>     * matsubara to email stub about dba report
<ubottu> Launchpad bug 422960 in launchpad-foundations "appear to be failing to record oops for all +translate HTTP 503 errors" [Undecided,New] https://launchpad.net/bugs/422960
<matsubara>         * emailed stub
<matsubara> sinzui, I take barry is still busy with 3.0 ui stuff?
<sinzui> matsubara: yes
<matsubara> intellectronica, news about 408738?
<rockstar> EVERYONE is busy with 3.0 UI stuff.
<intellectronica> matsubara: so, we've sceduled the bug for 3.0, and if everything goes according to plan it will be addressed next week. until now we were still very busy with 3.0 UI upgrade
<intellectronica> everyone and their sister, even
<matsubara> all right. I'll keep both action items in. thanks
<matsubara> [action]  barry to continue debug on bug 403606 after finishing 3.0 UI stuff
<MootBot> ACTION received:   barry to continue debug on bug 403606 after finishing 3.0 UI stuff
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<matsubara> [action] intellectronica to take a look or find someone to take a look on bug 408738 after finishing 3.0 UI stuff
<MootBot> ACTION received:  intellectronica to take a look or find someone to take a look on bug 408738 after finishing 3.0 UI stuff
<ubottu> Launchpad bug 408738 in malone "OOPS when rendering bug activity" [High,Triaged] https://launchpad.net/bugs/408738
<intellectronica> matsubara: no objection for keeping the action, but mind you it is now scheduled for this milestone
<matsubara> Chex, any news about 422960?
<Ursinha> I wonder if I got disconnected again
<matsubara> nope
<Ursinha> *whew*
<matsubara> well, let's move on then.
<matsubara> [action]  chex to trawl logs and add request that caused 500 error to bug 422960
<MootBot> ACTION received:   chex to trawl logs and add request that caused 500 error to bug 422960
<ubottu> Launchpad bug 422960 in launchpad-foundations "appear to be failing to record oops for all +translate HTTP 503 errors" [Undecided,New] https://launchpad.net/bugs/422960
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<Ursinha> me me
<Ursinha> well
<Ursinha> flacoste, stub, I have some oopses like OOPS-1345G2533, that reminded me of bug 174368 (that is fix released), but I couldn't reproduce it
<Ursinha> stub fixed that
<Ursinha> stub, could you take a look, please?
<ubottu> Launchpad bug 174368 in launchpad-foundations "Search query triggering error in tsearch" [Medium,Fix released] https://launchpad.net/bugs/174368
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1345G2533
<Chex> matsubara: I started to look at that last week and was sidetracked, I will still be looking at it
<matsubara> Chex, thanks. I added the action item back. it'll serve as reminder next meeting :-)
<Chex> matsubara: great thanks
<Ursinha> sinzui, also I have OOPS-1348XMLP49, that seems to be related to the problem barry was working on yesterday, the launchpad-reviewers mailing list
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1348XMLP49
<Ursinha> sinzui, do you know if that's correct? if so, is there a bug? (or do you want me to open one?)
<Ursinha> and
<Ursinha> rockstar, bug 427383, can I haz triage in that, please?
<ubottu> Launchpad bug 427383 in launchpad-code "ValueError: No JSON object could be decoded in merge through the API" [Undecided,New] https://launchpad.net/bugs/427383
<sinzui> Ursinha: there is a bug
<gary_poster> Ursinha: you should put me and stub down for that Foundations OOPS
<rockstar> Ursinha, I will look.
<Ursinha> thanks rockstar
<sinzui> Urshina: We do not understand what is wrong and we do not have time to investigate it
<rockstar> Launchpad is teh slow today.
<Ursinha> gary_poster, I'll file a new bug for that and let you know
<gary_poster> Ursinha: thanks
<stub> Ursinha: Yes, it looks similar. Separate bug, same piece of crap code.
<Ursinha> sinzui, I've added a highlight for 'Urshina' just for you here :)
<Ursinha> sinzui, do you know the bug number? I'll keep my eye on that problem and let you know if it gets critical
<stub> Ursinha: Not a high priority though, as it is unlikely to be triggered by anything other than a spam bot (like the OOPS you cited)
<sinzui> Ursinha: bug 403606
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,Triaged] https://launchpad.net/bugs/403606
<Ursinha> sinzui, this bug is the same of that oops? hmm.
<sinzui> Ursinha: sorry, I was confused..my scrolling is knackered
<Ursinha> :)
<matsubara> [action] ursinha to file a bug for OOPS-1345G2533 and coordinate a fix with gary/stub
<MootBot> ACTION received:  ursinha to file a bug for OOPS-1345G2533 and coordinate a fix with gary/stub
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1345G2533
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1345G2533
<sinzui> Ursinha: That is Barry and LOSAs doing DB surgery.
<intellectronica> siniuz: that's no excuse
<sinzui> Ursinha: That screwed of the data. They fixed it.
<Ursinha> sinzui, all right.
<Ursinha> thanks sinzui
<Ursinha> the only Critical bug is already Fix Committed
<Ursinha> thanks gary_poster :)
<gary_poster> sorry :-P
<Ursinha> matsubara, you can move on
<Ursinha> thanks guys
<matsubara> all right. thanks Ursinha and everyone
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Chex> hello everyone here is what we have for the report:
<Chex> - Buildbot issues in the process of being resolved (currently setting up a staging buildbot)
<Chex> - Higher than normal load on the app servers yesterday which seemed to be caused by higher than normal edge traffic, but not
<Chex> sure if that was slow processing of queries meaning more connections per second, or really more traffic
<Chex> (would need to correlate with apache logs)
<Chex> - Edge outage over the weekend caused by app server hanging during auto edge rollout (bug 307447)
<Chex> - Codebrowse is still timing out a lot
<ubottu> Launchpad bug 307447 in launchpad-foundations "launchpad process not exiting after make stop on staging" [High,In progress] https://launchpad.net/bugs/307447
<Chex> - A few CPs were applied in the past week.
<matsubara> Chex, re: high load on edge, I'll trawl some logs about it today. I'll let you know what I find out
<Chex> and thats it from us. any questions?
<Chex> matsubara: ok, great thank you on the edge load
<gary_poster> 307447 is in progress, btw
<matsubara> Chex, do you know if the LP outage reported by spm might be related with the high load?
<Chex> matsubara: I am not sure, I would have to check on that
 * gary_poster notices ubottu beat me to the punch
<matsubara> Chex, ok, we can coordinate after the meeting.
<matsubara> thanks Chex
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> Discussions afoot on migrating to PostgreSQL 8.4. PostgreSQL 8.4.1 has just been released, but will need packaging and backporting to Hardy. We also want Slony-I 1.2.27 to be released and packaged, as that is the version in the 1.2 series that supports PG 8.4 (I think - slony site is having issues right now so I can't fact check).
<stub> Nothing else interesting happening.
<stub> 1.2.17 is the Slony-I release we are waiting on
<stub> (site is back up, or my net connection is)
<matsubara> ok. questions for stub?
<matsubara> guess not. moving on
<matsubara> thanks stub
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> no proposed items
<matsubara> anything else before I close?
<rockstar> Purple monkey dishwasher.
<matsubara> [action] matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
<MootBot> ACTION received:  matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
<intellectronica> rockstar: i don't understand, what does it wash, dishes or monkeys?
<rockstar> intellectronica, it was a Simpsons reference, and I was just being silly.
<bigjools> or purples
<Ursinha> lol
<Ursinha> gary_poster, stub, bug 427397
<ubottu> Launchpad bug 427397 in launchpad-foundations "Search triggering error in tsearch query again" [Undecided,New] https://launchpad.net/bugs/427397
<Ursinha> matsubara, you can mark that action as completed :P
<gary_poster> thanks Ursinha.  stub, I'm marking it low and throwing it your way.
<matsubara> thanks Ursinha
<matsubara> ok, I think that's all
<Ursinha> thanks gary_poster
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<Ursinha> and matsubara
<Ursinha> and stub
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:26.
<Ursinha> and everyone else
<gary_poster> heh, thanks Ursinha and matsubara :-)
<Ursinha> :)
<intellectronica> thanks Urshina and matsubara
<Ursinha> :P
<Ursinha> awww I forgot mentioning something
<Ursinha> *crap*
<Ursinha> I'll mail the list
#launchpad-meeting 2010-09-13
<jtv> hi danilos, hi hen
<jtv> no henninge?
<danilos> hello jtv, welcome :)
<jtv> (yes, I hit tab and enter before waiting for an answer)
<danilos> jtv, not yet, maybe wrong server
<jtv> there he is
<henninge> I am here
<henninge> yes, wrong server ... ;)
<danilos> here he is?
<henninge> where am I?
<danilos> so, let's go over the kanban board
<danilos> jtv, the status of all the buildd stuff seems not to have changed much, how is it going? did you have a chance to talk to noodles?
<jtv> danilos: yes, I'm working on the UI now.
<jtv> That is, it renders without tracebacks, which is great; now to turn it into something watchable.
<danilos> jtv, ok, nice, you can get henninge involved in that as well :)
<jtv> (Right now I'm trying to fix up the links _to_ the new class in the UI)
<danilos> jtv, now, about that +templates timeout, why did you start on that at the same time?
<henninge> yes, get UI reviews early to avoid coding waste.
<danilos> jtv, links to stuff are overrated ;)
<jtv> Well they help find stuff.
<jtv> henninge: thanksâin this case it's not a big issue.
<jtv> danilos: I didn't quite start on it at the same time, actually; I started the +templates stuff later, when I was stuck for a bit.
<danilos> jtv, (I am asking about the timeout because you've got 3 other bugs in progress)
<danilos> jtv, just like the feature limit is 3 (and not 4 as the board says), the limit is 3 here as well... extra two are for split off work :)
<jtv> Well 2 of those are done except for landing.
<danilos> jtv, i.e. in my opinion, you've got too much stuff on your plate! :)
<danilos> jtv, that doesn't mean "done", as we all know :)
<danilos> jtv, especially since they are "blocked", aren't they?
<jtv> I suppose.
<danilos> jtv, please mark them as such, just so it's clear
<jtv> My absolute priority is the UI stuff for TTBs
<danilos> jtv, ok, so let's reflect that on the board
<danilos> jtv, cool, thanks
<danilos> henninge, that graph task can be considered "done", right? except that the graphs are not really updating :(
 * danilos tries to load them over blazingly fast connection
<henninge> danilos: they are updating!
<henninge> just not daily
<danilos> henninge, yeah? I haven't seen it up to Friday
<henninge> it's current up to Saturday now.
<henninge> mthaddon must have lied to me about log file updates happening daily - it's more like twice a week.
<danilos> henninge, oh, could this be related to log rotation?
<danilos> henninge, right, that explains it
<mthaddon> henninge: I lie as often as I can
<henninge> Hi mthaddon! ;-)
<danilos> henninge, it's not a big deal I think, we are getting history objects pretty soon and this is good enough
<danilos> mthaddon, we know, thanks :)
<jtv> henninge: go on, ask mthaddon if he lies daily :)
 * henninge does not want to upset his favorite losa
<jtv> henninge: then use the opening he clearly gave you for the purpose!
 * henninge also hopes spm did not read that ...
<danilos> henninge, (don't ping losas if you don't want them to know you are picking favorites :)
 * jtv pretends not to be in this conversation for the time being
<danilos> jtv, henninge: anyway, I've been stuck destroying LP Translations on Friday, getting OpenOffice.org imported into Maverick: I've helped dpm out a bit by constructing all the POTemplate rows based on lucid ones to help approver deal with this
<henninge> ok, let's move on
<danilos> jtv, henninge: that means that we've now got 35k files to import
<jtv> danilos: is that why the approver got into trouble?
<jtv> Great to hear btw
<jtv> And I'm sure dpm will be glad to hear it as well.
<danilos> jtv, very well could be, there were 3 imports by different people (3 package uploads) waiting to be imported
<jtv> _Plus_ it explains the oopses we got about inconsistent statistics.
<danilos> jtv, but, I haven't yet gone through the logs
<jtv> <shudder> 3 separate OO.o imports?
<jtv> What fun
<danilos> jtv, yes, they were all stuck in the queue because OO.o templates were disabled
<danilos> 75k needsreview files
<danilos> (jtv, btw, if it was just emails saying how approver hasn't run, then yes, that explains it :)
<jtv> Maybe we should just special-case OO.o imports to process them in EC2.  :-)
<jtv> Yes, those emails.
<jtv> I saw the decline in Needs-Review entries on Saturday.  Haven't looked today, but looking forward to it.
<jtv> Wow!
<jtv> https://lpstats.canonical.com/graphs/TranslationImportsCombined/
<jtv> That's a sizable chunk of the entire needs-review queue.
<danilos> yes
<danilos> anyway, I sucked coding wise, so I am going to be working today to improve that
<jtv> danilos: no time to work on get{Current,Imported}Translation?
<danilos> jtv, should have some today
<jtv> OK, I'll try not to bother you.  :)
<danilos> jtv, thanks :)
<henninge> danilos: I agree on calling the statistics task done if we can live with statistics only updating twice a week. Otherwise we should add a new task to change that.
<danilos> henninge, yeah, I think this is fine for now, let's call it done
 * henninge already moved the card ... ;)
<danilos> henninge, cool, ta
<danilos> henninge, jtv: anyway, I think we are done for the time being
<jtv> ok
<henninge> cool
#launchpad-meeting 2010-09-15
<bac> #startmeeting
<MootBot> Meeting started at 09:01. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> who is here today?
<sinzui> me
<sinzui> just me?
<henninge> me, too
<bac> me too
<bac> us
<abentley> me
<noodles775> me
<mars> me
<jelmer> me
<bigjools> me
<adeuring> me
<deryck> me
<leonardr> me
<danilos> me
<bac> EdwinGrubbs: ping
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> == Agenda ==
<bac>  * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>   * Mentat update.
<bac>   * https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<gmb> me
<bac>  * Peanut gallery
<EdwinGrubbs> me
<bac> [topic] Outstanding actions
<MootBot> New Topic:  Outstanding actions
<bac> * bac and lifeless to chat about branch size and (possibly) new metric.
<bac> this has not happened.  i'll start the conversation today.
<bac> [topic] Mentat update.
<MootBot> New Topic:  Mentat update.
<sinzui> Be sure to ask henninge and salgado for UI reviews
<henninge> it's happening
<bac> stevenk still lacks reviews.  his shift is AsiaPac Wednesday, so if you can assign non-urgent reviews to him, please do
<bac> salgado are you getting any UI reviews
<mars> bac, leonardr and I can let the queue fill up
<salgado> yes
<bac> mars: that is very selfless of you.  thanks.  :)
<leonardr> heh
<bac> salgado, henninge: great
<bac> note that allenap is back on the reviewer rotation on thursdays.  welcome back gavin.
<allenap> bac: Thank you. Obviously not up on the reviewer meeting schedule just yet. Me :)
<bac> we've got really good coverage now, fully staffed for eu and americas
<bac> [topic]  https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<MootBot> New Topic:   https://dev.launchpad.net/ArchitectureGuide as per the epic - will reviewers please start discussing the values and metrics during reviews?
<bac> i mentioned this last week at lifeless' request.
<bac> you'll see that he sent out an email expanding the topic a little more
<bac> please do read the wiki page and try to think about these issues when giving and receiving a review
<abentley> bac, Is code review the right time for this?  Shouldn't architectural issue be dealt with before implementations?
<bac> abentley: yes, they should be dealt with before
<deryck> I think asking about performance in code reviews is useful, though.  query counts, impact of adding code, etc.
<bac> abentley: but they can still be addressed in the review, if issues are seen
<bac> lifeless is doing a good job of reading all reviews and responding to many.  his questions in those follow-up reviews are a good example.
<abentley> bac, it drives me nuts when he does that.
<bac> i realize this is all a bit hand-wavy to ask that "the launchpad values for good code" be a part of the review and am stumped as to how to make it more concrete
<abentley> bac, if you're going to take the trouble of critiquing the code, you should do a review.
<bac> abentley: yes, it can be frustrating.  but i find he often raises good points i or my reviewer missed
<abentley> bac, I've see lots of cases where he did it before the initial review, and just did it as a comment.
<bac> abentley: ah, i have not seen that.
<bac> abentley: in that case you have a good point and i'll bring it up this evening
<bac> [topic] other stuff.  any one?
<MootBot> New Topic:  other stuff.  any one?
<bac> going once
<bac> going twice
<bac> #endmeeting
<MootBot> Meeting finished at 09:17.
<henninge> thanks bac
<bac> thanks for coming.
<benji> leonardr: first thought: use mechanize instead of testbrowser
<benji> heh
#launchpad-meeting 2010-09-16
<thumper> meeting?
<bac> #startmeeting
<MootBot> Meeting started at 19:02. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> who is here?
<StevenK> O hai!
<bac> sorry thumper for my tardiness
 * thumper is here
<bac> mwhudson, rockstar:ping
<thumper> rockstar: are you walked?
<mwhudson> hi
<StevenK> lifeless is around
<bac> yep
<StevenK> Just not here
<bac> but you're here, StevenK -- welcome
<bac> well, perhaps lifeless will turn up
<bac> sadly the only feedback from the ameu meeting was for him...
<bac> hi lifeless
<bac> it was a very brief meeting this morning.
 * wallyworld_ here too
<bac> outstanding actions:  big fail for me for not conversing with lifeless about a new metric for branch sizes
<bac> hi wallyworld_
 * rockstar is back...
<bac> perhaps this week...
<StevenK> I like meetings where the only action is for the chair
<bac> lifeless: we had a short discussion about your request to incorporate the values in https://dev.launchpad.net/ArchitectureGuide into reviews
<bac> everyone agrees it is a worthy goal.  i pointed to your post-review reviews for some guidance.
<bac> on that topic, lifeless, there was some feedback that your review comments should be more formalized.  by that, it was meant if you make comments on a branch that hasn't been reviewed yet, why not turn it into a real review?
<lifeless> I do when I have done one.
<bac> lifeless: personally, i haven't seen any pre-review comments from you, only post-review ones...which i thought were germane and helpful
<lifeless> thanks
<bac> StevenK & thumper, how is the mentoring going?
<StevenK> Slowly
<thumper> still
<StevenK> There's either no reviews to do, or someone steals mine.
 * StevenK glares at lifeless 
<bac> mars and leonard, who have the shift before you, offered to work more slowly so you'd have some reviews in the queue
<bac> they were commended for their selflessness
<thumper> heh
<wallyworld_> lol
<StevenK> Yes, I saw that :-)
<mwhudson> :)
<bac> i appealed to folks to pick you as a reviewer for any non-urgent reviews...but i suspect that just ain't going to happen
<bac> so, slog on, i guess
<bac> that was about it.
<lifeless> cool
<bac> do any of you have a new topic for discussion?
<mwhudson> not that i can think of
<lifeless> so bac, my feedback on the pre-review comments is that sometimes I havce the time to do a full review; othertimes I just glance.
<lifeless> I'd love to every review, but I think that would be a bit selfish.
<wallyworld_> i think lifeless has the right balance - as TA, he needs to be across everything but often not the fine detail
<bac> lifeless: yeah, i see your point.  no one is asking you to do them all.  hey, i'm just the messenger here.  you can look at the channel logs to see if i got it wrong.
<bac> so if there's nothing else to discuss we should adjourn and let mwhudson get to lunch.
<mwhudson> +1
<mwhudson> :)
<StevenK> Mmmmm, breakfast
<bac> thanks for coming.
<bac> #endmeeting
<MootBot> Meeting finished at 19:21.
<StevenK> bac: And thank you, for chairing
<bac> StevenK: i win, though.  i'm enjoying a cocktail
<thumper> bac: what type
<thumper> ?
<StevenK> thumper: Isn't it too early to start drinking? :-P
<bac> well, actually just a nice red wine ATM.  we accidentally opened a super expensive bottle that was a gift...
<thumper> StevenK: it is after noon here :)
<wallyworld_> doesn't matter does it, so long as it has a little umbrella and is green or pink?
<bac> while i install maverick onto my new SSD...
<wallyworld_> bac: you might need the wine then, if my upgrade experience is anything to go by
<bac> wallyworld_: yeah, i suspect i'll be reinstalling the old drive before the night is over and taking this up again tomorrow
<wallyworld_> i run kubuntu (i just can't like gnome at all) and it's almost ok now, but there's still some issues, hopefully sorted before 10.10.10
<bac> wallyworld_: you know, you're very welcome to attend the reviewers meeting but you don't have to...until you become a reviewer.
<wallyworld_> yeah, i know but it's a good chance for me to learn things, reading what others say and do etc, picking up tips. hope that's ok!
<bac> so when i select "install ubuntu" from the live cd menu and it then goes to a black screen with a flashing cursor for a really long time...that's bad, right?
<bac> and the cd stops spinning
<wgrant> What sort of hardware?
<wgrant> Oh, you're a MacBook, aren't you?
<wallyworld_> i assume so - i upgraded mine using update manager
<bac> wgrant: yeah
<bac> wallyworld_: me too.  haven't installed from scratch in a really long time
<wallyworld_> if it were windows you would have to do it every other month :-)
<wgrant> Argh.
<wgrant> Maverick got a new wallpaper this morning.
<wgrant> It's, er... like Intrepid's, but even less appropriate as a wallpaper.
<wallyworld_> wgrant: haven't seen the new one yet, what's wrong with it?
<wgrant> wallyworld_: It has white.
<wgrant> And it has black.
<wgrant> And gradients between them.
<wgrant> This is not good for a wallpaper, since it makes text unreadable on large parts of the screen.
<wallyworld_> oh :-(
<thumper> heh
<thumper> wgrant: kind of a basic mistake you'd think
<wgrant> It also has some odd rainbows in one corner.
<lifeless> people want text on their desktop?
 * lifeless sticks with doom3
<thumper> lifeless: lots of people have things on their desktop
 * mwhudson hasn't seen his desktop in weeks
<wgrant> While the old one just looked like someone accidentally dropped some paint, this one looks like somebody took a jumble of prisms and arranged them maliciously.
<wgrant> I only see it when I log in.
<lifeless> thumper: I was trolling
<wgrant> But it's still a shock.
<wallyworld_> there's been some discussion on the internal email about a new default wallpaper, not sure if it's the same one as we are discussing now
<lifeless> thumper: have you seen my desktop!
<lifeless> yes
<lifeless> it is
<StevenK> Haha, malicious prisms
<wgrant> StevenK: LOOK AT THE RAINBOW.
<wallyworld_> i better go have another look at it then
<StevenK> wgrant: Sorry, not qualified
<wgrant> lifeless: So there's a thread on the one that isn't like Lucid's at all?
<wgrant> Because the Lucid-like one caused an uproar as well.
<wgrant> But this is different.
 * StevenK notes with interest that wgrant the Stalker is back
<wgrant> Heh.
<wallyworld_> it looks like a film negative that has been exposed to a bit of extra light
<wgrant> Indeed.
<wallyworld_> oh wait, you young whipper snappers don't know about photographic film!
<wallyworld_> when I was a lad.....
<wallyworld_> we had cameras that took photos and you couldn't look at the back to see the photos
