#launchpad-meeting 2006-08-21
<jamesh> lifeless: I guess ddaa is on holiday.  Was there any decision on who would chair?
* lifeless votes jamesh
<jamesh> SteveA, mpool, lifeless, spiv, jamesh: is everyone here?
<spiv> I'm here.
<jamesh> no SteveA or mpool?
<lifeless> I'll nag
<jamesh> should we start without them?
<lifeless> ok, mpool nagged succesfully
<lifeless> I haven't nagged stevea
<jamesh> well, we're almost a third of the way through the timeslot, so we should probably start.
<jamesh>  * roll call
<jamesh>  * production status
<jamesh>  * Smart server
<jamesh>  * SFTP advertising
<jamesh>  * vcs-import knits
<jamesh>  * tarball-spider
<jamesh>  * Python import
<jamesh>  * critical bugs
<jamesh>  * pending sysadmin tasks
<jamesh>  * any other business
<SteveA> hi
<mpool> hi
<jamesh> first up is production status.  Does anyone have anything to report?
<SteveA> will the supermirror be down for writing when launchpad is down tomorrow?
<SteveA> if so, do the right people know about it?
<spiv> Yes.
<jamesh> we've still got bug #53825 (input validation problems in the branch puller), but I don't think there is any new issues.
<SteveA> will it fail elegantly, or inelegantly?
<spiv> It will refuse authentication.
<SteveA> as a future thing, can we make it refuse with a message
<SteveA> like "launchpad is down for maintenance" ?
<spiv> SFTP doesn't give us a nice way to say "sorry, we're down for maintenance" that I know of.
<SteveA> then at some point, we should do authserver cacheing with it
<SteveA> or some such
<spiv> Well, http://bazaar.launchpad.net/ will still be serving read-only branches ok.
<SteveA> maybe that's fixed when we go to two databases
<SteveA> mpool: what do you think about announcing it to the bzr list?
<spiv> (unless the cronscript generating the branch name mapping goes silly when the db is down?)
<SteveA> announcing the launchpad downtime, that is
<lifeless> I think 2 dbs is the right fix for it
<mpool> i think spiv  should send a message to the list
<mpool> or someone
<mpool> it would be nice if it could continue in r/o mode
<jamesh> spiv: looks like the rewritemap script opens the output file for writing after connecting to the DB, so assuming that fails it should be fine.
<spiv> I suggested to stub at the launchpad meeting that we should point the authserver at a r/o copy of the database -- that would still allow writes to existing branches, at least, but I don't know if he's had time to do that, it may be too much to ask at short notice.
<jamesh> next on the agenda is the smart server status
<mpool> we kept working on it
<jamesh> spiv: a read only connection to staging might be an option for that (or maybe for future downtime like this)
<jamesh> so nothing new to report for smart server?
<lifeless> some parts merged
<lifeless> more in progress
<lifeless> all conformance test passing, which means we're now in conversion mode rather than model overhaul
<jamesh> cool.
<jamesh> next up is SFTP advertising
<jamesh> I published the team branches article last week: http://blogs.gnome.org/view/jamesh/2006/08/17/1
<jamesh> there is a note in the agenda about spiv blogging about similarities between SVN and bzr usage with checkouts
<SteveA> it was well received outside of canonical, jamesh 
<SteveA> mgedmin read it and commented on irc about bzr looking better and better all the time
<jamesh> SteveA: cool.  We should check if it has a visible effect in the cricket statistics
<jamesh> since it is tracking the number of team owned branches
<SteveA> if the sftp server gets improved to not need --make-parents (or whatever the option is) from bzr
<lifeless> we may have got another user today, olive was the linchpin for him
<SteveA> then you could update the blog with that
<SteveA> what does "olive was the linchpin" mean?
<SteveA> sounds like secret agent codes
<lifeless> as his users include only-comfortable -with-guis folk
<lifeless> olive is our gui
<lifeless> written as part of SoC
<SteveA> i see
<lifeless> KDE and GTK, known to work on windows
<SteveA> it's a bit of an opaque codename
<jamesh> spiv: do you think getting rid of the --make-parents requirement would be easy for someone else to do, or would it require more twisted knowledge?
<spiv> jamesh: I think your analysis is probably correct -- it's probably not too hard.
<jamesh> (I mean --create-prefix rather than --make-parents)
<spiv> The twisted knowledge necessary should be cargo-cultable
<jamesh> spiv: okay.  I'll have a go at it tomorrow then.
<jamesh> if I get in over my head I'll ping you.
<SteveA> lifeless: imo, don't call it "olive" in public.  if you have $$$$ to spend on marketing like apple, then you can call your GUI "aqua" or other cute names.
<SteveA> but it's cliquey and offputting for a small project to obfuscate names, where more obvious (but boring) ones will work
<jamesh> next up on the agenda is "vcs-import knits", but last week's minutes says that it was completed so I'll skip it
<lifeless> SteveA: fair enough. I've had almost no involvement with it though, so I'll redirect your feedback to mpool
<SteveA> thanks
<mpool> in line with the other naming thread, we should just move to calling them 'bazaar gui'
<mpool> they need to all technically merge together
<SteveA> ah, about knits
<SteveA> james troup (or another sysadmin) commented to me
<SteveA> that there was a lot, a LOT, less space being used
<SteveA> on the SM machine
<jamesh> that's good to hear
<SteveA> he was concerned that some evil data loss had occured
<SteveA> so, in future, maybe warn the admins of such improvements ;-)
<lifeless> heh, we did
<lifeless> when we rolled it out
<jamesh> next up is the script formerly known as dyson
<jamesh> I landed my fixes for the last round of bugs today
<SteveA> that's the... tarball non-spider?
<jamesh> and renamed it to "product-release-finder"
<jamesh> lifeless has asked stub to do another test run of it on staging, so we'll have more to report next week
<jamesh> next is Python import.  Given ddaa isn't here, I'll skip it
<jamesh> unless anyone else knows the status
<lifeless> noidea
<jamesh> okay.  On to critical bugs.
<jamesh> bug 31308: Cannot set branch associated to a product series.
<jamesh> Mark mailed some of us with some concerns about having two branch references in the product series, but decided that it sounded okay after I explained what we were planning
<jamesh> lifeless: are you still responsible for specing this?
<lifeless> nope
<lifeless> last meeting ddaa said to not spec it
<lifeless> or around that time
<lifeless> anyhow, its now just down to implementation of the extra attribute
<mpool> is david going to do that?
<jamesh> last meeting's minutes says it has been assigned back to him
<spiv> The bug is assigned to him.
<jamesh> bug 37897: renaming project, product or series breaks vcs imports
<jamesh> looks like this one is now in my review queue
<jamesh> using the design discussed at the sprint
<jamesh> bug 51130: cannot use +admin on a branch I own
<jamesh> the branch mentioned in last minutes for this one is in BjornT's review queue
<jamesh> so I guess things are looking pretty good.
<jamesh> next up is pending sysadmin tasks
<jamesh> is anyone blocked on sysadmin stuff?
* jamesh takes that as a no
<mpool> next then?
<jamesh> there are a few items listed under proposed items, but I think they are unchanged from last week.  Should I go through them?
<jamesh> the first is lp: URLs for bzr.
<lifeless> you're the matre'd
<jamesh> there have been some comments added to the spec which probably need integrating.  I don't think there is much more to add.
<mpool> jamesh, spiv: have you read the spec?
<jamesh> mpool: yes.  I added some of the comments.
<spiv> mpool: not yet, I'll do that.
<jamesh> mpool: it looked pretty good.  The client side would be pretty easy to implement with better redirect handling in bzr :)
<mpool> ok, so: ACTION: spiv, read the spec
<mpool> ACTION: mbp read/integrate  the comments
<jamesh> next up is "important bugs according to bzr community"
<mpool> i spoke to david and mark
<mpool> i'll update the spec list instead
<mpool> so that item is closed
<jamesh> okay.
<jamesh> next is "Move vcs-import data out of ProductSeries"
<jamesh> I don't think there is much to add here.  It probably needs a bit of specing
<jamesh> next is "1.0 targets, what, who, when?"
<jamesh> we've already covered the smart server work, so I assume that's on target
<mpool> jamesh: do you have any 1.0 bazaar-related targets?
<SteveA> does that spec about lp: urls take into account our canonical pillar names?
<mpool> spiv: do you have any other ditto?
<mpool> SteveA: yes
<SteveA> great
<mpool> https://launchpad.canonical.com/BranchIndirection
<mpool> if you want to read it
<SteveA> thanks
<spiv> mpool: other ditto?
<jamesh> mpool: I'm not working on any of the 1.0 target bazaar specs at the moment.
<mpool> any lp 1.0 targets related to bazaar?
<jamesh> that spec should be registered in LP ...
<spiv> Oh, right.  Just the smart server.
<jamesh> One last thing before we finish.  There was an action item from the last meeting that we haven't covered
<jamesh> ACTION: spiv and ddaa to review PrivateBranches again
<jamesh> spiv: is that still a todo?
<spiv> Yes, but I've skimmed and it won't take long for me to do.
<jamesh> okay.  I think that's it.
<jamesh> Meeting ends.
<lifeless> thanks for chairing
<SteveA> thanks jamesh 
#launchpad-meeting 2008-08-19
<barry> #start-meeting
<barry> moot bot!
<thumper> hi
<barry> #startmeeting
<barry> erg
<barry> it's not just me having system problems i guess
<barry> anyway
<thumper> this could be a real short meeting
<barry> hello and welcome to this week's asiapac meeting
<barry> who's here today?
<thumper> as jml is getting his keyboard fixed and mwhudson is not well
<thumper> barry: it could be just me
<barry> just you and me then? :)
<thumper> yeah
<barry> let's make this short and then we can chat about merge proposals
<barry> week +=1 ?
<thumper> sure
<thumper> although I will be in London
<barry> right, team leads
<thumper> the others should be around though
<barry> week after that is labor day in the us so i won't be here
<thumper> week after that I'll probably be sleeping
<barry> :)
<barry> there's just one action item:
<thumper> ok
<barry>  * thumper to submit a bug for moving ftests contents to tests
<thumper> I did that
<barry> awesome, thanks
<thumper> and I gave you the bug number last time
<thumper> :)
<barry> d'oh!
<thumper> I could go and dig it up if you need it again
<barry> naw
<barry> i just forgot to remove it from the agenda
<barry> i have nothing on the queue or mentoring. anything on your end?
<thumper> just merge proposal votes
<barry> before we get to that...
<barry> just one other thing on the process:
<barry>    * review diffs can be trimmed (or not) at the discretion of the reviewer.  mentats must defer to their mentor's preferences
<thumper> sure
<barry> we talked about this at ameu and everyone was +1 on this.
<barry> okay with you?
<thumper> yep
<thumper> fine
<barry> cool
<barry> okay... votes! (i'm not sure i can get skype working again w/o a reboot)
<thumper> I tend to trimm diffs
<barry> i know aaron and kiko do, but i think most others don't
<thumper> barry: I can wait for a reboot
<barry> it's my mac... hang on a bit
<barry> i guess we're done here tho? :)
<thumper> yep
<mwhudson> i'm inconsistent about trimming diffs
<barry> #endmeeting
<barry> mwhudson: hi!
<mwhudson> i try only to chop out entire files
<barry> i try to only chop chunks
 * thumper tries with chunks
<thumper> but if it is too long, I'll strip bits of chunks
<barry> main thing is to keep enough context to know where you are
<barry> anyway.  see you on #lp-code
#launchpad-meeting 2008-08-20
 * gmb goes to grab a drink
<barry> #startmeeting
 * barry hopes somebody will kick mootbot
<barry> anyway...
<barry> welcome to this week's launchpad ameu reviewers meeting.  who's here today?
<bigjools> me-ow
<allenap> me
<gmb> me
<bac> me
 * barry knows abentley sent his apologies
<cprov> me
<BjornT> me
<salgado> me
<sinzu1> me
<sinzui> me
<EdwinGrubbs> me
<barry> flacoste: ping
<intellectronica> me
<barry> danilos: ping
<barry> [TOPIC] agenda
<barry>  * Roll call
<barry>  * Next meeting
<barry>  * Action items
<barry>  * Queue status
<barry>  * Mentoring update
<barry>  * Review process
<barry>    * watch for dead end links ([[https://bugs.edge.launchpad.net/launchpad/+bug/254436|bug 254436]] - flacoste)
<ubottu> Launchpad bug 254436 in launchpad "Launchpad contains lots of dead-end links" [Undecided,Incomplete]
<ubottu> Launchpad bug 254436 in launchpad "Launchpad contains lots of dead-end links" [Undecided,Incomplete] https://launchpad.net/bugs/254436
<barry> [TOPIC] next meeting
<barry> week += 1?
<barry> anybody know they won't be here?
<sinzui> I may not
<gmb> I won't be.
<sinzui> That depends upon my connectivity next week
<barry> cool.  please update the apologies section on ReviewerMeetingAgenda
<barry> [TOPIC]  * Action items
<barry>  * intellectronica to write up guidelines on check_permission in the wiki and email the ml for additional input
<intellectronica> i haven't done that, but have done my other action items.
<barry> intellectronica: rock on, thanks
<barry>  * intellectronica to start a list on the wiki of devs/available platforms
<barry> done
<barry>  * intellectronica to start the ball rolling on an email to the ml re: multiple browsers/platforms
<barry> done
<barry>  * Queue status
<barry> nothing much from me here. does anybody have any comments?
 * sinzui reprimands himself for not updating pending review 
 * barry can't kill of PR fast enough
<barry> [TOPIC]
<barry>  * Mentoring update
<barry> i don't think we have any mentors currently?
<barry> just abentley i believe
<intellectronica> do we have more people we want to invite, then?
<barry> intellectronica: my question exactly :)
<flacoste> me
<barry> we had talked about mars and leonardr
<barry> any other suggestions?
<barry> anyway, send them to me if you have them
<barry> [TOPIC] review process
<barry> not much from me here, except that i did my first merge proposal this week
<barry> tim and i talked about some improvements to that code and tim sent an email to the list about our discussions
<barry> i think with those additions, this is going to be really nice
<barry> diffs on the web and all-email reviewers are still a little ways off, but iiuc are being actively worked on
<barry> does anybody else have comments about merge proposals?
<barry> anyway, i'd like to encourage people to try them out, submit bugs, send emails, etc.  tim and co are very interested in making it fit with our process
<barry>    * watch for dead end links ([[https://bugs.edge.launchpad.net/launchpad/+bug/254436|bug 254436]] - flacoste)
<ubottu> Launchpad bug 254436 in launchpad "Launchpad contains lots of dead-end links" [Undecided,Incomplete] https://launchpad.net/bugs/254436
<BjornT> one thing i noticed is that it's really hard to follow the reviews by e-mail
<ubottu> Launchpad bug 254436 in launchpad "Launchpad contains lots of dead-end links" [Undecided,Incomplete]
<sinzui> We ultimately need something can can do branch analysis like out make lint.
<flacoste> see bug report :-)
<barry> BjornT: yep.  this is being actively worked on.  tim knows we want to do reviews by email
 * flacoste is n't really here sorry
<flacoste> we might postpone
<barry> flacoste: next week?
<barry> flacoste: ok
<barry> wow. shortest meeting evar.  does anybody have anything not on the agenda?
<barry> one thing from me then: if you have any suggestions for improving this meeting, making it more relevant or, um, interesting please let me know.  i want to take joey and kiko's lead and make sure you're getting benefit out of these meetings
<kiko> one trick
<kiko> is to get the people coming to the meeting
<kiko> to raise most of the agenda, preferrably in advance
<kiko> is there an easy place to coordinate this -- i.e. add agenda topics, etc?
<intellectronica> kiko: https://launchpad.canonical.com/ReviewerMeetingAgenda
<barry> kiko: yes
<kiko> and traditionally, how much of it is boilerplate and how much is dynamic?
<barry> kiko: a lot of it is boilerplate
<barry> which i'm not sure is very helpful to folks.  e.g. the mentor update is useless to asiapac
<barry> queue status is occasionally useful
<kiko> right
<kiko> yeah, I hear lots of debate about that
<kiko> so to add some spice to this conversation
<kiko> how about I throw up a topic of controversy?
<barry> kiko: puke away
<kiko> blech
<barry> "throw up"
<kiko> could we avoid the need to do pre-merge reviews for certain types of change that we want to encourage?
<kiko> pre-merge reviews are something that does add a set of handoffs to our process
<kiko> in many cases I think the benefits outweigh the cost
<kiko> but are there cases where a post-merge review would be smarter?
<intellectronica> i can't imagine such a case. do you have an example?
<kiko> really?
<kiko> wow
<kiko> I must have done my job well of convincing us of pre-merge reviews! :)
<bigjools> refactoring?
<BjornT> for simple straightforward changes it would make sense, but it's hard to identify them
<kiko> I thought refactorings too, if there was a good pre-imp call
<bigjools> are we heading back to r=trivial ? :)
<gmb> If we're talking about a textual change, fixing a typo or some such, maybe, but it'd have to be very, very, very trivial.
<kiko> this is a bit different
<kiko> as a reviewee
<kiko> do you think you always get value out of a review?
<kiko> and do you think the value outweighs the cost?
<kiko> I'd like you all to think back to single-person projects you might have worked on
<intellectronica> it's so cheap to get something reviewed these days, that the overhead is very low (unless it's hours before the pqm deadline)
<kiko> where you could check in code very quickly without asking anybody
<kiko> is your productivity different there and here?
<bac> yes i get value.  either improvements are suggested or i get the affirmation that the approach made sense and was sound.
<barry> kiko: yes. productivity is different.  one thing that might be interesting is to relax the requirement /if/ we could do some kind of real-time pair programming
<intellectronica> that's, basically, what trivial used to be. i thought it was ok to have it and was a bit sorry that it was gone. but for almost everything else, yes, you do get something out of a review
<barry> kiko: iow, if you and i pair on a particular task, chances are we're already reviewing each other's code so it'll (presumably) be higher quality
<barry> otoh, doing that in our distributed environment is challenging
<allenap> If we relax the requirements, I'm worried that what seems like a good idea might get coded and merged before we appreciate why it's not a good idea.
<barry> intellectronica, kiko also note that we're encouraging drive-bys, which takes care of many previously r=trivials
<EdwinGrubbs> herb: I'm still getting the 404 error when accessing <https://api.staging.launchpad.net/projects>. Unfortunately, you have to authenticate using the REST API to even see the error. Can you check in the logs to see if IP 12.231.120.224 is still getting redirected to product.html?
<intellectronica> barry: i think an interesting formulation of that could be that the goal is two have at least two developers behind a branch, and let them agree how they manage that
<BjornT> as i understand it, kiko wasn't suggesting dropping the reviews, but exchanging some pre-merge reveiws with post-merge reviews
<barry> intellectronica: interesting
<EdwinGrubbs> herb: fyi, my IP is 12.231.120.224 and not an IP related to the rewrite rule. I wasn't clear before.
<barry> i personally don't find arch-commits the most conducive format for that though
<barry> though i realize others do
<allenap> Because merged code starts running on edge, and thus mangling production data, post-merge reviews might be too late.
<kiko> what BjornT said, exactly (sorry, phone call)
<EdwinGrubbs> herb_: I'm still getting the 404 error when accessing https://api.staging.launchpad.net/projects;. Unfortunately, you have to authenticate using the REST API to even see the error. Can you check in the logs to see if my IP 12.231.120.224 is still getting redirected to product.html?
<barry> EdwinGrubbs: -> #launchpad-code ?
<kiko> EdwinGrubbs, why are you asking about this in -meeting?
<EdwinGrubbs> barry: oops soory
<kiko> oops
<BjornT> allenap: this would only be for certain changes, though. for example, if you have a really detailed pre-implementation call, and the changes seem straightforward
 * barry laments that few people have pre-impl calls these days :/
<BjornT> barry: something like this might encourage people :)
 * gmb makes a point of having at least an pre-imp IRC chat now
<barry> kiko: i think this is an interesting discussion.  can you take it to the ml to get non-reviewer input?
<intellectronica> how about that suggestion? instead of reviewer, rename that post to copilot. you can agree to just have a pre-imp, hack together, hack then get reviewed, or just rubber stamp (if it's a trivial)
<kiko> barry, no, but you can :)
<allenap> I think that's true - about promoting calls.
<kiko> I don't want to own this discussion, just to stimulate it
<barry> kiko: i might not be able to do justice to your enthusiasm :)
<kiko> barry, try harder <wink>
 * barry tries to get stimulated
<barry> kiko: okay :)
<barry> intellectronica: yes, let's explore that too
<allenap> Oh, bad images.
<barry> allenap: oh, you've seen them?! :)
<barry> [ACTION] barry will, er, stimulate discussion on post-merge reviews and pair-programming
<barry> kiko: thanks for bringing this up
<barry> any other topics today?
<kiko> barry, you're welcome
 * sinzui wonders who his stimulating partner will be in pair programming
 * gmb remembers this is a public channel; behaves
<barry> i think that's a sign that we're done
<barry> #endmeeting
<bigjools> +1
<barry> thanks everyone! :)
<intellectronica> cheers barry
<gmb> Thanks barry
#launchpad-meeting 2008-08-21
<Rinchen> #startmeeting
<Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<Rinchen> hmm
 * Rinchen pokes MootBot 
<Rinchen> mootbot is dead
<mrevell> long live mootbot
<mrevell> me
<mrevell> oops
<Rinchen> Well, Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<sinzui> or MootBot is very drunk again
<Rinchen> [TOPIC] Roll Call
<Rinchen> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<Ursinha> haha
<Rinchen> me!
<mrevell> me
<bigjools> me
<gmb> me (what timing!)
<cprov> me
<salgado> me
<beuno> me
<flacoste> me
<Ursinha> me
<stub> me
<mthaddon> me
<thumper> me
<EdwinGrubbs> me
<intellectronica> me
<sinzui> me
<adeuring> me
<mars> me
<BjornT> me
<mwhudson> me
<flacoste> barry is missing this meeting
<Rinchen> as will abently
<Ursinha> where is matsubara?
<al-maisan> me
<allenap> me
<BjornT> bugs team is here
<bigjools> soyuz here
<Rinchen> rockstar, ping
<rockstar> me
<flacoste> bac, leonardr: ping
<Rinchen> Releases is missing Diogo.. we're trying to find him
<matsubara> me
<rockstar> Found him!
<Ursinha> haha
<Rinchen> :-)
<Ursinha> :)
<bac> me
<matsubara> sorry
<Rinchen> ok Releases is here
<matsubara> I was grabbing something to eat
<Rinchen> danilos, here?
<Rinchen> jtv, here?
<jtv> Rinchen: yes, just got in
<Rinchen> ok, we'll go ahead then since we'll mostly here
<leonardr> me
<kiko> me
<kiko> I'm here, I'm here!
<jtv> who?
<Rinchen> [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>  * Next meeting
<Rinchen> hm
<Rinchen> Next meeting
<Rinchen> kiko, will we have a mtg next week?
<mrevell> Rinchen: I'm away next Thursday.
<kiko> I think we should if there's somebody that would like to run it
<mthaddon> herb will be away next Thursday
<gmb> So will I.
<Rinchen> The team leads will be sprinting
<sinzui> I may not be here next week
<rockstar> Maybe it would be better to ask who will be here?
<flacoste> Rinchen: Foundations is complete (apart barry which is excused)
<Rinchen> I propose skipping next week and starting on the 4th
<Ursinha> rockstar, +1 :)
<kiko> Ursinha, matsubara: why don't you guys run the meeting?
<mwhudson> (i am unlikely to be here but then you don't expect me anyway)
<Ursinha> Ursinha, i can try that, matsubara, what do you think?
<matsubara> kiko, you mean next week's meeting or all meetings from now on?
<mthaddon> matsubara, well volunteered!
<Ursinha> talking to myself is not good
<kiko> next week? :)
<matsubara> kiko, sure thing
<Ursinha> cool
<kiko> cool
<Rinchen> ok, then, thanks.
<Rinchen> we will have a meeting next with with several apologies
<Rinchen> Actions from last meeting
<Rinchen> We had two
<Rinchen>   * mwhudson to get with mthaddon to see if we can super-charge gdb to give us better diagnostic info on the staging
<Rinchen>   * Joey to review RT ticket Priorities in RT to ensure they are accurate.
<mwhudson> so we set some stuff up, but didn't collect any data aiui
<mthaddon> I think the first one ended up being herb, but I know there was some work done on that
<Rinchen> I did a once through on the RTs so they are in order as far as I can see for those who gave priorities. I did do some cleanup
<mwhudson> (because now we're looking at it staging so closely it's resolutely refusing to crash)
<kiko> herb_, mwhudson: really? I am a bit surprised because I think linkchecker didn't finish running and I thought that was the cause
<mthaddon> staging has crashed numerous times over the past week
<mthaddon> although to be fair, the last time seems to have been on the 18th
<mwhudson> mthaddon: oh, did my gdb voodoo work then?
<mthaddon> mwhudson, not sure - as I say, it's herb that's been working on this
<mwhudson> because the last time i got spm to look, my stuff had gone walkabout and it was the SIGPIPE thing again
<mwhudson> (which might have been on the 18th, indeed)
<kiko> mthaddon, herb_: we /really/ need to be able to run staging interactively.
<mthaddon> kiko, we've had this discussion before - I'm still getting you an answer on that one
<kiko> mthaddon, not me as in we. we as in OSAs :)
<Rinchen> mthaddon, herb_, spm - can you please maintain vigilance on staging and when gdb kicks in to contact one of the LP devs?
<mthaddon> oh okay :)
<kiko> mthaddon, or is that the same problem?
<mthaddon> no, I don't think that's the same problem
<kiko> I mean, I consider myself an OSA. just a particurly underprivileged one. :)
<mthaddon> I'll check with herb about the gdb issue when he's back
<kiko> mthaddon, sanks
<Rinchen> ok, so we'll keep this action item open but replace mwhudson with "LP devs"
<mthaddon> yah
<kiko> Rinchen, meaning nobody's responsible?
<Rinchen> kiko, meaning the OSAs are responsible
<kiko> I want somebody to own this problem and to actually want to fix it
<Rinchen> and to find whomever they can when it happens
<Rinchen> regardless of the hour
<kiko> is that the right direction for this vector, mthaddon?
<mthaddon> sure
<Rinchen> thanks... moving on then...
<Rinchen>  * Oops report & Critical Bugs (matsubara/ursinha)
<Ursinha> alright
<Ursinha> two new bugs, one question for thumper
<Ursinha> for translations, bug 259433, who can take a look at it, jtv or danilos? A candidate to RC, i think
<ubottu> Launchpad bug 259433 in rosetta "Oops error when translating one string to Serbian" [High,Confirmed] https://launchpad.net/bugs/259433
<thumper> Ursinha: shoot
<Ursinha> thumper, about that two items in the test plan that were hanging (stacked branches, i guess), what was the solution to them in the end?
<jtv> Ursinha: I'll have a look, thanks
<matsubara> that one is quite weird, I initially thought was a hacked url, but it OOPSes even with no parameters
<Ursinha> jtv, thanks
<thumper> Ursinha: it's bad, very bad
 * thumper is unhappy about the first bad item
<Ursinha> thumper, go ahead :)
<thumper> Ursinha: bad as in broken, not working, fubared
<Ursinha> holy cow
<matsubara> thumper, hmm did you disabled the feature for now?
<mwhudson> no, that was something else
<thumper> as much as we can, yes
<mwhudson> no stacking will happen by default, which limits the carnage
<matsubara> thumper, mwhudson: cool. can we expect a fix ready for the second rollout?
<Ursinha> thumper, too bad that it will take forever to fix?
<mwhudson> matsubara: when is the second rollout?
<thumper> I'm not sure that we know exactly what the problem is yet
<kiko> mwhudson, when would you like it?
<matsubara> when kiko/joey says so
<mwhudson> matsubara: but i guess the answer is going to be "maybe", the problems aren't well understood yet :/
<mwhudson> (too many moving parts)
<matsubara> all right. keep us posted on that one. I'll add that to the CurrentRolloutBlockers page
<Ursinha> so we can't really expect them as items to be RC
<Ursinha> thanks matsubara
<kiko> that sucks
<Ursinha> ok, moving on
<mwhudson> i guess it's what we'll be working on today
<mwhudson> kiko: yep
<kiko> mwhudson, can I help somehow?
<mwhudson> kiko: if we can think of a way, we'll let you know, but i guess it's a me, thumper, spm job mostly
<kiko> mwhudson, okay, I'm your man if you need some effort and energy to hack away with it
<Ursinha> cool
<Ursinha> may i move on?
<matsubara> go ahead
<Ursinha> for foundations, i guess, bug 260140 - an annoying timeout. Who can take that?
<Rinchen> go4it
<ubottu> Launchpad bug 260140 in launchpad-bazaar "revisions' rss feed timing out for some projects" [Undecided,New] https://launchpad.net/bugs/260140
<matsubara> bac or EdwinGrubbs ^?
<flacoste> Ursinha: that's for thumper's team, i reassigned
<thumper> that is probably me
 * mwhudson points at thumper 
<Ursinha> flacoste, thanks
<flacoste> 'retargeted' is the proper term, thumper will assign
<thumper> although it is purely DB query optimisation
<Ursinha> thumper, i thought so
<Ursinha> is that hard to fix?
<thumper> so stub is probably most able to understand it
<Ursinha> thumper, i'll assign him the bug
<kiko> thumper, maybe somebody on your team could have a call with him later today?
<Ursinha> and then you could talk to him about it
<thumper> kiko: sure, I'll try to get hold of him later
<Ursinha> ok, fine
<Ursinha> i'm done here
<matsubara> for the critical bugs session
<Ursinha> thanks guys
<kiko> thanks Ursinha
<flacoste> kiko, thumper: after this meeting is usually not the best time to speak to stub, it's pretty late for him
<matsubara> we have 5 critical bugs, all of them Fix Committed.
<Ursinha> matsubara, the same last week
<matsubara> so, good job guys!
<Rinchen> thanks Ursinha and matsubara
<matsubara> that's all from me. thanks
<kiko> flacoste, I meant tomorrow morning?
<flacoste> kiko: right, that's better
<Rinchen>  * Operations report (mthaddon/herb/spm)
<mthaddon> 2.1.8 rollout:
<mthaddon> â¢ default LPCONFIG has mailman build - now fixed by explicitly calling LPCONFIG for all make builds
<mthaddon> â¢ vostok connecting to internal xmlrpc server - temp fix in place, will be figuring out infrastructure issues later
<mthaddon> Continuing issues with app servers dying and leaving a stale pidfile(average 2-3 per day) - gdb testing on staging since 19th, hasn't yet crashed since then
<mthaddon> Codebrowse has needed a few restarts over the past week
<mthaddon> Codehosting needed a restart too (31 lp-serve processes of 32MB each, some up to 19 days old)
<mthaddon> Rollout time should be 22:00 UTC, not 00:00 UTC, right? If so, the blog will need updating
<mthaddon> That's it from herb, spm and me unless there are any questions
<thumper> flacoste: I'll talk when I see him turn up later
<mwhudson> mthaddon: any movement on the internal xml-rpc thing yet?
<Rinchen> mthaddon, do we have logs for the codehosting restart?
<mthaddon> mwhudson, not yet - will be following up post-meeting
<mwhudson> mthaddon: ok
<mthaddon> Rinchen, same as usual logs, yeah
<Rinchen> Do we have a bug for it?  That seems rather...unusual.
<Rinchen> (the event)
<mthaddon> Rinchen, no bug as yet - can create one
<Rinchen> mthaddon, please and pass it to Ursinha, matsubara, and thumper  for investigation
<mthaddon> will do
<Rinchen> thank you sir
<mthaddon> Rinchen, can you confirm on the rollout time question as well?
<Rinchen> kiko, 2nd code update tomorrow at 22?
<Rinchen> er
<mthaddon> Rinchen, I was meaning for future rollouts (2.1.9, etc.)
<Rinchen> that won't work will it
<kiko> Rinchen, or tonight?
<Rinchen> yeah, should be tonight
<Rinchen> mthaddon, yeah, let's set them for 22:00 and we'll try to be aggressive for getting PQM's last job on by 20:00
<Rinchen> mrevell, ^^
<mrevell> noted, thanks Rinchen
<mthaddon> Rinchen, that'd be great
<Rinchen> 22:00 seems to be working better for us than 00:00 ....  just seems to go smoother with less stress
<Rinchen> and I get to go home before 9pm :-)
<mthaddon> Rinchen, absolutely - esp if we need SA help
<mrevell> mthaddon: Still want to allow a two hour window in announcements?
<mthaddon> mrevell, I think it's best to leave it as that - gives us padding - maybe "up to 2 hours"?
<Rinchen> +1 on "up to 2 hours"
<mrevell> mthaddon: Yes, makes sense. Great, thanks.
<Rinchen> Anything else for the LOSAs?
<Rinchen> ok,
<Rinchen>  * DBA report (stub)
<stub> Nothing thrilling happening I can think of.
<Rinchen> yay! you're still awake
<stub> Not for long...
<Rinchen> I don't have anything for stub today.  Does anyone else?
<Ursinha> Rinchen, only the bug we've just talked about
<Rinchen> right.
<Ursinha> assigned to him already
<Rinchen> And that'll be taken care of after stub rises from the dead tomorrow
<Rinchen> ok, thanks stub.  nighty night
<Rinchen>  * Sysadmin requests (Rinchen)
<Rinchen> Is anyone blocked on an RT or have any that are becoming urgent?
<Rinchen> I've made some progress with IS this week
<Rinchen> on some higher priority tickets
<Rinchen> The two tickets I'm currently still tracking are
<allenap> I can't merge until RT 31486 is in, but it's not urgent.
<Rinchen> #31131 AutoReply: Jackass needs to access the Launchpad restricted librarian
<Rinchen> #31296: convert staging code import machine for production use, set up VMs on remaining staging box
<Rinchen> ok allenap, I'll have a look at that and set a priority and date for it
<Rinchen> anyone else?
<mwhudson> Rinchen: the codeimport one is partially in my court at the moment
<allenap> Rinchen: Thanks :)
<Rinchen> k, I'll keep it on my radar mwhudson
<mwhudson> (we need to make some code changes to reduce disk space usage)
<Rinchen> ok, thanks
<Rinchen>  * New packages required (salgado)
<salgado> anything for me?
<Rinchen> salgado, Jamesh's request?
<salgado> copying psycopg2 to lpdebs?
<salgado> (already did that one)
<salgado> is there another?
<Rinchen> no but I needed that one to remove deb http://ppa.launchpad.net/jamesh/ubuntu hardy main from the newlaunchpadder start up list
<Rinchen> I'll go remove that and email everyone to remove that from apt
<Rinchen> thanks salgado
<Rinchen> and with that, I come to the end of the agenda!
<Ursinha> yay
<Rinchen> Anything anyone wants to add before I close?
<Rinchen> ok then!
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
<Rinchen> except there won't be any logs for today from mootbot :-(
<mwhudson> thanks Rinchen
<mrevell> thanks rinchen, everyone
<al-maisan> bye!
 * Ursinha waves goodbye
<mohbana_> hi
#launchpad-meeting 2009-08-19
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> welcome to this week's ameu reviewer's meeting.  who's here today?
<BjornT> me
<EdwinGrubbs> me
<bac> me
<barry> deryck sends his apologies
<salgado> me
<abentley> me
<adeuring> me
<intellectronica> me
<sinzui> me
<barry> jtv: ping
<flacoste> me
<jtv> me
<barry> leonardr: ping
<jtv> barry: thanks :)
<barry> :)
<bigjools> me
<barry> cprov, gary_poster, gmb, noodles775 ping
<noodles775> me
<gary_poster> me, sorry
<cprov> me
<leonardr> me
<gmb> barry: OTP at the moment; apologies are on the schedule.
<gary_poster> :-)
 * barry reloads the page
<gary_poster> lol
<barry> gmb: are you sure you committed your draft? :)
<barry> danilos, allenap, rockstar ping
<danilos> me
<allenap> me
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry>  * Roll call
<barry>  * Action items
<barry>  * Mentoring update
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * intellectronica to report on relevant summary of ui reviewers meeting here
<barry> intellectronica: tell us some good news!
<intellectronica> i think there has been some kind of misunderstanding
<intellectronica> there aren't really any ui reviewers meetings
<barry> intellectronica: ui phone call maybe?
<intellectronica> i suppose the most interesting thing i can tell you is that martin is planning on beefing up the guidelines and in particular, start collecting case reports for interesting branches that went through ui review
<intellectronica> so if you're working on a ui branch from either side and think the process was interesting and other can learn from it, consider compiling a case report
<beuno> yes
<intellectronica> oh, we should have talked about a million dollars
<barry> :)
<barry> beuno: intellectronica was giving us a summary of the ui call
<barry> <intellectronica> i suppose the most interesting thing i can tell you is that
<barry>                  martin is planning on beefing up the guidelines and in
<barry>                  particular, start collecting case reports for interesting
<barry>                  branches that went through ui review  [10:08]
<barry> <intellectronica> so if you're working on a ui branch from either side and
<barry>                  think the process was interesting and other can learn from
<barry>                  it, consider compiling a case report
<barry>  
<barry> intellectronica: thanks; beuno do you have anything you want to add?
<beuno> well
<beuno> my goal is for the team to do it's own reviews
<beuno> and have teh UX team help with the long-term changes
<beuno> and I'm not sure how to get there, but I'm starting to
<barry> one other thing we talked about was adding a 'ui' specialty to ReviewerSchedule for people who have graduated from ui mentat
<beuno> so if anyone has suggestions, ideas, comments, anything, I'd be very grateful
<beuno> yes, it's on my ToDo
<barry> beuno: cool, thanks
<barry> beuno: do you want to join this meeting regularly?  i could add 'ui reviewer report' to the agenda
<beuno> barry, I would like to try, yes
 * barry will be pingmaster :)
<barry> beuno: awesome, thanks.  i'll remove intellectronica's action item then
<barry> anything else on ui reviewing, from anybody?
<barry> cool, moving on
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> i think i'll remove this topic for now.  when wgrant wants to become a reviewer we can add it back
<intellectronica> aren't we all reviewing now? i think this item can be skipped until some community members start reviewing
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<barry> intellectronica: yes, we are all reviewers!
<barry> so, does anybody have anything not on the agenda?
<intellectronica> yes
<barry> i guess that's it then!
<intellectronica> almost :)
<barry> intellectronica: go4it
<gary_poster> barry: (I'm not going to be OCR on Wednesday because of team lead duties)
<gary_poster> 6 mo. :-)
<intellectronica> a reminder to everyone that python branches with a diff > 800 lines and javascript branches with a diff > 1600 lines are exceptional, and need to have a review sorted in advance. OCRs will often not be able to take them just like that
<barry> gary_poster: gotcha.  EdwinGrubbs will have to carry the west
<gary_poster> k
<barry> intellectronica: thanks, and remember as a reviewer you always have a right to kick the branch back
<barry> anything else today?
<barry> 5
 * cprov feels guilty and hides.
<barry> 4
<barry> 3
<barry> 2
<barry> 1
<barry> #endmeeting
<MootBot> Meeting finished at 09:19.
<barry> thanks everyone!
<jtv> thanks barry
<gary_poster> thanks barry
<intellectronica> thanks barry
<barry> #startmeeting
<MootBot> Meeting started at 17:30. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello and welcome to this week's asiapac meeting, who's here today?
<barry> thumper, rockstar ping
<thumper> hey
<barry> thumper: hi.  i think it's just the three of us today, right?
<barry> should be a quick meeting i think
<thumper> yep, although rockstar is out for a walk right now, so maybe just me
<thumper> did rockstar go to the earlier one?
<barry> nope, he's joining us now
<barry> s'okay, we can start (and maybe finish without him :)
<thumper> ok
<barry> not much to report from ameu; gary_poster will suspend ocr duties while he fills in for flacoste, who's filling in for kiko
 * thumper nods
<barry> that's really about it.  got anything on your mind today?
 * thumper thinks
<thumper> mainly just 3.0 redesign
<thumper> although...
<thumper> there was a question earlier by gmb
<thumper> about "do mechanical 3.0 changes need a ui review"
<thumper> I was under the impression that mechanical ones don't
<thumper> new pages/designs do
<barry> those are up to the reviewer+dev.  if they feel it doesn't need another ui review, they're fine
<thumper> ok
<thumper> that's it for me
<wgrant> One thing...
<wgrant> Not sure where is appropriate, though.
<thumper> shoot
<thumper> ask away
<wgrant> It seems to me that contributors should always get a reviewer from the team that their branch targets, because otherwise the team has no chance to object.
<wgrant> The dev wiki just says to poke an OCR, but that probably often isn't right.
<thumper> wgrant: I think it depends on the change
<barry> wgrant: that should be okayedin a pre-imp call, likely with a team member
<thumper> wgrant: if it is something trivial, then I'd be happy to OK a bugs or soyuz change
<barry> we're all /supposed/ to be be able to review anything
<thumper> but if it is not trivial, or requires more specialised knowledge
<thumper> I'll pass it on, like I have done
<rockstar> oops.
<rockstar> Hi
<barry> rockstar: hi
<barry> thumper: yep
<barry> wgrant: does that make sense?
<wgrant> barry: It says to do the pre-imp chat with the OCR, but I suppose in most cases they'll just defer to a member of the right team, in which case that's fine.
<wgrant> It does.
<barry> wgrant: cool, yep
<wgrant> Thanks.
<barry> wgrant: it's great to see you here, and fantastic to see your branches landing.  how is the processing going for you?
<barry> er, process
<wgrant> barry: Very well, apart from the opacity of PQM and ec2test.
<barry> wgrant: well, at least we feel your pain there too :)
<thumper> wgrant: we are wanting to move to LP queues
<wgrant> The actual review stuff is fine.
<thumper> wgrant: which will make at least that part more visible
<wgrant> But after the review, it goes into a black hole and sometimes doesn't appear again.
<rockstar> And once we're on queues, tarmac.
<barry> rockstar: ftw
<thumper> rockstar: maybe ;-)
<wgrant> There's also the problem of security branches, but I believe you're working that out elsewhere.
<wgrant> That hit me today.
<rockstar> thumper, don't toy with my emotions like that...  :)
<thumper> I'm supposed to come up with a plan
<barry> wgrant: because you can't make private branches?
<thumper> but I've not had time right now with the 3.0 stuff
<wgrant> barry: Correct.
<thumper> we are planning the ability for anyone to be able to have a private branch
<thumper> to fix security bugs
<wgrant> barry: I got spm to make it private, but then had to go back to him to get it visible to ~launchpad.
<thumper> but there are issues about who gets emailed when
<wgrant> I'm not a member of ~launchpad, so I can't subscribe them to my private branch.
<barry> thumper: would they have to be tied to security bugs?
<thumper> barry: possibly
<thumper> barry: we are lacking some ui ability
<barry> wgrant: yep, that's losa territory
<thumper> barry: it may just work, but I'm not convinced, and will have to look at the tests
<barry> cool.  rockstar anything on your mind for today?
<rockstar> barry, nope, not really.  I think the UI review for mechanical changes thing was the only thing.
<barry> if there's nothing else from thumper, wgrant...
<wgrant> Is devpad.info going to be public at some point?
<thumper> nope
<thumper> buildbot is moving
<wgrant> It's annoying getting buildbot failures with me in the blamelist, and not being able to actually see what went wrong.
<wgrant> Ah.
<thumper> wgrant: lpbuildbot.canonical.com
<thumper> wgrant: but I'm not sure on the visibility of it
<rockstar> It should be public.
<wgrant> thumper: Aha!
<wgrant> But no, it's not public.
<barry> i think we're done...
<barry> #endmeeting
<MootBot> Meeting finished at 17:47.
<thumper> thanks barry
<barry> thanks everyone
#launchpad-meeting 2009-08-20
<Ursinha> OOPS-1307J16
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1307J16
<Ursinha> thanks ubottu
 * Ursinha looks at matsubara
<matsubara> #startmeeting
<MootBot> Meeting started at 10:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<sinzui> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<gary_poster> me
<Ursinha> me
<danilos> me
<matsubara> stub, cprov, herb, rockstar, intellectronica: hi
<cprov> me
<rockstar> ni!
<mthaddon> me
<intellectronica> me
<matsubara> hi mthaddon
<mthaddon> matsubara: herb won't be attending these meetings any more since he's no longer a LOSA
<Ursinha> it's true
<matsubara> mthaddon, indeed!
<matsubara> let me update the page
<Chex> hello!
<mthaddon> matsubara: most likely Chex will be his replacement (given he's on the same timezone that herb was on)
<Ursinha> hi Chex, welcome!
<matsubara> mthaddon, all right thanks
<matsubara> hi Chex, welcome
<Chex> all: thank you
<stub> moo
<matsubara> ok, everyone is here
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<intellectronica> hi Chex, welcome
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (stub)
<matsubara> [TOPIC] * Actions from last meeting
<Ursinha> matsubara, you'll may want to s/flacoste/gary_poster in that page
<MootBot> New Topic:  * Actions from last meeting
<matsubara> Ursinha, already done
<Ursinha> matsubara, thanks
<Andre_Gondim> me
<matsubara>   * ursinha to chase mars about OOPS-1307J16 and file a bug about it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1307J16
<matsubara>   * matsubara to file a bug for OOPS-1315A253
<matsubara>     * Filed https://launchpad.net/bugs/413706
<matsubara>   * sinzui to file bugs for OOPS-1318S626, OOPS-1321EB223 and OOPS-1318EA4
<matsubara>   * gary_poster to chase librarian-gc failure and report back to the list
<matsubara>   * matsubara to ask stub to email the dba report to the list
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1315A253
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1318S626
<matsubara>     * stub sent the dba report to the list
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1321EB223
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1318EA4
<ubottu> Ubuntu bug 413706 in launchpad-foundations "InvalidURIError using %s as the search term in the global search" [Undecided,New]
<matsubara> hi Andre_Gondim, welcome
<Andre_Gondim> thanks =]
<matsubara> hi sinzui, did you file those bugs?
<matsubara> Ursinha, no news about that oops? shall I remove the action item?
<Ursinha> matsubara, do that, I'll file a bug if that happens again
<matsubara> Ursinha, thanks
 * sinzui has no screen
<matsubara> re: the librarian-gc failure, it was disabled that week, that's why we had a script failure email to the list
<gary_poster> stub is working on that as his next task
<mthaddon> I think there's a CP pending approval for that
<sinzui> matsubara: I did file bugs
<matsubara> gary_poster, mthaddon: cool. thanks
<stub> The next bit of work on the librarian may be related - depends on what happens with the cherry pick and test run ;)
<Ursinha> gary_poster, this is bug 410576, right?
<sinzui> OOPS-1315A253 is soyuz
<ubottu> Launchpad bug 410576 in launchpad-foundations "Librarian-gc discovered file missing from disk" [Critical,Triaged] https://launchpad.net/bugs/410576
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1315A253
<matsubara> sinzui, thanks. if you have them handy, could you priv msg them to me?
<sinzui> bug 413174
<ubottu> Launchpad bug 413174 in launchpad-registry "API AssertionError creating a release" [Low,Triaged] https://launchpad.net/bugs/413174
<gary_poster> Ursinha, that's not my understanding.  hm, that's a dupe.
<Ursinha> gary_poster, a dupe? is there another?
<Ursinha> this one is set as Critical... I'll talk about it in the next section :)
<sinzui> matsubara: OOPS-1318EA4 is new. It relates to another bug that I intend to fix in 3.0 I will file and assign it
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1318EA4
<matsubara> thanks sinzui
<gary_poster> Ursinha: either dupe or related: bug 413749
<ubottu> Bug 413749 on http://launchpad.net/bugs/413749 is private
<Ursinha> gary_poster, let me see
<Ursinha> matsubara, you can move to the next section and we keep discussing there
<matsubara> ok, thanks Ursinha and gar0t0
<matsubara> err
<matsubara> gary_poster,
<gary_poster> :-)
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<matsubara> there you go Ursinha
<Ursinha> okay
<Ursinha> +branches timeout has a fix already committed, and also that horrible 'specications' bug is fix committed as well
<Ursinha> so, two issues to ask: foundations and registry
<Ursinha> sinzui, I can see a lot of these ExpatErrors, that are bug 403606, does barry said something about fixing that?
<Ursinha> gary_poster, bug 410576 is Critical but I see there's no activity for almost a week now, is that really critical?
<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 410576 in launchpad-foundations "Librarian-gc discovered file missing from disk" [Critical,Triaged] https://launchpad.net/bugs/410576
<Ursinha> (in this meantime, I'll check bug 413749
<ubottu> Bug 413749 on http://launchpad.net/bugs/413749 is private
<Ursinha> )
<gary_poster> Ursinha: I believe it is high: afaik, the criticality is what mthaddon describes in his comments to that issue.  This is what stub is going to next.
<sinzui> Ursinha: barry has not provided any insight into the issue yet. I cannot estimate it
<stub> Its critical because it is part of the impending librarian collapse.
<sinzui> matsubara: bug #41648
<mthaddon> gary_poster: it's critical - LP will blow up in 20 days or so if it's not fixed (as the librarian will run out of space)
<ubottu> Launchpad bug 41648 in acpi "Sleep and hibernate fail on Acer Ferrari 3400" [Medium,Fix released] https://launchpad.net/bugs/41648
<matsubara> sinzui, hmm that doesn't look like a lp bug
<sinzui> matsubara: bug #416483
<ubottu> Launchpad bug 416483 in launchpad-registry "deletion of series and milestone must remove structural subscriptions" [High,Triaged] https://launchpad.net/bugs/416483
<matsubara> cool. thanks sinzui!
<sinzui> ^ points the the related bug too
<gary_poster> mthaddon, stub: (procedural, apologies) what does critical mean then?  I thought it meant drop everything, while afaict this is a do it within 10 days?
<Ursinha> gary_poster, mthaddon, we have two bugs here, bug 410576 and bug 413749
<ubottu> Launchpad bug 410576 in launchpad-foundations "Librarian-gc discovered file missing from disk" [Critical,Triaged] https://launchpad.net/bugs/410576
<ubottu> Bug 413749 on http://launchpad.net/bugs/413749 is private
<Ursinha> gary_poster, that's my question as well
<mthaddon> gary_poster: I think if we know it's going to blow up all of LP in a short period of time, that's critical
<gary_poster> afaik 413749 is the (a?) symptom of 410576.  stub, mthaddon, can you please correct me?
<stub> gary_poster: It is my top priority, as we need to know the genuine rate of disk consuption for the librarian so we can accurately predict when new disk has to be purchased and installed by, or soyuz has to decrease their consumption by
<gary_poster> stub thank you
<mthaddon> gary_poster: it's related, but fixing the librarian-gc will buy us more time, not fix it forever
<gary_poster> ok, gotcha
<gary_poster> So Ursinha, it is critical, and we should be moving to in progress, at least, within a day or so.
<Ursinha> great gary_poster, thanks a lot
<matsubara> Ursinha, anything else re: oops and critical bugs?
<Ursinha> sinzui, could you poke barry again about that bug? I can do that as well if you want :)
<sinzui> I will
<Ursinha> thanks a lot sinzui
<cprov> stub: we have to adjust the removal of BPRs to be more aggressive.
<danilos> cprov: can you (i.e. Soyuz team) provide data flacoste asked for in https://bugs.edge.launchpad.net/launchpad-foundations/+bug/413749 so we've got raw numbers there as well?
<ubottu> Error: This bug is private
<mthaddon> cprov: any idea of how much space that would buy us?
<cprov> danilos: sure, I can try.
<stub> cprov: Bug 413749 has a soyuz task, so you may want to triage it.
<ubottu> Bug 413749 on http://launchpad.net/bugs/413749 is private
<matsubara> garbo-hourly failed on the 17th even after spm adjusted the check to 12 hours. stub do you know what's up?
<stub> matsubara: I wasn't aware of that.
<cprov> mthaddon: can't tell exactly, but I issue the queries for estimating few other scenarios than 1 month quarantine for BPR files
<mthaddon> ok
<matsubara> there's a "Scripts failed to run: loganberry:garbo-hourly" email sent to the list on the 17th. could you investigate and reply to that email?
<matsubara> stub, ^
<Ursinha> cprov, can you follow up later on that bug then, please?
<cprov> Ursinha: sure
<Ursinha> thanks cprov
<matsubara> [action] cprov to follow up on bug 413749
<MootBot> ACTION received:  cprov to follow up on bug 413749
<ubottu> Bug 413749 on http://launchpad.net/bugs/413749 is private
<ubottu> Bug 413749 on http://launchpad.net/bugs/413749 is private
<matsubara> [action] stub to investigate garbo-hourly failure after spm adjusted script checking to 12h
<MootBot> ACTION received:  stub to investigate garbo-hourly failure after spm adjusted script checking to 12h
<matsubara> [action] sinzui to poke barry about ExpatError OOPSes (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
<MootBot> ACTION received:  sinzui to poke barry about ExpatError OOPSes (bug 403606)
<sinzui> done
 * sinzui eagerly awaits an assessment
<matsubara> cool
<matsubara> I think that's all for this section
<matsubara> thanks everyone
<Ursinha> thanks a bunch sinzui
<Ursinha> and everyone else :)
<Ursinha> do ahead matsubara
<Ursinha> *go
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm)
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm)
<danilos> mbarnett for the agenda as well? :)
<mthaddon> :)
<Chex> - Buildbot now hosted from the DC
<Chex>  - Multiple Cherry Picks this past week
<Chex>  - Will be beginning to implement recommendations from SplitIt Sprint before too long
<Chex>  - Codebrowse needed restarting more than usual this week (see IncidentLog)
<Chex>  - Incident with edge rollout breaking as one app server refused to stop, and interaction with the session DB being trashed - see Incident Report and most likely discussed earlier in the meeting
<Chex>  - LOSA sprint this week to get new LOSAs (Chex, mbarnett) up to speed
<matsubara> danilos, good catch. thanks
<Chex> and thats it for us, unless there are any questions??
<gary_poster> yay buildbot in DC! :-)
<danilos> yeah, great stuff, looking forward to everything else that enables :)
<danilos> (like the production branch in buildbot *grin*)
<matsubara> thanks Chex
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> Our disk usage is going steadily up. Nothing alarming yet, but it did prompt me to turn on the long-running-transaction killer. Non-system transactions running over 3 hours will now be killed. This should alleviate database bloat, which adversely affects everything. It will also stop processes that block on long running transactions from blocking too long (like the garbo).
<stub> I've bumped up the default statistics target to 250. We have twice over the last several months had a query chewing up huge amounts of disk space in temporary tables, and my best guess as to why is bad query plans. The higher statistics target should make this less likely.
<stub> Done.
 * Ursinha misses the oot thing
<Ursinha> questions for stub?
<danilos> stub: ok, so that means that fixing langpack exporter is now critical for us, right?
<stub> danilos: I can turn it off if necessary. I'm not sure what effect is has on the langpack export.
<stub> Will all of them be affected?
<stub> oot
<danilos> stub: most of the runs will
<Ursinha> hehe
<danilos> stub: I've made it critical for us, it should be a simple fix, it'll only require cherrypicking
<stub> danilos: ok. I'd like that issue raised to high or critical. I'll turn the check to 8 hours which will cover the current longest transaction I'm seeing in the graphs.
<stub> k
<danilos> stub: it was high and scheduled for 3.0, now it's scheduled for asap :)
<stub> Please add a note to the CP request that the limit needs to be put back.
<danilos> stub: sure, thanks
<Ursinha> thanks stub
<Ursinha> and danilos
<matsubara> thanks stub and danilos
<stub> danilos: Bug number?
<danilos> stub: bug 411697
<ubottu> Launchpad bug 411697 in rosetta "Language pack export has very long running transactions" [Critical,Triaged] https://launchpad.net/bugs/411697
<matsubara> * In-team handling of OOPSes (Danilo)
<danilos> ok, a long paste follows
 * matsubara hands the mic to danilos 
<danilos> Breaking news from the team leads call!  Read all about it!
<danilos> Many of the duties Diogo and Ursula had you spoiled with (like trawling OOPS summaries and error logs and matching/filing relevant bugs) is what QA contacts in each team should do (generally, it was considered that this is what they should have been doing anyway).
<danilos> According to Gary, Diogo is happy to continue maintaining oops-tools (and relevant infrastructure, which will stay in Foundations turf), but everybody else is invited to contribute and take interest in the tools if they want something added.
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=tools
<danilos> Similarly, if someone finds it hard to go through numerous places to see all the possible problems (i.e. going through several OOPS summaries, error-reports list, etc), they are welcome to improve our infrastructure for aggregating these.
<danilos> I am personally hoping that once we pick a release manager for 3.0, (s)he'll take care that all QA contacts are on top of their game. Perhaps we can have Ursula and Diogo continue as is until RM for 3.0 is appointed.
<danilos> Any suggestions on what should change in the format of the meeting to make sure this is not a regression compared to what we do today?
<gary_poster> (eh, that summary came out in such a way that I feel I should have talked with matsubara first.  sorry, matsubara, and feel free to correct the summary about your personal position)
<matsubara> gary_poster, it's correct :-)
<danilos> gary_poster: (I was just being careful not to put words in matsubara's mouth, I should have talked to him first, but there just wasn't the time between the teamleads call and this meeting :)
<gary_poster> cool :-)
<danilos> anyway, how should the meetings be run from now on? matsubara, you want to keep running them?
<gary_poster> +1 if you are willing matsubara
<matsubara> danilos, yes, I talked to francis about it and Ursinha and I will still run the production meeting
<cprov> +1
<danilos> anybody else has any comments? everybody, this means more work for you and less for matsubara, Ursinha :)
<Ursinha> +1 from me
<stub> How to teams claim an oops? The benefit of a central monitor and this meeting is when teams disagree on who the problem belongs too.
<matsubara> but it'd be nice to have help from the QA contacts doing the daily oops analysis and help with triage
<danilos> stub: that's for the release manager to worry about IMO, but in general, we should be having bug attached to all the OOPSes
<stub> Who creates the bugs?
<Ursinha> danilos, that's the idea
<Ursinha> stub, it depends
<Ursinha> stub, for instance, afaik, translations has been creating its own bugs for some time now
<Ursinha> checking the summaries daily
<danilos> stub: in general, we might be able to improve tools to split summaries by vhost initially
<stub> I'm just wondering how we avoid them being dropped on the floor because, say, translations thinks an oops is a foundations issue and vice versa.
<Ursinha> danilos, matsubara has the idea of using page ids
<Ursinha> for splitting
<Ursinha> *had
<danilos> Ursinha: right, that might be a good one as well
<stub> splitting the reports into areas of responsibility would address my concern I think.
<danilos> Ursinha: actually, it's perfect
<cprov> okay, running the risk to sound like an idiot,  who are the current QA contacts ? TLs ?
<Ursinha> cprov, the people that attend this meeting
<stub> TLs until they delegate ;)
<matsubara> cprov, everyone who attend this meeting weekly
<danilos> cprov: it means it's you! :)
<matsubara> cprov, actually it's bigjools, but he's away today
<cprov> fantastic! thanks.
<Ursinha> danilos, :P, bigjools actually
<danilos> heh, ok... in general, I think this is best done by a team lead
<danilos> (and soon enough, I'll be replacing henninge as the translations QA contact)
<Ursinha> danilos, it was TL's call when they pointed the QA contacts
<danilos> Ursinha: I know
<gary_poster> hm.  question.  if we *all* trawl oops, is that a collective time loss?
<Ursinha> but that can be changed for this new experiment
<Ursinha> gary_poster, if we separate per teams, not that much
<Ursinha> I believe
<danilos> so, matsubara, can we have an action for me to discuss with Ursinha and you how we can split OOPS reports into per-team summaries?
<Ursinha> per "teams"
<gary_poster> oh I see
<danilos> gary_poster: right, see above
<gary_poster> ok thanks
<matsubara> [action] danilos, Ursinha and matsubara to discuss oops summaries split per team
<MootBot> ACTION received:  danilos, Ursinha and matsubara to discuss oops summaries split per team
<danilos> matsubara: thanks
<Ursinha> gary_poster, we in fact have a new feature on oops-tools that associate a bug to a exception type (matsubara correct me if I'm wrong here)
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=tools
<Ursinha> this helps a lot
<danilos> ubottu: thanks for nothing (just so you don't get used to praise only)
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<Ursinha> sometimes you freak me out ubottu
<Ursinha> anyway
<Ursinha> :)
<danilos> anyway, that's all settled afaiac
<matsubara> gary_poster, Ursinha: now we have a feature on oops-tools that once an oops is linked to a bug, subsequent oopses of that same type are already linked to the bug report
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=tools
<Ursinha> gary_poster, if you click the oops, most of them have a bug associated, on top left
<danilos> we'll be reporting back, everything stays as is until we've got better oops reports, but do expect changes soon
<matsubara> makes analysis much easier
<Ursinha> bug report?
<matsubara> next step is to add that info to the summary
<gary_poster> heh.  ah I see cool
<gary_poster> thanks Ursinha, matsubara
<matsubara> all right. thanks danilos for bringing this up
<Ursinha> ah, I got that
<matsubara> and thanks everyone
<Ursinha> thanks everyone
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:46.
<matsubara> 1 min late. sorry about that
<gary_poster> :-) thanks matsubara
<Ursinha> thanks matsubara and everyone!
<gary_poster> thanks Ursinha :-)
#launchpad-meeting 2009-08-21
 * sinzui kicks about the channel wondering if he is alone
<flacoste> hi
<sinzui> I am not alone!
<flacoste> anybody here for the Q&A session?
<flacoste> otherwise there seems to be a bad failure in buildbot
<sinzui> With thumper off, I do not think their are any launchpad-code hackers about at this  time
<flacoste> right
<flacoste> cancel it?
<sinzui> But I hope that anyone who is watching launchpad change has a question that I can answer
<flacoste> postpone?
<flacoste> wait and see?
<sinzui> I am up at this time hacking on 3.0. I it is no bother to linger
<sinzui> michael and jono will not be attending. I have been talking the thumper every day about 3.0
<sinzui> So I was hoping to practice answers with a small antipodean crowd
 * sinzui kicks about the channel wondering if he is alone
<flacoste> looks like it
<wgrant> sinzui: You listed the wrong channel in #launchpad-dev.
<sinzui> I did where shoule I be
 * sinzui looks at email
<wgrant> I interpreted the ' meeting' in '#launchpad meeting' as being a typo.
<wgrant> As in, a dupe word.
<sinzui> I see #launchpad-meeting
<sinzui> I will answer questions any where
<sinzui> wgrant: I did file about about the missing query information from the edge and lp.net pages
<wgrant> sinzui: I saw that; thanks.
<sinzui> wgrant: I merged two sections and wrongly guarded everything
<wgrant> where are the breadcrumbs going in UI 3.0? That wiki page still lives on wiki.c.c.
<wgrant> Between the branding/watermark/location/blah and app tabs?
<sinzui> We do need to move that. There is nothing secrete and a lot teams have not seen it since it is in a awkward place to go
<sinzui> The mockup that I have seen place the breadscrumbs under the wrongly named heading-slot
<wgrant> Which heading is heading-slot?
<wgrant> There are three that could be incorrectly called that.
<sinzui> yes.
 * wgrant checks the template.
<sinzui> https://edge.launchpad.net/launchpad-registry
<sinzui> ^ There should be breadcrumbs under the Green <h1>The Launchpad Registry
<wgrant> Under? That doesn't sound right. Won't that sometimes be 'Edit The Launchpad Registry'?
<wgrant> Or is that the odd grey heading which appears rarely?
<sinzui> If you were to view a form page The breadcumbs are in the same place, but the heading above it is demoted to a <h2>
<sinzui> The form label becomes the <h1> an is under the breadcrumbs
<wgrant> Ah, that makes sense.
<sinzui> Think of the three heading as 1) a watermark 2) a context heading and 3) the page title/heading
<wgrant> sinzui: Should the context and page headings be omitted if either is the same as the watermark?
<wgrant> 'cause they're not on the new pages, and it looks silly.
<sinzui> But this is still hard to engineer and review because both parties must know when to pass the page title/heading to the heading slot to prevent duplicate titles
<sinzui> Your question has not been settled. The answer is no, but I do not think anyone likes that answer
<sinzui> The case you point out is a pillar, person, or top-level colllection.
<wgrant> The project edit and index pages, for example, look pretty strange with the differently duplicated headings.
<sinzui> yes they are
<wgrant> But I suppose otherwise the descendant objects would have different numbers of headings for their edit forms.
<sinzui> To combine the watermark heading and the context heading requires some clever work because editable titles cannot be autocreated by the layout
<sinzui> wgrant: If we solve the editable title issue, I think we would consider dropping the context header
<wgrant> sinzui: Oh. I thought the watermark would get an inline edit link. But that idea formed in my mind before I realised how shallow that heading was.
<sinzui> Right
<sinzui> We will solve this, but I am not certain we will do it for 3.0
<sinzui> We need to make the logo editable in the page and we need to communicate it is editable
<sinzui> We have an idea EdwinGrubbs will start work on in the next two weeks
<wgrant> Good, good.
<sinzui> The registry will loose its colur
<wgrant> Hm?
<sinzui> Answers will get a colour refinement
<sinzui> The reason is that blue and green mean links in Launchpad .
<wgrant> Ah.
<wgrant> I noticed that the Blueprint and Answers involvement link colours are too close to the background for my liking.
<sinzui> indeed that bug has not been filed.
<wgrant> The new project index view also exposes the wrong release for download.
<sinzui> The set answer contact page is very confusing because it is just links and headings-- blue ans blue on white.
<sinzui> really?
<wgrant> Yes.
<wgrant> It was showing bzr 1.18rc1 until today.
<sinzui> That comes from a query that was considered proven
<wgrant> But that's a flaw in the data model :(
<sinzui> The rdf link is a problem
<wgrant> I think it needs to die.
<wgrant> Or go down the bottom
<wgrant> Or just generally hide.
<sinzui> I argue that we move into the <project|distro|projectgroup> information portlet since the info is an alternate of the portlet info
<sinzui> poolie and I discussed dropping RDF.
<wgrant> It certainly doesn't belong in the Downloads portlet.
<wgrant> And it causes it to show up on projects where it makes no sense.
<sinzui> I was strongly inclined to do it since the FOAD and DOAP is useless from my inspection
<sinzui> I found that there are a minority of users who are using it
<wgrant> If people know what FOAF and DOAP are, they can probably find an obscure link.
<sinzui> s/FOAD/FOAF/
<wgrant> FOAF was useful once upon a time.
<wgrant> And I think REVU might still use it.
<sinzui> My fallback proposal was to add a meta instruction to the page to indicate there is an RDF alternate for the page
<sinzui> We need help converting blueprints
<sinzui> It is assigned to the registry team, but my team already has 3 times more templates than other teams
<wgrant> I considered working on some Blueprint stuff. But, well, I think Blueprint needs to go away and be subsumed into Bugs.
<sinzui> I am told that that is unlikely
<wgrant> Damn.
<sinzui> I think the next best thing is to give them feature parity so that the similarities make the argument more compelling
 * thumper reads scrollback
<sinzui> I am sure blueprints would be more successful if it's statues, events, and email were like bugs
<wgrant> Blueprint and Bugs each have sets of unique features, all of which would be useful for the other.
<sinzui> No one has brought up the NavigationalMenus, the bane of every developer's existence
<wgrant> Are NavigationMenus those grey-turned-black things that lurk at the top of the old pages?
<sinzui> There is a request to create a small task/todo application. It is assigned to the registry for evaluation
<sinzui> YES they are
<sinzui> There are many names for them.
<wgrant> And they are very confusing and easy to miss.
<wgrant> It takes ages to work out how to alter a person's OpenPGP keys.
<sinzui> Looking at the designs we (me) assumed they would go away, a failed 2.0 experiment
 * thumper never like the navigational menus in the first place
<sinzui> mpt did. beuno announced they were going away on the day he took over the UI
<wgrant> sinzui: To what level should I be filing bugs on new UI bugs?
<wgrant> eg. the unconditional "padding-bottom: 0.3em" on 3.0 <li>s, which makes the actions portlet too tall.
<sinzui> We are being pretty details. I have bugs for each portlet I am working on
<sinzui> Engineers started speaking up on the CSS  this week. I think we have all seen enough to know what does not work
<sinzui> The <h2> elements were updated today I think
<sinzui> We should have bugs on these  issues.
<sinzui> There was an accidental reuse of of the summary class that makes search results look very large
<sinzui> wgrant: when I change a detail, I search the bugs to see if I can fix something else at the same time
<wgrant> The same thing happens on ArchiveActivateView when there are existing PPAs.
<sinzui> The registry had 50 UI bugs when this started. I think we should try to solve all of them
<sinzui> was that converted?
<wgrant> It was.
<sinzui> damn
<wgrant> But the view it uses to list the PPAs wasn't.
<wgrant> Yet.
<wgrant> It's the same listing view that's used on the person index, so it should be fixed when that goes 3.0.
<sinzui> I can adjust the CSS rules. I think this also relates to the overlap of object attributes
<sinzui> title and displayname, summary and description and homepage
<wgrant> Oh, also, the project summary looks far too fat here.
<wgrant> Am I the only one who thinks this?
<sinzui> I am uncertain.
<sinzui> I think the issue is how much info was put in it
<wgrant> The description of the summary is lacking, and I'm not sure if any existing projects do it properly.
<wgrant> Actually, launchpad-project's works very well.
<sinzui> I agree
<wgrant> launchpad-registry... not so much.
<sinzui> I have been meaning to rewrite the registry
<sinzui> It was given to me. I like Ed' RDF work, but the registry is not really about that
<wgrant> Maybe it was initially.
<sinzui> yes there are foaf and doap directories in the tree still
<wgrant> Huh. I thought those were removed ages ago.
<sinzui> after 3.0 I think we can rename some directories
<sinzui> We are stilling find tests and templates in the wrong place. The effort to update everything is making us clean up a lot
<wgrant> I've seen a lot of stuff in canonical.launchpad that should really be moved out to the app packages. :(
<sinzui> yep
<sinzui> That is officially the foundations team, they have had other priorities over the past year
<sinzui> thumper and I started moving items there because it is frankly easier to find
<wgrant> Mmm. It has definitely made it rather harder to find, but that's just because everything is spread around horribly.
<sinzui> everything in canonical/launchpad/webapp should become canoncial/lazr The code is too intermixed to separate it easily
<sinzui> webapp/tales is getting lot of work. We should try to move that soon. Maybe give up on lazr and move it to lp/app
<sinzui> There are a lot of old tests or unowned code that needs sorting out in c.l
<sinzui> I think structural subscriptions should become the registry's domain
 * sinzui would like to take sprints form blueprints too
<wgrant> They should.
<wgrant> Shouldn't c.l.webapp.tales be cut into lots of pieces and thrown into different apps, rather than all going into lp.app?
<sinzui> I am adding links to create sprints from the series pages
<thumper> wgrant: yes it should
<sinzui> absolutely.
<thumper> wgrant: I did the first yesterday
<wgrant> sinzui: I don't think it's a good idea to link to sprints before they're improved.
<sinzui> There are some ancient tests (canonical/launchapd/doc/menu.txt comes to mind) that can be dismantled because they duplicate other tests
<sinzui> wgrant: yes, I would commit to fixing them when I move them
<sinzui> I do not think the need to be dependent on blueprints. There are date and report issue that need fixing
<wgrant> Why has the bounty tracker not been purged completely like the calendars were years ago?
<wgrant> Or is it meant to maybe be revived at some point?
<sinzui> there was some thought about resurrecting it.
<sinzui> well that thought certainly died before 2.0
<sinzui> We are driven to work on business priories. while 20% of our time should be spent one clean up the code and tree, I do not think it is being done my every engineer
<sinzui> It would have been cleaned up if it was a specific team or person's responsability
<sinzui> It is going to be removed either by the registry team or the soyuz team because we have bounty templates we are obligated to remove
<wgrant> Ah.
<sinzui> I do not have access to the script that generates the progress report
<sinzui> It shows the templates that need converting
<wgrant> The one on devpad run by mars?
<sinzui> yes
<flacoste> there is a branch for it
<sinzui> That would be nice
<sinzui> We can push the static ajax data and the output file to a public location
<sinzui> Do I dare start a meeting
 * beuno cheers
<sinzui> Well
<sinzui> time to start
<sinzui> #startmeeting
<MootBot> Meeting started at 09:02. The chair is sinzui.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bigjools> me
<sinzui> Let's try a rollcall just so I know how many people are listening
<sinzui> ha
<noodles775> I'm here to learn from any discussions too!
<beuno> me
<deryck> me
<bac> me
<sinzui> I seem to have missed jtv in both sessions
<sinzui> okay. we can start.
<sinzui> Does anyone have a question about UI 3.0
<sinzui> I will ask a question then
 * bigjools raises hand
<sinzui> beuno: The registration information should appear in the header. bug should it appear all the time? I am certain it should appear for an index  of a context object, but what about a alternate view of it?
<sinzui> s/bug/But/
<beuno> sinzui, I think only on the overview
<beuno> it's not that important
<sinzui> beuno: when I look at the mirror listing for a distro, should I see then the distro's registration info
<sinzui> beuno: it is for some tests, but only on the index
<bigjools> this sort of thing breaks down a bit on the packaging pages
<beuno> so there's your answer
<beuno> "only on the index"
<sinzui> That is easier to do. I can provide both automatic rules and a slot to override it
 * sinzui worries about every page.
<sinzui> thanks beuno
<sinzui> bigjools: you have a question?
<bigjools> is there a general plan to deal with the type of objects that have no narrative to show under the title?
<sinzui> I do not think so
<sinzui> rockstar: has a similar issue with answers, where the narrative should not be separated from the comments, so the details is first
<bigjools> in a page I was doing mechanical changes to, the distroarchseries index, there's no narrative, and I need to go straight into a two column grid
<sinzui> That can happen with milestones and releases too
<sinzui> bigjools: their narrative is optional, so the design must DTRT
<bigjools> what is DTRT in this case?
<sinzui> beuno: Have you seen a design that we can use to implement without thinks for objects we are not redesigning?
<bigjools> yeah, that'd be nice, since I have a few pages that have details portlets that I need to move inline somewhere
<sinzui> bigjools: I do not know. I think the infrastructure or design rules should be clear enough that I do not need to think
<sinzui> bigjools: that is exactly the problem that rockstar encountered
<sinzui> bigjools: is this issue blocking DSP?
<bigjools> not really, I think we've settled on that now
<sinzui> because we found a sentence to start the page with?
 * beuno reads the scrollback
<bigjools> sort of, I gave it a "This package has XXX new bugs and XXX open questions"
<beuno> could I see a screenshot or a page of this?
<beuno> I'm not sure I fully understand it
<sinzui> I ponder what this means about these kids of artefacts. Do we consider them self-explanatory?
<bigjools> have a look at https://edge.launchpad.net/ubuntu/jaunty/i386 and tell me how you would redesign it
<sinzui> bigjools: distroarchseries is the i386 details of karmic?
<bigjools> beuno: you've already seen that DSP page quite a few times  :)
<bigjools> sinzui: it exists to be able to do binary package searches for that architecture
<bigjools> but it doubles as an index I guess
<sinzui> does it really need it's own page then (I know you do not want to invest a lot of time)
<bigjools> exactly, this was supposed to be a simple mechanical change :)
<beuno> bigjools, I think that moving the information beneath the search box is TRTTD
 * sinzui merge milestones and releases to reduce duplication
<bigjools> beuno: yeah, I have it to the right at the moment, it doesn't look quite right
<bigjools> it also has a separate template for +search that is 95% the same as +index, so I merged them
<beuno> bigjools, it sounds like we need a better answer for moving that type of portlet into the content rather than the description-less issue
<bigjools> I onlt mentioned the description-less stuff because curtis said it looked weird on the DSP page :)
<bigjools> but yeah, this is another issue to work out
<beuno> I don't think the lack of description in itself is a problem
<bigjools> the question was whether it was good or not to put a two-column portlet arrangement immediately below the title
<beuno> not in this case
<sinzui> So do we want to set this as an action item to define a no-think-required way to handle narrativeless pages?
<beuno> that means more work for me, so I'm not 100% sure of it
<bigjools> heh
<beuno> but I will work with someone to figure out a pattern  :)
<sinzui> I think the issue is that a page cannot start with two columns, so we must always have a piece of content that can be used as a top-portlet
<bigjools> so I think what I did on the DSP was fine
<bigjools> even w/o the extra text I added
<bigjools> we could do with some styling to bottom pad the <h1> in the main content though, it butts up too close to the rest of the content
<sinzui> bigjools: by making the search the first content and it span all main, does this create a second problem? That the arch information is now spanning two columns and it creates unwanted whitespace?
<beuno> maybe it doesn't need 2 columns?
<bigjools> sinzui: I've not tried that layout yet, I started with a two column arrangment to see how it looked
<beuno> bigjools, I think that there's no padding because breadcrumbs are coming, and they will have it
<bigjools> coolio
<sinzui> 2 columns is optional, never required
<bigjools> the other thing is that I know beuno will hassle me for just moving the details portlet inline as it doesn't look that good
<sinzui> I believe that many listing/collection pages will never use 2 columns
<beuno> I like being predictable
<bigjools> which means making it a 2-column <dl> I guess
<noodles775> I have a question too - has anyone opened a bug for the watermark heading (h1/h2) issues that we've always known about, but not yet had time to fix? (ie. https://edge.launchpad.net/ubuntu/+search)
<sinzui> bigjools: I expect the details/info to be in the upper left of every page.
<bigjools> sinzui: that would displace the search form
 * sinzui does not want to search the page for that information
<sinzui> bigjools: I ti not the first item on any approved design
<bigjools> I think search forms should always be at the top
<sinzui> bigjools: it is the second
<bigjools> for example, the search form on the distro index page mockup was in the wrong place for me
<sinzui> bigjools: the general rule of pages (on the whole WWW) is first state what the page is about, then provide some details. then provide things that you can do
<sinzui> bigjools: It has not been approves
<sinzui> bigjools: It has not been approved
<sinzui> bigjools: we will discuss that design today. The issue is not just the importance of the field, but the links that relate to it
<bigjools> ok
<sinzui> bigjools: if we do not place content is a consistent manner, users will report a bug.
<bigjools> so beuno said above that on my DAS page the search should come ahead of the details
<sinzui> bigjools: so if we try to make an exception, we should be prepared to unmake it if users point out the issue
<beuno> well, because I feel that those aren't really details, as the title really asys it all
<beuno> says, even
<sinzui> and I say the detail comes after it like the pillar pages
<bigjools> indeed
<bigjools> oh I should also mention that the search results come at the bottom of the page now
<bigjools> since I removed the ridiculous second +search template that was 95% similar
<beuno> so that's another reason to place the info beneath the search feild
<beuno> so you don't move it around on the page when searching
<bigjools> it won't...?
<bigjools> you'd just have:
<bigjools> ______________ SEARCH
<sinzui> the details is also below the search results
<bigjools> [info]
<bigjools> [results]
<beuno> no, I think the details should go when you search
<bigjools> argh
<beuno> :)
 * sinzui this thinks is the same as when a project puts 8 paragraphs of homepage content, pushing project details below the fold.
<bigjools> so much for "no-think" changes :)
<bigjools> this is why I put the info on the right!
<beuno> well, there always some thinking, otherwise sinzui would just write a script that did all the work
<bigjools> lol
<sinzui> I assume that someone has read the details before searching. Once the user has searched, the results are the most important
<sinzui> I think search, results, details is the best order in the circumstance
<bigjools> or in a side portlet...
 * bigjools hides
 * sinzui gets nightvision goggles
<noodles775> lol
<sinzui> bigjools: are you concerned that the details are below the fold after a user  has searched?
<beuno> details are clutter and distraction in a search results page
<sinzui> beuno: that is my point
<bigjools> below the fold is fine with me
<sinzui> we know the user is only going to look at the results
<beuno> bigjools, it can't be that hard to only how the details if there's no results
<bigjools> beuno: yeah easy to fix
<beuno> good, then it's done!
<bigjools> it just goes to show there's no such thing as a mechanical change, even on the most trivial of pages
<bigjools> look at the damn thing...
<bigjools> it's gone a search form and a details portlet FFS :)
<sinzui> We have discovered a rule that collections can place alternate links to lists in the side portlets. /people and /project will use this
<barry> and /projectgroups /distros /sprints
<sinzui> beuno: Question listing and bug lists also have alternate views of the list. can they be in the side portlets too?
<barry> to refine: beuno suggested no info icon and a very simple word for the links (e.g. People)
<beuno> sinzui, I think intellectronica has listed them as such in his mockup, yes
<sinzui> he did
<sinzui> I suggest to bac to move them inline for the mirror listing pages. he may want to reconsider
 * sinzui thinks the two links looked better inline
<bac> yeah, they do look good in-line
<sinzui> beuno: the +global-action view that makes the side portlet links never generates a header because it si always first.
<sinzui> beuno: since there can be two portlets of links, should we have an alternate layout that add the menu title?
<barry> sinzui: in the examples i've done, i don't think a menu title would be useful
<beuno> sinzui, if things are clearly grouped by actions and links
<beuno> I don't think a heading is needed
<sinzui> I am happy to not make an new named view
<sinzui> beuno: is there are rule for the use of "view" and "show" in link text?
<sinzui> "View" takes you away, "show" is inline/ajax
<beuno> sinzui, I wouldn't use them unless they're part of a phrase
<beuno> I think the color of the links should be the ones that tip you off what it's going to do
<sinzui> The use of view and show see arbitrary
<beuno> although I agree that "show" should only be used for inline actions
<sinzui> We prefer "register" over "create" since in may cases, launchpad is modeling what has happen in the real world.
<sinzui> Are you registering a milestone or creating it?
<sinzui> for projects this semantic difference many imply placeholder versues hosted projects
<beuno> true
<beuno> I think my brain is telling me that I want to create a milestone
<beuno> but I think you're right that we model reality rather than crate it
<sinzui> beuno: I bring this up because we are doing a lot of menu reporganisation. a link might uses a different term in two different menus.
<beuno> sinzui, yes, it's grat that you do
 * sinzui needs to pick a term and update the old tests
<beuno> sinzui, I think I'd use create, as it's clearer for users
<beuno> and, not use "view" in a link ever, and only "show" if you need to for inline displaying
<bac> "create" something in LP, "register" something external, like a mirror
<beuno> "register" sort of feels "sign up"-ish to me
<sinzui> beuno: but "view" is the action in all th top-level listings?
<beuno> sinzui, not after I worked on it with barry  :)
<sinzui> We have talked for an hour
<sinzui> If no one has any further questions, I will close this meeting
<sinzui> We can always talk on #launchpad-dev
<noodles775> sinzui: just the one I asked before...
<noodles775> <noodles775> I have a question too - has anyone opened a bug for the watermark heading (h1/h2) issues that we've always known about, but not yet had time to fix? (ie. https://edge.launchpad.net/ubuntu/+search)
<sinzui> noodles775: I do not know about a bug
<sinzui> I think we should report one so that someone can fix it
<noodles775> sinzui: yep, doing so now.
<sinzui> I need to report a bug about adjusting the CSS so that .summary is not giant in all cases
<sinzui> thank you everyone for participating
<sinzui> #endmeeting
<MootBot> Meeting finished at 10:07.
<deryck> thanks for hosting this sinzui!
 * deryck lurked but found it useful.
<beuno> thanks sinzui
<bigjools> cheers sinzui
<noodles775> Also, beuno, sinzui,  can we discuss the question beuno  had about https://edge.launchpad.net/ubuntu/+ppas
<noodles775> I think cprov landed that with your approval sinzui, but beuno is uncertain about the second (default context.title) heading, which is the same as the root-context heading in the watermark.
<noodles775> Thanks sinzui !
<sinzui> I think cprov followed the rules. I agree it looks wrong
<noodles775> sinzui: so, we should in that case fill the heading slot with the <h1>Ubuntu Personal Package Archives</h1> right?
<sinzui> This is why I stopped working on the heading. The rules seem arbitrary. I cannot explain the rules, so I am not qualified to hack on them
<sinzui> Only when we are looking the context's index page  do we override the heading-slot
<sinzui> I expect to see a lot of this when the many team views are updated
<bigjools> yeah it makes no sense on +ppas
<sinzui> I do not think we should be talking about this There should be a rule in the code and it DTRT
<sinzui> I do not know how to write the rule. thinking about is was very frustrating
<noodles775> yes, that would be ideal - but to create that rule we have to talk about it. Yes, I can imagine it was frustrating.
<sinzui> I decided I need to work on my team's pages
<noodles775> Yep.
<noodles775> Maybe an exception to the above rule could be: except when you are on a view of the root-context? (although it seems unnecessarily complex)
<sinzui> Deep in my heart, I think this design is flawed. I was very sad when I had to add that slot. It was such a F'up in the 1.0 design
<sinzui> I will not be surprised if 4.0 removes it again
<noodles775> Yeah, that's not fun.
<noodles775> I'll have a think about it and maybe run something by you on monday.
<sinzui> noodles775: now that we have a new way if identifying the watermark, maybe we can have the context-slot never render if the context is also IPrimaryContext
<noodles775> sinzui: but, just in case you know it yourself, everyone thinks you've done an amazing job coordinating this effort!
<noodles775> sinzui: yeah, that's a great idea! (As there's no need for breadcrumbs - is that right?)
<sinzui> my self-esteem is directly proportional to the number of branches I land
<sinzui> well
<noodles775> heh... you sound like cprov ;)
<sinzui> I *think* that is still the rul
<sinzui> e
 * sinzui finds beuno to ask
#launchpad-meeting 2010-08-25
<StevenK> Don't we have a meeting on now-ish?
<mwhudson> StevenK: mm, maybe
<bac> #startMEeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bigjools> me
<noodles775> me
<EdwinGrubbs> me
<gmb> me
<sinzui> me
<deryck> me
<danilos> me
<gary_poster> mich
<adeuring> me
<bac> i had such high hopes for my mass reminder strategy...
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac>  * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>   * Henning Rocks.  One-import-per-line now done and in effect.
<bac>   * Mentat update.
<bac>  * Peanut gallery
<bac> Guest3182: ping
<jelmer> me
<leonardr> me
<bac> [topic] outstanding stuff
<MootBot> New Topic:  outstanding stuff
<abentley> me
<bac> * lifeless and the lp/coop renaming.  I'm unsure where this stands.  I'll get clarification this evening in the AsiaPac meeting
<bac> * * bac to update wiki regarding one-import-per-line new policy.
<bac> done.
<bac> * henninge to write a tool to reformat our imports.
<bac> \0/
<bac> henning did a great job knocking this out.
<bac> i hope everyone enjoys our new imports...  :)
<bac> reviewers, please ensure we stick to the new standard.
<bac> that, gentlemen, is all there is for today's meeting.
<gary_poster> peanut gallery!
<bac> does anyone have a topic they didn't list?
<bac> gary_poster: ?
<gary_poster> benji is checking in our generated WADL and adding tests of the WADL generated for our webservice versions.  This is supposed to mean that changing the frozen versions of the webservice in a backwards-incompatible way will be more easily caught by reviewers: don't allow it!
<gary_poster> It should also mean that running make initially will be noticeably faster.
<gary_poster> (Done.)
<bigjools> one more thing from me
<bac> good news, gary_poster
<bac> gary_poster: i'm not sure, exactly, reviewers are to look for
<gary_poster> bac: checked-in WADL files for frozen versions of the webservice should not change--you should not see changes in the diff.  (we'll send out an email as well.  This is trying to blast over all possible communication channels)
<bac> gary_poster: ok, will look for it.  thanks.
<gary_poster> (we'll aslo have a wiki page)
<henninge> me
<bac> bigjools: yes?
<henninge> sorry
<bac> hi henninge
<bigjools> hi
<bigjools> so
<gary_poster> you missed all the praise for you, henninge :-)
<noodles775> Great work on the imports henninge :)
<bigjools> I saw some new files landing that didn't have a) the AGPL header, b) an __all__ or c) a docstring
<henninge> gary_poster: I am so shy, so I came late on purpose ... ;)
<gary_poster> lol :-)
<bigjools> can reviewers please be more vigilant
<henninge> thanks noodles775 :)
<bac> bigjools: scandal!
<bac> thanks for catching that bigjools
<bigjools> I was lucky, since I am making an enums.py for Soyuz and happened to look at a lot of files
<bac> henninge: yes, thanks again.  BTW, where does the import fixer tool live?  i'd like to reference it on the wiki
<henninge> lp:~henninge/+junk/format-imports
<henninge> It has been suggested to put it somewhere else.
<bac> henninge: shouldn't it be moved into the tree?
<henninge> - into dev-tools
 * gary_poster wishes +junk were called +sandbox
<henninge> - in the tree
<sinzui> or repo
<henninge> - or even a bzr plugin
<henninge> bac: into utilities? I can do that.
<bac> henninge: as a reviewer i'd like to say "this is messed up, go run henning's tool."  so, yeah, utilities would be great, i think.
 * henninge realizes it may need some tests, then.
<bac> gary_poster: +1
<bac> any other topics?
<bac> reminder the asiapac meeting has moved to Thursday at 0000Z
<bac> thanks for participating.
<bac> #endmeeting
<MootBot> Meeting finished at 09:14.
#launchpad-meeting 2010-08-26
<bac> meeting time
<bac> #startmeeting
<MootBot> Meeting started at 19:01. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> thumper, mwhudson, StevenK: ping
<bac> anyone?
<mwhudson> hi
<bac> hi michael
<mwhudson> StevenK was here this time yesterday
<mwhudson> maybe timezone confusion...
<bac> for the meeting?
<mwhudson> yeah
<bac> ah, that's not good
<bac> the whole thursday thing is more confusing for me but i figured it wouldn't confuse you all
<bac> i see rockstar bailed about 30 minutes ago too
<bac> well, mwhudson what say we cancel this week and try again next thursday?
<bac> #endmeeting
<mwhudson> bac: sure
<MootBot> Meeting finished at 19:06.
<thumper> ah
<thumper> sorry
<thumper> went for lunch
