#launchpad-meeting 2006-10-02
<ddaa> _thumper_: we you informed that the bazaar meeting has been postponed by 24h
<_thumper_> yep
<ddaa> for reason of today being a holiday in relevant parts of .au
<_thumper_> I think poolie included me in the emails
<ddaa> good
<ddaa> _thumper_: so, what are you up to?
<_thumper_> ddaa, going through the new starter wiki page
<_thumper_> adding myself to the appropriate pages
<_thumper_> mailing lists et al
<ddaa> The one about updating a few pages on wiki.canonical.com etc.?
<SteveA> there's also the "canonical admin" system for managing vacation time and expenses etc.
<_thumper_> I don't seem to have a login to that yet
<SteveA> one day, we'll have a cohesive system for these things...
<SteveA> ask clan about that
<_thumper_> clan?
<ddaa> Claire Newman
<_thumper_> ok
<ddaa> give or take one letter in the last name
<_thumper_> I'm slightly miffed this morning as my older laptop's backlight has just gone futt
<SteveA> replaceable?
<_thumper_> yeah, but the question is "is it worth replacing"
<_thumper_> it isn't my primary laptop now as it is *heavy*
<_thumper_> I could just run it through an external monitor
<ddaa> _thumper_: I know you are eyeing one of those shiny dual core lappies :)
<_thumper_> got one :-)
<_thumper_> vaio sz2xp
<ddaa> I promised myself I bought the next lappy from one of those linux-friendly manufacturers
<ddaa> anyway...
<ddaa> Jumping through all hoops of the NewStaffTasks is going to take a little while
<ddaa> esp. setting up the jabber client that nobody uses
<SteveA> I use jabber with people
<_thumper_> I have MSN and yahoo IM alreaddy
<ddaa> strike that, the jabber client that I should be using
<ddaa> if only jabber.org was halfway reliable
<SteveA> I'm also on msn and yahoo
<SteveA> but not so much for work
<_thumper_> if jabber is actually used, I should go and create one
<SteveA> _thumper_: steve@z3u.com for MSN and kaguanas for yahoo
<ddaa> After that, there is probably an half out-of-date page about how to set-up Launchpad development environment somewhere on launchpad.canonical.com
<SteveA> ddaa: you're sounding very negative today
<SteveA> or maybe that's cynical
<SteveA> have a smoke and a coffee, perhaps?
<ddaa> SteveA: bah, got some adversity at home, but I guess that should not affect my work
<SteveA> ping me later if you want to have a private rant about it ;-)
<ddaa> SteveA: the truth is, I noticed how many references to Arch stuff and old import stuff there are still on the wiki.canonical.com
<_thumper_> since launchpad is backed by a real db, do dev versions need postgresql too?
<_thumper_> as opposed to zodb which is easy :)
<ddaa> yes
<ddaa> the database setup instructions are quite up to date on the other hand
<ddaa> which is good because it's not easy to guess
<SteveA> on your development machine, you're running a miniature version of the launchpad we run in production
<_thumper_> I'll do all that on the laptop as this box is going to be in a container for two months
<SteveA> I'm leaving non-laptops non-macminis here in lithuania
<SteveA> I don't believe they'll still work on the other side of the trip to amsterdam
<ddaa> which means that between launchpad, bzr and the rest, you need about 1GB RAM to work comfortably
<_thumper_> lappie has 1G
<ddaa> same here
<_thumper_> btw, tim@penhey.net on MSN, timbo_kiwi on yahoo
<_thumper_> since I'm not technically working on bzr source, is the dapper package suitable?
<ddaa> _thumper_: there's some custom source we should be using, so when the launchpad devs are asked to dogfood some rc package you get it automatically.
<ddaa> but most of the time, the policy is to use the package in the current released ubuntu
<ddaa> from my apt/sources.list
<ddaa> # testing bzr for launchpad devos
<ddaa> deb http://bazaar-vcs.org/releases/debs/scratchy/ ./
<_thumper_> ok, I'll add that in
<ddaa> Most of the instructions for Launchpad dev setup should be there
<ddaa> https://launchpad.canonical.com/FrontPage?action=fullsearch&context=180&value=setup&titlesearch=Titles
<ddaa> Ignore "AutoBuildSlaveSetup"
<_thumper_> auth?
<ddaa> cannot tell you here
<ddaa> and actually, I'm looking it up :)
<_thumper_> email?
<SteveA> I'll email it
<_thumper_> ok
<_thumper_> probably one of the most stressful things at the moment is moving my domains
<_thumper_> it is the one that I collect all my mail from
<ddaa> SteveA: seriously, I think warning that https://launchpad.canonical.com/RocketFuelSetup is half out of date is not being negative. It's being informative.
<_thumper_> how badly out of date is it?
<_thumper_> usable?
<SteveA> try going though it
<SteveA> anything that doesn't work, ask here
<_thumper_> ok
<ddaa> Like, do not try to contact James Blackwell, he left the company several months ago
<SteveA> we'll help, and you can update the page as you go
<_thumper_> is there a mailing list I should partake in?
<ddaa> launchpad@lists.canonical.com
<ddaa> primary list for all development discussion, restricted to company members
<ddaa> launchpad-users@lists.canonical.com
<SteveA> you should be on:
<ddaa> public discussion of launchpad
<SteveA> launchpad, launchpad-users, allhands, warthogs
<_thumper_> I've done allhands and warthogs so far
<_thumper_> also got on bazaar-ng some time ago (few weeks)
<_thumper_> and kubuntu-users
<_thumper_> and ubuntu-users I think
<_thumper_> I don't read them all though
<ddaa> hu... your probably do not want to stay on ubuntu-users
<_thumper_> the -users one that is
<_thumper_> something interesting every now an then...
<ddaa> it's very high traffic, and mostly not relevant to launchpad development
<_thumper_> I'm not on it for work purposes :)
<ddaa> sure, but then it's a personal choice :)
<ddaa> eventually, you may want to subscribe to launchpad-bugs, but you'll need to set up quite a few mail filters to keep it useful
<_thumper_> I think I have about 30 filters running already
<ddaa> There is a X-Launchpad-Bug header in all mail sent by the launchpad bug tracking system
<ddaa> that allows you to sort bugspam by product
<_thumper_> handy
<ddaa> so I actually only look at bugspam about launchpad and launcphad-bazaar products
<ddaa> all the rest, the filter marks as "read" and I keep archived just in case
<_thumper_> high volume?
<ddaa> yes
<ddaa> all the launchpad devs and users generate quite a bit of bug activity
<ddaa> need to answer the morning call of nature now, and then phone with mpt about the launchpad 1.0 UI changes for code.launchpad.net pages
<ddaa> back in ~ 1 hour I think
<_thumper_> np
* _thumper_ fetching more coffee
<_thumper_> i'm guessing that allhands and warthogs have to be authorised by someone as I don't have acceptance emails from them yet
<ddaa> yup
<ddaa> these are restricted lists and need moderator approval
<_thumper_> thought as much
<ddaa> BTW, there is a smtp.canonical.com that forwards only emails from canonical.com and ubuntu.com
<ddaa> quite fast and reliable
<_thumper_> could be useful
<ddaa> it actually made people start using their @canonical.com email addresses :)
<ddaa> well, some people were using them before, but I have seen a strong rise in usage since the smtp was put in place
<ddaa> You'll find about it in the allhands archive
<_thumper_> ah, where are those mail archives>
<ddaa> allhands is at https://lists.ubuntu.com/mailman/listinfo/allhands
<ddaa> you'll need your ML password of course to access the archive
<_thumper_> which I don't have yet :)
* ddaa looks for his own
<_thumper_> don't worry, not too bothered yet
<ddaa> how familiar with bzr are you, at the moment?
<_thumper_> not
<_thumper_> been reading the website docs from time to time
<ddaa> okay, so about RocketFuelSetup
<ddaa> some remarks to help you avoid wrong tracks
<_thumper_> got the dependencies installed
<ddaa> * JamesBlackwell not here anymore
<ddaa> * references to chinstrap should be replaced by devpad
<ddaa> * The sample bazaar.conf might be obsolete, in particular "check_signatures=require" used to mean "always sign revisions" (yes, it was a bug)
<ddaa> The stuff about ~/.arch-params is cruft, as it was the baz (GNU Arch) config stuff
<_thumper_> ok
<_thumper_> looks like I need to organise the login to devpad through ssh
<ddaa> mh
<ddaa> Host devpad devpad.canonical.com
<ddaa>     HostName devpad.canonical.com
<ddaa>     ProxyCommand ssh chinstrap.ubuntu.com nc -q0 %h %p
<ddaa> in your ~/.ssh/config
<ddaa> chinstrap is still the ssh proxy for all DC access
<_thumper_> ok
<ddaa> the rocketfuel-get script on that page appears mostly up to date
<ddaa> but I do not use it, since it overrides bzr locking and thus can lead to pain
<ddaa> YMMV here, depending on connectivity and the sort of work your are doing, but here is what I do
<ddaa> I have a mirror of rocketfuel-built in ~/canonical/upstream-launcphad
<ddaa> that I update with a trivial rsync script
<ddaa> manually
<_thumper_> ok
<ddaa> Then I have on bzr repository for each branch in there (that is the launchpad branch, and all the branches in ./sourcecode)
<_thumper_> what technically is rocketfuel?
<ddaa> each repository contains a branch, whose parent is the corresponding branch in rocketfuel-built
<ddaa> so I do "bzr pull" to pull the rocketfuel data into those repos
<ddaa> then when I create a new work branch, I make it as a branch in this repo, and I push with bzr to devpad.
<ddaa> Initially, you will want to prime your bzr repositories locally on devpad
* _thumper_ needs to read up more on bzr
<ddaa> so you do not have to upload all of rockefuel again
<_thumper_> I'm sure all this will make more sense soon 
<ddaa> rocketfuel, technically, is the name of launchpad trunk branch
<ddaa> only PQM can commit to that branch
<_thumper_> PQM?
<ddaa> Painful Quibble Master
<ddaa> hu
<ddaa> Patch Queue Monitor
<_thumper_> ok
<ddaa> That's an email-driven bot that you use to commit to trunk branches in launchpad development
<ddaa> So, you send it a gpg-signed email message (using the bzr pqm-submit plugin)
<ddaa> asking to merge one of your branches into the pqm-managed trunk
<ddaa> it gets a checkout of the trunk, merge from your feature branch found on devpad
<ddaa> bails out if there is any merge conflict
<ddaa> runs the FULL GODDAMN test suite
<ddaa> bails out and if it there is any failure
<ddaa> then commit the merge
<_thumper_> and only authorised people can use the bot?
<ddaa> normally, when it baills out it should send you an email with some log that can be useful for understanding what failed
<ddaa> yes, lifeless (Robert Collins) is the pqm admin, and gives people the right to merge into this or that branch
<ddaa> you should probably start with the right to commit on launchpad and cscvs
<ddaa> you want to look at http://pqm.launchpad.net/ from time to time
<ddaa> to see where your merge requests are in the queue
<ddaa> occasionally, the test suite fails in pqm in a way you cannot easily reproduce locally
* _thumper_ head hurts already
<ddaa> and sometimes, the test suite on pqm just hangs (there are timing bugs that can lead to that)
<_thumper_> hmm, not good
<ddaa> when the latter happens, you need to ask an admin to SIGINT pqm, then you need to figure out what causes the hang, because when this shit starts happening that pretty much puts development to a halt, and that makes everybody very grumpy
<ddaa> luckily, it does not happen that often anymore
<ddaa> but no need to worry about that right now
<ddaa> just remember that the launchpad test suite runtime is about 45mins on pqm
<ddaa> okay, the PQMSetup page is completely obsolete
<ddaa> thanks to the bzr-pqm plugin, that makes things quite simpler
<ddaa> The DatabaseSetup page should be entirely up to date
<ddaa> if you have any problem with that, complain
<_thumper_> sure
<_thumper_> gotta get gpg keys sorted
<ddaa> The SodiumSetup page is mostly not relevant to you (since it's mostly about migrating from chinstrap), but it has an interesting bit at the end about priming up repositories and the location of all trunk branches.
<ddaa> I'll walk you through the pqm-submit things when you first have something to commit, probably next week
<_thumper_> ok
<ddaa> Finding you way around until you have a working local launchpad should keep you busy for a little while. Ask me if you have any question whatsoever.
<_thumper_> for the gpg keys, do you use rsa or other?
<_thumper_> or does it not matter?
<ddaa> whatever the gpg defaults are is considered good enough at any given time
<_thumper_> ok
<ddaa> but you are free to use something stronger if you wish
<ddaa> note that working at canonical can very quickly push your key in the top 2k
<ddaa> because most are quite densely cross-signed, and quite a few canonical folks (or ex-canonical, like lamont) are gpg celebrities.
<SteveA> how's all the setup going?
<SteveA> I wouldn't bother with any of the rocketfuel-get stuff anymore
<_thumper_> ok, don't entirely understand how that works, but I guess I don't have to care yet
<SteveA> things are easy enough and fast enough when you use repositories
<SteveA> and will improve more when we get the smartserver on devpad
<ddaa> SteveA told me he wants to keep an "annoying user" posture towards bzr, so if he tells you that repositories are good enough, you can trust him.
<ddaa> Unlike me, I am an unashamed bzr fanboy.
<_thumper_> I have just used the dapper repositories for launchpad dependancies
<jamesh> _thumper_: https://launchpad.canonical.com/WorkingWithSharedRepositories <- this describes the workflow I use to hack on Launchpad
<jamesh> using a shared repository
<_thumper_> jamesh, thanks
<SteveA> hi james.  happy labour day.
<ddaa> I have been trying to confuse _thumper_ with lots of more-or-less relevant information. I think I did a pretty good job of it :)
<jamesh> SteveA: Queen's Birthday for me, actually
<jamesh> Labour Day in NSW
<jamesh> ddaa: btw, is importd likely to handle the SVN URL I entered here? https://launchpad.net/products/viewvc/trunk
<jamesh> it includes the userinfo needed to connect
<ddaa> jamesh: it does not do anything fancy with urls, just hand them over as is to bzrlib
<ddaa> I guess that URL might work
<jamesh> you mean subversion?
<ddaa> s/bzrlib/libsvn/
<ddaa> ETOOMANYTLAS
<ddaa> jamesh: if you want some quick feedback, I can do a round of imports herding right now
<jamesh> ddaa: if you're busy with other stuff, then I can wait
<ddaa> I've not yet had time to get myself busy today. But I'm looking forwards to diving into cscvs coding ASAP.
<ddaa> So we might actually have a more useful svn import code by the end of the week.
<jamesh> we should have the improved +source form up for the next rollout
<jamesh> I didn't include the removal of the cvsbranch entry yet -- the diff was getting a bit large, so will do that separately
<ddaa> okay that's great
<_thumper_> ok, I'm new to gpg... does any one know how I can keep keys on both laptop and desktop?
<_thumper_> I'm assuming export only exports public bit
<ddaa> rsyncing the ~/.gnupg over works well :)
<ddaa> and that saves going nuts over gpg command line options
<_thumper_> ok
<ddaa> though I guess that gpg zealots will tell you that you should never do that, etc.
<_thumper_> well I'm not a zealot and rsync seems ok over my private lan :)
<ddaa> jamesh: it didn't go through
<ddaa> pysvn._pysvn.ClientError: callback_get_login required
<ddaa> though, I can probably get it to work by manually storing the credentials
<ddaa> handling authenticated svn should probably be a wishlist or low priority bug
<ddaa> though it's rare enough that's it's okay to deal with it manually
<ddaa> more troublesome is handling https, as it currently need manual operation to approve the certificate
<jamesh> ddaa: thanks for checking.  It seems that the tigris.org SVN always requires auth (even if it to auth as the guest user)
<ddaa> jamesh: credentials fixed
<ddaa> _thumper_: got it at last (email about the smtp relay server) https://lists.ubuntu.com/mailman/private/allhands/2006-August/000181.html
<_thumper_> ddaa, thanks, I'll check it out once I'm technically on allhands
* _thumper_ lunch
<_thumper_> from the dapper repositories I have bzr 0.8.2
<_thumper_> is that sufficient?
<_thumper_> I've notices that the bzr release is somewhat later
<_thumper_> jamesh: I'm working through your info on working with shared repositories
<_thumper_> what is needed after the bzr init-repo commands?
<ddaa> _thumper_: you should add the sources.list line I gave before
<ddaa> here I have bzr 0.10
<ddaa> that features some very significant performance improvements
<ddaa> and also helps API issues with plugins
<ddaa> # testing bzr for launchpad devos
<ddaa> deb http://bazaar-vcs.org/releases/debs/scratchy/ ./
<ddaa> once you have done init-repo, you have an empty repository
<ddaa> if you create a branch in it, it will use the repository for history storage
<ddaa> I think branches in a repo do not have a working tree by default too
<ddaa> that helps saving disk space, and speeds up bzr pull for large trees like launchpad
<_thumper_> that deb line didn't show updates :(
<ddaa> _thumper_: how familiar are you with debian-based systems
<_thumper_> s'ok, typo
<_thumper_> so what is the simplest way to get a copy of the trunk source for lp?
<ddaa> so, what you probably want to start with, is to create a repository on sodium for launcphad, and branch rocketfuel in it. Then make a tarball of it and download it to your workstation
<_thumper_> what's sodium? canonical box?
<ddaa> it's devpad
<ddaa> devpad is an alias to sodium
<ddaa> we should use devpad everywhere in config files so the host can be changed quickly if needs arise without breaking configs
<ddaa> the little repository gymnastic will allow you to upload your new launchpad branches with only minimal data transfer.
<_thumper_> still waiting for login and email from canonical guys
<ddaa> mh
<ddaa> _thumper_: -> #canonical-sysadmin
<ddaa> that's the place to harass sysadmins when you really want to
<ddaa> did you file a RT about having an account on devpad?
<ddaa> _thumper_: the simplest way to get launchpad code would be "bzr get sftp://devpad/home/warthogs/archives/rocketfuel/launchpad"
<ddaa> but it's going to take quite a long time, because launchpad is huge
<jamesh> _thumper_: the way a lot of people work is to rsync a copy of the "rocketfuel-built" tree, which includes Launchpad plus a number of its dependencies that we maintain branches of (sqlobject, zope, etc)
<jamesh> then pull from that tree locally
<_thumper_> jamesh, rsync from devpad?
<jamesh> yeah
<_thumper_> sounds strange (from a svn bod)
<jamesh> _thumper_: if I'm maintaining 3 or 4 development branches, it means I only need to pay the network latency once to update each of them
<_thumper_> how much space does the drocketfuel-built take?
<jamesh> 552MB currently
<_thumper_> ddaa, yes RTs submitted
<ddaa> jamesh: I usually make a tarball for the initial transfer. I find it's faster than rsync for priming the state.
<ddaa> then rsync for incremental updates
<jamesh> ddaa: how does a tarball compare with "scp -R"?
<jamesh> or maybe -r
<ddaa> No figure at hand, maybe 1.5x or 2x as fast. But it's probably a matter of latency.
<ddaa> _thumper_: well, until the accounts are sorted, I do not see a whole lot you could do.
<ddaa> maybe just browse through the canonical and launchpad wikis
<_thumper_> ddaa, reading docs
<_thumper_> trying to get my head around how bzr works :)
<ddaa> and do not forget to read wiki.canonical.com/Quotes!
<_thumper_> seen some of that 
<ddaa> _thumper_: feel free to ask stupid questions in #bzr
<_thumper_> ok
<ddaa> it's probably about time for the transatlantic folks to get up by now
<_thumper_> although I think I'll read first so I don't look too stupid
<jamesh> _thumper_: look on the bright side: you could have joined the company while we were still using arch
<_thumper_> jamesh, that was bad was it?
<jamesh> _thumper_: bazaar is a lot nicer.
<jamesh> there are some operations that arch was very slow at (or needed lots of disk and memory to do at reasonable speeds)
<SteveA> arch also had a command line syntax that involved typing -- a lot
<SteveA> so much so that people joked about adding a "--" key to their keyboards
<jamesh> SteveA: look on the bright side: they could have used em dashes
<ddaa> nope, tomlord does not believe in unicode
<SteveA> _thumper_: so, where are you up to with getting set up?
<jamesh> there is so much more punctuation to play with if you use unicode
<jamesh> I would have thought he'd love it
<ddaa> well, he'd love to replace unicode with his own NIH, actually
<_thumper_> SteveA, sysadmins are setting up email and accounts
<SteveA> ok, so you don't currently have access to the code
<_thumper_> I have dependancies and 0.10 bzr on laptop
<_thumper_> no, not yet
<_thumper_> been reading the page from jamesh about shared repositories
<SteveA> ok.  we can sort that out by tarring up rocketfuel-built and putting it in a web-accessible place on devpad
<_thumper_> and reading through database config for lp
<SteveA> I'm making such a tarball now
<SteveA> you'll be able to download it over http, and switch to using sftp later, when you have an account
<_thumper_> ok
<SteveA> 308MB
<SteveA> once you have this, you'll have all the current revisions and history
<SteveA> you can use that set of branches / trees directly
<SteveA> or you can branch from them into your repositories
<SteveA> and set things up as recommended by jamesh
<_thumper_> ddaa, quick question: configuring command line mail command
<ddaa> irrelevant
<SteveA> um
<ddaa> bzr-pqm does it all right for you
<SteveA> it's needed if you're to use pqm
<SteveA> ddaa: how does bzr-pqm send mail?
<_thumper_> just looking the the commands: cat ~/.ssh/id_rsa.pub  | gpg --clearsign | mail address_removed...
<SteveA> so, you'll need to have that set up
<ddaa> bzr-pqm does smtplib
<SteveA> although you won't need it until you want to merge code into pqm yourself
<ddaa> so it does not care the least about your command-line mail, it talks directly to the MTA
<SteveA> I'd rather pqm accepted instruction via POST actually
<_thumper_> and where does smtplib determine the MTA?
<SteveA> at a total guess, I expect pqm-submit uses localhost by default
<SteveA> and maybe has a config option for an alternative
<ddaa> _thumper_: it's a config option of bzr-pqm, it defaults to localhost
<_thumper_> I don't have a local MTA right now
<ddaa> SteveA: score
<SteveA> _thumper_: ever done any twisted programming?
<_thumper_> got the book :)
<SteveA> this need for a local MTA is the source of much woe
<SteveA> I'm tempted to suggest you hack a POST url onto PQM that adds a command to its queue.  But, to do that right so that it would be accepted upstream means talking it through with lifeless I think.
<SteveA> So, I won't suggest that right now.
<ddaa> SteveA: I think bzr-pqm could be easily modified to be able to provide login/passwd to the MTA, so it could use smtp.canonical.com
<SteveA> login + password + email address
<SteveA> that would be nice also
<SteveA> and such a hack should be easily accepted upstream
<SteveA> _thumper_: I like ddaa's suggestion, and it might actually be simpler than getting a local MTA set up properly in a way that will work for submitting pqm requests.
<SteveA> and it also gets you looking at the code to a bzr plugin
<SteveA> which is pertinent to your work
<_thumper_> ah, yeah
<_thumper_> alright
<ddaa> (hint!)
<jamesh> the bzr-pqm plugin can do TLS and SMTP auth
<jamesh> so you could configure it to use the canonical.com SMTP server
<ddaa> mh... mine must be out of date then :/
<jamesh> must be.
<_thumper_> yay
<jamesh> you need to put the smtp_server, smtp_username and smtp_password options in ~/.bazaar/bazaar.conf
<SteveA> _thumper_: so, that error you got, was that from sending it to pqm?
<_thumper_> SteveA, no it was trying to send my ssh pub key to admins
<_thumper_> Couldn't do it from devpad (chinstrap, whatever) as I don't have my gpg stuff there
<SteveA> ah
<_thumper_> so attempting to get postfix working locally
<SteveA> I usually use thunderbird + enigmail for gpg
<_thumper_> shouldn't be too hard
<SteveA> although I used to use mutt a lot
<_thumper_> I use kontact on both laptop and server though
<_thumper_> I'm not a gnome type person
<SteveA> I have postfix set up to do auth smtp to a server I use
<SteveA> so I can send you parts of config files if you need it
<_thumper_> I think the default dapper bits are reasonable, but I'll check
<SteveA> the issues are about what envelope address it's using
<SteveA> because that should be routable if you're to receive bounces
<SteveA> and whether your machine will be trying to send smtp directly, because that is blocked by many isps
<SteveA> or will have the mail marked as spam
<SteveA> depending on exactly what network you're on when you're sending the mail
<ddaa> yeah, smtp.canonical.com is nice to dodge the blacklists at async
<ddaa> async.com.br I mean
<SteveA> the other thing I've done before is set up an ssh tunnel
<SteveA> and sent mail down that
<_thumper_> Hmm, didn't know that many isps blocked smtp
<SteveA> well
<_thumper_> although it makes sense
<SteveA> mostly they don't block it but tunnel it 
<SteveA> through their own smtp servers
<SteveA> but, many of these are blacklisted
<SteveA> by other smtp servers
<SteveA> so it's all a bit crap really
<SteveA> by "tunnel it" I meant "transparently proxy it"
<SteveA> and by "proxy" I mean "murder the original and send it in their own particular way"
<ddaa> and for those who don't, their consumer IP ranges are often blacklisted
<ddaa> mostly because they are rich in zombie systems, I guess
<_thumper_> SteveA, ok, I'll take you up on those postfix config files :)
<SteveA> https://devpad.canonical.com/~stevea/postfix/
<SteveA> there's also a sasl_passwd and sasl_passwd.db
<SteveA> that, unsurprisingly, contain my credentials
<_thumper_> ok, thanks
<_thumper_> I hate mail, why doesn't it just work?
<_thumper_> anyway sent the email from devpad in the end
<_thumper_> so hopefully that should propagate appropriately
<_thumper_> see y'all tomorrow
#launchpad-meeting 2006-10-03
* _thumper_ getting coffee back in 3 min
* _thumper_ back early
<ddaa> Hello
<_thumper_> morning
<ddaa> looks like some of the .au tribe is out
<_thumper_> yeah
<_thumper_> speak of the devil
<mpool> hi
<mpool> welcome!
<ddaa> okay, only lifeless missing can start
<ddaa> MEETING STARTS
<mpool> lifeless is excused, he worked yesterday and said he might miss this
<ddaa> == Agenda ==
<ddaa> Next meeting 2006-10-09, 10:00-10:45 UTC.
<ddaa> SteveA, _thumper_ and ddaa will be on a sprint in London.
<ddaa>  * roll call
<ddaa>  * production status
<ddaa>  * release finder
<ddaa>  * Python import
<ddaa>  * strategic plan
<ddaa>  * bzr-lp features
<ddaa>  * interesting bzr list threads
<ddaa>  * advertising
<ddaa>  * 1.0 targets
<ddaa>  * highlighted bugs
<ddaa>  * any other business
<ddaa> If you wish to change the time of the meeting or add/remove agenda items, say "bzzzt!".
<ddaa> If we are short on time, the "any other business" item will be automatically, dropped. So if you ''want'' to discuss something more, speak up now.
<ddaa> I want to go back working on cscvs, so I plan to finish this meeting on time. No digressions today, please.
<ddaa> == Roll call ==
<ddaa> No excuse was given.
<ddaa> mpool said: mpool: lifeless is excused, he worked yesterday and said he might miss this
<spiv> I'm here.
<mpool> john's arriving early tomorrow so i'd like to keep this short if possible
<ddaa> Anyway lifeless' attendance at this meeting is optional
<mpool> here
<_thumper_> here
<jamesh> here
<SteveA> hi
<ddaa> okay, everybody here
<ddaa> everybody happy with agenda
<ddaa> roll it!
<ddaa> == Prodution status ==
<ddaa> Nothing new to report on production.
<ddaa> Well, importd rollout when okay, with only a couple of band-aid fixes
<ddaa> which mere merged as trivial end of last week
<ddaa> == Product release finder ==
<ddaa>  * jamesh: report on PRF progress.
<SteveA> what was the nature of the band-aid fies?
<jamesh> I've got a branch up for review that fixes the remaining problems that need to be fixed before rollout
<ddaa> SteveA: needed to restore some importd file which is actually imported by buildbot, and needed for what we do
<jamesh> It is in my "jamesh/launchpad/bug-50569" branch, along with some other ProductSeries cleanups
<jamesh> so hopefully we can turn it on after next rollout
<ddaa> SteveA: and needed to tweak a method so the new source tree upload/download system does no cause a failure when the botslave data has been cleared out.
<ddaa> jamesh: ack good... I'm itching to ask who's going to be responsible for this code once it is landed, but I think it would be off-topic for the meeting, so I'm not asking
<ddaa> == Python import ==
<ddaa>  * ddaa: status of Python blocker cscvs bug
<ddaa>  * jamesh: bzr-0.11 fixage for launchpad and cscvs
<jamesh> lifeless was merging this today.
<ddaa> I'm hacking on cscvs like the end of the world is coming, so I can actually have the new logic for svn changeset working by the end of the week
<jamesh> I am not sure how that is going
<lifeless> *is* metging this
<jamesh> lifeless: okay.  So barring any test failures we should have new bzr to play with
<ddaa> lifeless: thank you for the love
<ddaa> action: jamesh fix unexpected test failures ;)
<ddaa> of course, there won't be any
<ddaa> == strategic plan ==
<ddaa>  * mpool owns that agenda item
<jamesh> are you saying they would be expected test failures?
<mpool> ddaa: thanks, i have comments from everyone, not all are integrated yet
<mpool> but it's basically ticked off, you can remove the item
<ddaa> mpool: ack
<ddaa> jamesh: ya trying to cscvsfuse me
<ddaa> == bzr-lp features ==
<ddaa>  * mpool: report on bzr-lp features
<ddaa> what's hot, what's next, what's cold, what's out without love?
<mpool> well let's hear from everyone working on bzr-lp features, *quickly*?
<mpool> jamesh? spiv?
<SteveA> I'm interested in the latest on the smartserver and supermirror application of it
<SteveA> and getting the smartserver running on devpad for launchpad developers to use
<ddaa> SteveA: later this meeting
<spiv> I'm working on smart server over HTTP -- the basic code in bzr has been written.
<SteveA> and whether anything's happening about overlay repositories (sometime later)
<jamesh> I merged the .bzr dir stuff into rocketfuel today, so tomorrow "bzr branch https://staging.launchpad.net/products/bzr" should do something sensible
<spiv> I'm now looking at writing a WSGI application for it, so it can actually be deployed.
<ddaa> moving on
<ddaa> == Interesting bzr list threads ==
<ddaa> Do you guys have keywords for outstanding bzr threads from last week?
<ddaa> I'm hopelessly behind bzr mail again, so pointers would be greatly appreciated
<mpool> ddaa, remind me why this topic is in the meeting?
<SteveA> so, david would like to be able to keep up with bzr goings-on
<SteveA> but has not the time to keep up with the mailing list
<ddaa> it is a suggestion from SteveA to use you guys collectively as a replacement for the not-yet-here bzr community guy and help folks like me who need to stay up to date with the bzr ML but cannot get around to.
<SteveA> various attendees at this meeting do keep up with the mailing list
<SteveA> so, the idea is that david can be given pointers to topics that are pertinent to him that arise
<mpool> nice idea, but it doesn't seem to catch a lot of content
<ddaa> *nod*
<SteveA> does anyone do a bzr traffic kind of thing?
<mpool> not at the moment
<ddaa> Nope
<SteveA> that was james b's job at one time
<mpool> it would be nice, but, again, it takes time
<mpool> rather than doing it on irc i think we should either
<mpool> (A) actually do a traffic summary or
<ddaa> We need a trafficker in the bazaar, we!
<mpool> (B) just forward interesting threads to ddaa or some internal list
<mpool> (B) is cheaper
<SteveA> if something is relevant to david, it's probably relevant to launchpad.  so I'd encourage bzr people to point out such threads on the launchpad list
<SteveA> or even launchpad-users
<SteveA> and get some cross launchpad-bzr interest going
<mpool> OK
<mpool> i like when you've [steve]  done that on related topics in the past
<ddaa> launchpad-users sounds a good idea it first
<mpool> ok, depending on whether it's a user or developer question
<ddaa> until people start complaining, then we can move it to launchpad@
<SteveA> ok, that's an action point for people who read the bzr list
<mpool> lp-users seems mainly concerned with "send me cdsss!!"
<SteveA> who here reads the bzr list?
* spiv puts his hand up
<mpool> me, lifeless, spiv, maybe jamesh?
<spiv> FSVO "read" :)
* _thumper_ gets it and reads some
<SteveA> a current target for the launchpad team is to increase useful traffic on launchpad-users
<mpool> ok, so we all know something about what lp devs need to know 
<mpool> if you see something, forward it
<SteveA> better than forwarding
<jamesh> I read it occasionally.  I certainly don't read all messages
<mpool> SteveA: or to lp if it's something about internals that might affect lp users
<SteveA> send a proper brief mail
<SteveA> with a summary of what it is and why it is important to launchpad
<SteveA> this doesn't take long
<mpool> right, if you do forward at least put on a summary
<mpool> OK, great
<SteveA> and vastly increases the usefulness of the pointer to readers
<mpool> resolved
<ddaa> let's see how it goes next week, moving on
<mpool> let's leave this item on the agenda (new title) as a reminder to get in the habit
<mpool> move on
<SteveA> (particularly to people who subscribe to the launchpad-users list who are not here today)
<ddaa> == Advertising ==
<ddaa>  * spiv: post draft to LP mailing list for comments.
<spiv> D'oh.
<spiv> I haven't done that.  I just re-read it, though, and I think I'll Just Post It(TM).
<spiv> (i.e. to my blog)
<ddaa> as you want, but feel free to ask for review
<lifeless> I dont read all the messages
<lifeless> its a busy list
<ddaa> flascoste gave very useful comments to me in the past
<lifeless> I certainly read all the threads enough to decide to finish the thread or not
<ddaa> moving on
<ddaa> == 1.0 targets ==
<ddaa> supermirror-smart-server: spiv: still looking on track for october 8th? What did you work on recently, what is still todo?
<ddaa> importd-bzr-native: ddaa: progress of Arch removal and dists cleanup. Next: slice out HCT to remove pybaz dependency.
<ddaa> bzr-roundtrip-svn: not for 1.0
<ddaa>  * mpool: read up/tick off svn roundtripping discussion
<ddaa> mpool: since I have no read the ML recently, I have no idea if anything relevent happened recently
<ddaa> spiv: in summary, worked on http transport, next wsgi something to integrate into launchpad?
<mpool> ddaa, sorry, it hasn't got to the top of my list yet
<spiv> ddaa: For anonymous smart serving over HTTP, it looks likely I'll have the code ready or close to, but I'm not sure that I'll be able to get it deployed in that timeframe.
<spiv> ddaa: Right.
<ddaa> spiv: talk with SteveA and/or kiko about getting a delay
<lifeless> ddaa: yeah, the http transport needed a large refactor of the code base, more than expected
<lifeless> but thats over with
<ddaa> nice to hear
<ddaa> kiko said something about telling him about spec that will need some extra time to deliver
<ddaa> so you should get that straightened out with him, I think, please keep me in CC
* ddaa needs to be more precise
<spiv> ddaa: Ok.
<SteveA> and please keep the spec metadata in launchpad up to date
<SteveA> as that is what we use in conf calls with mark
<ddaa> Okay, I think I got my fuzzy
<ddaa> my fuzzy point across
<SteveA>   importd-bzr-transition, supermirror-smart-server,   bzr-roundtrip-svn
<SteveA> on https://features.launchpad.net/products/launchpad-bazaar/
<SteveA> david and andrew, please ensure the metadata is up to date
<ddaa> == Highlighted bugs ==
<ddaa>  * Related to +source
<ddaa>    * bug 2649: CVS branch details should not be editable or displayed. (https://launchpad.net/products/launchpad-bazaar/+bug/2649)
<ddaa>    * bug 46240: posting $series/+source yields a confusing warning (https://launchpad.net/products/launchpad-bazaar/+bug/46240)
<ddaa>    * bug 50569: the product series page does not allow entering source or ftp details for projects without SVN or VCS (https://launchpad.net/products/launchpad-bazaar/+bug/50569)
<ddaa>  * bug: 48813: Efficiently mirroring sftp hosted branches with minimal latency (https://launchpad.net/products/launchpad-bazaar/+bug/48813)
<ddaa>  * bug: 58889: Merged and abandoned branch should not appear in main branch listings (https://launchpad.net/products/launchpad-bazaar/+bug/58889)
<ddaa> Bonus bug: sabdfl asked for the ability to link a spec to a branch.
<spiv> SteveA: Ok.
<ddaa> bug 46240 fixcommitted last week
<ddaa> bug 50569 in-progress by jamesh
<ddaa> along with a ton a refactoring and cleanups for +source
<jamesh> because of the refactoring, bug 2649 should probably wait for my branch to land
<lifeless> ddaa: cscvs failure
<lifeless> ERROR: testCommitWithAutomaticLogFiller (cscvs.tests.test_bzr.TestBzrWorkingTreeCommit)
<lifeless> ERROR: testCommitWithAutomaticLog (cscvs.tests.test_bzr.TestBzrWorkingTreeCommit)
<lifeless> jamesh: ^
<ddaa> *sigh*
<ddaa> context: ^^ that is status of bzr-0.11 landing on rocketfuel
<lifeless> thats with vanilla 0.11, bzrtools removed, lp 0.11 compat branc merged and cscvs compat branch merged
<jamesh> lifeless: weird.  I'll try with 0.11 final
<ddaa> SteveA: I think the sabdfl bonus bug will be a good think to get _thumper_ started on next week
<ddaa> gets to touch all the webapp stack, and not really complicated or risky
<SteveA> ok
<_thumper_> sounds good
<ddaa> Quite unusually, we are ahead of time.
<mpool> keep it up!
<ddaa> == Any other business? ==
<ddaa> So, I'll wait for 10 minutes there ;)
<lifeless> jamesh: details :  
<lifeless> AssertionError: {'converted-by': 'launchpad.net', 'cscvs-id': 'MAIN.1', 'branch-nick': 'bzr_branch'} != {'converted-by': 'launchpad.net', 'cscvs-id': 'MAIN.1'}
<lifeless> AssertionError: {'converted-by': 'launchpad.net', 'cscvs-defaultfiller': '1.1.1.1 1.1 file_name', 'cscvs-id': 'MAIN.1', 'branch-nick': 'bzr_branch'} != {'converted-by': 'launchpad.net', 'cscvs-defaultfiller': '1.1.1.1 1.1 file_name', 'cscvs-id': 'MAIN.1'}
<jamesh> yeah.  I see it
<_thumper_> I did hit two problems with utilities/launchpad-database-setup
<mpool> spiv: jameinel will be at my house tomorrow
<SteveA> so, I asked earlier
<spiv> mpool: Cool.  I'd be happy to join you.
<ddaa> So, I'm done for the meeting.
<ddaa> <insert random rant here about cscvs>
<SteveA> about whether anything will happen about overlay repositories or similar thing
<spiv> Right.
<lifeless> there has been no serious discussion about it on list
<SteveA> I'd also like to know about supermirror/smartserver stuff in more detail than "delayed"
<SteveA> like, delayed by how much
<lifeless> unless its a mark-mandated feature or some such, I'd say its way off. Myself, I'm not convinced its even a feature rather than a trap.
<mpool> lifeless: take it you're refering to overlay repos, not the smart server?
<lifeless> right
<lifeless> :)
<mpool> :-)
<mpool> phew
<ddaa> mpool: thanks for the clarification :)
<SteveA> it feels silly to me to be storing and transporting revisions to the server we use many times more than necessary.  it's a problem I think it important to be fixed for other projects that work as launchpad does, assuming there are/will be any
* ddaa thinks overlay repos sounds like useful
<SteveA> the problem can be fixed in many different ways, I'm sure
<mpool> SteveA: i think the motivation for it is definitely good
<mpool> i think i suggested (or at least thought :-) that you should make a braindump spec
<SteveA> well
<mpool> that will give it at least some lease of life
<SteveA> I can describe the problem
<jamesh> lifeless: weird.  I thought I'd done a complete run of the test suite.  I'm uploading the fix now
<SteveA> but it appears, from lifeless's comments, that I'm not qualified to propose a solution
<mpool> well
<mpool> it's a valid identification of a problem
<ddaa> actually...
<lifeless> this is a wicked problem space
<mpool> i don't think we should run into the design of the solution in this meeting :)
<mpool> but we can talk about it this week with john
<lifeless> we tend to evaluate many proposals before finding a good balance
<ddaa> thinking of it, I think it's close to congruent to the smart server
<lifeless> having a clear statement of the problem is very useful to guide those evaluations
<mpool> ddaa: it's definitely related
<SteveA> mpool: a good description of the problem is on the mailing list
<mpool> SteveA: so i guess you're mainly concerned at this point that it not just be dropped/ignored?
<SteveA> and john did answer the email
<SteveA> do you want me to do something else with it?
<mpool> SteveA: yes, that's what i'm looking at
<ddaa> unless convinced otherwise, I'll believe that SteveA wants a smart server with ACL
<mpool> i read it too
<mpool> no, i'll paste it into the spec tracker
<mpool> ddaa: what does this have to do with acls?
<spiv> ddaa: that's one possible solution, but I don't think it's the only one or necessarily the obviously correctly one.
<ddaa> I mean, access control
<mpool> SteveA:  the thread "Overlay Repositories"?
<ddaa> okay, I'm just talking out of my ass
<mpool> SteveA: is that an ok outcome for you, for hte moment?
<SteveA> more or less I'm concerned with it not being dropped.  I want to start getting people to look at bzr for their VCS system, and issues like this make people feel like something is clumsily designed, even when that's not the case
<SteveA> because it takes an insider to see the design trade-offs or the unfinished work
<SteveA> I'm happy with that outcome.  thanks
<ddaa> Well...
<spiv> SteveA: Also, you wanted to discuss launchpad developers testing the smart server on devpad?
<SteveA> spiv: thanks.  yes, that seemed like a good way to get some testing out of the system.
<spiv> We should get bzr 0.11 installed on devpad.
<ddaa> spiv: yeah, gimme smart server, I give 50 dinars!
<SteveA> mpool: also, did you ask etienne about packaging bzr-pqm ?
<SteveA> or rather, whatever the plugin for pam-submit is called
<mpool> sorry, no
<jamesh> bzr-pqm is the right name
<spiv> (it's possible to get people using it without installing it system-wide, but it'll be unnecessarily complex)
<ddaa> Meeting nominally closed. Please go on.
<SteveA> thanks ddaa, for a swift meeting
<SteveA> spiv: when bzr 0.11 is packaged, we can get it installed on devpad
<spiv> There's a package at http://bazaar-vcs.org/releases/debs/ -- is that sufficiently good?
<SteveA> if it is for dapper, yes
<SteveA> do we also need to get launchpad developers to use 0.11 ?
<SteveA> if so, "scratchy" should be updated
<spiv> The package from there is working on my dapper system.
<spiv> Once 0.11 is installed on devpad, I'll be very happy to mail the launchpad list with details of how to test it and what to expect.
<SteveA> well
<SteveA> we have a way to get launchpad developers to use it
<mpool> SteveA: apparently 'scratchy' split into different directories to accomodate edgy
<SteveA> that is, we put it in that "scratchy" apt repository
<SteveA> I don't want to give launchpad developers a change to their sources.list without good cause
<ddaa> SteveA: I'd love if we could get some traction on branch-notification-email too. It's more complicated, but not terribly so, so maybe we could put that on the sprint too?
<SteveA> and I think the "scratchy" thing should be kept up to date with what we want launchpad developers to be using
<SteveA> ddaa: sure
<ddaa> especially since having you handy to point to the right infrastructure bits needed
<SteveA> ddaa: we'll see how that goes.  I added it to the agenda
<mpool> SteveA: we should probably just make a different repository for lp developers on edgy
<lifeless> I thought scratchy was mant to be empty when the current release was in the distro ?
<ddaa> SteveA: where's the agenda? Here's what I propose: hiding merged/abandoned branthes by default, branch-spec listing, branch-notification email.
<SteveA> mpool: that's fine.  My concern is if we set up a repository, tell launchpad people to use it, and then forget about it
<lifeless> mpool: thats what the subdirs in scratchy are
<SteveA> it needs to be something that is maintained, so that we're not changing people's config
<lifeless> mpool: scratchy-for-edgy, scratchy-for-dapper
<SteveA> and so that we don't roll back versions for people
<lifeless> anyhow, you should go sleep, as I. early morning tomorrow.
<SteveA> ddaa: the draft agenda is in a tomboy note on my laptop.
<ddaa> s/branch-spec listing/branch-spec linking/
<SteveA> ddaa: bring other things with you to the meeting and we'll set a firm agenda as the first thing in london
<mpool> SteveA: would it be too intrusive to get them to update their apt-sources once to the new url?
<jamesh> lifeless: I've fixed the cscvs test failure, so the merge should go through fine next time
* spiv -> dinner
<lifeless> jamesh: I'll try again
<lifeless> jamesh: tomorrow, theres a merge pending
<lifeless> night all
<jamesh> thanks.
<SteveA> mpool: if we have a new URL, I want it to be one that we can put all .debs that launchpad developers need in.
<SteveA> that includes the launchpad-dependencies things, and any other special debs they need
<SteveA> as well as bzr tests
<lifeless> well, thats really something that should be hosted by the support team
<ddaa> jamesh: just to be sure
<lifeless> rather than being on the bzr website TBH
<lifeless> so I propose it be given as a request to Jeff Bailey
<ddaa> you fixed the code not to set the branch-nick, right?
<SteveA> it should be hosted by the sysadmin team
<SteveA> and maintained by the support team
<SteveA> with input from the bzr team about what bzr version goes in there
<SteveA> then used by the launchpad team
<SteveA> team
<mpool> OK
<mpool> i'll send a mail
<mpool> is there any equivalent of x-debbugs-cc for RT?
<SteveA> what does that mean?
<mpool> any way to subscribe you to the ticket
<SteveA> there is in the web interface
<SteveA> I don't know about via email
<SteveA> both the support people and the sysadmins use RT
<SteveA> so they may know
<SteveA> and this is kind of a support question :)
#launchpad-meeting 2008-10-01
<barry> hello everyone and welcome to this week's reviewer's meeting.  who's here today?
<rockstar> me
<EdwinGrubbs> me
<sinzui> me
<salgado> me
<mars> me
<flacoste> me
<bac> me
<jtv> me
<danilos> me
<intellectronica> me
<barry> bigjools: ping
<barry> BjornT: ping
<bigjools> me
<barry> cprov: ping
<bigjools> (sorry)
<barry> gmb: ping
<gmb> ,e
<gmb> me, even
<barry> i think that's everybody in the channel at least
<bigjools> cprov is out to lunch already
<barry> this is probably not a good time for him, eh
<barry> ?
<abentley> me
<bigjools> it usually is but he's gone early for some reason
<barry> np, it's going to be a short meeting anyway, there's almost nothing on the agenda
 * barry has nothing new and fun to discuss
<barry> [TOPIC] action items
<barry> # barry will move the preimp discussion to the ml
<barry> i will definitely get off my ass and finish that email
<barry> # flacoste to take discussion of rest v. moin to ml
<flacoste> hmm
<flacoste> yes
<flacoste> but there was something we wanted to do first
<flacoste> which was build a show case
<rockstar> No mootbot?
<flacoste> iow, convert launchpadlib to use sphinx
<barry> flacoste: correct
<flacoste> so, still needs to be done
<barry> #startmeeting
<MootBot> Meeting started at 09:07. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<flacoste> gary started on it
<barry> flacoste: cool, thanks.
<barry> flacoste: i'll update the action item
<barry> # mars to add links for reviewers to js style guide
<mars> I added a link to the JavaScriptStyleGuide from the reviewer's checklist
<mars> and added some of the links I had lying around as well
<barry> mars: great, thanks
<barry> [TOPIC] queue status
<MootBot> New Topic:  queue status
<barry> does anybody have any comments on the queue?
<barry> either PR or pqm
<barry> [TOPIC] mentoring update
<MootBot> New Topic:  mentoring update
<barry> mars, rockstar, abentley how are things going?  abentley sorry i was away on monday, is there anything for me to mentor?
<mars> barry, going well
<rockstar> Things is going most excellent!
<gmb> barry: mars Endured a really slow Thursday last week, alas.
<mars> eh, I made the best of it :)
<abentley> barry: We managed.  Warning would have been nice.  Nothing to mentor.  Do we have a contingency plan?
<barry> abentley: sorry, i should have added a note and sent an email.  at least i remembered to update the lp calendar ;)
<barry> abentley: contingency is to get another reviewer to mentor for the day, or i can just catch up when i get back
<abentley> barry: No worries.
<barry> abentley: thanks
<barry> mars, rockstar excellent
<barry> thanks to all mentors
<abentley> barry: I got intellectronica and bac to fill in for you.
<barry> abentley: perfect
<abentley> Delaying mentoring of OCRs seemed self-defeating.
<barry> indeed
<barry> well, that's all i have today.  does anybody have anything not on the agenda?
<rockstar> I do
<abentley> barry: I was thinking about code coverage.
<barry> rockstar: the floor is yours, abentley you're next
<rockstar> bac and I noticed that it's rather difficult to test branches that expose the API.
<rockstar> In fact, without getting launchpadlib out and writing our own tests, we just have to take the coder's word for it.
<barry> rockstar: that's not good
<rockstar> That makes me a bit uneasy, since they put my name as the reviewer on submit.
<rockstar> Can me put some thought into how we approach that issue?
<rockstar> It might be a conversation better suited for the ml, but I wanted to raise it in this meeting, in case anyone else had a better solution.
<barry> rockstar: flacoste or leonardr might have some thoughts here
<salgado> my feeling is that, in general, a new test in pagetests/webservice/ is enough for a newly exposed API
<flacoste> i agree
 * leonardr too
<intellectronica> i think that it would be nice if we could have tests that use launchpadlib
<salgado> yeah, nice to have, but not essential
<rockstar> I think it's necessary, since that's how our user's will use it.
<intellectronica> they could also serve as documentation for the use of launchpadlib to access launchpad
<rockstar> blackbox+whitebox
<flacoste> yes, there is no reason why we cannot use launchpadlib in our pagetests now
<barry> doesn't that mean a coordinated landing though?
<flacoste> well, actually there
<BjornT> barry: sorry i'm late, i'm here now
<flacoste> is
<barry> BjornT: np, welcome
<flacoste> we would need a new _Browser that uses the publisher directly
<intellectronica> salgado: there were quite a few cases where we discovered incompatibilities or things that just don't work like you'd expect in user testing
<flacoste> or do we have that already?
<EdwinGrubbs> there are a bunch of tests that already use launchpadlib, but they are not in the pagetests directory
<barry> shouldn't those tests go in launchpadlib doctests though (or as well)?
<bac> intellectronica: yes, i've seen the same.  i've found most people aren't testing using lplib until it lands on staging.
<flacoste> actually, those uses AppServerLayer
<flacoste> which is really slow iirc
<intellectronica> EdwinGrubbs: oh. could you please point us to them?
<intellectronica> ah, ok
<flacoste> intellectronica: they are in launchpadlib
<salgado> intellectronica, the only ones I saw were corner cases of a newly exported method.  these could have been tested in a pagetest
<intellectronica> but it shouldn't be difficult to get _Browser to access zope directly, no?
<EdwinGrubbs> most of the launchpadlib tests are in launchpadlib/docs and there are a few more in c/l/tests/test_launchpadlib.py
<intellectronica> also, doctests written using launchpadlib would read much nicer
<barry> rockstar: can you take this to the ml?  i think it's something we should definitely be doing
<rockstar> Yes sir!
<barry> thanks!
<barry> [ACTION] rockstar to take discussion of adding launchpadlib tests for exposed api to ml
<MootBot> ACTION received:  rockstar to take discussion of adding launchpadlib tests for exposed api to ml
<barry> abentley: the floor is yours
<abentley> I'm just wondering whether we could make it easier to check test coverage?
<abentley> I know there are code coverage tools out there.  Would it be hard to rig them into the test command?
<abentley> The annoying thing is knowing which tests to run, since that's only in the cover letter.
<abentley> So we couldn't do it in make lint.
 * barry thinks there's some plumbing do this already
<barry> but it's not too hard to add it if it isn't
<BjornT> abentley: have you tried the --coverage option to test.py?
<salgado> gmb did something like that
<abentley> barry: I would be happy if this was a documentation issue.
<mars> abentley, ./test.py --coverage might be a good place to start, but I don't know how effective it is.
<salgado> or was it allenap?
<barry> abentley: i'm not sure what you mean
<abentley> barry: I would be happy if the functionality is present already and we just need to advertise it better.
<barry> abentley: gotcha
<cprov> me (late)
<gmb> salgado: That was allenap, I believe, and jsk.
<barry> abentley: maybe you can try playing with --coverage and see if it does what you're looking for.  if so then next week we can talk about how to incorporate that into reviews
<abentley> I would like to tie this into a comparison against trunk, so we can make sure that the code introduced by the branch is all tested, whether or not other code is.
<abentley> barry: Okay, I'll look into it.
<barry> abentley: thanks.  i think code coverage is definitely work measuring and improving
<barry> [ACTINO] abentley to investigate current code coverage tools for lp tests
<abentley> barry: Bad keyboard day?
<barry> [ACTION] abentley to investigate current code coverage tools for lp tests
<MootBot> ACTION received:  abentley to investigate current code coverage tools for lp tests
<barry> abentley: yeah, that's what happens on 4 hours sleep ;)
<barry> abentley, rockstar thanks for those topics
<barry> does anybody have anything else today?
<barry> okay then, we're done.  have a great day
<barry> #endmeeting
<MootBot> Meeting finished at 09:35.
<barry> thanks everyone
<gmb> Cheers barry.
#launchpad-meeting 2008-10-02
<matsubara> #startmeeting
<MootBot> Meeting started at 09:57. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> hmm it seems that my clock is a bit early
<intellectronica> matsubara: isn't it in 1h?
<rockstar> No, 2 min.
<matsubara> 1500 UTC
 * rockstar preemptively me-s
<matsubara> ok, I can wait another 2 min :-)
 * matsubara uses the time to actually fix ntp on this computer
<rockstar> NOW!
<matsubara> ok, thanks rockstar
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<rockstar> :)
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<matsubara> so, who's here today?
<matsubara> Ursinha, Rinchen ?
<Rinchen> matsubara, me and mrevell are here but we're on a call
<Ursinha> me
<Rinchen> we'll be here if you need us
<intellectronica> me
<matsubara> Rinchen: okie
<matsubara> so, bugs and code are here
<matsubara> cprov: ?
<matsubara> herb: ?
<cprov> me
 * mpt waves
<bigjools> me (kinda)
<Ursinha> soyuz is here
<flacoste> me
<matsubara> hi mpt!
<danilos> me
<matsubara> foundations is here
<Ursinha> translations is here
<matsubara> sinzu1: hi
<sinzui> hi
<matsubara> ok, registry is here.
<sinzui> me
<matsubara> flacoste: are you proxying for stub? or stub is here?
<flacoste> stub?
<stub> ?
<flacoste> he' s here :-)
<matsubara> ok, so DBA is here :-)
<Ursinha> cool
<matsubara> we're missing someone from losas then
<matsubara> they can join us later, let's move on
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Next meeting
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs
<matsubara>  * Operations report (mthaddon/herb/spm)
<matsubara>  * DBA report (DBA contact)
<matsubara> [TOPIC] * Next meeting
<MootBot> New Topic:  * Next meeting
<matsubara> so, same time next week?
<herb> me
<danilos> yes
<danilos> :)
<matsubara> hi herb
<matsubara> all right then
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara> no actions from last meeting
<matsubara> [TOPIC] * Oops report & Critical Bugs
<MootBot> New Topic:  * Oops report & Critical Bugs
<matsubara> Ursinha: stage is yours
<Ursinha> bug 276950
<ubottu> Launchpad bug 276950 in soyuz "Timeout accepting more than 6 packages in queue page" [Undecided,New] https://launchpad.net/bugs/276950
<Ursinha> matsubara filed this one yesterday
<Ursinha> right?
<bigjools> BjornT is looking at that right now
<Ursinha> cool
<Ursinha> bug 277129
<ubottu> Launchpad bug 277129 in launchpad-foundations "OOPS when attempting to render a timeout page" [Undecided,New] https://launchpad.net/bugs/277129
<Ursinha> i just filed it, can anybody take a look>
<Ursinha> ?
<Ursinha> flacoste, I just talked with salgado about that
<Ursinha> he's not aware of that, even having one OOPS authenticated as him
<flacoste> and what was his assessment?
<salgado> I don't remember seeing that OOPS
<Ursinha> he never saw that
<Ursinha> anyway, stub said that it's a timeout rendering page problem
<Ursinha> as I wrote on the bug
<salgado> it doesn't look like that to me
<flacoste> hmm, not sure of that looking at the traceback
<Ursinha> it's been happening a few times these days and with different users
<flacoste> we don't have time to look into this week, but we can next week
<Ursinha> flacoste, ok, if you want to give you two cents on what that would be, go ahead
<Ursinha> flacoste, and ok, thanks
<matsubara> [ACTION] foundations to look up bug 277129
<MootBot> ACTION received:  foundations to look up bug 277129
<ubottu> Launchpad bug 277129 in launchpad-foundations "OOPS when attempting to render a timeout page" [High,Triaged] https://launchpad.net/bugs/277129
<Ursinha> the last bug is the critical of translations, bug 273489
<ubottu> Launchpad bug 273489 in rosetta "Remaining Intrepid template approvals" [Critical,Fix committed] https://launchpad.net/bugs/273489
<Ursinha> danilos, when the script finished running?
<danilos> Ursinha: that was a few days ago, we are basically handling the manual stuff right now
<Ursinha> danilos, ok
<danilos> Ursinha: that one might even be 'Fix released' so far, I'll make sure to check with jtv
<Ursinha> danilos, ok, thanks
<Ursinha> matsubara, you can move on
<Ursinha> thanks guys
<matsubara> thanks Ursinha
<matsubara> thanks everyone.
<matsubara> we have another critical bug which is already fix committed
<matsubara> so, I won't bring it up again
<matsubara> [TOPIC] * Operations report (mthaddon/herb/spm)
<MootBot> New Topic:  * Operations report (mthaddon/herb/spm)
<herb> * 2008-09-25: Cherry pick r7080 to the FTP master, updating cron.
<herb> * 2008-09-26: Cherry pick r7087 to the scripts server.
<herb> * 2008-09-29: Cherry pick zope r46 to lpnet*
<herb> * We still have app servers dying periodically. mwhudson provided some additional information to gather when core dumps are found.
<herb> * Codebrowse was unresponse and needed to be restarted a couple of times this week.
<herb> flacoste: have you been able to look through the backtraces?  anything of value there?
<herb> re: app servers dying.
<flacoste> nope
<flacoste> well, nothing that I saw
<herb> ok
<herb> so are we at a dead end?
<flacoste> i was very impressed by the kind of output you can get though
<flacoste> when you know what you are doing
<herb> heh
<flacoste> and i was waiting to have at least another to see a pattern
<herb> ok
<herb> Well that's it from the losas unless there are any questions for us.
<matsubara> ok. thanks herb
<herb> thanks
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> Nothing thrilling happening with the production systems - business as usual.
<stub> DB patch review call with Mark scheduled for tomorrow, although that might not be relevant to this forum now.
<stub> demo.launchpad.net running with a replicated database backend just fine. The updated db maintenance scripts will be landing when the db freeze is lifted on launchpad/devel, so Friday or Monday. devs can run replicated if they want easily - we may want to give thought to making this the default.
<stub> ping?
<matsubara> stub: sounds like a good idea to run it replicated locally. is it going to give a big hit in the performance?
<flacoste> yes
<danilos> stub: we hear you
<flacoste> stub: we discussed rolling out replicated yesterday
<flacoste> we weren't sure it was a good idea
<flacoste> one question came though is do we have to take LP down to set-up the replication?
<stub> I don't think we would want to take the hit running tests against a replicated environment.
<stub> The appservers and systems will only need to be down for a few minutes.
<stub> It will take three hours to build the replica, but that can happen live. The appservers of course shouldn't be making use of the replica as it won't have data on it at that point.
<stub> Once the replica is built, you change the appserver configs and bounce them.
<flacoste> ok, that makes sense
<stub> I should add a master-only flag or something to make that easy, as it will probably be standard rollout procedure.
<flacoste> so it was deemed safer to not roll-out replication to staging next week
<flacoste> well, run staging replicated
<flacoste> and turn it on week-0
<flacoste> if we need the performance boost
<flacoste> we can turn it on in production after sufficient staging QA
<flacoste> iow, we don't need to wait for the roll-out to turn it on in production
<stub> I have some concern about how a replicated staging will affect a replicated production, given staging runs on the same server slated as being the lpmain slave and eventually the authdb master.
<stub> But we can deal with that at the time - I think it is better to run the risk of losing staging for a while than purchase some very expensive hardware just in case.
<stub> The concern being that the staging rebuild process will be going on for 4 hours of every day (if we continue with daily db builds) - that is 4 hours of a single core being hammered. I don't think we will really know how that impacts things in reality until we try it though.
<stub> Sorry - 4.5 hours every day ;)
<danilos> stub: so it means chokecherry will serve as the main readonly slave as well?
<danilos> (once it all goes up, of course)
<matsubara> there are proposals to change staging db update to once a week
<stub> Yes. We only have two servers with suitable hardware - hackberry (current db server) and chokecherry.
<danilos> ok, thanks for clarifying stub
<stub> It also impacts our disaster recovery - instead of having a hot spare, we need scale back to a single server if one explodes.
<stub> So we need to watch our load - at some point we will have too much load to run on a single box and we need to think about DR before then.
<matsubara> DR?
<stub> disaster recovery
<rockstar> Disaster Recovery
<matsubara> ok
<matsubara> i'll add that to the disaster scenarios page, if that's still up to date
<matsubara> anything else stub?
<stub> nah - I'm just rambling.
<matsubara> thanks for bringing up your concerns
<matsubara> I have one last thing to ask you all before closing the meeting
<matsubara> I've noticed that the number of "New" bugs are climbing, so please, keep an eye on the daily triage backlog. Ursinha and I can help each team, but you need to approach us.
<matsubara> please QA contacts, pass that on to your TLs
<matsubara> so I think that's all
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:31.
<Ursinha> thanks matsubara
<rockstar> Thanks matsubara
#launchpad-meeting 2009-09-30
<barry> #startmeeting
<MootBot> Meeting started at 09:00. The chair is barry.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<barry> hello everybody and welcome to this week's ameu reviewers meeting.  who's here today?
<jtv> me
<gmb> me
<noodles775> me
<bac> me
<henninge> me
<jtv> hi barry!
<barry> jtv: hi!
<cprov> me
<barry> i know a number of folks are at the tl meeting and won't be joining us
<adeuring> me
<intellectronica> me
<barry> abentley leonardr EdwinGrubbs ping
<abentley> me
<leonardr> me
<barry> allenap: ping?
<allenap> me
<allenap> Sorry.
<barry> it's a light day today so this might go quickly
<barry> [TOPIC] agenda
<MootBot> New Topic:  agenda
<barry> == Agenda ==
<barry>  
<barry>  * Roll call
<barry>  * Action items
<barry>  * UI review call update
<barry>  * Peanut gallery (anything not on the agenda)
<barry>  
<barry>  
<barry> [TOPIC] action items
<MootBot> New Topic:  action items
<barry>  * gary_poster and barry will transfer review guidelines from the old wiki and old old wiki to the new wiki
<barry> not done, though i will try to get with gary to work on this now that 3.0 is out
<barry>  * cprov to update guidelines to clarify how code sensitive to env changes should be written
<cprov> jeez, I haven't done that.
<barry> cprov: still up for it?
<cprov> barry: I have to, right ? :)
<cprov> I will do that right now.
<noodles775> (cprov's last day today ;) ).
<intellectronica> oh wow
<barry> cprov: !  ;(
<barry> cprov: you're not allowed to leave
<intellectronica> ... until you update the wiki ;)
<barry> :D
<cprov> aha
<barry> cprov: good luck man and stay in touch!
<intellectronica> cprov: what barry said
<EdwinGrubbs> me
<cprov> barry: thank you, I will be around.
<barry> cprov: and thanks for updating the wiki
<barry> [TOPIC] ui review call update
<MootBot> New Topic:  ui review call update
<barry> intellectronica: was there a call this week?  i was out
<intellectronica> there was no ui call
<barry> [TOPIC] peanut gallery
<MootBot> New Topic:  peanut gallery
<barry> that's all i have today then.  anything from y'all?
<jtv> deafening silence
<barry> 5...4...3...2...1
<barry> we're done.  enjoy week 0 everybody
<barry> #endmeeting
<MootBot> Meeting finished at 09:09.
<abentley> barry: thanks!
<jtv> thanks!
<barry> record time!
<intellectronica> thanks barry, record time!
#launchpad-meeting 2009-10-01
<matsubara> #startmeeting
<MootBot> Meeting started at 10:00. The chair is matsubara.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<matsubara> Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues.
<matsubara> [TOPIC] Roll Call
<MootBot> New Topic:  Roll Call
<stub> me
<matsubara> Not on the Launchpad Dev team? Welcome! Come "me" with the rest of us!
<mbarnett> me
<Chex> me
<henninge> me
<Ursinha> me
<matsubara> rockstar, allenap: hi
<allenap> me
<matsubara> noodles775, hi, can you stand in for bigjools ?
<Ursinha> allenap, are you here in behalf of bugs team?
<noodles775> matsubara: yep.
<matsubara> Ursinha, allenap is the new QA contact
<allenap> Ursinha: Yes.
<Ursinha> cool
<Ursinha> thanks
<matsubara> thanks noodles775
<matsubara> we're misssing someone from code and registry. let's move on and they can join in later
<matsubara> [TOPIC] Agenda
<MootBot> New Topic:  Agenda
<matsubara>  * Actions from last meeting
<matsubara>  * Oops report & Critical Bugs & Broken scripts
<matsubara>  * Operations report (mthaddon/Chex/spm/mbarnett)
<matsubara>  * DBA report (stub)
<matsubara>  * Proposed items
<matsubara> [TOPIC] * Actions from last meeting
<MootBot> New Topic:  * Actions from last meeting
<matsubara>     * barry to continue debug on bug 403606 after finishing 3.0 UI stuff
<matsubara>     * matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
<matsubara>     * matsubara to update translations qa contact on meeting agenda page
<matsubara>         * done
<matsubara>     * matsubara to generate new oops summary including oopses only for after the rollout
<matsubara>         * done
<ubottu> Launchpad bug 403606 in launchpad-registry "ExpatError errors should be handled to not generate the OOPSes" [High,In progress] https://launchpad.net/bugs/403606
<matsubara> I still haven't trawled those logs. :-(
<matsubara> [action] * matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
<MootBot> ACTION received:  * matsubara to trawl logs related to high load on edge yesterday and ping Chex about it
<matsubara> and I know that barry is working on more debugging for 403606. some code was cowboyed yesterday in the production server to help with this debugging
<matsubara> so I won't re-add that action item
<matsubara> [TOPIC] * Oops report & Critical Bugs & Broken scripts
<MootBot> New Topic:  * Oops report & Critical Bugs & Broken scripts
<Ursinha> me me
<matsubara> go ahead
<Ursinha> two bugs
<Ursinha> allenap, bug 438985, it's happening quite frequently, do you think it's going to be fixed soon?
<ubottu> Launchpad bug 438985 in malone "Trying to make myself as bug supervisor of my project oopses" [High,Triaged] https://launchpad.net/bugs/438985
<Ursinha> matsubara, who's here for foundations
<Ursinha> ?
<matsubara> I am
<matsubara> what's up?
<Ursinha> :D
<Ursinha> since last meeting we're having a lot of DisconnectionErrors, about 200 a day
<Ursinha> I'd suggest bug 436640 to be fixed and cherrypicked, so we could understand what's happening
<ubottu> Launchpad bug 436640 in launchpad-foundations "Add more info to DisconnectionErrors" [Undecided,New] https://launchpad.net/bugs/436640
<Ursinha> is that hard to accomplish? What do you think?
<allenap> Ursinha: I'll see if we can have a go at it this week.
<Ursinha> matsubara, also, could you triage that
<Ursinha> ?
<Ursinha> pleasse
<Ursinha> please
<Ursinha> thanks allenap
<matsubara> Ursinha, gary was working on it last I heard. I'll ask him once he comes back from the TL meeting
<matsubara> and yes, I'll have it triaged and raise the importance
<Ursinha> matsubara, triaged or in progress?
<matsubara> triaged, I don't know if gary started the patch yet. no point in having a in progress bug without assignee :-)
<matsubara> [action] matsubara to talk to gary about bug 436640
<MootBot> ACTION received:  matsubara to talk to gary about bug 436640
<ubottu> Launchpad bug 436640 in launchpad-foundations "Add more info to DisconnectionErrors" [Undecided,New] https://launchpad.net/bugs/436640
<Ursinha> matsubara, ok, I thought he was actually working on that
<Ursinha> matsubara, thanks
<Ursinha> we have one critical bug, bug 438039, and henninge is already working on it, so ok
<ubottu> Launchpad bug 438039 in rosetta "bzr branch import script oopses sometimes" [Critical,In progress] https://launchpad.net/bugs/438039
<Ursinha> about failing scripts, I'd need rockstar here
<Ursinha> rockstar, what's happening with update_review_diffs?
<matsubara> Ursinha, he showed me some example code to add more info, but I'm not sure if he started it or not. I'll confirm with him before making any changes
<henninge> Ursinha: that has been cherry picked, actually.
 * henninge goes to check if the oopses still occur
<Ursinha> henninge, even better :) can you set the bug status properly, please?
<henninge> Ursinha: just done that
<matsubara> Ursinha, please follow up with rockstar about that script after the meeting.
<Ursinha> matsubara, ok, can you add an action item, please?
<Ursinha> thanks henninge :)
<matsubara> [action] Ursinha to talk to rockstar about failing update_preview_diffs script
<MootBot> ACTION received:  Ursinha to talk to rockstar about failing update_preview_diffs script
<Ursinha> thanks :)
<Ursinha> thanks guys
<Ursinha> matsubara, stage is yours again
<matsubara> [action] allenap to talk to Bugs team about bug 438985 and have it fixed.
<MootBot> ACTION received:  allenap to talk to Bugs team about bug 438985 and have it fixed.
<ubottu> Launchpad bug 438985 in malone "Trying to make myself as bug supervisor of my project oopses" [High,Triaged] https://launchpad.net/bugs/438985
<matsubara> thanks Ursinha and everyone
<matsubara> [TOPIC] * Operations report (mthaddon/Chex/spm/mbarnett)
<henninge> Ursinha: oopses are still there ... :( Back to 'in progress'
<MootBot> New Topic:  * Operations report (mthaddon/Chex/spm/mbarnett)
<Chex> hello everyone, here is the report for this week
<Chex>  Automated LP Cherry Picks: We've migrated to hosting the production LP
<Chex> branches on LP itself and are using PQM to manage production-devel. LP
<Chex> developers can now submit their own Cherry Picks making the deploy of updates
<Chex> easier.
<Chex> - Super-Mirror puller stability: We have setup a nagios check to watch this
<Chex> service, and it has been more stable recently.
<Chex> anyone have any questions??
<matsubara> henninge, when was the fix CP'ed? could it be that those oopses happened before the CP?
<noodles775> Chex: yeah, do we just simply pqm-submit targeting production-devel (after getting permission of course)? or is there some documentation?
<noodles775> That sounds great!
<matsubara> indeed
<henninge> matsubara: matsubara unfortunately no, there are some dated today ...
<matsubara> henninge, :-(
<Chex> noodles775: I believe you can just do that pqm-submit , but I would need to check to be sure on that..
<noodles775> Chex: k, thanks!
<matsubara> Chex, could you email the list with your findings and perhaps a link to a wiki page explaining the process?
<Chex> matsubara: yes sure, I will do that.
<matsubara> [action] Chex to email the list about the automated LP cherry pick process
<MootBot> ACTION received:  Chex to email the list about the automated LP cherry pick process
<matsubara> thanks a lot Chex
<matsubara> moving on
<matsubara> [TOPIC] * DBA report (stub)
<MootBot> New Topic:  * DBA report (stub)
<stub> It looks like we will be moving the master server for the auth replication set to new hardware as part of the continuing migration of the authentication service to the ISD team. Not sure of schedules yet. There will likely need to be a few minutes downtime while we switch masters.
<stub> Load on the databases actually seems a bit lighter with Launchpad 3.0 which is good. No real metrics so this just might be wishful thinking, but I suspect less random statistics scattered around the page and fewer large document reloads due to ajax is helping.
<stub> Nothing else interesting happening.
<matsubara> thanks stub
<matsubara> [TOPIC] * Proposed items
<MootBot> New Topic:  * Proposed items
<matsubara> no new proposed items
<matsubara> anything else before I close?
<matsubara> 4
<matsubara> 3
<matsubara> 2
<matsubara> 1
<matsubara> Thank you all for attending this week's Launchpad Production Meeting. See https://dev.launchpad.net/MeetingAgenda for the logs.
<matsubara> #endmeeting
<MootBot> Meeting finished at 10:24.
<Ursinha> thanks everyone
<mthaddon> noodles775: you need to get permission as you normally would, and then you can submit to PQM
<mthaddon> (as you normally would for a cherry pick request, that is)
<noodles775> mthaddon: great... using --submit-branch etc. Thanks!
<mthaddon> yep
#launchpad-meeting 2010-10-06
<bac> #startmeeting
<MootBot> Meeting started at 09:00. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
 * bigjools is here
<bac> who is here?
<mars> me
<wgrant> me
<bigjools> ha, I read your mind!
<noodles775> me
<henninge> me
<sinzui> me
<mars> bac, gary-dentist sends his apologies
<jelmer> me
<abentley> me
<bac> mars: i was assuming that would be the case
<bac> and deryck as well
<bac> EdwinGrubbs, danilos, gmb: pings
<danilos> me
<bac> flacoste: ping
<EdwinGrubbs> me
<flacoste> me
<bac> allenap: yo
 * bac thought the mass invite was such a good idea...
<bac> [topic] agenda
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * Mentat update.
<bac>    * salgado (ui)
<MootBot> New Topic:  agenda
<bac>    * henninge (ui)
<bac>    * stevenk (code)
<bac>  * New topics
<bac>   * Nice Storm gotcha (bigjools)
<bac>   * canonical.launchpad is still deprecated, sinzui (AsiaPac meeting only)
<bac>   * [[http://paste.ubuntu.com/507156/|Truth conditionals and the new "all" and "any" functions]], henninge
<adeuring> me
<allenap> me
 * sinzui read that as "sinzui is deprecated" At least he is not obsolete
<bac> salgado: ping
<bac> [topic] mentoring update
<MootBot> New Topic:  mentoring update
<salgado> me!
<sinzui> we are getting lots of UI reviews
<sinzui> I do mean a lot, more than last month
<sinzui> well, more than aug and jul
<salgado> some weeks I get more, others I get less
<henninge> I enjoy them but please try to provide screenshots ...
<henninge> ... or even screencasts, like noodles775 does ;-)
<salgado> yeah, screen[shots,casts] help a lot for small changes
<salgado> but when they're not trivial I like to exercise them manually to test for corner cases and all that
<henninge> true. Did not have any of those yet, though ... ;)
<noodles775> Yeah, I think it's nearly always worth exercising manually - I just provide the screencasts to demo and get the context.
<salgado> it's also nice when devs add demo data (aka dev sample data) that makes it easy to exercise the changes
<bac> sorry about that, my internet died
<bac> what did i miss?
<sinzui> Paris is in flames
<salgado> bac, http://paste.ubuntu.com/507276/
<bigjools> how did they do that when they're on strike?
<danilos> salgado, +1 for adding dev sampledata! I want to see much more of it
<bac> noodles775: can you provide a link to one of your screencasts?  i've never seen one
<noodles775> bac: https://code.edge.launchpad.net/~michael.nelson/launchpad/652838-select-diffs-for-syncing/+merge/37572
<bac> noodles775: thanks
<noodles775> (the mp has the screencast as well as a script for sample data setup).
<bac> [topic] new topics
<MootBot> New Topic:  new topics
<bac> [topic] Nice Storm gotcha (bigjools)
<MootBot> New Topic:  Nice Storm gotcha (bigjools)
<wgrant> :(
<bigjools> heh
<bigjools> I'd like to point you all to revision 11670 of devel
<bigjools> notice the change - a storm expression was using Python's "in" instead of Storm's is_in
<bigjools> this has been quite catastrophic for soyuz
<bigjools> because the former was evaluating to True all the time
<danilos> :(
<sinzui> yuck
<bigjools> so this is just a warning to not fuck up quite as spectacularly
<wgrant> You'd think it would fail to False, but nooo.
<bigjools> I'm wondering if we can get it lint checked?
<sinzui> it's in a string, and pyflakes/pep8 ignore string content
<wgrant> It's not in a string.
<bigjools> or perhaps make Storm DTRT
<wgrant> I'm not sure that Storm can be fixed.
<bac> bigjools: is there a storm bug?
<sinzui> but I think I can write a regexp that locates problems like this
<wgrant> It's probably just seeing that __eq__ returns something that isn't False.
<bigjools> bac: I don't know if it can be a bug or not
<bac> bigjools: i mean, have we filed a bug or discussed with the stormers
<bigjools> bac: not yet, I'm still in the middle of cleaning up the mess
<bac> right
<bigjools> when things are calmer I can do that
<bigjools> anyway, that's it from me
<bac> sinzui: are you going to take a look to see if lint can catch it?  can i assign you an item?
<sinzui> I am
<bac> [action] sinzui to try to fix lint wrt storm gotcha
<MootBot> ACTION received:  sinzui to try to fix lint wrt storm gotcha
<bigjools> it would be inside a .find() of course
<bac> [topic] * [[http://paste.ubuntu.com/507156/|Truth conditionals and the new "all" and "any" functions]], henninge
<MootBot> New Topic:  * [[http://paste.ubuntu.com/507156/|Truth conditionals and the new "all" and "any" functions]], henninge
<henninge> everybody please read the paste ;-)
<henninge> http://paste.ubuntu.com/507156/
<bac> here's the link again http://paste.ubuntu.com/507156
<MootBot> LINK received:  http://paste.ubuntu.com/507156/
<allenap> bigjools, sinzui: Storm should probably not compile a raw True. It's a smell that something is wrong.
 * sinzui has used if val not in (None, '')
<allenap> henninge: any() and all() can consume generator expressions.
<henninge> yes, any iterable
<allenap> any(translation is not None and translation != "" for translation in translations)
<henninge> yeah, ok ...
<henninge> ;-)
<bigjools> allenap: yes, good point
<henninge> although is that not a 2.6ism with out the [] ?
<allenap> henninge: I was against the explicit truthiness testing originally, but if we're having it then I feel we should stick to it.
<allenap> No, it worked on 2.5 I think.
<bigjools> FWIW jelmer and I found a bug in Soyuz code earlier where it was using "if thing:"
<bigjools> instead of something more explicit
<abentley> allenap, but also: len([translation is not None and translation != "" for translation in translations]) != 0
<allenap> And, fwiw, I'm on-board with explicit conditionals now.
<henninge> ok, I had not thought of allenap's solution,
<henninge> that would work well for me, too.
<henninge> No softening the policy, then?
<allenap> abentley: That's cool, but I think any() and all() do add to readability, and they can shortcut too.
<bac> henninge: sounds like there is not much support
<danilos> I kind of feel like we should losen it
<bigjools> I think they are dangerous
<danilos> any() sounds quite to the point to me (i.e. it's not exactly like "if something" vs "if something is None", where being explicit does add value; with any() you are being explicit to a point)
<henninge> danilos: but it *is* doing "if something" internally and you cannot do anything about it.
<danilos> henninge, right, that's why I agree we should see what everybody feels about it :)
<henninge> ;-)
<sinzui> I see any as explicit. It looks like it is removing redundancy from the code
<abentley> allenap: I'm okay with the semantics of your revised version, but I don't agree it's more readable.  It's one more thing to remember how it works.
<henninge> abentley: I find the word "any" quite obvious ...
<allenap> danilos: henninge's example could be split into two lines to enhance readability: valid_translations = (t is not None and t != "" for t in translations); if any(valid_translations): ...
<noodles775> +1 for allenap's suggestion.
<bac> allenap: but at that point you could just see if you have an empty list, no?
<allenap> It's a builtin too; no hiding from it.
<abentley> henninge: not me.  Does it mean "length > 1" or does it mean "anything in this iterable is true"?
<allenap> bac: The generator expression combined with any() means you can shortcut as soon as a translation is available.
<henninge> abentley: well, the latter.
<allenap> If translations is expensive to iterate over then it could make a difference.
<abentley> henninge: That's not the most obvious meaning to me, but with storm, "any" has yet another meaning.
<danilos> I don't think we need a solution to replace bare "any()" use in this meeting, we should just decide whether we want to stop basic usage as non-explicit
<allenap> abentley: Yeah, that's unfortunate.
<danilos> allenap, it is not, it's a list of at most 6 items
<allenap> danilos: Here, okay, but in general it might be useful to shortcut evaluation.
<allenap> danilos: Which is what the for loop does.
<danilos> allenap, right, but as I said, I am not interested in valid use cases of any(), but rather, invalid, in terms of our "be-explicit" policy :)
<allenap> Anyway, I thought this was just about being explicit in conditionals? I think we should be explicit everywhere, including in any() and all().
<danilos> allenap, yeah, but not many people have an opinion on any() in particular
<henninge> allenap: right, that was my questions and that is an answer ... ;)
<henninge> danilos: no opinion, no change ...
<danilos> henninge, that's right, let's move on bac :)
<bac> henninge: right.  would you still update the page to include the summary?
<henninge> bac: I am done. I will add a comment to the style guide to suggest allenaps code.
<bac> thanks
<henninge> :)
<bac> [topic] anything else?
<MootBot> New Topic:  anything else?
<bac> no?
<bac> #endmeeting
<MootBot> Meeting finished at 09:36.
<bac> thanks for coming
<henninge> thanks bac!
<bigjools> cheers bac
#launchpad-meeting 2010-10-07
<bac> thumper, rockstar, stub, mwhudson, stevek, lifeless -- Reviewer Meeting in a few minutes
<mwhudson> hi bac
<bac> hi mwhudson
<mwhudson> bac: how is asia treating you?
<bac> mwhudson: good.  having fun.  eating well.  not ill.
<mwhudson> bac: all good
<bac> #startmeeting
<MootBot> Meeting started at 19:01. The chair is bac.
<MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
<bac> good morning...who is here?
<bac> me
<mwhudson> me
<mwhudson> thumper won't be here
<wgrant> me
 * wallyworld here
<bac> [topic] agenda
<MootBot> New Topic:  agenda
<bac> * Roll call
<bac>  * Agenda
<bac>  * Outstanding actions
<bac>  * Mentat update.
<bac>    * salgado (ui)
<bac>    * henninge (ui)
<bac>    * stevenk (code)
<bac>  * New topics
<bac>   * Nice Storm gotcha (bigjools)
<bac>   * canonical.launchpad is still deprecated, sinzui (AsiaPac meeting only)
<bac>   * [[http://paste.ubuntu.com/507156/|Truth conditionals and the new "all" and "any" functions]], henninge
<bac> [topic] mentoring update
<MootBot> New Topic:  mentoring update
<bac> it may be news to you here that henninge and salgado are UI mentats.  they are doing really well.  please send your UI reviews to them first, if you can spare the extra time mentoring entails.
<bac> i've been using them both lately and getting really good feedback from them.
<bac> also, sinzui reports the number of UI reviews overall has gone up quite a bit in the last two months, which is great.
<bac> there are no UI reviewers in this timezone.  do you normally just throw it at rockstar?
<bac> since stevenk and thumper are both absent we won't get a report out out of them...
<mwhudson> i haven't had a ui review to do in aaaaages
<bac> [topic] Nice Storm gotcha (bigjools)
<MootBot> New Topic:  Nice Storm gotcha (bigjools)
<mwhudson> is this the one that wgrant knows all about?
<bac> wgrant do you want to discuss this issue?
<wgrant> Indeed.
 * wgrant finds the rev.
<bac> wgrant: did you discover it or just fix it?
<wgrant> I broke, discovered, and fixed it.
<wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/bug-653382-domination-series-restriction/+merge/37333
<bac> the trifecta
<wgrant> Saying "SomeClass.column in (some list of values)" will always evaluate to True.
<wgrant> This can be... dangerous.
<wgrant> So please watch for it.
<wgrant> Probably a Storm bug, but also probably not fixable.
<wallyworld> all bugs are fixable, no?
<bac> wgrant: do you have any sense of why it is evaluating to True?  makes no sense on the surface
<lifeless> hi
<bac> hi lifeless
<lifeless> sorry for tardiness
<wgrant> bac: Storm columns have an __eq__ which returns an Expr.
<wgrant> An Expr is not False.
<wgrant> I suspect this is the problem.
<lifeless> whats the exact code in question?
<mwhudson> oh right, you can't override what the list does for __contains__
<wgrant> mwhudson: You can override from the other end.
<bac> wgrant: and the work-around is to use is_in
<wgrant> bac: Right.
<wgrant> And it non-intuitively fails in the wrong direction.
<mwhudson> lifeless: https://code.edge.launchpad.net/~wgrant/launchpad/bug-653382-domination-series-restriction/+merge/37333
<lifeless> right
<lifeless> theres a broader issue
<lifeless> storms syntax often looks right but is wrong
<lifeless> for instance Class.column == otherclass.column
<lifeless> is nearly always wrong.
<wgrant> Is it?
<lifeless> yes, because one or both are Reference objects
<lifeless> not Int objects
<wgrant> Oh, right, yeah.
<lifeless> the right spelling, with SQLBase is Class.columnID == otherclass.columnID
<wgrant> But that at least generates an error.
<lifeless> wgrant: not always, for entertainment value.
<lifeless> (or Class.columnID == otherclass.column, or vice versa)
<wgrant> That has always irked me, and it seems like it should be fixable.
<wgrant> Have we talked to Stormers about it?
<lifeless> comment on the bug I filed
<bac> regarding the first problem with 'in', sinzui has volunteered to see if he can create a matching regex to throw into lint to catch them.
<lifeless> that would be nice, *if* when that is found, we always write a test (because it implies missing test coverage)
<bac> returning a bit to UI reviews, henninge mentioned that a lot of people are including screenshots, which are great.  he also said noodles has created some screencasts which have been helpful.  an example is at https://code.edge.launchpad.net/~michael.nelson/launchpad/652838-select-diffs-for-syncing/+merge/37572
<bac> given my mad video skillz, i could see this easily taking me twice as long as writing the patch so i doubt i'll try it
<bac> [topic]  canonical.launchpad is still deprecated, sinzui (AsiaPac meeting only)
<MootBot> New Topic:   canonical.launchpad is still deprecated, sinzui (AsiaPac meeting only)
<bac> this topic was from last week in the AmEu meeting.
<bac> apologies for me having to late cancel the meeting here last week.
<bac> sinzui was disturbed to see some people adding to the code in canonical.launchpad
<bac> reviewers should look out for that
<lifeless> Thats quite likely me, and I'll happily defend doing that if needed.
<lifeless> moving stuff around doesn't fix bugs or improve performance
<lifeless> it doesn't help our users
<lifeless> it *may* make things easier to maintain.
<lifeless> Not moving things around doesn't increase the cost of maintenance, avoids conflicts with db-stable and focuses on getting things done.
<bac> lifeless: it is deprecated and the agreed goal is to evacuate it.
<lifeless> right
<lifeless> but thats separate to fixing specific bugs or issues.
<bac> i don't think the issue is with making short-term fixes there but trying to avoid growing a lot of new code
<bac> with the recognition that it is sometimes very tangled and hard to extract
<lifeless> As PEP8 says, fitting in with an existing structure is often better than being pure but inconsistent.
<lifeless> I *have* extracted things from there when it made sense.
<bac> the appeal was for reviewers to keep their eyes open for it and expect a solid argument for why it makes sense.
<lifeless> So I think this adds friction to no benefit
<lifeless> I don't think reviews should be worrying about trivia like this, its not a good use of the reviewer or reviewees time.
<lifeless> sure, mention it - 'are you aware we're trying to kill that namespace'
<lifeless> but that should be the limit, IMNSHO.
<mwhudson> i'm not sure that the proposal was for anything more than that
<lifeless> mwhudson: 'solid argument' sounds considerably more.
<lifeless> I would be very sad to see someone double or triple the time to make a change, because a reviewer wouldn't approve the branch unless they moved the code
<bac> lifeless: well, if i was given a flimsy argument to that question i think i'd be concerned
<lifeless> why?
<mwhudson> there is a more general discussion here along the lines of 'how do we make sure changes to our coding standard actually happen'\
<mwhudson> lifeless: it sounds like you're very opposed to using reviews for this
<bac> in my mind it would me the developer hadn't thought it through.
<lifeless> mwhudson: yes, I am. I don't think coding standards do much for our code.
<bac> if it were a non-crititical patch in week one and the developer didn't have a good reason, then i'd say it is entirely appropriate to ask them to not add new code there
<mwhudson> that sounds like a topic for the mailing list :)
<lifeless> mwhudson: I'm also concerned because I'm not seeing my architectural stuff, which is endemic in the code base, getting airplay.
<lifeless> mwhudson: I've been letting the hindbrain think about this for a while; yes its probably time to start discussing, I think I broadly know what I want to say now.
<lifeless> bac: I think requiring them to have a good reason suggests a stop-energy workflow and heavy rather than light touch process.
<mwhudson> lifeless: in some sense any change that happens as a result review is too late
<lifeless> bac: driving iteration time down means doing less each time, but taking more bites at it.
<mwhudson> lifeless: even more so for architectural stuff, if you want a check on that, i think it needs to come earlier
<lifeless> bac: combining tasks because both need to be done, and both happen to be in the same region of code, reverses the stuff needed to drive iteration time down.
<lifeless> bac: and there is broad agreement that small chunks are easier to review (both to assess fo rlanding, and simply to keep up with whats changing in the code base); so conflating the long term effort with short term stuff seems purely counterproductive to me.
<mwhudson> $ python -c 'import this' | grep -i now
<mwhudson> Now is better than never.
<mwhudson> Although never is often better than *right* now.
<bac> lifeless: i guess it depends on the scope.
<lifeless> mwhudson: Yes, by the time someone has added a function to a class rather than adding a class; its rather late. OTOH asking 'does this scale well... how do you know' is different to asking 'how should we do this to scale well'.
<lifeless> mwhudson: and both questions are needed.
<lifeless> (arguably)
<wallyworld> my take is that the bigger picture architectural stuff should be discussed pre-implementation, FWIW
<wallyworld> since by the code review stage, it's too late, as i think lifeless said
<mwhudson> lifeless: yes, that's likely true
<lifeless> wallyworld: I would love to see folk discussing the details of their goals on the list before doing stuff, OTOH a blocking process isn't very in-the-zone-friendly.
<lifeless> wallyworld: So I vigorously defend folks right to JFDI
<wallyworld> yes, in the list of with their team
<wallyworld> s/of/or
<lifeless> wallyworld: specifically on the mailing list; team chats on voice and irc chats in channels other than launchpad-dev are invisible to many people.
<lifeless> There are plenty of studies showing that for group intelligence, the more *participants* the better the outcome.
<wallyworld> ack
<lifeless> here's what I want: if someone sees a bug, they can:
<lifeless>  - fix it
<lifeless>  - land the fix
<lifeless>  - in a short period of time
<lifeless>  - get feedback on what
<lifeless>   - *must* be made better before deployment
<lifeless>   - *can* be made better if someone wants to
<lifeless>   - *should* be improved before they forget the context for what they did
<mwhudson> i also wonder if (in some cases) we should land stuff behind a feature flag
<mwhudson> as an almost matter of course
<lifeless> I think we do much of this today, but in an order that has many many handoffs.
<lifeless> mwhudson: +1
<wallyworld> IMHO, this architectural stuff needs to be right up there since with the small incremental changes we tend to do, it's way to easy to get architectural decay over time, like the frog in the boiling water analogy
<mwhudson> then it becomes "what must be done before the flag turned on"
<lifeless> mwhudson: I think it would be a sensible default. See my mail to the list later this afternoon.
<mwhudson> lifeless:  :-)
<mwhudson> because turning on flags out of order is way easier than deploying revisions out of order
<bac> mwhudson: good point
<lifeless> wallyworld: I think its all too easy to get gearing-issues.
<lifeless> wallyworld: Are you familiar with LEAN ?
<wallyworld> yes, but not an expert
<lifeless> value stream maps ring a bell ?
<mwhudson> lifeless: an advantage of blocking landing until something has been done is that it's less likely to be forgotten and less damaging (in some ways) if it is
<wallyworld> no
<lifeless> wallyworld: http://en.wikipedia.org/wiki/Value_stream_mapping
<mwhudson> lifeless: kanban boards probably help with this though
<lifeless> wallyworld: each /type/ of review, and each time someone blocks/context switches /in/ a review is a handoff
<lifeless> a VSM of our landing process is scary scary stuff
<lifeless> mwhudson: a bit, but its also an accomodation to having a painful process.
<lifeless> concretely, lets say that we asked every team lead to *enforce* an architectural review : transparency, performance, cohesion, etc, on *every landing*
<wallyworld> lifeless: agree, which is why i mentioned that if the bigger picture stuff were done pre-implementation, it wouldn't hopefully be an issue come review time
<lifeless> wallyworld: pre-impl is part of the VSM
<lifeless> bac: so, sorry that this has scaled into a larger discussion.
<bac> but i think pre-impls are not being done consistently or with much vigor
<lifeless> I don't think preimpls work.
<bac> lifeless: not a problem.  it is a good discussion
<lifeless> because they are another blocking step in doing stuff
<lifeless> people will often chat about things
<lifeless> but a detailed preimpl at the level needed to catch these things, given our maturity as a project, is actually a big deal.
<wallyworld> better to put in some effort up front and catch any issue early rather than pay a bigger cost later IMHO
<bac> lifeless: it seems like you're saying each opportunity for collaboration is a blocking point to be avoided.
<lifeless> bac: no, I'm saying *requirements to collaborate* are harmful.
<lifeless> wallyworld: some years ago I would have agreed with you; now I think we need to identify where things could have been done better and train individuals so the next time is better.
<lifeless> bac: here's an example. If you *had* to have a preimpl call, came up with a good idea on saturday, who would you speak to? or would you wait until sunday when I'm around (my monday)
<bac> lifeless: i don't see that we have those 'requirements to collaborate'.  we have suggested collaboration points, if warranted.
<wallyworld> hmmm. not sure i agree :-) look at methodologies life orthogonal defect classification etc - all designed to catch issues early since the cost of fixing later is too great
<lifeless> wallyworld: this ties into the cycle time. if the cycle time is a days work, more or less, how much will you gain/lose ?
<lifeless> wallyworld: the risk is bounded, the delay is minimal.
<bac> lifeless: the only time we've *enforced* pre-imp calls is with community contributors and only to ensure their work is on target and desirable
<lifeless> bac: I'm addressing wallyworld's argument, not what we have today. Today reviews are the mandatory choking point.
<wallyworld> i would warrant if it takes a day up from to save the collective project cost of bad implementation, recfactoring costs etc later, then it's worth it :-)
<lifeless> bac: and I'm arguing that we need to take trivia out of that choke point and put things that matter in.
<lifeless> wallyworld: I couldn't parse that, sorry.
<wallyworld> sorry, if it takes a day up front to save much more time later due to the cost of bad implementation, factoring etc, then it's worth it
<wallyworld> but the real answer IMHO it "it depends" - it's a judgement call as to what effort is needed depending on the downstream risk and cost of getting it wrong
<mwhudson> another thought is that tying some of these discussions to branches is a bit silly
<bac> wallyworld: and i do see that in practice.  the answer to a reviewer request is often "that's a good idea but out of scope.  i'll open a tech-debt bug and put in an XXX but i'd like to land what i have now."
<wallyworld> lifeless: "things that matter" = getting the architecture right
<wallyworld> bac: yes. i think it comes down to our collective experience as competenent software engineers to do The Right Thing
<bac> this has been good, but let's move on
<bac> [topic]  [[http://paste.ubuntu.com/507156/ |Truth conditionals and the new "all" and "any" functions]], henninge
<MootBot> New Topic:   [[http://paste.ubuntu.com/507156/ |Truth conditionals and the new "all" and "any" functions]], henninge
<bac> so, this was a request to change our style guide to account for any() and all()
<bac> after some good discussion we decided not to change the contional rules and to incorporate them into the use of any() if desired
<bac> henning was agreeable and is going to update the style guide
<lifeless> one sec
<lifeless> so, I think 'if foo:' is perfectly cromulent python and we should use it.
<lifeless> when its an accurate statement of the desired logic.
<bac> the concensus from the discussion is that the truth conditional can be problematic as is masks what is being tested.  there was strong support for making those tests explicit
 * mwhudson is on a call now, drifting out
<lifeless> bac: by that logic we shouldn't use functions
<lifeless> because they mask what they do
<bac> a recent example of where we didn't follow the requirement was your suggestion to wgrant this week
<lifeless> right
<lifeless> the long winded version was *wrong*
<lifeless> (buggy)
<bac> yes, b/c he really did need to check all of the conditions that are implied by the shorter test
<lifeless> its a mistake to avoid a powerful idiom in the language simply because its brief.
<lifeless> there can be good reasons to avoid it, but brevity isn't one IMO.
<lifeless> (for instance, storm result sets don't define a __nonzero__, and they need to define one which raises, I suspect)
<bac> the reason for avoiding it isn't the inherent brevity.  brevity is good, is readable, and takes less typing.
<bac> the rationale is that implicitly testing for None and "" and 0 often leads to mistakes.
<bac> lifeless: i urge you to bring your argument up on the list.
<bac> i also think we need to have a multisession throw down at the epic to cover a lot of these topics.  doing it in person may be the best way to get real concensus with everyone's buy in
<lifeless> I'll put it in my queue; its not something I feel strongly compelled to debate at this point in time (because to me this falls in the bucket of 'we shouldn't be specifying this in reviews anyway')
<bac> i think our process may be at a point similar to where we were at MIT and those sessions were tremendously valuable in affecting change
<lifeless> bac: tell me more?
<bac> the sessions with the poppen-people
<bac> mary and tom
<bac> i think we made fundamental changes to our process that were great
<bac> and i think we may be equally stagnant now and need something similar to address the problems
<bac> the reviewers meeting is the wrong forum, especially since it is disjointed
<bac> the ML doesn't seem to work for big changes
<bac> anyway, we've had a wide-ranging long discussion here and i appreciate it.
<bac> but i need to get some breakfast.
<lifeless> I have one more thing :)
<bac> thank you all for participating
<lifeless> sorry!
<bac> #endmeetin...
<bac> yes?
<lifeless> I'd like to find out how reviewers have been going with discussions about the architectural guide stuff
<lifeless> has is slipped your mind? been tried and too hard? No context? would training help? is it too vague? or too wacky?
<bac> i cannot say.  we discussed the idea and it seemed to be well received.  i have not done follow up.
<lifeless> this is important to me, and I'm being asked about it by mgmt folk :)
<bac> i don't think this is a change that is going to happen by simple encouragement in a meeting or in a list message
<lifeless> bac: if you have suggestions about getting it to happen, I'm all ears.
<lifeless> bac: after your breakfast, perhaps :)
<bac> lifeless: i have nothing useful ATM
<bac> lifeless: sure
<bac> anything else?
<bac> 3
<bac> 2
<bac> 1
<bac> #endmeeting
<lifeless> bac: failing that, can we at least add a 'retrospective on arch guide' to the next meeting
<MootBot> Meeting finished at 20:17.
<bac> lifeless: let's talk later.  i'm pretty busy for the next four hours.  does that run past your EOD?
<lifeless> my day is all confused today
<lifeless> ping me
<bac> ok
<Ursinha> OOPS-1741SMS1
<ubot5> https://lp-oops.canonical.com/oops.py/?oopsid=1741SMS1
