#launchpad-meeting 2006-07-31
<SteveA> hi
<SteveA> welcome to vilnius, jamesh 
<SteveA> how was your vacation BjornT ?
<BjornT> it was fine, thanks, very relaxing
<jamesh> hi
<SteveA> I was thinking that you guys could work together for a few days, looking at how forms and maybe widgets work
<SteveA> we've got a bunch of problems with the forms in launchpad
<SteveA> like, they're tricky to use
<SteveA> we have three varieties of forms that work differently
<ddaa> like tab-browsing them send you mad
<SteveA> and indeed, tab browsing
<SteveA> hi ddaa.  did you get back okay on the train?
<ddaa> absolutely, it was only a very mild hangover compared to what I usually get at the end of sprints/conferences :)
<BjornT> that sounds good. it'd be nice start using zope.formlib for our forms.
<SteveA> there was also a discussion I had with a bunch of zope3 people (jim, faassen, philikon) at europython
<SteveA> about improving formlib
<BjornT> i'll send a mail to gary today to see where he's at with his widget work, it'd be nice starting to use them as well, since it's hard to improve the current widgets
<SteveA> that we should write notes on and take into account
<SteveA> ok
<SteveA> the three of us should meet up, and work out what specific things to do this week
<BjornT> ok. gary mention he would do some changes to formlib as well, but maybe jim was aware of the changes?
<SteveA> first by sketching out a bunch of ideas of what we could do, and things that need improving
<SteveA> then deciding on which ones to tackle
<SteveA> the EP discussion was only a little about formlib
<SteveA> it was more about improving how we do view classes and link them with templates
<SteveA> but included discussion of how to link this with use of formlib
<BjornT> ok
<SteveA> how about we meet for lunch in a while
<SteveA> and then go to my place to sketch things out around a whiteboard?
<SteveA> we should also look through the form-related bugs we have outstanding on launchpad
<SteveA> perhaps tag them with a keyword
<BjornT> sounds good, i'm already starting to get hungry, so anytime (an hour from now) is fine by me
<jamesh> okay
* SteveA checks a weather report
<SteveA> possible showers over the next hour
<SteveA> then fine for the rest of the day
<SteveA> james is in the e-guesthouse on evenkos g.
<SteveA> BjornT: you'll be driving, so how about you pick up james from there at 1pm or so
<SteveA> and then park near my place, and we'll walk together into old town?
<BjornT> SteveA: sure
<jamesh> So I'll wait downstairs at 1pm then
<SteveA> ok.  I will now go put some laundry on, so I'll have clothes to wear tomorrow.
<BjornT> cool
<jamesh> hi mpt
<mpt_> hi jamesh 
<jamesh> so, what issues would you say are most important to address from a UI perspective?
<SteveA> mpt: irssi :-)
<mpt> So, forms
<mpt> I guess the biggest problems involving forms are
<mpt> 1. the tab-cycle bug
<mpt> 2. validation feedback is very poor - often errors don't explain the problem, suggesting that maybe it's not easy enough to say to Zope "this is the kind of data I want in this field"
<mpt> 3. validation only ever happens after you've submitted the form, not before (e.g. impossible characters aren't ignored when you type them)
<mpt> 4. No easy construction of dependent controls -- e.g. when you arrive at the Blueprint front page an obvious thing to do is to register a specificaiton, but sabdfl rejected the bug solely because there isn't an easy way to create a form with different branches for product/distribution
<mpt> I guess 2 and 3 are related.
<mpt> 5. The layout is crummy, especially for checkboxes
<jamesh> (3) and (4) seem to call for a way to easily inject JS code into the form
<jamesh> we've got a few forms that add JS in different ways already, so it would be nice to have a standard way to do it
<mpt> yes
<SteveA> I saw a nice demo of doing that in London
<SteveA> using some ajax stuff to do dynamic form validation using the server
<mpt> I guess Ajax would be the last 10% of the benefit and the last 50% of the effort, e.g. "That ID is already taken"
<mpt> But most of it would need JS only, e.g. missing required fields, no letters in numeric fields
<mpt> and that would need to be auto-generated because you'd have to be doing equivalent validation on the server anyway, since you can't trust the client
<mpt> so the server-side and client-side validation would need to be kept reliably in sync.
<SteveA> well
<SteveA> I'm not so sure about your estimates of effort
<SteveA> the thing with doing full ajax validation is that there is just one set of validation code
<SteveA> on the server
<SteveA> and no need to translate it into javascript at all
<SteveA> if we were programming launchpad entirely in JS, that would be a different matter
<mpt> hmmm, that would be one possibility
<mpt> though it would result in a lot of extra network traffic
<mpt> and would work in fewer browsers
<SteveA> perhaps not a *lot*
<SteveA> I'd leave that estimate up to an analysis rather than a gut feeling
<mpt> Well, the amount of network traffic would be inversely proportional to how quickly you were correcting/preventing errors
<mpt> For example, take the rule that you're not allowed to use spaces in "Name" fields
<mpt> directly proportional, rather
<SteveA> also... network traffic is not all that useful a measure for us
<SteveA> latency overall is
<mpt> If you check after each character to see whether it's allowed, that's going to be really slow
<mpt> If you check once I leave the field, that'll be much more practical, but also a bit more annoying
<SteveA> you check every N seconds if there was a change in data between now and the last check
<mpt> if you check when I'm about to submit the form, that's only one transmission for the whole form, but it's more annoying still
<SteveA> also, using ajax will likely have a good effect on the overall application's performance
<SteveA> because the validation requests would be GETs, and never lock tables
<SteveA> whereas the actual POSTs to post form data will be POSTs and often lock tables
<SteveA> having many gets and one POST (lots of attempts, corrected by ajax, followed by a successful form submission)
<SteveA> is better for us than a few POSTs
<SteveA> per one form post in the workflow
* sivang wonders how would that be tested, to make sure ajax validation is doing the right thing.
<SteveA> you'd test the validation logic just like we test any other page of launchpad
<SteveA> then there would be some standard lightweight stuff to do the ajax request that either is not tested or is tested using a selenium test
<sivang> ah, I see
<mpt> First sodium, now selenium
<sivang> heh
#launchpad-meeting 2006-08-01
<SteveA> About forms...
<SteveA> the next thing to do is to list all the stuff we need to think about
<SteveA> we have
<SteveA>  - an email from mpt
<SteveA>  - some requirements from the landscape guys
<SteveA>  - http://furius.ca/atocha/
<SteveA>  - zope.formlib
<SteveA>  - various specs and bugs from launchpad
<SteveA>  - Gary Poster's recent refactoring of widgets
<SteveA>  - The concept of whole-form server-side validation via ajax
#launchpad-meeting 2006-08-02
<sivang> SteveA: mornin
<sivang> SteveA: you probably know about this, ut I'll paste just in case - http://www.zope.org/Members/tseaver/Zelenium/Zelenium-0.8/README.txt
<sivang> SteveA: (re our discussions about integrating ajax and pagetests)
<SteveA> hi sivan
<SteveA> thanks.  cool, isn't it?
<sivang> SteveA: very much,  although I wonder why I can't just "record" the tests through the selenium browser control rather then the instructions there with tcpwatch. I recall from what I played with it, that is has the recording facility from the selenium web page.
<sivang> s/web page/web interface/
#launchpad-meeting 2006-08-03
<SteveA> OMG a pony!
<ddaa> SteveA: jamesh: lifeless: meeting about to start
<ddaa> once mpool finds the way
<ddaa> Meeting starts
<ddaa> All things bazaar, yadda yadda yadd
<ddaa> * roll call
<ddaa> * production status
<ddaa> Current focus
<ddaa> * Smart server
<ddaa> * SFTP advertising (jamesh)
<ddaa> * vcs-import knits (ddaa)
<ddaa> * supermirror branch browser
<ddaa> * private branches
<ddaa> * dyson
<ddaa> * empty hosted branches
<ddaa> Usual end
<ddaa> * other meeting actions
<ddaa> * critical bugs
<ddaa> * pending sysadmin tasks
<ddaa> * any other business
<ddaa> https://launchpad.canonical.com/BazaarMeetingAgenda
<ddaa> * Roll call
<ddaa> SteveA is on a pony
<ddaa> I'm here
<SteveA> hi
<jamesh> hi
<SteveA> what's the time limit on this meeting/
<SteveA> ?
<ddaa> Normally until 11:45
<ddaa> lifeless: pingus
<ddaa> Let's move forward.
<ddaa> Production status
<ddaa> https://launchpad.net/products/launchpad-bazaar/+bug/53825
<ddaa> Still out there
<ddaa> Talked with lifeless about how to fix it and updated bug description
<ddaa> Would be nice for somebody to do the BzrError -> oops thing soon
* ddaa looks at jamesh
<SteveA> jamesh will be kinda occupied for the next 2 weeks
<jamesh> we need to finish off the plan for doing error reporting from scripts
<ddaa> Okay, then I'm happy to keep on spamming launchpad-error-reports for the time being
<SteveA> jamesh: that can go on the agenda for next week's infra meeting
<jamesh> there is a spec on the wiki about some of the work that needs to be done
<mpool> ddaa: lifeless is ill, gives his apologies
<jamesh> we should probably move on though, given that we aren't discussing details
<ddaa> Last time I spoke to him, he was going to a birthday party ;)
<ddaa> * sftp hosting advert
<SteveA> birthday parties can do that to you
<ddaa> jamesh still supposed to blog about team branches
<ddaa> I take it nothing will happen there in the near future unless somebody else gets to do it
<jamesh> I've written part of the article.  Will post it to the launchpad list when I've fleshed it out
<ddaa> Cool
<ddaa> Looking forward to seeing that this week
<ddaa> * vcs-imports knits
<ddaa> Still waiting for spec review from lifeless and SteveA
<ddaa> * supermirror branch browser
<ddaa> spiv said it was focusing on that last week and should give us a delivery estimate soon, but is on leave
<ddaa> * private branches
<ddaa> I think there was no progress there
<ddaa> still waiting for lifeless reply on spec review
<ddaa> * dyson
<ddaa> last week's action:  jamesh to talk to sabdfl to loosen DB constraint, re grass bug.
<ddaa> https://launchpad.net/products/launchpad/+bug/53698
<jamesh> I talked with him and added a comment to the bug
<jamesh> I also talked with Keybuk about whether there was a particular use case for recursively checking for matching tarballs
<ddaa> I think that's quite a useful thing to do
<ddaa> but maybe not by default
<ddaa> Is that on somebody's business for the next couple of weeks?
<jamesh> yep.  In the grass case it probably isn't desirable, but it is for the other examples you posted
<mpool> what is grass (in this context)?
<jamesh> mpool: a GIS package
<jamesh> geographical information systems
<ddaa> mpool: see the bug, it was just a package with weird release names
<mpool> ok
<ddaa> that tripped a db integrity check
<SteveA> from "Ge" the god of the earth, and "graphical" to do with drawings.
<ddaa> So, it looks like nobody will be working on that in the near future.
<ddaa> * empty hosted branches
<ddaa> there's a bug in bzr about pushing to an existing directory and overwrite contents
<ddaa> mpool: are you tracking that?
<mpool> ddaa: i'm aware of it
<jamesh> is this the case where we get an empty branch dir with no .bzr subdir
<ddaa> I had some discussion with john in the bug, but I do not have the reference handp
<jamesh> and bzr won't push to it?
<ddaa> jamesh: yes
<mpool> right
<mpool> do you think it's a high priority?
<ddaa> Yes, not critical, but pretty important.
<ddaa> Since it's very easy to get into a situation where you get a busted bzr branch on the sftp server
<ddaa> * Other meeting actions
<ddaa> well, this part of the agenda is out of date
<ddaa> mpool: you said you planned to do some nice spec braindumping
<ddaa> branch viewing, reviews, email subscription, and so on
<mpool> ddaa: most of that time has gone into supermirror-smartserver, and the svn roundtripping thing
<mpool> i'll upload the smartserver spec
<ddaa> Well spent time.
<mpool> this is more of a continuing task for me than a particular action
<ddaa> ack, will drop the action reminder from the agenda
<mpool> we should talk about roundtripping after the formal completion of this meeting, perhaps verbally
<ddaa> Time permitting, this meeting is followed by the launchpad weekly meeting
<ddaa> * Critical bugs
<ddaa> I started work on https://launchpad.net/products/launchpad-bazaar/+bug/37897
<ddaa> Plan to fix by making importd upload and retrieve cscvs source branches on a remote sftp
<ddaa> That change will also enable a number of other nice things in the medium and long term
<ddaa> And it's needed for correctness because the failure mode described in bug 37897 has changed with importd-bzr-native and I did not think of that in advance
<ddaa> I had preimpl call with jamesh about that before meeting
<ddaa> Will abuse bzrlib's SFTPTransport
<mpool> (ok the empty-directory bug is https://launchpad.net/products/bzr/+bug/30576, have marked it for 0.10)
<ddaa> and use that as a paramiko wrapper
<ddaa> bzrlib.transport.get_transport is the best thing since sliced bananas methink
<jamesh> I wouldn't describe it as an abuse
<ddaa> Ok, creative reuse.
<ddaa> I may get around doing https://launchpad.net/products/launchpad-bazaar/+bug/51130 soon
<ddaa> I'm tired of delegating, and I want some fun too.
<ddaa> * Pending sysadmin tasks
<ddaa> Anybody?
<mpool> sysadmins have been beautiful
<mpool> we're getting a dedicated little machine for benchmarks
<SteveA> cool
<ddaa> Yeah, elmo got a haircut and a shave, he's cute like that.
<ddaa> mpool: are we getting a win32 machine for running regression tests?
<mpool> that would be nice too but i haven't asked for it yet
<mpool> are you interested in setting it up?
<mpool> hey, you could use buildbot? :-)
<ddaa> Yeah buildbot is a nice tool for that.
<ddaa> It's what it was designed for.
<ddaa> But I'm entirely unwilling to touch a win32 machine
<ddaa> j-a-meinel seems the most familiar with that part of bzr
<SteveA> off topic
<ddaa> right
<SteveA> time is short
<ddaa> * Other business
<SteveA> and so is joe pesci
<ddaa> SteveA: how's our new hire?
<SteveA> things are progressing well
<SteveA> we're scheduling further interviews with martin and with me
<mpool> ddaa: we will probably hire not a bzr community advocate, but rather one person across lp and bzr
<ddaa> Makes mucho sense.
<mpool> so, readjusting the role and criteria for that
<ddaa> but I was specifically interested in the fate of the prospective new launchpad-bazaar guy
<ddaa> Anybody has other business to discuss?
<SteveA> I want to confirm a couple of things
<SteveA> get an idea of whether they have happened, or when they might happen
<SteveA> is that okay ddaa?
<SteveA> how long is the meeting left to run?
<ddaa> Absolutely, I'm done with the agenda.
<ddaa> We have as much time as you are confortable with.
<ddaa> Nominally, 11 mins left.
<SteveA> ok
<SteveA> 1. bzr native
<SteveA> is it in RF?
<ddaa> Nah, the last bit is/was waiting for review by jamesh
<SteveA> ok
<SteveA> 2. python import.  when can we do it?
<jamesh> ddaa: I'll try to get to it soon.  pending-reviews also lists your david/cscvs/bzr-native branch as not merged
<ddaa> I'm not too hot about doing the python import before we have support for svn renames.
<SteveA> why?
<ddaa> because it's high profile, and we do not want to give the impression that bzr does not do renames
<ddaa> and because it's not something we can fix post hoc without breaking compatibility
<mpool> ddaa: this is the kind of thing i was getting into in my mail
<mpool> about the priorities for various types of work
<ddaa> well, we do do it post hoc without breaking compat
<SteveA> ok
<SteveA> getting python imported is an important goal for me
<ddaa> but what we have already converted will have bad quality
<mpool> ddaa: is "we do not want to give the impression that bzr does not do renames" really the real reason?
<SteveA> so I'd like a bug opened for that, and a description in there of the things we should do first to enable that
<mpool> i mean, "bzr does not convert svn renames" is a much less serious shortcoming
<ddaa> jamesh: cscvs/bzr-native needs a fix, thanks for reminding me
<ddaa> mpool: SteveA: if everybody is happy with running a python import without renames, I can start it today
<mpool> well, is everyone happy with it?
<SteveA> I don't understand the thing about renames
<ddaa> Will mail you two about it.
<ddaa> It's not a difficult decision to make,
<SteveA> ok
<jamesh> SteveA: if a file gets renamed in SVN, when it gets imported, it will look like an add and a delete, which will affect annotate info, etc
<SteveA> so that is all that is holding up python
<ddaa> I could find plenty of bad reasons for postponing it, but nothing really serious
<jamesh> there aren't that many renames, so it probably won't be visible most of the time
<SteveA> I don't think python do a lot of renaming on the mainline
<SteveA> so just doit
<mpool> i agree
<ddaa> okay
<ddaa> ACTION: ddaa to import python
<SteveA> error reporting
<SteveA> 3. error reporting
<SteveA> (from buildbot) is this a problem at present?
<ddaa> yes
<ddaa> I just do not know how to get buildbot to tell launchpad about errors
<SteveA> what is the 1 sentence summary of the nature of the problem?
<SteveA> why is it important?
<SteveA> what user or admin workflow does it negatively effect?
<ddaa> Because I want to do something that uses: https://sodium.ubuntu.com/~jamesh/pending-reviews/david/launchpad/importd-ng/full-diff
<SteveA> um, affect
<SteveA> or whichever
<ddaa> Overall, the problem is that users do not see errors.
<SteveA> ok
<SteveA> so, user adds their upstream svn in launchpad
<ddaa> And that it's hard for admin to get synthetic info, though jamesh script can help punctually
<SteveA> and then nothing happens
<SteveA> because there is an error
<SteveA> and the user never sees that there is a problem
<SteveA> is that so?
<ddaa> SteveA: nothing happens because of the requirement of operator intervention
<ddaa> When the operator reload roomba, the import gets tested
<SteveA> what is roomba?
<ddaa> and if it fails, it gets marked as "test failed" and the use does not know what failed
<SteveA> please can we rename things to have less obscure names?
<ddaa> SteveA: importd autotest system
<mpool> I second that
<SteveA> let us call it "importd autotest"
<ddaa> that was thoroughly explained in the importd documentation I wrote a few months ago
<SteveA> yes
<mpool> would it not be possible to have buildbot write to a plain old log file, and just look through that?
<ddaa> also, when an import that's syncing starts failing
<SteveA> and antidisestablishmentarianism is thoroughly explained in Hobbe's tract of 1643
<SteveA> but that doesn't mean it is a good name for something
<ddaa> the only way for the user to notice is to see that the branch has gone out of sync
<ddaa> Sorry no way to make a one sentence summary of the issues with the import process.
<SteveA> ddaa: by "that" do you mean "the thing called roomba"?
<SteveA> or do you mean "the problem with error reporting"
<SteveA> <ddaa> that was thoroughly explained in the importd documentation I wrote a few months ago
<SteveA> beware of using pronouns on irc
<ddaa> that = "an import that's syncing starts failing"
<SteveA> much possibility of misunderstanding
<SteveA> I see
<ddaa> an import that's syncing is run by hoover BTW
<SteveA> I'm sorry.  I thought you were saying:
<SteveA> "roomba is documented somewhere, so it is a good enough name"
<mpool> can we back up for a sec
<mpool> is the problem that "the system won't automatically tell users what's wrong"
<mpool> or "it's too hard for david to find out what's wrong?"
<ddaa> yes, but not only
<mpool> or a bit of both?
<ddaa> it's easy for me to find what's wrong usually, at least when the answer is easy
<ddaa> the problem is that "the system does tell users that something is wrong"
<ddaa> and that "the system relies on ddaa to babysit it so new user entered data turns into an import"
<mpool> ok..
<mpool> and would it be enough to just tell the user broadly what happened
<ddaa> The hard be for me is to collate failures to get a sense of what are the important problems.
<mpool> like a one-sentence description
<ddaa> Nope.
<mpool> "failed because of an error while converitng", "couldn't contact server", etc
<mpool> what kind of thing do you want to tell them?
<mpool> actually we're running out of time
<mpool> should we continue or defer it?
<ddaa> Please ask me on ML
<mpool> ok
<mpool> steve, anything else
<ddaa> that's a complicated issue and I would have to do some background research to give good answers
<ddaa> Meeting closed then
<ddaa> Need to take a rest break before the launchpad meeting.
<mpool> sure
#launchpad-meeting 2008-07-29
<mwhudson> #startmeeting
<MootBot> Meeting started at 21:20. The chair is mwhudson.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<mwhudson> #endmeeting
<MootBot> Meeting finished at 21:20.
<mwhudson> :)
<spiv> Haha.
<Ursinha> hahaha
#launchpad-meeting 2008-07-30
<salgado> it's time for our weekly meeting
<salgado> reviewers meeting, that is
<salgado> who's here today?
<cprov> me
<gmb> me (but sprinting, so I may not pay attention).
<bac> me
<EdwinGrubbs> me
<allenap> me
<salgado> flacoste, BjornT, allenap?
<salgado> oops
<flacoste> me
<intellectronica> me
<flacoste> sinzui and barry are off
<bac> danilo and jtv?
<salgado> okay, moving on.  let's see what we have in the agenda for today
<salgado>  * Roll call
<salgado>  * Next meeting
<salgado>  * Action items
<salgado>  * Queue status
<salgado>  * Mentoring update
<salgado>  * Review process
<salgado> no objections for same time next week, for the next meeting, I guess?
<BjornT> me
<salgado> hmmm. should I have told MootBot about the meeting?
<salgado> #startmeeting
<MootBot> Meeting started at 09:09. The chair is salgado.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<salgado> the actions from last meeting are
<salgado>  * intellectronica to write up guidelines on check_permission in the wiki and email the ml for additional input
<intellectronica> sorry, haven't done that
<salgado>  * intellectronica to start a list on the wiki of devs/available platforms
<salgado>  * intellectronica to start the ball rolling on an email to the ml re: multiple browsers/platforms
<intellectronica> or this one either
<intellectronica> sorry!
<intellectronica> i'll try to do those before next week
<salgado> no worries.  barry will remind you about them next week again
<salgado>   * Queue status
<salgado> 4 old unreviewed branches
<salgado> 5 if I count correctly
<salgado> nobody is on call today, so I guess I'll get them all tomorrow
<salgado> unless anybody wants to take some of them?
<salgado> cprov, would you like to take any?
<salgado> EdwinGrubbs, it'd be great if you could do one or two today, so that I mentor them early tomorrow
<cprov> salgado: I'll be busy today, but I can take one of them
<EdwinGrubbs> salgado: I'll try to do that
<salgado> cool
<salgado>  * Mentoring update
<salgado> any updates on mentoring?
<salgado> guess not
<salgado>  * Review process
<salgado> comments on the process?
<gmb> It works quite well?
<salgado> indeed it does!
<salgado> anything else that was not in the agenda already?
<salgado> okay, since nobody says anything, I will
<salgado> I hate client-side mail filtering!
<salgado> now I'll let you guys get some real work done.  thanks for your time
<salgado> #endmeeting
<MootBot> Meeting finished at 09:20.
<bac> thanks salgado
<intellectronica> thanks salgado
#launchpad-meeting 2008-07-31
 * Rinchen prays to the buggy intel driver not to crash during the meeting.
 * Rinchen continues to pray to the buggy intel driver not to crash during the meeting.
<Ursinha> Rinchen, use irssi :P
<Ursinha> if you're talking about the video one..
<Rinchen> that won't help with my external display crashes :-(
<Rinchen> #startmeeting
<Rinchen> Welcome to this week's Launchpad development meeting. For the next 45 minutes or so, we'll be coordinating Launchpad development.
<MootBot> Meeting started at 13:03. The chair is Rinchen.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<Rinchen> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<Rinchen> moo
<mars> moo
<Ursinha> me
<adeuring> me
<flacoste> me
<bac> me
<salgado> me
<gmb_> me
<mrevell> me
<flacoste> barry, sinzui are on leave
<jtv> me
<Rinchen> apologies from gavin, barry, curtis....
<matsubara> me
<Rinchen> mpt?
<BjornT> me
<flacoste> EdwinGrubbs, mars, leonardr: ping
<leonardr> me
<mars> flacoste, moo?
<flacoste> mars: moo doesn't count ;-)
<mars> flacoste, sorry, couldn't help myself :)
<mars> me
<EdwinGrubbs> me
<Rinchen> next week is "cluck"
<jtv> à¸à¸¡
<flacoste> Foundations is here
<Rinchen> thanks
<flacoste> Rinchen: i'll miss next two meetings
<intellectronica> me
<herb> me
<Rinchen> thumper won't make it today
<cody-somerville> me
<mpt> yo
<mpt> me
<BjornT> Bugs is here
<kiko-phony> me
<Rinchen> ok, releases is here
<Rinchen> code is sprinting so they won't be here
<Rinchen> jtv, danilo coming?
<Rinchen> and no stub. :-( I even emailed him
<jtv> Rinchen: not sure, forgot about the time so only just woke up again
<Rinchen> k
<Rinchen> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<Rinchen>  * Next meeting
<Rinchen>  * Actions from last meeting
<Rinchen>  * Oops report (Matsubara)
<Rinchen>  * Critical Bugs (Rinchen)
<Rinchen>  * Bug tags
<Rinchen>  * Operations report (mthaddon/herb/spm)
<Rinchen>  * DBA report (stub)
<Rinchen>  * Sysadmin requests (Rinchen)
<Rinchen>  * New packages required (salgado)
<Rinchen>  * A top user-affecting issue (mrevell)
<Rinchen>  * Doc Team report (mrevell)
<Rinchen> plus
<Rinchen> Introduce Reinhard Tartler as the new MOTU liaison - mrevell
<Rinchen> #
<Rinchen> Store OOPSes for Unauthorized exceptions - salgado
<Rinchen> #
<Rinchen> Bug triage & the triage status - kiko
<Rinchen> librarian upload concerns - kiko
<kiko-phony> cool
<Rinchen>  
<Rinchen> action packed mtg
<kiko-phony> heh
<mrevell> Rinchen: Damn, sorry, I thought the MOTU-liaison thing was off the agenda. that's old.
<Rinchen> no worries, we can skip that one
<Rinchen> [TOPIC] Next meeting
<MootBot> New Topic:  Next meeting
<Rinchen> Aug 7th. Same time, same channel.
<flacoste> i'll miss next two meetings
<mrevell> I'll be sprinting :)
<mpt> I'll probably be here, but I won't be taking part
<jtv> Translations'll be sprinting too
<Ursinha> me too
<mrevell> goodbye mpt
<mrevell> mpt: thanks for all the fish
<BjornT> i'll miss the next meeting
<Rinchen> ok, releases team will try to be there :-)
<Rinchen> ok. Kiko you don't want to skip next week do you? :-)
<kiko-phony> nooooo
<kiko-phony> I'll be here
<Rinchen> [AGREED] Aug 7th. Same time, same channel.
<MootBot> AGREED received:  Aug 7th. Same time, same channel.
<Rinchen> k
<Rinchen> [TOPIC] Actions from last meeting
<MootBot> New Topic:  Actions from last meeting
<Rinchen> nothing was entered from last week
<kiko-phony> stub!
<Rinchen> so I'll assume it was just salgado to file a bug about the store OOPSes :-)
<stub> me
<salgado> and I haven't done that
<salgado> will do today
<Rinchen> thanks salgado
<Rinchen> [TOPIC] Oops report (Matsubara)
<MootBot> New Topic:  Oops report (Matsubara)
<Rinchen> and I will add Ursinha there too
<Ursinha> Rinchen, thanks
<matsubara> Ursinha is handling that :-)
<Ursinha> ok
<Ursinha> i have some timeout bugs here
<Ursinha> bug 252695
<ubottu> Launchpad bug 252695 in launchpad "+peoplelist taking too long to render and timing out" [Undecided,New] https://launchpad.net/bugs/252695
<Ursinha> can anybody please take a look at it? guess it's foundations one
<Rinchen> I wonder, is there any value in retaining +peoplelist?
<flacoste> salgado can you take care of it sometimes while i'm away?
<flacoste> Rinchen: crawlers
<salgado> flacoste, sure thing
<Rinchen> googlebot ftw. ok
<Ursinha> ok, next one, specworkload bug, bug 124205
<flacoste> Rinchen: didn't you read, cuil is the next big thing ;-)
<ubottu> Launchpad bug 124205 in blueprint "timeout in specworkload page" [Medium,In progress] https://launchpad.net/bugs/124205
<flacoste> bac is handling that one
<Ursinha> flacoste, haha
<mpt> flacoste, I don't think that's really a reason
<bac> Ursinha: in review
<BjornT> flacoste: aren't all the interesting people linked to anyway?
<mpt> flacoste, because if someone's worth indexing, they'll be linked to from plenty of other pages in LP
<flacoste> BjornT: good point
<Ursinha> bac, ok, thanks
<flacoste> salgado: acceptable fix is to remove the page ;-)
<Rinchen> ln -s +peoplelist ~rinchen and be done with it ;-)
<salgado> consider it done, then
<Rinchen> Ursinha, any other bugs for today?
<Ursinha> yes
<Ursinha> bug 252709, the roadmap page
<ubottu> Launchpad bug 252709 in blueprint "+roadmap pages taking too much time to render and timing out" [Undecided,New] https://launchpad.net/bugs/252709
<flacoste> another page that we could get rid of
<Ursinha> it's timing out a lot, and it was suggested in bug 174480 to get rid of it
<ubottu> Launchpad bug 174480 in blueprint "Person's +roadmap page contains blueprints they're not assigned to" [Undecided,New] https://launchpad.net/bugs/174480
<Rinchen>  +roadmap, a wonderful idea that we never expanded on
<intellectronica> again?
<Rinchen> at this juncture I'm +1 to remove +roadmap
<Rinchen> it is not providing the value we had intended originally
<intellectronica> +1, since it's quite hard to optimise, and not a very useful or popular page
<cprov> err, I didn't say "me", sorry
<Rinchen> BjornT, can intellectronica do the honours there?
<BjornT> Rinchen: sure
<Rinchen> thanks BjornT  and intellectronica
<Ursinha> ok
<Ursinha> the next
<Ursinha> ok, one for bugs now, i suppose: bug 252674
<ubottu> Ursinha: Bug 252674 on http://launchpad.net/bugs/252674 is private
<Ursinha> it's a bug on malone, too many timeouts because of large queries
<kiko-phony> Rinchen, intellectronica: you sure the mysql guys aren't using +roadmap?
<intellectronica> kiko-phony: i can find out before killing it, just to make sure
<Rinchen> intellectronica, I can help you with the email on that. Ping me post meeting!
<BjornT> Ursinha: has that been happening lately? it looked like an intermittent problem
<BjornT> Ursinha: i.e, usually those queries are fast to run
<Ursinha> BjornT, the timeouts are strange, the oopses show low sql AND non-sql times
<Ursinha> it's been happening quite frequently
<kiko-phony> intellectronica, mtaylor is the guy to ask, on #launchpad
<BjornT> Ursinha: right, and it should be because the query takes a really long time. do you have an example of such an oops for today/yesterday?
<Rinchen> several in the bug report
<Ursinha> oh, not on hands now, sorry
<BjornT> Ursinha: ok. i'm asking since all the oops in the bug report are around the same time
<Ursinha> BjornT, found one: https://devpad.canonical.com/~matsubara/oops.cgi/2008-07-31/F2030
<BjornT> Ursinha: ok, thanks. i'm going to have to check with the losas to get more information
<Ursinha> ok, thanks BjornT
<Ursinha> the last one
<Ursinha> bug 251569
<ubottu> Launchpad bug 251569 in launchpad "UnicodeEncodeError when trying to search in launchpad/people/+index" [Undecided,Confirmed] https://launchpad.net/bugs/251569
<Ursinha> guess i've mentioned that one with salgado
<Ursinha> salgado, sorry, didn't have the time to look at it closely
<Ursinha> can you do that for me?
<kiko-phony> Ursinha, it might be better to reping the foundations guys on monday or tuesday once they've done the API announcement
<salgado> Ursinha, yes, I can have a look at it next week
<kiko-phony> Ursinha, right now they are scrambling to get that done
<Rinchen> [AGREED] salgado to handle 252695, bac to handle 124205, intellectronica to handle 174480, bjorn to talk to losas about 252674, salgado to handle 251569
<Ursinha> kiko-phony, ok
<MootBot> AGREED received:  salgado to handle 252695, bac to handle 124205, intellectronica to handle 174480, bjorn to talk to losas about 252674, salgado to handle 251569
<kiko-phony> Ursinha, and they are likely to forget everything they're saying they will do by then :)
<Ursinha> kiko-phony, ok, thanks :)
<Rinchen> anything else Ursinha ?
<Ursinha> Rinchen, guess that's all folks
<Ursinha> thanks all
<Rinchen> thanks Ursinha
<Rinchen> [TOPIC] Critical Bugs (Rinchen)
<Rinchen> https://bugs.edge.launchpad.net/launchpad/+bug/253217
<Rinchen> needs an owner
<MootBot> New Topic:  Critical Bugs (Rinchen)
<ubottu> Rinchen: Error: This bug is private
<Rinchen> flacoste, please update the status on
<Rinchen> https://bugs.edge.launchpad.net/launchpad/+bug/252673
<ubottu> Rinchen: Error: This bug is private
<Rinchen> flacoste, and also milestone if appropriate please
<Rinchen> it looks like leonardr has been working on 253217
<intellectronica> Rinchen: leonardr has been working on a fix for the first one
<intellectronica> duh
<flacoste> Rinchen: i updated both of them
<Rinchen> Thanks
<leonardr> i'm responding to salgado's review
<leonardr> it's almost ready to go in
<Rinchen> that's it from me. Thanks for resolving the other criticals on the list earlier.
<Rinchen> [TOPIC] Bug tags
<MootBot> New Topic:  Bug tags
<Rinchen> we have one from matsubara
<Rinchen> https://help.launchpad.net/TaggingLaunchpadBugs
<Rinchen> pqm-analyzer
<Rinchen> This is for the atomic pqm analyzer that kiko wrote that we're trying to get setup in the DC
<kiko-phony> flacoste, you did? :)
<matsubara> I'm not fussed about that tag, but I want something to group bugs related to the kiko's APA tool
<kiko-phony> matsubara, does it have bugs in it??
<flacoste> kiko-phony: refresh
<kiko-phony> flacoste, woo! thanks :)
<intellectronica> why not have a product for it?
<flacoste> +1
<flacoste> less bugs for me to triage :-)
<kiko-phony> intellectronica's on the ball
<Rinchen> There are two questions that I've been debating.  A new product and having PQM manage the code
<kiko-phony> new product, not sure about PQM management
<flacoste> until it's deployed, not sure it's worth it
<kiko-phony> it's right now two files.. :) no tests!
<Rinchen> at this point I was trying to be flexible :-)
<flacoste> not like there were any tests to run yet anyway
<flacoste> PQM != flexible
<kiko-phony> ken
<Rinchen> I meant, that's why I didn't do either :-)
<matsubara> ok. so no tag and create a new product. fine by me.
<Rinchen> Any objections to creating a new product and not a tag?
<kiko-phony> DO IT
 * matsubara wonders if I should do the same with oops-tools
<kiko> matsubara, probably
 * Ursinha agrees on doing the same to oops-tools
<Rinchen> [AGREED] create new product of the APA instead of using a tag.
<MootBot> AGREED received:  create new product of the APA instead of using a tag.
<Rinchen> matsubara, can you please update the tag page?
<matsubara> sure Rinchen. thanks everyone
<stub> oops-tools should be a tag since it is part of Launchapd, but you knew I would say that :)
<Rinchen> [TOPIC] Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  Operations report (mthaddon/herb/spm)
<herb> Early morning Tuesday (2008-07-29) we rolled out 2.0 at r6771.
<herb> Late in the day Tuesday (2008-07-29) we re-rolled 2.0 at r6773 to catch some important bug fixes.
<herb> All week we've been fighting the dreaded "app server dying" bug. Bug 247227.
<ubottu> herb: Bug 247227 on http://launchpad.net/bugs/247227 is private
<herb> Other than that it's been a quiet week. That's it from mthaddon, spm and me forthis week.
<kiko> herb, has anyone been looking at that with you?
<herb> kiko: not really, no.
<kiko> herb, okay. how much is this being a problem for production?
 * kiko #@@!
<herb> kiko: if you take a look at the bug it shows how many times we've had to deal with a downed app server.  happens almost daily.
<herb> and we have seen it multiple times in a day.
<kiko> herb, can we do something to figure out what it's doing when it dies I wonder
<kiko> flacoste, stub: any ideas of possible instrumenting we could do?
<stub> For it to die like that, something is messing up in C code. And I'm utterly useless at that stuff.
<flacoste> python dying is kind of out of my compentcy
<flacoste> kiko: we need barry for that
<flacoste> well, he might have an idea
<Rinchen> herb, we still have yet to see this on edge?
<flacoste> or lifeless
<stub> or second jamesh back for a bit ;)
<herb> Rinchen: correct.  so far just staging and production.
<kiko> herb, flacoste, stub: well, hang on. are we saying it dies in a horrible SEGV or similar?
<flacoste> kiko: yes
<kiko> herb, and not an OOM?
<herb> kiko: not an oom
<kiko> herb, can't we run one instance inside gdb?
<herb> I suspect we could.
<kiko> it would be a bit slower but since it's so reliable it'd eventually crash.. or at least we'd know that we could move everything to gdb and fix the problem <wink>
<Rinchen> we could address that by using staging
<kiko> herb, do you want assistance doing this? I could add a make target I guess
<Rinchen> that would then not impact production users
<kiko> good point joey
<herb> well, it's not reliable in the sense that we know which app server will die in any particular day. :)
<kiko> herb, how often does it die on staging?
<Rinchen> I find it very odd that we don't see this on edge. What is different about edge over staging and lpnet?
<stub> The load for a start
<herb> we've seen it die a couple of times on staging in the last couple of weeks.
<kiko> staging isn't very loaded, is it?
<Rinchen> linkchecker
<kiko> which hasn't run properly for the past weeks
<kiko> i.e. look at the staging oops reports
<stub> But it has run?
<Rinchen> matsubara, Ursinha - please look into the linkchecker issue
<matsubara> it's running, yes.
<kiko> not completely
<kiko> the OOPS reports we get are very sparse
<kiko> it's not hitting any bug pages, for instance
<stub> Well... it won't if it crashes the staging servers ;)
<kiko> stub, it doesn't crash them every day though :-(
<kiko> anyway
<matsubara> there's only one instance running. I disable the translations.staging.launchpad.net one as that one was causing OOM on devpad.
<Rinchen> we can fire up staging under gdb and pound it. we're good at loading up staging :-)
<matsubara> disabled, I mean
<kiko> herb, do you want assistance doing this gdb thing? I could add a make target I guess
<kiko> matsubara, it's not hitting any bugs pages, regardless.
<kiko> matsubara, or if it is, then we need to lower the soft timeout threshold
<kiko> because we're not getting any oopses
<herb> kiko: I can do it.  would prefer some direction to make sure I'm doing it right.
<kiko> and very few 404s
<matsubara> kiko: I'll look into it
<kiko> herb, okay, I'll test on my local box after the meeting and then ping you.
<herb> kiko: cool.  thanks.
<Rinchen> Thanks gents + lady
<Rinchen> anything else for herb ?
<kiko> matsubara, the 404s are the hint to me. we normally get hundreds. we now get tens
<Rinchen> [TOPIC] DBA report (stub)
<MootBot> New Topic:  DBA report (stub)
<stub> After the earlier cleanups, the Session database had way too much empty space so I trashed the session tables. This logged everyone out but meant no downtime needed to cleanthings up and we are back within our free space map settings.
<stub> I've got more disk space on Chokecherry. Yay. I will be abusing demo.launchpad.net in earnest - any objections speak now.
<stub> There is a branch due to land as soon as I fix a few failing tests and get Edwins approval that changes things so we have four Storm Stores instead of the current single store. The load balancing algorithms between the launchpad master and slave stores will be tested on demo.launchpad.net. The other two stores - authdb master and slave - will not be active when the branch lands.
<stub> The envisaged roadmap is to test load balancing between a single master and slave while finishing of the scripts needed to maintain a replicated production database environment. The initial rollout may have a single replica set or two replica sets (lpmain and authdb), although either model the appserver will be accessing everything through a single master/slave pair of Stores (ie. authdb master and authdb slave will remain unused).
<stub> And that is all my incoherent ramblings for now.
<kiko> stub, what are you abusing demo for?
<kiko> ah, I see
<Rinchen> stub, do you have a general timeframe when we can move past the single pair of stores?
<stub> Seeing how Launchpad works with a real data set and talking to both a master and slave replica
<kiko> gotcha, yeah, your final paragraph made it very clear
<kiko> stub, this is awesome news, I'm thrilled to see this progress
<Rinchen> yeah me too. I'm excited for this all to land and be turned up
<stub> Rinchen: Not long I think. Next cycle?
<Rinchen> Great! I'll keep the champagne on ice then.  :-)
<Rinchen> anything else for stub?
<Rinchen> thanks stub
<kiko> yes
<stub> The trick with the authdb master and slaves becoming active is updating the code to actually use them - that is all the screens on login.launchpad.net for a start I think
<kiko> stub, what do you make of the librarian timeouts we're getting?
<stub> We are getting Librarian timeouts?
<kiko> stub, when people upload larger files, it pretty consistently dies and gives us a 503
<kiko> it's only on uploads -- downloads work reliably
<kiko> (well, I hope -- we don't have OOPSes there)
<matsubara> stub: something like this https://pastebin.canonical.com/7785/
<stub> I'd say there is an exception in the Librarian log file that needs to be looked at.
<kiko> herb, but there isn't, is there?
<herb> nope
<herb> the librarian log file is less than good.
<stub> Bad gateway is from Apache
<herb> and doesn't seem to be logging anything related to uploads.
<stub> So Apache is not passing the huge request through to the Librarian.
<kiko> stub, only sometimes, it works!
<kiko> hmph
<Rinchen> there is an apport bug reported with a 503 as well and I suspect the cause of that is related to what we're seeing. Both are large uploads
<kiko> this affects us with apport and file uploads
<kiko> for file uploads I'd propose using sftp://
<kiko> but for apport..
<kiko> stub, any clue where we could start looking if it is indeed an apache issue?
<stub> 503 or 502? The pastbin is a 502. There might be two bugs if you are getting two different codes.
<kiko> good point
<stub> Check the Apache logs to see if there is anything useful in there for that request
<Rinchen> 502 sorry
<kiko> thanks
<Rinchen> https://bugs.edge.launchpad.net/apport/+bug/114962
<ubottu> Launchpad bug 114962 in apport "502 bad gateway while automated crash reporting happening" [Undecided,Confirmed]
<stub> Otherwise, not sure. We might have to instrument the Librarian to log all the responses it sends out or stick in some sort of a sniffer in the middle.
<kiko> stub, okay, I'll do some googling.
<kiko> Rinchen, what's the apport bug id, have it handy?
<stub> My guess would be the Librarian is taking too long to store the file and give a response, and Apache is giving up waiting.
<Rinchen> kiko, in fact I do. :-)  read up a few lines
<stub> There will be some Apache tuning knobs for those timeouts we can poke
<kiko> thanks Rinchen
<Rinchen> anything else for stub?
<Rinchen> thanks stub
<Rinchen> [TOPIC] Sysadmin requests (Rinchen)
<Rinchen> Is anyone blocked on an RT or have any that are becoming urgent?  I know about 31340, 31296, and 31389.
<MootBot> New Topic:  Sysadmin requests (Rinchen)
<Rinchen> ok then
<Rinchen> [TOPIC] New packages required (salgado)
<MootBot> New Topic:  New packages required (salgado)
<salgado> anything for me this week?
<salgado> please say NO
<salgado> or don't say anything. :)
<salgado> Rinchen, I'm done. :)
<Rinchen> :-)
<kiko> salgado, well
<kiko> salgado, wanted to check with you
<kiko> I saw that we placed a request for xsltproc this week
<salgado> yesterday, to be precise
<kiko> salgado, was this brought up last meeting?
<salgado> no, it wasn't
<kiko> should it have been?
<salgado> it should, but we didn't know about it at that time, I think
<salgado> flacoste, when did we decide to use xsltproc?
<kiko> I just want to understand if this is something we just discovered, or some piece of the process that's busted
<salgado> I first heard about it being a dependency yesterday
<flacoste> we discussed it some time ago, and then toyed with it last week
<kiko> because IS are understandably unhappy about having to do last-minute package installs on all our servers
<flacoste> but it was only this week that it was clear it becomes a build-time dependancy
<flacoste> i could work around it for a while
<flacoste> commit the file to bzr and only generate it on demand
<kiko> flacoste, okay. in the future, if you "play around with it" then request it -- the lead time is important
<flacoste> until that is deployed
<kiko> flacoste, that might have to be done -- depends on what Rinchen tells us
<Rinchen> I'll know more tomorrow morning.
<kiko> flacoste, it's better to request and then not need it than to request too late, ok?
<flacoste> kiko: let's do it
<flacoste> no need for IS to be more pissed-off at us
<flacoste> kiko: got it
<kiko> thanks
<kiko> guys please
<kiko> lead time on package installations
<kiko> no fucking around or Rinchen and I get in big trouble with the man
<kiko> over and out
<flacoste> Rinchen: i'll work around it
<flacoste> Rinchen: so you can lower the priority of the thing
<Rinchen> That about that sums up our issue with dependencies.....
<Rinchen> thanks salgado kiko and flacoste
<Rinchen> [TOPIC] A top user-affecting issue (mrevell)
<MootBot> New Topic:  A top user-affecting issue (mrevell)
<mrevell> Hello people of Planet Earth.
<mrevell> This week has been relatively quiet in terms of user-affecting issues. However, we have had some comments from people who felt we could have done more to explain the changes to the Launchpad web interface's layout.
<mrevell> We've already highlighted the main changes on the blog but not where each item has moved to. So, mpt, if you have some time tomorrow it'd be great if we could have a chat about producing a more comprehensive step by step guide to the changes, if you feel that's appropriate.
<mrevell> Thanks Rinchen.
<mpt> ok
<Rinchen> [TOPIC] Doc Team report (mrevell)
<MootBot> New Topic:  Doc Team report (mrevell)
<kiko> part of the problem is that the changes are not all complete
<Rinchen> indeed
<mrevell> kiko: Right
<kiko> it's a consequence of being agile, in a sense, and also a consequence of being late :)
<Rinchen> it'll be hard to get a step by step done
<Rinchen> but a summary should be easy enough
<mrevell> Rinchen: Right, okay, well I'll talk to both you and mpt tomorrow about it.
<mrevell> thanks
<mrevell> Docs:
<mrevell> This week the big docs-related story is the release of the tour. We've had some good community feedback, both in terms of people who like and also people who've made helpful suggestions as to where we can improve it.
<mrevell> I've done another pass on the text today, correcting some typos. We're also going to look at some possible design improvements over the next few weeks.
<mrevell> I'm going to be planning the next stage of the tour's evolution over the next week or so. If you have any comments, please let me know.
<Rinchen> although I wonder if anyone will read it
<mrevell> If there are no questions, it's back to the Rinchenator.
<kiko> mrevell, why don't you use bzr to manipulate the tour?
<kiko> won't that be much easier than giving patches to mats?
<stub> I was very impressed, and I generally find things like the tour really sucky wearing my antisocial user hat.
<kiko> (on the UI, I think people's concerns are more about the process than with the actual changes)
<mrevell> kiko: matsubara has passed me a bzr branch that we'll work with now. the original reason was that I don't have RF access.
<kiko> stub, yeah, I liked it a lot, and wgrant did too :)
<mrevell> heh
<cprov> :)
<mrevell> stub: I'm glad you found it impressive, thanks.
<kiko> mrevell, you should request that -- no reason from me why you shouldn't
<Rinchen> mrevell, yeah, go talk to your manager about requesting that ;-)
<mrevell> okay, thanks kiko. Rinchen, I'll bend your ear about that tomorrow :)
<mrevell> heh
<Rinchen> anything else for mrevell ?
<matsubara> kiko, mrevell: I think it'd not hurt to give RF access to mrevell. I could still land the changes for him but it'd make the patches passing much easier
<kiko> matsubara, yeah, I didn't make that policy up!!
<kiko> but I can sure shoot it down
<kiko> Rinchen, anything else? going for a world record? :)
<Rinchen> [TOPIC] Bug triage & the triage status - kiko
<MootBot> New Topic:  Bug triage & the triage status - kiko
<kiko> okay
<kiko> very quickly
<kiko> triaged is being kinda inconsistently across our projects
<kiko> let's be consistent in using a reasonable meaning
<kiko> and the TLs proposal for a reasonable meaning is
<Rinchen> (the triaged status that)
<Rinchen> (is)
<kiko> we understand enough about the problem
<kiko> not know the solution -- just that the problem the user is experiencing is well-understood
<kiko> when you look at a bug
<kiko> you should do one of two things
<kiko> if it's not well-understood, mark it incomplete, and ask a question
<kiko> if it's well-understood, mark it triaged
<kiko> if it's in the wrong LP project, change the project
<kiko> that's three things. but YKWIM
 * kiko runs
<mpt> "we understand enough about the problem" to do what, exactly?
<matsubara> so, triaged is a developer only or not?
<kiko> mpt, we understand the problem to the developer's/triager's satisfaction.
<mpt> to start fixing it straight away?
<kiko> no
<mpt> to assign it to a person?
<mpt> to give it an accurate Importance?
<stub> Know enough to stop logging OOPS ids?
<kiko> just that the problem is well-understood, that the reporter doesn't need to provide any further information to describe it
<mpt> ok
<mpt> So how is that different from Confirmed?
<matsubara> isn't that what confirmed is for?
<flacoste> anybody can confirm bugs
<kiko> it's officially set
<kiko> that's the difference
<kiko> (confirmed has its days counted if I have my way!!)
<intellectronica> confirmed might go away at some point. it's just an indication that users really do experience this bug
<Rinchen> currently we go from new -> confirmed -> maybe triaged -> in progress.     Confirmed doesn't help us devs though because we might still be missing information required to understand the problem.
<kiko> +1 for me toos
<mpt> So "New" means "Unconfirmed", and "Triaged" means "Confirmed", and "Confirmed" means "don't use me".
<cody-somerville> maybe s/confirmed/open ?
<matsubara> lol
<kiko> cody-somerville, maybe s/confirmed// :)
<intellectronica> mpt: not really
<mpt> A bug can be "New" and be really really old, and a bug can be "Triaged" without having ever been triaged.
<kiko> no
<kiko> if a bug is in triaged, someone who's official has looked at it and marked it so
<kiko> agreed with New.
<intellectronica> triaged means (i think) - confirmed and investigated and will be scheduled for fixing
<salgado> intellectronica, I thought confirmed meant that
<kiko> if you are a developer or a launchpad triager
<kiko> don't use confirmed
<kiko> use triaged
<intellectronica> salgado: no, i think confirmed just means "yes, this bug really does happen"
<Rinchen> originally we had intended for triaged to me RTC... but in practice for bugs it's hard to get to RTC just by looking at the bug.  If we understand the nature of the problem, that will allow us to develop an approach to fix it
<Rinchen> so triaged becomes "we know what we should do" but it doesn't imply the bug is RTC yet
<Rinchen> Agile dictates it may not be RTC until you play with the code a bit
<salgado> kiko, I think most devs don't know about that
<intellectronica> Rinchen: RTC?
<Rinchen> Ready to Code
<intellectronica> oh right
<kiko> salgado, that's why i brought this up!
<mpt> Launchpad currently has 4 untriaged Triaged bugs. :-)
<kiko> but now that I have spent 10 minutes of our time on the topic I'll send an email to the list to solidify this. :)
<Rinchen> great!
<Rinchen> and we've already talked about the librarian with stu!
<Rinchen> so guess what time it is?
<flacoste> #endmeeting
<stub> beer o'clock!
<bac> T+24?
<Rinchen> bingo!
<Rinchen> Thank you all for attending this week's Launchpad Developer Meeting. See the channel topic for the location of the logs.
<Rinchen> #endmeeting
<MootBot> Meeting finished at 14:12.
<intellectronica> thanks Rinchen
<Rinchen> the Rinchenator
<Rinchen> lol
<kiko> phew
<Rinchen> I so wanted to /nick but figured mootbot would freak out
<mrevell> thsnks Rinchen
<kiko> this was more fun than usual!!
#launchpad-meeting 2008-08-02
<Anubias> hello
<Anubias> any body can help me?
#launchpad-meeting 2009-07-29
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> hi all.  welcome to the AMEU reviewer's meeting.  who is here today?
<sinzui> me
<mars> me
<bigjools> me
<cprov> me
<abentley> me
<gary_poster> me
<adeuring> me
<leonardr> me
<jtv> me
<bac> bigjools, noodles775, BjornT, deryck: ping
<rockstar> ni!
<intellectronica> me
 * bigjools thinks bac can't read
<bac> allenap, gmb, salgado: ping
<bac> bigjools: sorry
<bigjools> :)
<intellectronica> bac: gmb is on leave today
<allenap> me
<bac> EdwinGrubbs: meeting ping
<noodles775_> me
<bac> who've i missed?  danilo and henning send their regrets.
<bac> [TOPIC] agenda
<MootBot> New Topic:  agenda
<bac> * Roll call
<bac> * Barry out for two weeks. Brad to chair the meeting.
<bac> * Reviewer Meeting summary to launchpad-dev list? - bac
<bac> * Action items
<bac> * Mentoring update (leondardr/rockstar)
<bac> * Peanut gallery (anything not on the agenda)
<bac> [TOPIC] * Barry out for two weeks. Brad to chair the meeting.
<MootBot> New Topic:  * Barry out for two weeks. Brad to chair the meeting.
<bac> if that wasn't obvious already...
<gary_poster> :-)
<bac> [TOPIC] * Reviewer Meeting summary to launchpad-dev list? - bac
<MootBot> New Topic:  * Reviewer Meeting summary to launchpad-dev list? - bac
<rockstar> bac, +1
<gary_poster> +1
<mars> +1
<bac> last week barry sent the meeting summary to the old list.  all agree we should move?
<bigjools> yes
<bac> rather than vote are there any objections?
<rockstar> Lots of people outside our development community are interested in our coding standards, etc.
<intellectronica> i think we shouldn't email it but rather put it in the wiki
<bac> rockstar: yeah, i think it was just an oversight.
<intellectronica> but if we continue emailing then yes, the new list makes sense
<bac> intellectronica: it will be on the wiki too
<gary_poster> urg.  I guess I can subscribe.  I like the email vector.
<bigjools> -1 for meeting notes in the wiki, +1 for up-to-date coding standards
<rockstar> intellectronica, but we put the logs on different pages, so you can't subscribe to the wiki changes.
<gary_poster> oh good point
<bac> bigjools: the notes have always been on the wiki, no?
<mars> bigjools, easier said than done.  We have a very large set of standards :)
<bac> https://dev.launchpad.net/ReviewerMeetingAgenda
<bigjools> and larger meeting notes :)
<intellectronica> rockstar, gary_poster: fair enough. if people like getting the emails then it makes sense to continue with that
<bac> bigjools: so you want to take an action item to clean up the coding standards page?
<bigjools> I assume you're joking
<gary_poster> lol
<bac> well it was your suggestion..
<bac> [TOPIC] * Action items
<MootBot> New Topic:  * Action items
<allenap> rockstar: You can subscribe to the wiki with a regex.
<gary_poster> oh, that's good to know!
<bac> * gary_poster to take importfascist and rSP() discussion to ml
<rockstar> allenap, yeah, but then you have two problems.
<gary_poster> lol
<allenap> :)
<bigjools> lol
<bac> gary_poster: i suspect you didn't get to that while at OSCON
<gary_poster> bac: I am writing that email as we speak.  I'll send it out this morning.
<rockstar> Can we just take that action item off.  I think it's been around for 6 months now.
<bac> gary_poster: great.
<gary_poster> (was hoping to get it done by the meeting)
<rockstar> :)
<gary_poster> sorry rockstar, ack :-(
<bac> * barry to update wiki about sponsoring contributions and take RFC to the mailing list
<bac> i don't think barry did this.
<rockstar> gary_poster, it apparently was important to any of us either.  Not your fault.  :)
<gary_poster> :-)
<bac> since barry is out for two weeks, would anyone like to volunteer to go ahead and take care of the sponsoring write up and ML discussion?
<bac> would anyone like to volunteer karl?
<gary_poster> lol we all can do that together!
<gary_poster> I propose that we all collectively nominate call
<gary_poster> objections?
<bac> i'll see if karl will take the task or take care of it.
<gary_poster> karl I mean
<bac> [ACTION] bac to ask karl to write the sponsorship process page and ML discussion
<MootBot> ACTION received:  bac to ask karl to write the sponsorship process page and ML discussion
<bac> [TOPIC] * Mentoring update (leondardr/rockstar)
<MootBot> New Topic:  * Mentoring update (leondardr/rockstar)
<bac> leonardr is the only mentor at the moment.  how's it going?
<leonardr> bac: no complaints
<mars> leonardr, how's the volume?
<bac> i've had good reviews from leonardr and got to mentor one of his yesterday.
<bac> moving along...
<bac> [TOPIC] * Peanut gallery (anything not on the agenda)
<MootBot> New Topic:  * Peanut gallery (anything not on the agenda)
<bac> anyone have an issue to discuss?
<bac> community contributor reviews going ok?
<wgrant> (I think they're going well.)
 * gary_poster missed how that works.  will have to search wiki...
<bac> welcome wgrant
<bac> thanks for your contributions!
<noodles775> bigjools: did you find an easy way to submit community-contributed branches?
<wgrant> Hi bac.
<bac> gary_poster: there was a good discussion on the ML last week
 * wgrant thanks bigjools and gmb for the swift reviews.
<gary_poster> bac: ok, cool, thanks, I'll look for it
<bigjools> noodles775: nothing easy, we need to hack pqm-submit
 * bigjools thanks wgrant for his contributions
<adeuring> i'd like to add andrea-bs, who also submitted good stuff
<mars> cool
<bac> thanks adeuring for the recognition.
<bac> anything else?
<bac> 5
<bac> 4
<bac> 3
<bac> 2
<bac> 1
<bac> thanks everyone for coming.
<jtv> thanks bac!
<bac> #endmeeting
<MootBot> Meeting finished at 09:21.
<gary_poster> thanks bac!
<bac> in record time
<abentley> thanks, bac!
#launchpad-meeting 2009-07-30
<intellectronica> me
<Ursinha> haha
<jtv> hi Ursinha
<intellectronica> hihi
<jtv> hi intellectronica
<Ursinha> #startmeeting
<Ursinha> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<Ursinha> [TOPIC] Roll Call
<Ursinha> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<MootBot> Meeting started at 10:00. The chair is Ursinha.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<MootBot> New Topic:  Roll Call
<sinzui> me
<Ursinha> me
<Ursinha> !
<herb> me
<rockstar> ni!
<jtv> me
<Ursinha> lol
<Ursinha> I demand a SHRUBBERY!
<mars> me
<jtv> (the rest of the Translations team is out on vacation.  Presumably I'll get a T-shirt)
<Ursinha> matsubara, hi
<Ursinha> lol
<Ursinha> bigjools, hi
<bigjools> me, still on TL call
<Ursinha> okay, nothing to soyuz today
<Ursinha> from oops land
<Ursinha> stub, hi
<matsubara> me
<stub> me
<Ursinha> matsubara, welcome back
<matsubara> thanks Ursinha
<Ursinha> [TOPIC] Agenda
<Ursinha>  * Actions from last meeting
<Ursinha>  * Oops report & Critical Bugs & Broken scripts
<Ursinha>  * Operations report (mthaddon/herb/spm)
<Ursinha>  * DBA report (stub)
<MootBot> New Topic:  Agenda
<Ursinha> [TOPIC] * Actions from last meeting
<Ursinha>     * matsubara to chase rockstar about failure on updatebranches script
<Ursinha>     * stub to get RC for branch that fixes bug 403283
<Ursinha>         * landed in r8319
<Ursinha>     * ursinha do file bug for OOPS-1300XMLP5
<Ursinha>         * filed https://bugs.edge.launchpad.net/launchpad-foundations/+bug/403606
<MootBot> New Topic:  * Actions from last meeting
<ubottu> Bug 403283 on http://launchpad.net/bugs/403283 is private
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1300XMLP5
<Ursinha>     * Ursinha to keep one eye on UnicodeDecodeErrors, and will report back next meeting
<ubottu> Launchpad bug 403606 in launchpad-foundations "ExpatError errors should be handled to not generate the OOPSes" [Undecided,New]
<Ursinha>         * we're having less errors, Salgado will try to fix bug 61171
<Ursinha>     * mars to take a look at bug 354593
<ubottu> Bug 61171 on http://launchpad.net/bugs/61171 is private
<Ursinha>     * matsubara to chase salgado about people pruning script
<ubottu> Launchpad bug 354593 in launchpad-foundations "SSO exceptions views need proper branding" [High,Triaged] https://launchpad.net/bugs/354593
<jtv> Ursinha: We're having "fewer" errors :-P
<stub> The person pruner is running on production. It will take 3 or 4 weeks to complete.
<matsubara> Ursinha, I haven't had time to do that this week as I was on vacation
<Ursinha> thanks jtv :P
<Ursinha> matsubara, okay
<matsubara> please, re-add to the list and I'll chase
<Ursinha> [action] matsubara to chase rockstar about failure on updatebranches script
<mars> stub, wow
<MootBot> ACTION received:  matsubara to chase rockstar about failure on updatebranches script
<matsubara> Ursinha, the other one about the pruning script too
<Ursinha> [action] matsubara to chase salgado about people pruning script
<MootBot> ACTION received:  matsubara to chase salgado about people pruning script
<stub> Chase what? it is running.
<Ursinha> but what stub said?
<Ursinha> yes, yes
<rockstar> Yes, what stub said.
<Ursinha> matsubara, ^
<salgado> stub, don't we need to pass --experimental to it?
<stub> It is - I filed an rt and chased it through with spm.
<stub> And monitoring too
<matsubara> ok, so that's sorted then :-)
<Ursinha> [action] remove last matsubara item as stub already reported it's ok]
<MootBot> ACTION received:  remove last matsubara item as stub already reported it's ok]
<matsubara> :-)
<matsubara> thanks Ursinha
<Ursinha> matsubara, np :)
<Ursinha> mars, did you have the time to look at bug 354593?
<ubottu> Launchpad bug 354593 in launchpad-foundations "SSO exceptions views need proper branding" [High,Triaged] https://launchpad.net/bugs/354593
 * Ursinha wonders if mars is on the TL call as well
<mars> nope
<rockstar> Why is there a TL call this early?
<Ursinha> *whew*
<mars> I did not have a chance to address it
<Ursinha> oops section is all foundations today
<rockstar> I doubt my TL is on that TL call...
<bigjools> he's not
<Ursinha> well, mars, can you do that then, please? :)
<mars> stub, would you be able to take the SSO bug?  Or find someone who has time to address it?
<stub> The branding one?
<Ursinha> stub, yes sir
<mars> yes
<Ursinha> stub, bug 354593
<ubottu> Launchpad bug 354593 in launchpad-foundations "SSO exceptions views need proper branding" [High,Triaged] https://launchpad.net/bugs/354593
<stub> I can try. I haven't done UI stuff for a long time though so it will be slow.
<Ursinha> mars, ^
<mars> Ursinha, ?
<mars> stub, I can give you a hand with it
<Ursinha> okay then
<Ursinha> [action] stub to give a try on bug 354593 with mars help if needed
<ubottu> Launchpad bug 354593 in launchpad-foundations "SSO exceptions views need proper branding" [High,Triaged] https://launchpad.net/bugs/354593
<MootBot> ACTION received:  stub to give a try on bug 354593 with mars help if needed
<Ursinha> moving on
<Ursinha> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<Ursinha> mars, I have two bugs and one oops for foundations
<Ursinha> mars, can you triage bug 403606, and take a look at it, if possible?
<Ursinha> mars, also, OOPS-1307J16 shows an AssertionError without any description
<Ursinha> and finally
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<Ursinha> mars, do you know if someone could have some time to fix bug 310818? we had some weird timeouts today and the oops report was borked
<ubottu> Launchpad bug 403606 in launchpad-foundations "ExpatError errors should be handled to not generate the OOPSes" [Undecided,New] https://launchpad.net/bugs/403606
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1307J16
<ubottu> Launchpad bug 310818 in launchpad-foundations "Oops report does not always log timed-out query" [High,Triaged] https://launchpad.net/bugs/310818
<mars> Ursinha, I'll have to ask the team
<Ursinha> mars, about what exactly? :)
<Ursinha> btw, thanks for helping with the Unicode issues debugging last week, was very useful
<mars> Ursinha, to see who on foundations has time to address the issue - I would guess gary or stub, but I don't know how heavily committed they are at the moment
<Ursinha> mars, the bug 310818?
<ubottu> Launchpad bug 310818 in launchpad-foundations "Oops report does not always log timed-out query" [High,Triaged] https://launchpad.net/bugs/310818
<stub> I was going to look at it but someone designated me victim for the SSO exception stuff ;)
<Ursinha> haha
<gary_poster> Heh, It feels like I have a backlog to kingdom come, and I keep getting more. :-)  But if this is urgent, then it's urgent
<stub> I can probably do both - what should be done first Ursinha?
<Ursinha> stub, the oops one, I'd suggest
<Ursinha> as I said earlier we had some weird timeouts and it would be nice to be able to debug them if they happen again
<Ursinha> [action] stub to fix bug 310818
<mars> Ursinha, sorry, I was reading the Expat error one.  That sounded like something gary would be able to address, since it starts in the heart of Zope, and has to do with exception bubbling through the architecture
<ubottu> Launchpad bug 310818 in launchpad-foundations "Oops report does not always log timed-out query" [High,Triaged] https://launchpad.net/bugs/310818
<MootBot> ACTION received:  stub to fix bug 310818
<Ursinha> mars, right. gary_poster, want to fix that? :)
<mars> gary_poster, ^ does that make sense?
<gary_poster> looking
<mars> Ursinha, I'll look at OOPS-1307J16
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1307J16
<Ursinha> [action] mars to take a look at OOPS-1307J16
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1307J16
<MootBot> ACTION received:  mars to take a look at OOPS-1307J16
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1307J16
<Ursinha> thanks mars
<Ursinha> mars, I'd open a bug but had no clue about what happened
<gary_poster> Ursinha, not precisely clear on the goal but we can talk later.  I'm guessing this is low priority.  I'll take it.
<gary_poster> (bug 403606)
<ubottu> Launchpad bug 403606 in launchpad-foundations "ExpatError errors should be handled to not generate the OOPSes" [Undecided,New] https://launchpad.net/bugs/403606
<Ursinha> thanks gary_poster
<Ursinha> gary_poster, the point is that it fills the oops reports with those
<Ursinha> it would be great to get rid of them
<gary_poster> and they just mean that somebody is sending us bad XMLRPC, afaict, and we don't want to care?
<mars> gary_poster, it would be nice if the ExpatError was, say, turned into a 400 HTTP status code
<mars> right
<Ursinha> creating a section on the summary or moving them to dev/null was told to be not a good idea (I agree)
<gary_poster> ack, ok.
<Ursinha> gary_poster, do you think it's to painful to fix?
<Ursinha> *too
<Ursinha> [action] Ursinha to learn to type
<MootBot> ACTION received:  Ursinha to learn to type
<gary_poster> Ursinha: It will involve changing zope publication machinery.  Doing so will mean either hacking our zope tree, which we are really trying not to do; or migrating to a newer version of the publication machinery, which should wait on the Zope-buildbot work that I keep not finishing, and then will be a migration exercise, possibly accompanied with a negotiate-with-upstream exercise.
<gary_poster> lol
<gary_poster> so...
<gary_poster> the only quick and easy fix is the hack
<Ursinha> I see.....
<gary_poster> that I would be hoping to eliminate RSN
<gary_poster> when I move all the zope stuff to eggs
<Ursinha> gary_poster, so, a very temporary hack?
<gary_poster> so I'm happy to have that be a bug, but I'd like it to be a back-burner bug, myself
<gary_poster> right
<gary_poster> I certainly understand the pain though :-(
<mars> Ursinha, sound good?  We can review the solution outside the meeting
<gary_poster> or have a hint of it at least
<Ursinha> mars, sure
<mars> thanks gary_poster
<Ursinha> [action] Discuss the solution proposed by gary_poster after the meeting, about ExpatErrors and bug 403606
<ubottu> Launchpad bug 403606 in launchpad-foundations "ExpatError errors should be handled to not generate the OOPSes" [Undecided,New] https://launchpad.net/bugs/403606
<MootBot> ACTION received:  Discuss the solution proposed by gary_poster after the meeting, about ExpatErrors and bug 403606
<Ursinha> thanks mars and gary_poster
<Ursinha> well
<gary_poster> thanks mars and Ursinha  :-)
<Ursinha> :)
<Ursinha> we're not having more InterfaceErrors (thanks salgado), but we're still having OperationalErrors (OOPS-1306J75, OOPS-1306J96) and DisconnectionErrors (OOPS-1306I440, OOPS-1306J343)
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1306J75
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1306J96
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1306I440
<ubottu> https://lp-oops.canonical.com/oops.py/?oopsid=1306J343
<Ursinha> what can we do about it?
<Ursinha> I think that's yours too mars
<mars> Ursinha, I'll need to look at them
<mars> (obviously :)
<Ursinha> :)
<Ursinha> stub, do you have any clues?
<mars> stub, that looks like something for you - Storm barfing while talking over the internal network?
<stub> gary_poster: You could probably switch of the oops in errorlog.py - we already skip certain well defined exceptions entirely.
<gary_poster> stub: oh, ok.  not familiar with that.  sounds good on the face of it.
<mars> stub, gary_poster, well, that's why I suggested wrapping the ExpatError in a 400 status - it's the nice HTTP thing to do, since the client is in the wrong, not us.
<stub> Ursinha: All 'due to administrator command' are when the server killed the connection, usually because it was sitting idle too long.
<gary_poster> mars, can't do that without getting into the publication machinery.  stub's approach is not as elegant as what you suggest, but much more doable in the short term.
<mars> stub, so too much lag between opening the app server request and actually getting to issue commands?
<gary_poster> hm, unless there's an indirection lurking around...checking...
<mars> gary_poster, ok
<stub> mars: For an appserver request, we kill anything that doesn't complete in 2 minutes. For scripts, we kill anything that is idle-in-transaction for 90 minutes (or something like that).
<stub> mars: So a massive slowdown or pause anytime after the db transaction starts
<mars> stub, ok, would you be able to do an analysis, or help me do one, after the meeting?
<mars> to find what is taking so long to execute
<stub> I already looked at this one - I have no idea why that query would stop (the OOPS i'm looking at Ursinha pointed me at earlier)
<mars> you know what the problem is, but I would have to troll the OOPSes to find the root cause
<Ursinha> stub, did I?
<stub> A number of requests timed out all at exactly the same time. I doubt we can reproduce it, and there doesn't seem enough information to diagnose it.
<Ursinha> stub, that was another oops, I guess
<stub> Yup. But the one I'm looking at is select replication_lag() again - this time it took so long it got terminated by the reaper.
<Ursinha> stub, oh, I see
<Ursinha> so they are related
<Ursinha> stub, because of having not enough data in that oops you can't diagnose the Errors?
<Ursinha> *Errors
<Ursinha> mars, stub, we're running out of time, can we discuss that on -dev after the meeting?
<mars> Ursinha, sure
<Ursinha> allright
<Ursinha> [action] mars and stub to discuss the Disconnection and OperationalErrors after the meeting
<MootBot> ACTION received:  mars and stub to discuss the Disconnection and OperationalErrors after the meeting
<Ursinha> critical bugs: we have bug 403283, that is in progress as commented on it
<ubottu> Bug 403283 on http://launchpad.net/bugs/403283 is private
<Ursinha> moving on!
<Ursinha> thanks a lot guys
<Ursinha> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> 2009-07-28 - Rolled critical fixes to the app servers and scripts server.
<herb> We've had some issues with codebrowse in the last week where the process dies but doesn't leave a core file. It's also not leaving anything interesting in the logs. We haven't filed a bug yet, but expect one soon. Any help in determining the best way to debug the issue would be helpful.
<herb> mthaddon has a 2nd librarian instance up and running. We're preparing to load balance between them. mthaddon updated bug #403283 with some questions and it appears stub has responded to them.
<ubottu> Bug 403283 on http://launchpad.net/bugs/403283 is private
<herb> There aren't any pending queries or cherry pick requests.
<herb> That's it for the LOSAs unless there are questions.
<Ursinha> anything for herb?
<Ursinha> thanks herb!
<Ursinha> moving on
<Ursinha> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<herb> thanks Ursinha
<stub> I generated a new database baseline from the production database and landed it. We do this occasionally to ensure that the version of the db we are developing on matches what is actually running on production (patches made to the live system not backported to the trunk or stuffups can cause drift).
<stub> If you have an approved but unlanded database patch you will need a new database patch number from me.
<Ursinha> stub, oot?
<Ursinha> :)
<stub> oot
<Ursinha> sweet
<Ursinha> anyone wants to say something?
<Ursinha> thanks stub :)
<Ursinha> I have something to say to all contacts
<Ursinha> we want to close the 2.2.7 milestone, so, if you have pending bugs or blueprints, please, retarget of fix release them
<Ursinha> intellectronica, I saw that bugs team has a lot (really) of not assigned bugs targeted to 2.2.7
<intellectronica> Ursinha: sure, will make sure we sort them out now
<Ursinha> thanks a lot intellectronica
<Ursinha> and all guys
<Ursinha> you rock
<Ursinha> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<Ursinha> #endmeeting
<MootBot> Meeting finished at 10:47.
<intellectronica> Ursinha: you rock too
<herb> thanks everyone
<gary_poster> (mars, re bug 403606: the only hook I see is the big honking one that specifies what request class to use.  we could do that probably.  I wish it could go in the standard implementation though, since returning a 400, as you suggest, is good reasonable behavior.  I suspect stub's error squelching solution will be an easier quick hack.)
<ubottu> Launchpad bug 403606 in launchpad-foundations "ExpatError errors should be handled to not generate the OOPSes" [Undecided,New] https://launchpad.net/bugs/403606
<Ursinha> thanks herb
<Ursinha> ahh.. I love my job
#launchpad-meeting 2009-07-31
<Ursinha> it seems gmb is having internet issues..
<gmb> Ursinha: Yeah... :)
#launchpad-meeting 2010-08-03
<gary_poster> hey stub.  I'm ready on mumble whenever you are
#launchpad-meeting 2010-08-04
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<danilos> hi
<gary_poster> me?
<jelmer> me!
<mars> moo
 * bigjools on the edge of my seat
<adeuring> me
<EdwinGrubbs> me
<abentley> meÂ¡
<sinzui> meâ¢
<bigjools> how do you keep a bunch of wankers in suspense
 * mars pokes the meeting chair
<bac> mars: ?
 * gary_poster wonders if bac's connection died
<bac> huh?
<bac> am i not here?
<gary_poster> we were expecting you to tell us to say "me" :-)
<bac> i never say me
<mars> bac, dude, where's the protocol? :)
<bac> it's embedded in #startMEeting
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> == Agenda ==
<bac>  * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * New topics
<bac>    * try/else/finally is considered harmful in doctests [curtis]
<bac>  * Peanut gallery
<bac> [topic] outstanding actions
<MootBot> New Topic:  outstanding actions
<bac> so lifeless and i are having this inefficient discussion:
<bac> * lifeless: to set a policy on what can live in lib/lp, lib/services, and lib/coop
<bac>    ** I plan to ignore this, folk seem to have the idea already **
<bac>    ** Please reconsider.  This item came about because we couldn't figure it out ourselves.  Some people won't use 'coop' due to its name.  Personally I don't know the difference.  --bac **
<flacoste> me
<bac> so my question for the reviewers, is this really an issue?  we originally asked bjorn for an opionion b/c none of really knew what went where wrt services and coop/co-op
<bac> er, 'none of us'
<bigjools> I bet the code guys hate it when using tab completion
<bac> bigjools: that plus the name
<abentley> bigjools, I actually hate that 'code' is a prefix of 'codehosting'.
<danilos> what do we have in coop?
<bac> answerbugs
<sinzui> bug-answer
<bigjools> if that is all, why not lib/lp/answersbugs
<sinzui> coop is for cross app dependancies
<sinzui> registry exempted
<danilos> sinzui, right, but we haven't really went forward with it
<bigjools> I must admit, I forgot it existed
<mars> Is it something the reviewer should look for?  Or is it something for the pre-imp?
<gary_poster> My take: yes, we are still confused
<sinzui> because it is neigh impossible to separate branch-bug-spec-question
<danilos> i.e. we have developed a lot of translations-code and translations-soyuz bridges (well, there are some old ones), and like bigjools, I forgot it existed so never pushed for using it
<gary_poster> Either robert d=should decide, or we should
<gary_poster> and that's what bac is asking, I think
<bac> gary_poster: yep
<gary_poster> I'd be happy to tell robert, "yes, I confirmed, we're still confused.  please help."
<danilos> well, setting a policy is easy, but how do we migrate existing stuff?
<gary_poster> ...happy for you to tell...
<abentley> My original question was about whether the job system and the build farm should be in different places.
<abentley> Right now, jobs is under lp.services and buildmaster is under lp
<EdwinGrubbs> maybe, calling it crossappdeps would be clearer than coop.
<danilos> EdwinGrubbs, isn't that what services is as well?
 * EdwinGrubbs shrugs
<mars> bac, so, we are still confused, and we have no migration strategy
<bac> danilos: i'd be happy combining the two
<bac> mars: right.
<mars> design by committee (us) isn't working
<sinzui> Services is intended to hold utilities that have no lp deps, but other lp apps depend on them
<mars> (IMHO)
<bac> so i think i shall leave the item for lifeless and encourage him to think about it
<gary_poster> +1
<danilos> yeah, I think everybody is happy to go with a decision whatever it is :)
<bac> which i've really already done.
<bac> danilos: yes, clarity now!
<bac> ok, let's move on
<bac> [topic]  try/else/finally is considered harmful in doctests [curtis]
<MootBot> New Topic:   try/else/finally is considered harmful in doctests [curtis]
<sinzui> http://pastebin.ubuntu.com/473086/
<MootBot> LINK received:  http://pastebin.ubuntu.com/473086/
<sinzui> ^ take a moment to read this example
<gary_poster> ContextManager use does not confuse the parser, I take it?
<bac> sinzui: by that do you mean 'with'?  i thought you said that was broken too.
<sinzui> I think the issue in the parser is that it assumes '... ' is always an indented block
<bigjools> that whole piece of code looks like a unit test to me
<danilos> I must admit to not seeing that too often
<bac> bigjools: yep
<sinzui> yes, every example I have seen looks like a mis use of doctests
<abentley> so ">>> finally:" doesn't work?
<sinzui> the testrunner dies
<danilos> there seems to be a total of 9 uses of "finally" in lib/lp/*/doc
<mars> sinzui, so then it is safe to say "don't do it, because it smells funny"?
<mars> as well as breaking the parser
<sinzui> this may also be bad: ... else:
<sinzui> mars, yes
<bac> so when lint complains about it we should listen
<sinzui> Something that constructs the tests from the doctest is correcting the parsed doctest parts.
<danilos> sinzui, +1 on making it a lint failure (or well, keeping it a lint failure)
 * bac notes the new pocket-lint is much less chatty.  thanks sinzui.
<mars> danilos, +1, and now we all know a better way to fix it, too
<abentley> sinzui, -1.  If lib/lp/*/doc is supposed to be documentation, it shoujld demonstrate the best way to write code.
<bac> sinzui: would you update the appropriate test style wiki with your findings?
<abentley> sinzui, and omitting a finally block that you would normally put there doesn't seem like good documentation.
<sinzui> We can place branching statements in functions and classes
<gary_poster> I think abentley makes a good point.  Moreover, I thing the argument being proposed here is "the parser doesn't understand blocks in doctests so don't use the,"
<gary_poster> them
<gary_poster> that seems a bit weak on its own
<gary_poster> if doctests are about documentation, not unit tests, then blocks may be appropriate in some cases
<gary_poster> I've written them in doctests that I felt were pretty good documentation
<bac> gary_poster: but is it testable documentation if the testing framework doesn't work?
<gary_poster> bac, ?  doctests understand this fine
<gary_poster> the *lint* parser gets confused
<sinzui> Do we advocate that users write code without classes and functions? I think not. If we want to show branching, we can easily show it in function
<EdwinGrubbs> won't the parser be happy enough with the try/finally if you put it inside a function that is defined in the doctest?
<sinzui> Keep in mind, that the example I have seen do not look like good documentation
<bac> gary_poster: thanks for clearing that up
<gary_poster> (np)
<gary_poster> forcing docs to use a function for this purpose seems arbitrary
<abentley> EdwinGrubbs, in cases where the function is needed anyway, that's reasonable.  If it's not...
<gary_poster> (or class)
<abentley> EdwinGrubbs, ... then it's bad documentation to have a function you otherwise wouldn't need.
<gary_poster> right
<sinzui> gary_poster, jamesh wrote pyflakes-doctest because the test did play fine, but it was invalid. He discovered we had unreachable code in them, or code that was broken
<bac> sinzui: so is the finally getting executed in doctests?  is the doctest runner broken because it uses the same parser?
<sinzui> The essence of this issue is that we are not presented with the unittest that is built from the doctest. We need to be careful and clear about what we write in them
<sinzui> All the tools we are talking about use DocTestParser()
<sinzui> I think the finally is, but I have not seen the unittest that was constructed
<bac> I think we need to do more analysis to fully understand the problem.
<sinzui> Since we are in am ambiguous situation, lets write code that in not ambiguous to the tools and ourselves
<gary_poster> sinzui, pyflakes-doctest: ok.  but I don't see how that's a point against the position that abentley and are taking.
<gary_poster> unittest: we have already established quite clearly that doctests are not good for unit tests.
<gary_poster> finally parsed: it is, as can be demonstrated very easily, and as has been part of the doctest library behavior since its release to my knoweldge
<sinzui> gary_poster, I think my point is being missed
<gary_poster> maybe so :-)
<sinzui> I have not seen an example in our doctests, that our tools report an issue with that does not look like a bad test.
<gary_poster> I would be +1 on this as something that had to be explained in a review
<gary_poster> perhaps that's all that you are proposing
<sinzui> Since changing our tools requires second guessing the reparsing of the parsed doctest objects, we then place our selves into a false sense of confidence that we are right
<gary_poster> I would be -1 on making a blanket statement that using blocks in doctests is not OK
<bigjools> I agree with gary_poster
<gary_poster> and similar sub-blanket statements
<bac> bigjools: you're +1 with gary's -1?
<bigjools> bac something like that :)
<gary_poster> :-)
<sinzui> Well what do you want to do then. Do you propose a change to doctestparser or the two tools we have used?
<bigjools> sinzui: I still don't understand the point you're trying to make :(
<sinzui> That markup fails. and the doctestparser says it is bad
<gary_poster> I don't know these tools, but I also generically object to tools' limitations driving style
<bigjools> is it that we think the tests are not executing code in finally: or else: blocks?
<sinzui> No
<bigjools> so it's just the linter?
<gary_poster> can we make "be quiet about this warning" linter statements in doctests the way we can in other contexts?
<sinzui> This is about the fact that the example code is not being interpreted exactly as we write it! it is being reinterpreted.
<flacoste> sinzui: what reinterprets it?
<flacoste> the testrunner?
 * gary_poster is confused again
 * bac too
<sinzui> I assume the class that build the source + want blocks into a unittest
<flacoste> isn't that the doctest module itself?
<gary_poster> yes
<flacoste> so the same thing you think you are using in the linter?
<flacoste> the testrunner uses doctest primitives
<sinzui> yes
<flacoste> like you do
<flacoste> if it works in the testrunner but not in the linter there is a mystery to be solved
<flacoste> not style statement to be changed
<sinzui> two engineers wrote near identical code re using the doctest lib to parse the content to get the code that is compiled
<gary_poster> +1 to what flacoste said (though, as I said, I'm happy to try the position that "blocks in a doctest are worth  questioning in a review")
<abentley> gary_poster, as am I.
<flacoste> but again, if if it works in the testrunner
<flacoste> ...
<sinzui> Well
<flacoste> unless you show that the testrunner is doing something funky
<flacoste> so as not to complain
<sinzui> I recall several asserts in doctests that were never played
<flacoste> that was different
<sinzui> The linter found that, not out test runner
<flacoste> that's a known python limitation
<flacoste> not a syntax error
<flacoste> here you are talking about a case where the linter has a parse error
<flacoste> and the testrunner doesn't
<sinzui> yes
<flacoste> in the assert case, both parsed it correctly
<flacoste> they were valid statements that didn't do what the author intended
<flacoste> that's very different
<bac> but does the testrunner DTRT or not regarding try...finally?
<gary_poster> it DTRT
<bac> ok
<flacoste> it's a separate question anyway
<flacoste> the problem pointed here is that the lint tools choke on it, not that it's dubious
<flacoste> an assert with a comma is dubious, but valid
<flacoste> here, the try: finally: is a syntax error
<flacoste> for one tool and not for the other
<flacoste> or others
<abentley> flacoste, I think there are a few things: 1, it's dubious: it should be '>>>'.  2. the linter is not following the dubious formatting.  3. the linter is valuable to us, so we should play nice with it.
<abentley> sinzui, is that what you mean?
<flacoste> abentley: you mean, ... finaly: should be written as >>> finaly:
<flacoste> ?
<flacoste> that baffles me
<bigjools> me too
<abentley> flacoste, well, lemme try in a python console here...
<danilos> shouldn't we just fix the linter then? (provided it's not too much work)
<gary_poster> (disagree on >>> point also)
<flacoste> >>> try:
<flacoste> ...      print 1
<flacoste> ... finally:
<flacoste> ...      print 2
<flacoste> ...
<flacoste> that works fine in the python interpreter
<flacoste> console
<abentley> flacoste, verified.
<abentley> I withdraw my 1 2 3.
<gary_poster> well, your 3 is the core issue still, from my perspective
<gary_poster> "the linter is valuable to us, so we should play nice with it."
<danilos> gary_poster, +1, so we should either fix the linter, or make code slightly uglier but keep the linter happy
<jelmer> danilos: I agree, the best solution would be to just fix the linter if that's not too hard.
<flacoste> first step in that direction is to understand what the linter and testrunner do differently
<sinzui> The issue is broader than finally:
<bac> flacoste: +1
<sinzui> it is branch statements
<danilos> sinzui, then we should probably fix the linter
<sinzui> I said wont fix because I do not want to second guess how the parsed objects are reparsed
<danilos> I don't think we've got to come up with a coding solution here, as long as we agree that these: 1) warnings can be ignored until linter is fixed or 2) doctest code should accommodate the buggy linter
<flacoste> sinzui: sure, but i'm pretty sure that the testrunner doesn't mess with the input either
<sinzui> Using the same process that makes a playable doctest is a requirement
<flacoste> sinzui: unless you have evidence to the contrary
<gary_poster> +1 on danilo's resolution to the current topic
<gary_poster> with the acknowledgement that sinzui shouldn't be forced to be the one to make the code changes
<danilos> yeah :)
<danilos> he won't be forced, he'll be just politely asked by everybody :)
<gary_poster> heh
<sinzui> https://bugs.edge.launchpad.net/pocket-lint/+bug/606897
<ubot5> Launchpad bug 606897 in pocket-lint "doctest cannot compile finally (affected: 1, heat: 8)" [Undecided,Triaged]
<mars> so can we say this issue is resolved?
<sinzui> yes
<bac> mars: i think so, for now, unless we get more information
<bac> we'll have to address this on the ML or a future meeting, if required, as we're out of time.
<bac> thanks sinzui
<bac> thanks everyone.
<jelmer> thanks bac
<mars> thanks bac
<gary_poster> thanks bac, sinzui
<abentley> thanks bac
<bac> #endmeeting
<MootBot> Meeting finished at 09:46.
<bigjools> tqa
<danilos> thanks sinzui, bac :)
<bac> thumper, rockstar: you around?
<thumper> bac: should also ping mwhudson and lifeless
<thumper> rockstar is not around today
<bac> thumper: sure.  i thought mwhudson was no longer participating and lifeless would not be up.
<bac> but i'd forgotten lifeless was in NZ
<lifeless> hiya, sorry to be late
<bac> lifeless: it's pretty hard to be late for this meeting.  it sort of drifts around.
<lifeless> :P
<bac> lifeless: but glad you're here
<bac> it's just you, thumper, and me
<lifeless> ok cool
<lifeless> its your show, so lead on :)
<bac> we had a rousing 30 minute discussion this morning about the linter and test runner wrt to try/finally in doctests
<bac> it turns out, the base assumptions were wrong.  curtis sent out a mea culpa email and has gone to live underground.
<bac> lifeless: we also talked a bit about the action item you inherited regarding lib/lp/services and lib/lp/coop
<lifeless> ok
<thumper> I want to propose that we rename lp.coop to lp.shared
<lifeless> I saw your 'please do it'
<bac> as i suspected we're still mightily confused and are looking for some guidance
<thumper> or lp.crossapp
<thumper> anything but "coop"
<lifeless> thumper: AIUI coop is for XtoY code
<bac> or merge the two...
<lifeless> like bugstobranch
<lifeless> or branchtoproduct
<thumper> lifeless: yes
<bac> answerstobugs is all there now
<thumper> more between app
<thumper> rather than app -> registry
<lifeless> so between
<lifeless> or inter
<thumper> app -> registry is still considered app
<bac> i actually found some definition in utilities/migrater/README
<lifeless> I don't like shared, for the same reason as coop - its a true but useless definition
<thumper> bac: but bug-branch and branch-spec are not
<lifeless> lp.services is also shared
<thumper> lp.interapp
<thumper> gah
<thumper> maybe I don't care as much
<thumper> but I just really dislike coop
<lifeless> I don't love it either
<lifeless> so here's my take: everyone seems to know, its about XtoY
<thumper> because I read it as "coup" rather than co-op
<bac> in an amazing big of self-awareness, i think we agree we'll never come to satisfaction making the decision as a group but are willing to follow any well-thought fiat
<bac> s/big/bit
<lifeless> if its the definition that is missing, I'll edit the namespace package to say - well exactly what it says now.
<lifeless> (pydoc lp.coop -> useful answer)
<thumper> no Python documentation found for 'lp.coop'
<lifeless> if its the name that sucks, I'll raise it on the list and we can paint it anycolour but coop
<lifeless> thumper: oh yeah, another reason to hate buildout :)
<thumper> I'm happy with the concept
<thumper> unhappy with the name
<wgrant> Doesn't it still only have answersbugs?
<thumper> but lets continue...
<thumper> wgrant: for now yes
<bac> no, just pick a name.  no list!  use your authoritarian mandate
<thumper> I've not moved the branch ones there as I hate the name
<lifeless> bac: I gave that up on day one :)
<thumper> bac: I'll discuss with lifeless and we'll pick a name
<bac> suits me
<lifeless> but sure, I'll lead organising a better name
<lifeless> lp.cracks
<lifeless> because its in between
<thumper> lifeless: no... we'll choose one between us
<thumper> lifeless: and bend the team to our will
<lifeless> thumper: Well, we'll move it forward.
<bac> lifeless: as to your other issue about imports per line, it did not come up as i didn't understand your position
<lifeless> bac: so I replied in the list thread about 40 minutes ago
<thumper> bac: one import per line
<sinzui> We had someone who made a mandate, and we discovered that if enough engineers hate it, it will not happen
<bac> lifeless: we did have quite a go at that one last time and it was not a popular idea
<sinzui> only flacoste used coop/
<lifeless> bac: could you read my reply ?
<lifeless> sinzui: exactly, mandate == fail
<thumper> sinzui: but I'll move my code if I can tollerate the name
<bac> lifeless: yes, i'd already read your reply
<lifeless> the way I think of it, leaders only have one mandate card at a time; if they play a new one, the old one gets lost :)
<lifeless> bac: ok. Still confused ?
<bac> lifeless: no.  i'm not confused now but was 8 hours ago, hence it didn't make the meeting
<lifeless> righto
<lifeless> bac: so I'm up to speed now :)
<lifeless> I think changing this will have several good effects.
<lifeless> firstly it will make reviews easier.
<thumper> less merge conflicts
<lifeless> secondly it will mead we can delete most of the section about import scopes, because that is dealing with fallout from the current policy - such as the current policy causing merge conflicts.
<bac> personally i don't think changes to imports affect reviews as the linter will tell you whether you have extras and it won't compile if you leave something out
<thumper> bac: but we do get (unnecessary) conflicts
<lifeless> bac: you've never had your eyes glaze over as you try to assess what was changed ?
<bac> thumper: really?  are you seeing lots of merge conflicts on imports?
<thumper> bac: reasonably regularly, yes
<bac> i must be living right, then, as i don't see it often
<wgrant> FWIW, I hit it fairly frequently.
<bac> lifeless: you don't have to convince me, though, but the rest of the reviewers.
<lifeless> bac: well, you've got three enthusiastic votes here.
<lifeless> and noone shouted it down on the list.
 * sinzui is still seeing lots of conflicts his apocalypse branches because imports are still using c.l globs
<lifeless> so I think we should just do it
<lifeless> four enthusiastic votes here.
<wgrant> sinzui: I've pondered making the linter complain about c.l.i imports.
<bac> lifeless: and i will say we have lost one of the biggest proponents of the status quo to another team so it might be easier
<sinzui> jml and I agree it should, maybe scream at every change to the module
<bac> lifeless: seriously?  i'll bring it up and take a vote next week.
<bac> lifeless: you may want to stay up late and come argue your case...
<lifeless> bac: what time, UTC, is it ?
<bac> 1400
<lifeless> 2am
<bac> ugh
<lifeless> I think I'll pass.
<lifeless> But I'll keep gnawing at this on the list until the pros and cons are clearly established :)
<bac> right
<bac> any other topics to discuss?
<thumper> I might mention something
<lifeless> Separately, there is a meta-thing here, which is that I think the review team <-> style guidelines interaction may need a tuneup
<thumper> I sent an email to the list about lp.<app>.errors and lp.<app>.enums
<lifeless> the review team is now ~= all developers
<lifeless> sorry thumper, go ahead
<thumper> we should raise it on the reviewer meeting too
<thumper> by moving enums and errors out of interface files we reduce circular dependencies
<sinzui> thumper, emums and errors is just going to happen
<thumper> enums and errors have fairly static and defined dependencies
<thumper> emum?
<sinzui> the people who really want to kill the issue will make it happen
<thumper> sinzui: I've been moving more out
<thumper> I almost created the registry ones
<thumper> moving NotFound though was quite taxing
<sinzui> I bet you broken shipit
<bac> thumper: i like your idea and will bring it up next week
<thumper> sinzui: yep
<bac> [action] bac to bring up thumper's point about errors and enums
<sinzui> All the webapp globs in c.l have to stay until we can kill it
<thumper> sinzui: so there is an import that keeps it where shipit cares about
<sinzui> I have that in one of my apoc branches
<wgrant> sinzui: It seems like it's pretty killable, except that it needs access to Person.karma.
<wgrant> sinzui: Everything else can be done through SSO.
<thumper> sinzui: how many epoc branches do you have unlanded?
<sinzui> shipit has insider knowledge of lp, and it's knowledge is wrong. I do not think most lp engineers are aware of the webapp shims
<sinzui> thumper, 1. I estimate I need to do 5 from my master branch
<bac> lifeless: you had another issue?
<lifeless> yes, was letting sinzui and thumper duke it out ;)
<lifeless> My issue - Separately, there is a meta-thing here, which is that I think the review team <-> style guidelines interaction may need a tuneup
<lifeless> the review team is now approximately all developers
<sinzui> I cannot complete branch 6 until enum, errors are address, and we soyuz and registry need to stop fighting over distroseries
<lifeless> so I think that the original responsibility - tuning process & deciding on the coding guidelines, are perhaps no longer a good fit for these meetings
<bac> lifeless: yes.  the AMEU meeting sometimes reflects that as it is the only time during the week we're basically all around for a chat
<lifeless> instead, the meeting should be about tuning process
<lifeless> and we should just use the mailing list to build consensus on the guidelines and act directly from that
<lifeless> this would do two things:
<lifeless>  - make the review meetings more focused on the /review/ component
<lifeless>  - allow faster iteration when good ideas come up, because it would no longer be bypassing-the-system to change guidelines based on list consensus
<lifeless> I haven't thought really deeply about this yet - its a sketch, a possibility; I'm interested in what you think about this idea.
<bac> i'm not convinced that getting a consensus on the list is faster.  often in a meeting we can quickly come to a conclusion.  the times we don't we send it off to the list.
<lifeless> perhaps I should say then, that 'consensus should be the test, decoupled from any specific meeting'
<lifeless> if a meeting helps achieve consensus, great, but its a tool towards consensus, not the approval-step
<lifeless> anyhow, as I say, this is a fairly fresh thought, not time-hammered and analysed yet ;)
<bac> lifeless: i'm open to any ideas to improve the meetings and make them more productive
<lifeless> it struck me as very formal to need to bring the import change through the review team process, rather than just saying 'any objections... wait... done'
<lifeless> and so I was pondering what the formality buys us.
<bac> actually, that is a bad example, i think b/c until your last email it was not clear to me what was being proposed
<lifeless> Years ago, it bought us consensus amongst senior developers and no requirement for team wide consensus. The team is a very different place today.
<bac> ten messages over the course of two days before the actual proposal was fleshed out
<lifeless> bac: Its a good example - it shows the thing needing discussion to make it clear to everone, but no synchronisation point needed
<lifeless> neverhteless, I'm not proposing a change here; its in the minutes and folk can think about this.
<bac> right, but were we able to all be in a meeting at once it would been clear within about 90 seconds
<bac> lifeless: it's definitely worth considering.  thanks for bringing it up.
<lifeless> we feel -very- process heavy compared to the bzr team, and I'm just questioning in a state of childlike naivety the tradeoffs all over the place
<lifeless> so - I'm 'fin' on that point
<bac> anything else?
<lifeless> back to the chair
<thumper> nope
<bac> ok, thanks for showing up and having a good discussion.  see you next week.
<lifeless> roger wilco
<lifeless> ciao ;)
#launchpad-meeting 2011-08-04
<harry_> hey any one with the knowledge of language selector in Ubuntu 11.04???
