15:02 <slangasek> #startmeeting
15:02 <meetingology> Meeting started Wed Jun 19 15:02:59 2013 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:02 <meetingology> 
15:02 <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
15:04 <slangasek> [TOPIC] Lightning round
15:05 <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek cjwatson xnox stokachu)
15:05 <slangasek> doko bdmurray ev xnox cjwatson stokachu jodh slangasek stgraber barry
15:05 <slangasek> doko: moin :)
15:05 * barry is not sure if he wins or loses
15:05 <doko> wow, first time the first after years ...
15:05 <doko> - chase down a regression in GCC 4.8 and lto
15:05 <doko> - build a gcj cross compiler
15:05 <doko> - cross build gcj, should have a gcj for aarch64 soonish
15:05 <doko> - next step is trying to cross build openjdk
15:05 <doko> - looked into issues with the armhf gcc cross builds (multilib related)
15:05 <doko> (done)
15:06 <bdmurray> modifications to the phased-updater code
15:06 <bdmurray> modifications to phased-updater code to show 0% and what the % before was
15:06 <bdmurray> resolved an issue with the package crash rate check not working in the phased-updater
15:06 <bdmurray> merge proposal for package-rate-of-crashes returning a number for the difference
15:06 <bdmurray> reported errors bug 1191182 regarding &version being appended when choosing &period
15:06 <ubottu> bug 1191182 in Errors "choosing a period on the main page appends a version to the query" [High,New] https://launchpad.net/bugs/1191182
15:06 <bdmurray> worked with thedac to update errors to r435
15:06 <bdmurray> investigation into and resolution of oops querying bucketversionsystems2
15:06 <bdmurray> irc discussion with cjwatson and infinity regarding sru-release and copy package
15:06 <bdmurray> reported bug 1192286 regarding phased update percentage and copy package
15:06 <ubottu> bug 1192286 in Launchpad itself "Allow phased update percentage to be set when copying a package" [Undecided,New] https://launchpad.net/bugs/1192286
15:06 <bdmurray> reported bug 1192332 regarding SRU of update-manager
15:06 <ubottu> bug 1192332 in update-manager (Ubuntu Raring) "SRU of change to phased updater percentage calculation to consider source not binary packages" [Medium,In progress] https://launchpad.net/bugs/1192332
15:06 <bdmurray> updated meta-release file on changelogs for bug 1173209
15:06 <ubottu> bug 1173209 in ubuntu-release-upgrader (Ubuntu Saucy) "Prompted about New Release for 13.04 again after dist-upgrade and a restart" [Low,Fix released] https://launchpad.net/bugs/1173209
15:06 <bdmurray> approval of Fabio Marconi in ubuntu bug control
15:06 <bdmurray> tested bug 1175637
15:06 <ubottu> bug 1175637 in unattended-upgrades (Ubuntu) "Kernel updates are being marked as manually installed" [Undecided,Confirmed] https://launchpad.net/bugs/1175637
15:07 <bdmurray> ␗ done
15:07 <ev> - Bringing back the diagnostics page to activity-log-manager. It was
15:07 <ev> accidentally dropped as they rewrote the build system (most of the code is
15:07 <ev> Vala, ours is C):
15:07 <ev> https://code.launchpad.net/~ev/activity-log-manager/add-whoopsie-back/+merge/169855
15:07 <ev> - Spent some time updating the packaging, only to find that Jeremy had done
15:07 <ev> much the same thing.
15:07 <ev> - Some hand holding of the two back population jobs we've been trying to get
15:07 <ev> completed the past few weeks (we've had to kill them a few time due to high
15:07 <ev> load - the cluster is at 3TB per node, which is putting too much on each
15:07 <ev> machine).
15:07 <ev> - The first improves our calculation of the average errors per calendar day
15:07 <ev> graph, and will be finished in just under a day:
15:07 <ev> https://bugs.launchpad.net/errors/+bug/1069827
15:07 <ev> https://bugs.launchpad.net/daisy/+bug/1077122
15:07 <ubottu> Launchpad bug 1069827 in Errors "Error rate incorrectly spikes with any influx of machines" [High,Confirmed]
15:07 <ubottu> Launchpad bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed]
15:07 <ev> - This will need to be run a second time for the data to be accurate.
15:07 <ev> - The second rebuilds the table of releases and binary package versions for
15:07 <ev> each problem ("Package versions with this error"), and will finish by the
15:07 <ev> weekend:
15:07 <ev> https://errors.ubuntu.com/problem/4eebfa6d3f91386f752207eeaf410b5a8ce81081
15:07 <ev> - There will be a second phase to this that adjusts the counters based on
15:07 <ev> the data generated here.
15:07 <ev> - Firefighting the Cassandra nodes being critically out of space.
15:07 <ev> - Spent an evening digging through the database, looking for invalid data,
15:07 <ev> but it only forms significantly less than 0.05% of all the error reports.
15:08 <ev> - Tom agrees that purging unneeded data wont gain us much. Liam is now full
15:08 <ev> time on bringing up Cassandra nodes in Prodstack.
15:08 <ev> - Code review for Brian.
15:08 <ev> - More discussion on enabling error reporting on Ubuntu Server.
15:08 <ev> - Delivered the amended NDA for hunting security vulnerabilities to Kees.
15:08 <ev> - Added revno headers to lp:errors with added support to the deployment
15:08 <ev> scripts.
15:08 <ev> - Added Hadoop support to lp:error-tracker-deployment \o/. Further deployments
15:08 <ev> to stagingstack/prodstack will have a Hadoop namenode and jobtracker, as well
15:08 <ev> as a datanode, tasktracker, and pig shell on each Cassandra node.
15:08 <ev> - Moved to Cassandra 1.2 in the default (the settings we use for Tarmac and our
15:08 <ev> own testing) lp:error-tracker-deployment deployment. Built
15:08 <ev> libcassandra-dpkgversiontype-java for C* 1.2.5 and verified everything still
15:08 <ev> works. Hooray for integration tests.
15:08 <ev> - Slowly working on accounting for realistic SLAs in the services we build and
15:08 <ev> depend on. First up, handling Swift 503s:
15:08 <ev> https://bugs.launchpad.net/daisy/+bug/1191859
15:08 <ev> (done)
15:08 <ubottu> Launchpad bug 1191859 in Daisy "Provide fallback for core storage" [High,Confirmed]
15:08 <xnox> * gcc-android toolchain: dropped clang/llvm/compiler-rt build-deps,
15:08 <xnox> building phablet image using that toolchain. Grouper image builds,
15:08 <xnox> now trying to boot it.
15:08 <xnox> * upstart-jobs: forwarded dbus, at. Also filed
15:08 <xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712763 as
15:08 <ubottu> Debian bug 712763 in upstart "upstart: implementing Debian Policy §9.11.1" [Normal,Open]
15:08 <xnox> alternative way to implement policy compliant lsb init scripts.
15:08 <xnox> * uploaded upstart raring SRU with full-serialisation (lossless
15:08 <xnox> stateful rexec) and reload-configuration fixes. SRU team, please
15:08 <xnox> review.
15:08 <xnox> * uploaded ubiquity update with u1 bugfixes and UI tweaks, drop of
15:08 <xnox> gksudo.
15:09 <xnox> done.
15:09 <cjwatson> A few fixups for build failures in main.
15:09 <cjwatson> foundations-1305-arm64-bringup: Discussions re simulator and next stages of bringup.
15:09 <cjwatson> Backported upstream parted patches for bug 1187560.
15:09 <ubottu> bug 1187560 in parted (Ubuntu) "parted rejects GPT as corrupt, kernel + gdisk think it's ok" [Medium,Fix released] https://launchpad.net/bugs/1187560
15:09 <cjwatson> community-s-autopkgtesting: Finally attached autopkgtest to proposed-migration with sticky tape and chicken wire.  There are still a couple of bits to clean up before I announce it to developers but it's mostly there and working.
15:09 <cjwatson> Disentangled signon-ui vs. powerpc vs. proposed-migration problems.
15:09 <cjwatson> foundations-1305-click-package: Fleshed out work items.  Working on finalising click-package file format and polishing prototype in preparation for upload to saucy.
15:09 <cjwatson> ..
15:09 <stokachu> - released sosreport 3.0
15:09 <stokachu> - rest of my time spent building and productizing a security auditing tool
15:09 <stokachu> - no bugs on fire
15:09 <stokachu> (done)
15:12 <slangasek> bdmurray: AIUI bug #1192286 is critical path for rollout of phased-updates now... do we know when that might get fixed?
15:12 <ubottu> bug 1192286 in Launchpad itself "Allow phased update percentage to be set when copying a package" [Undecided,New] https://launchpad.net/bugs/1192286
15:12 <cjwatson> jodh is still on holiday, so it's slangasek
15:12 <bdmurray> slangasek: no, I don't know when it might get fixed
15:12 <cjwatson> slangasek: I can probably look at it soon - asked bdmurray to file it since I kept forgetting
15:13 <cjwatson> will have a crack at it tomorrow since I think I was last to touch that code anyway
15:14 <cjwatson> William didn't entirely explode at my suggested fix
15:16 <slangasek> xnox: can I suggest discussing 712763 on debian-devel as well?  I dunno how the lsb maintainer feels about it, but I would certainly like to see some kind of consensus so we don't have to keep adding more interfaces to lsb-functions :)
15:17 <xnox> slangasek: ack.
15:17 <slangasek> ah, it is me, isn't it?
15:17 <slangasek> new rule, people have to paste as slow as I read :P
15:18 <slangasek> * partner work: centrifydc update published to precise, then pulled again
15:18 <slangasek> * working with the phonedations team for flipping the container
15:18 <slangasek> * catching us up on the SRU queue (python, unity in precise)
15:18 <slangasek> * had a meeting, got consensus that we want to try to repartition
15:18 <slangasek> (done)
15:18 <slangasek> * working to support repartitioning on install so we can use the system partition; hard to make parted happy with the non-standard GPTs that come on some of these devices (grouper)
15:18 <slangasek> * testing the working container-flipped install on grouper (yay!), but noticing kernel output that shouldn't be there... talked to ogra, filed some meddlesome bugs on the kernel package, have been superseded by ogra's more correct fix
15:18 <slangasek> stokachu:
15:18 <ogra_> slangasek, its gone with the new kernel
15:18 <ogra_> fbdev is ripped out again (as it should be)
15:18 <slangasek> ogra_: great :)
15:19 <slangasek> ogra_: so do I need to re-bootstrap to get that, or just flash the latest armel+grouper?
15:19 <slangasek> stgraber:
15:19 <ogra_> slangasek, since the archive is wonky today i cant build an image atm ... waiting for it to sort itself
15:19 <slangasek> (sorry, not stokachu )
15:19 <stgraber> Blueprint-related work:
15:19 <stgraber> - Image based updates (BLUEPRINT: foundations-1305-image-based-updates)
15:19 <stgraber> - Production server is online, just need to be populated now
15:19 <stgraber> - Added config file and config file parsing to the server code
15:19 <stgraber> - Added support for channels.json and index.json generation
15:19 <stgraber> - Added code to publish device keyring and images
15:20 <slangasek> ogra_: wonky how?
15:20 <stgraber> - Updated the tests to keep us at 100% code coverage
15:20 <stgraber> - Had a couple of meetings on the subject
15:20 <stgraber> - Clarified some details in the specs
15:20 <stgraber> Other work:
15:20 <ogra_> slangasek, signon-ui issues
15:20 <slangasek> the archive is not supposed to be wonky ever
15:20 <stgraber> - Ubuntu touch
15:20 <stgraber> - Spent a day or so implementing a working prototype of the loop-mounted system partition design.
15:20 <stgraber> - Some more discussions on partitioning and containers
15:20 <stgraber> - LXC
15:20 <stgraber> - Usual code reviews
15:20 <stgraber> - Patch pilot on Monday
15:20 <stgraber> - Processed a bunch of ~ubuntu-archive bugs
15:20 <stgraber> 
15:20 <stgraber> TODO:
15:20 <stgraber> - TODAY: Test my loop-mounted setup on grouper (nexus7)
15:20 <stgraber> - TODAY: Write some internal wiki documentation of the key infrastructure for system-image
15:20 <stgraber> - TODAY: File an RT to get the new keys and keyrings generated
15:20 <cjwatson> slangasek: proposed-migration doesn't consider component mismatches (and it would be really hard to make it do so)
15:20 <stgraber> - THIS WEEK: Update livefs infrastructure to generate .tar.xz files for the touch rootfs (probably not published to cdimage.ubuntu.com though but only on system-image.ubuntu.com)
15:20 <xnox> slangasek: components-mismatched wonky.
15:20 <stgraber> - THIS WEEK: Finish self-rebuilds feature implementation on nusakan
15:20 <stgraber> - Integrate the system-image module with cdimage to publish updates to the daily channel as they appear
15:20 <stgraber> - Write some tools for manual actions on system-image (manage channels, manage keyrings, manually publish updates, ...)
15:20 <stgraber> - Process some pending merges (ifupdown and resolvconf)
15:20 <stgraber> 
15:20 <stgraber> I won't be working on Monday (24th of June) as it's a public holiday here (but may still make it to the release call and TB meeting).
15:21 <stgraber> 
15:21 <slangasek> cjwatson, xnox: ah, right - sigh
15:21 <stgraber> (DONE)
15:21 <barry> ubuntu: LP: #1094218, LP: #1167177, LP: #1191979
15:21 <xnox> slangasek: blame yet another copy of webkit in the archive ;-)
15:21 <ubottu> Launchpad bug 1094218 in lsb (Ubuntu Raring) "lsb_release crashed with IOError in getstatusoutput(): [Errno 10] No child processes (called by teamviewerd)" [High,Fix committed] https://launchpad.net/bugs/1094218
15:21 <ubottu> Launchpad bug 1167177 in python-defaults (Ubuntu) "package python-dev 2.7.3-0ubuntu2 failed to install/upgrade: tentative de remplacement de « /usr/lib/pkgconfig/python2.pc », qui appartient aussi au paquet python2.7 2.7.3-0ubuntu3.1" [Undecided,Confirmed] https://launchpad.net/bugs/1167177
15:21 <ubottu> Launchpad bug 1191979 in Ubuntu system image "A bogusly signed blacklist file infloops the state machine" [High,Fix committed] https://launchpad.net/bugs/1191979
15:21 <barry> also: fixing problems with emacs in both the archive and my personal settings
15:21 <barry> image based upgrades: logging and testing against the real server. various keyring fixes. inaugural weekly ghangout. bug filing and housekeeping.  LP: #1191141, LP: #1191885, LP: #1191982 (still unresolved).  todo: LP: #1191150
15:21 <ubottu> Launchpad bug 1191141 in Ubuntu system image "Only the archive master should be required" [High,Fix committed] https://launchpad.net/bugs/1191141
15:21 <ubottu> Launchpad bug 1191885 in Ubuntu system image "Test suite should lower log level" [High,Fix committed] https://launchpad.net/bugs/1191885
15:21 <ubottu> Launchpad bug 1191982 in Ubuntu system image "Test suite produces ResourceWarnings" [Low,Triaged] https://launchpad.net/bugs/1191982
15:21 <barry> ☮
15:21 <ubottu> Launchpad bug 1191150 in Ubuntu system image "Save the.tar.xz and tar.xz.asc keyring files" [High,Triaged] https://launchpad.net/bugs/1191150
15:21 <slangasek> that's been burning us rather more than I like - I realize proposed-mismatches shouldn't be trying to deal with c-m, but do we need more proactive c-m handling somewhere?
15:22 <stokachu> barry: just let it rewrite itself until it is fixed
15:22 <slangasek> I mean, we already get the emails
15:22 <barry> stokachu: :)
15:23 <slangasek> "ghangout" - what a lovely gutteral consonant
15:23 <cjwatson> slangasek: from my point of view as an archive admin the problem is that doing anything about it in reasonable bulk requires going through tons of MIR paperwork for packages I know nothing in particular about
15:23 * barry wonders if that's g-as-in-gif or g-as-in-gif
15:24 <cjwatson> ghangout> that's clearly a https://en.wikipedia.org/wiki/Voiced_velar_fricative
15:24 <slangasek> right :)
15:26 <cjwatson> slangasek: so I think it has to be pushed to uploaders more, somehow - I know some of them are due to syncs but certainly far from all
15:26 <doko> barry, thanks for the python sru's
15:26 <slangasek> cjwatson: is an adjustment to the MIR process needed?  should c-m be linkified to appropriate bug searches?
15:26 <barry> doko: np!
15:26 <cjwatson> it is linkified
15:26 <cjwatson> I mean, if the bug exists you get a link
15:26 <slangasek> cjwatson: where?
15:26 <slangasek> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is not html :)
15:26 <cjwatson> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt  grep for MIR:
15:26 <cjwatson> OK, "link"
15:26 <cjwatson> Or http://people.canonical.com/~ubuntu-archive/component-mismatches.svg has clickable links
15:27 <cjwatson> And indeed clickable bug searches
15:27 <cjwatson> s/bug searches/filebug links/
15:27 <slangasek> but only searches open MIRs
15:27 <ogra_> shouldnt it probably just mail the uploader in parallel to the ML =
15:27 <ogra_> ?
15:27 <cjwatson> slangasek: Right, not sure what else it should do
15:27 <slangasek> so if someone has promoted it in -proposed and the bug has been closed, the search won't find it - is that one of the problems here or not?
15:27 <cjwatson> Also, when I try to act upon this sort of thing, I get the kinds of response times in https://bugs.launchpad.net/ubuntu/+source/ruby-json/+bug/1178274
15:27 <ubottu> Launchpad bug 1178274 in ruby-json (Ubuntu) "[MIR] ruby-json" [Undecided,New]
15:28 <cjwatson> slangasek: Oh, it's true that happens from time to time but I don't think it's a particularly large part of the problem
15:28 <slangasek> ok
15:29 <slangasek> cjwatson: maybe we should chat after so I can understand exactly where the bottleneck is
15:29 <cjwatson> How about I put this on the agenda for next month's release eng sprint?
15:29 <slangasek> ah, sounds good
15:30 <slangasek> [TOPIC] Bugs
15:30 <cjwatson> I think doing anything about it will be a chunk of (worthwhile) work no matter what
15:30 <slangasek> right
15:31 <slangasek> bdmurray: anything you want to highlight this week?
15:31 <bdmurray> slangasek: nope
15:31 <slangasek> ok
15:32 <slangasek> [TOPIC] Meeting format
15:32 <slangasek> so I have a topic to discuss this week :)
15:32 <slangasek> I've chatted a bit with cjwatson about this already, and we wanted to get feedback from the rest of the team about the layout of this meeting itself
15:33 <slangasek> currently, the bug triaging seems to be happening efficiently outside the meetings, and we rarely have other topics brought up for discussion besides the lightning round
15:33 <slangasek> it seems like if all we were doing was weekly status reports, we could do that by email just as well
15:33 <slangasek> but I like us having the weekly real-time meeting
15:34 <slangasek> do you guys have thoughts on how we could make it more useful?
15:34 <stokachu> are the weekly status report by email public?
15:34 <slangasek> they could be published in a wiki page instead of by email
15:34 <cjwatson> We don't really have a suitable public list, but ... that
15:34 <barry> as long as we do it. :)
15:35 <stokachu> i already do a weekly status report for my group but of course some couldnt be public
15:35 <cjwatson> a real-time meeting is a pretty good way to ensure we actually do it
15:35 <cjwatson> stokachu: as public as this meeting; but of course private-platfound is available if need be
15:35 <slangasek> yeah... I'm not keen on the idea of dropping the meeting and doing status in the wiki, because I know people will get neck-deep in work and not get around to sending them in on time ;)
15:35 <barry> if we do it enough ahead of the public meeting, then we can use this time to dive a little deeper into one or two topics.
15:35 <cjwatson> however I think slangasek was talking about e-mailed status reports as one possibility, not necessarily as a done deal
15:36 <slangasek> barry: I think the current scheduled meetings (1h IRC, + 1/2h mumble) allow plenty of time to dive deep on a topic... if we have topics we want to discuss :)
15:36 <stokachu> i do like the real time meetings to get ack's on bugs needing attention
15:37 <cjwatson> I think it's helpful to have some way where those of us who aren't involved in e.g. whole-image updates can see what's happening there, and perhaps rotating through various topics at greater length would provide some similar usefulness
15:37 <stgraber> I think there's value in having it on IRC if only because it's easier to discuss specific points of somebody else's work than by replying to a bunch of e-mails or commenting on a wiki page. Also it's nice being able to quickly highlight someone from another team and have their feedback immediately.
15:37 <cjwatson> OTOH I kind of don't want to make people prepare presentations all the time
15:37 <doko> hmm, I think we had status reports by email before, but did change it to online reports
15:37 <cjwatson> Right, it was hard to get them done on time
15:37 <cjwatson> Or at all :)
15:38 <cjwatson> OTOH turning up to press the paste button isn't necessarily a perfect use of time
15:38 <doko> I like the current way better (if the reports don't get excessive, hint, hint ...)
15:38 <barry> the problem i see with the current format is that things scroll by so quickly, it's hard to keep up and further, to have a conversation about specific points (e.g. in the middle of other people's status)
15:38 <cjwatson> Yeah, I have difficulty with that too
15:39 <stokachu> why not use etherpad or something?
15:39 <barry> as evidenced by slangasek's comment earlier :)
15:39 <cjwatson> I do try to read them - but it can be a bit TMI
15:39 <stokachu> has chat and everyone can log their status
15:39 <cjwatson> oh god oh god etherpad *PTSD*
15:39 <stokachu> LOL
15:39 <cjwatson> worst UI on the planet
15:39 <stokachu> or gobby?
15:39 <slangasek> well, I know it's perhaps not considered good IRC meeting etiquette, but from my POV it's far preferable for people to talk about things as they come up in status reports, even if it slows the meeting down
15:40 <xnox> just to complete the flamewar: google wave and google docs.
15:40 <stokachu> xnox: hah
15:40 <slangasek> but yes, being able to have reports side-by-side with the IRC discussion might be better
15:40 <cjwatson> the problem with those is that they're either awfully ephemeral (gobby - in theory logs/saves, but in practice loses things all the time) or terrible UI from hell (etherpad)
15:40 <slangasek> again, the challenge is getting everything into the wiki ahead of time
15:41 <cjwatson> I actually don't regard the current status report format as a particular problem, but it does feel that we have settled into a local minimum of mostly doing *only* the lightning round
15:41 <slangasek> I know half the team is furiously finishing their reports *during the meeting*, that wouldn't work if they had to be in the wiki at the start of the meeting ;)
15:41 <slangasek> xnox: this is not the wave you're looking for
15:41 <stokachu> true i have last minute bugs coming up just before the meetings
15:41 <slangasek> xnox: oh wait, YOU HAVEN'T SEEN THAT MOVIE
15:41 <cjwatson> And it rather feels as though there should be additional uses for a weekly sync point
15:41 * xnox =(
15:42 <slangasek> so to be clear, I'm strongly in favor of keeping a weekly real-time sync point
15:42 <ogra_> slangasek, what ?!?! how did he get the job without that
15:43 <slangasek> I would just like it to be more dynamic
15:43 <slangasek> ogra_: we interviewed him based on skills instead? :)
15:43 <stokachu> is there no team management software that we could use
15:43 <stokachu> like basecamp or something
15:43 <barry> slangasek: do you find the weekly meetings to be useful for you as a manager to know what we're up to?
15:43 <slangasek> wtf, I just read "tea management" and did a double take
15:43 <xnox> slangasek: my personalised google search results bring up only a song by Fall Out Boy, which I'm sure is not the reference you made.
15:44 <stokachu> haha
15:44 <ogra_> lol
15:44 <slangasek> barry: yes - but if it's *just* that, it could all be handled by emailed/wikied status reports, or covered in 1:1s or whatever
15:45 <slangasek> barry: I'm more interested in making sure the team is getting something out of the meetings collectively - i.e., surfacing from their own underground silos once a week to talk with their peers
15:45 <cjwatson> it's useful for me too FWIW; I don't routinely have 1:1s but it's helpful to have a general awareness of what everyone's doing
15:45 * xnox ponders if it would make any sence to bring together kernel/phonedations/foundations to talk together.
15:45 <slangasek> stokachu: I don't think different software solves the problem that's bothering me :)
15:45 <barry> slangasek: definitely
15:45 <ScottK> Personally, I find the IRC discussion interesting and sometimes, because it's on IRC, I'll have something to contribute.
15:45 <stokachu> ah ok
15:46 <slangasek> ScottK: right, having it open to the rest of the community is also a concern of mine
15:46 <cjwatson> yeah, I think we would lose something important if we moved into some silo or other
15:46 <slangasek> so, strawman time
15:47 <slangasek> how about if we continue with the existing format, but we pick one topic a week to go into more depth on?
15:47 <stgraber> +1
15:47 <slangasek> and I'll announce the topics within the team the night before, so the people working on the topic know they should be ready (but not needing to prepare a presentation per se)
15:48 <cjwatson> I think perhaps a day or two's warning would be better
15:48 <cjwatson> just in case there's something else going on on Wednesday morning
15:48 <bdmurray> slangasek: being in the same tz as you I'd like some more time ;-)
15:48 <slangasek> and at any time, if someone has a problem they're struggling with that they would like the team's eyeballs on, they can pre-empt
15:48 <cjwatson> but that's just a refinement
15:48 <slangasek> cjwatson, bdmurray: hmm, I'm wary that giving more time will lead people to be inclined to over-prepare?
15:49 <cjwatson> I suppose it's a balance between overpreparation and panic
15:49 <cjwatson> we could see how it works ...
15:49 <cjwatson> does anyone feel this kind of thing would be bad?
15:50 <barry> nope
15:50 * xnox is curious what we will discuss? Mir vs X ?
15:50 <slangasek> xnox: well, I /could/ give folks an update on plymouth + Mir
15:50 <ev> Scala vs Clojure
15:50 <slangasek> because that's a thing we'll be working on in the near future
15:51 <ev> give me time, I'll wear you down ;)
15:51 <slangasek> xnox: or you could talk about the status of the android cross-toolchain work, or we could talk about the system image updates and have Q&A about that, or go deeper on the container flip architecture and the problems we're running into, or click packages, or...
15:51 <xnox> ev: "Scala vs Clojure" - perfect name for the first audiobook monologue from you to be published on amazon audio books =)
15:52 <slangasek> I think we have no shortage of topics where it would be useful to have more mind-melding^W cross-pollination
15:52 <stokachu> "Why Lisp will rule the world"
15:52 <xnox> s/will/didn't/
15:52 <barry> slangasek: that would also make it more interesting for non-team members
15:53 <stokachu> haha
15:53 <cjwatson> xnox: I think it ought to be something directly related to things we're doing; while there is certainly a connection via Plymouth, I wasn't envisaging general discussion about the state of Ubuntu
15:53 <barry> s/will/does/
15:53 <barry> ev: FORTH
15:53 <xnox> cjwatson: I see.
15:53 <cjwatson> Basically what slangasek said by way of examples
15:53 <ev> xnox: I'm going to save my dulcet tones for the audiobook version of The C++ Programming Language. Mostly so I can end every paragraph with "but wait, it gets worse."
15:54 * ev stops being a distraction
15:54 <cjwatson> (If we happened to be doing it today I probably would have sanity-checks to ask for about click-package, for instance)
15:54 <slangasek> if we feel after a while that we've exhausted our own topics (but that seems improbable), we could invite guest speakers from other teams
15:54 <ev> barry: :D
15:54 <cjwatson> ev: My roommate at university had his bookshelf organised from humour to horror
15:54 <slangasek> ev: you should just do an audio book of "PHP: A Fractal of Bad Design" :)
15:54 <cjwatson> ev: The right-hand-side went ..., Whit, The Wasp Factory, The C++ Programming Language
15:54 <ev> lol!
15:55 <ev> amazing all around
15:56 <slangasek> ok, so it sounds like we have a rough consensus to add explicit discussion topics to the meeting
15:56 <slangasek> and I've marked in my calendar to pick these topics the day before - hopefully striking the right overpreparing vs. panic balance :)
15:57 <slangasek> frankly, I think if we're picking the right topics people are going to be able to talk about them extemporaneously
15:57 <slangasek> because it's the stuff that you're already working on that's in your brain :)
15:57 <cjwatson> Yeah, that's probably true
15:57 <slangasek> sound good?
15:57 <ev> yes
15:57 <stokachu> +1
15:57 <ScottK> And if not, the panic will be fun to watch.
15:58 <slangasek> [TOPIC] AOB
15:58 <slangasek> anything else? :)
15:58 <barry> slangasek: "extemporaneously" is probably an acknowledgment of reality anyway :)  +1
15:59 <slangasek> :D
16:00 <slangasek> #endmeeting