[12:01] <Daviey> Is there a UDD meeting now?
[12:03] <jelmer> Daviey: I think so (according to my calendar), but I haven't seen Barry yet
[12:03] <jelmer> Daviey: oh, thanks for that Sync ACK earlier :)
[12:04] <Daviey> jelmer: np :)
[12:08] <jelmer> hi Barry
[12:09] <barry> hi jelmer
[12:09] <barry> sorry about getting here late.  only 2 more weeks of school left :)
[12:09] <barry> let me bring up the agenda and then we'll start
[12:09] <barry> #startmeeting
[12:09] <MootBot> Meeting started at 06:09. The chair is barry.
[12:09] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[12:10] <barry> hello and welcome to this week's ubuntu distributed development steering meeting.  who's here today?
[12:10]  * jelmer waves
[12:10] <barry> [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20110601
[12:10] <MootBot> LINK received:  https://wiki.ubuntu.com/DistributedDevelopment/20110601
[12:11] <barry> no poolie?
[12:11] <jelmer> I just pinged in #bzr
[12:11] <barry> thanks!
[12:12] <barry> hi jam
[12:12] <james_w> yo
[12:12] <jam> hi barry. Why did I think this was the "not-a-meeting" week?
[12:12] <barry> ;)
[12:12] <jam> I guess because I'm crazy
[12:12] <jam> I see it on the calendar
[12:13] <barry> let's give poolie another minute or so
[12:13] <jam> I don't think he realized, he didn't mention it in our standup this morning
[12:13] <jam> I wouldn't wait too long
[12:13] <barry> okay then
[12:14] <barry> [TOPIC]
[12:14] <MootBot> New Topic:
[12:14] <barry>  * Action items
[12:14] <barry>  
[12:14] <barry>    * jelmer to study the feasibility of merge helper ([[https://bugs.launchpad.net/bzr-builddeb/+bug/608675|bug 608675]]) as an intermediate step for quilt support
[12:14] <barry>  
[12:15] <jelmer> I've been sprinting and holiday'ing since our last meeting so I haven't had much time to look at that yet
[12:15] <barry> okay, no worries, we'll just leave it on for next time
[12:15] <barry>    * poolie to send condensed summary of uds sessions
[12:15] <barry>  
[12:15] <barry> does anybody know, was this done?
[12:16] <jam> barry: I assume he would send it to the udd list, and I haven't seen anything from him since April
[12:16] <jam> so I'm guessing not
[12:17] <barry> yep, i just looked at gmane and didn't see anything.  okay, continuing
[12:17] <barry>    * Riddell to give summary of current import failures with rough HARD/NOTHARD classification, and failure numbers
[12:17] <barry>  
[12:18] <barry> p-i.u.c looks flat.  i guess this is still todo.
[12:19] <barry>    * jelmer to look into [[https://bugs.launchpad.net/udd/+bug/609187|bug 609187]] (warn when package import is out of date)
[12:19] <barry>  
[12:19] <barry> jelmer: continue for next time?
[12:19] <jelmer> barry: yeah
[12:19] <barry> k
[12:20] <barry> [TOPIC]  * Package importer progress
[12:20] <barry>  
[12:20] <MootBot> New Topic:   * Package importer progress
[12:20] <jam> jelmer: if you're interested, I'd be happy to pair with you on some of those
[12:20] <jelmer> jam: me too, perhaps next week some time ?
[12:20] <barry> jam, jelmer awesome
[12:21] <Riddell> hi
[12:21] <barry> any status on the package importer?  did i see some traffic on that the last couple of days?
[12:21] <barry> Riddell: hi
[12:21] <Riddell> on the classification I discussed it with maxb who said that any one error would have several reasons for failure
[12:21] <Riddell> and by the time you diagnose the failure enough to classify it you're most of the way to fixing it any way
[12:22] <jam> jelmer: sure
[12:22] <jam> I'm off the rest of this one :)
[12:22] <maxb> Indeed - I propose that attempting an overall classification of all current failures is less valuable that iterating a "pick one; fix" approach
[12:23] <maxb> s/that/than/
[12:23] <barry> Riddell: question: once you've done that for one bug in a class, does that help with the other similar failures?
[12:23] <maxb> When I say "pick one", I mean one distinct failure cause, rather than one single package
[12:23] <barry> maxb: hi.
[12:24] <jam> maxb: one of my concerns is this failure: http://package-import.ubuntu.com/status/5cabf40249181425fdb66e301d75f02b.html
[12:24] <Riddell> barry: depending on the bug you can do a mass retry for all the ones with that error, then you just have to see which ones it fixes and which are caused by something else
[12:24] <jam> it feels like you have to check each package manually
[12:24] <jam> with 100 failures, that's a lot of overhead.
[12:24] <jam> any ideas on it?
[12:24] <maxb> We looked a little at that one at the sprint, and established that there are at least two sub-classes to that traceback
[12:25] <maxb> One involves the revision ids having identical timestamps, one not.
[12:26] <barry> maxb, Riddell okay.  it sounds like the effort is better spent on just fixing the problems.  i can take this one off the todo list.
[12:26] <maxb> I got as far as rerunning the importer for a subset of those packages locally, but did not return to analyze the results yet
[12:28] <barry> jam, jelmer if i can put in a plug for increasing the priority of 609187 then :).  having that warning will i think at least give people a better feeling that they won't be wasting their time, and will simplify the docs.
[12:28] <jelmer> barry: ok
[12:28] <barry> any other thoughts on the package importer?
[12:28] <jam> barry: was "run 'bzr is-package-current'" a sufficient first pass at that?
[12:29] <jam> I think there is already code for that, just waiting on making it faster.
[12:29] <barry> jam: is that a real command?
[12:29] <maxb> I have added "UDD failure ratchet: 487" to the topic of #bzr, to 1) make the descending count more visible, and 2) ensure it stays descending
[12:29] <jam> barry: I don't know the command name. I do know someone wrote a plugin that interfaces with launchpadlib
[12:30] <barry> jam: i must have missed it
[12:30] <maxb> In doing so, I have realized that it would be useful for the package-import status page to separately count permanent and will-be-retried failures
[12:31] <maxb> For example, it's up to 522 right now, but many of those appear to be transient errors
[12:31] <barry> maxb: that would be nice to know
[12:32] <barry> maxb: what's the interval for auto-retries?
[12:32] <jam> barry: maybe it was just discussed in the bzr sprint?
[12:32] <jam> I remember discussing it
[12:32] <maxb> barry: Looks to be 3 hours currently - presumably to bridge a typical Launchpad downtime
[12:32] <barry> jam: on the face of it, some easy to spell check command would be a decent first shot
[12:32] <barry> maxb: ack, thanks
[12:33] <barry> okay, moving on...
[12:33] <barry> [TOPIC] Bugs of interest:
[12:33] <MootBot> New Topic:  Bugs of interest:
[12:33] <barry> http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html
 p-i.u.c looks flat. <--- but remember the scale is logarithmic
[12:33] <MootBot> LINK received:  http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html
[12:33] <barry> maxb: right, thanks for the reminder!
[12:34] <vila> sorry for the late arrival, lunch time
[12:34] <barry> vila: hi
[12:35] <barry> wow.  lots of bugs in needs release.  do you know which (if any) are being back ported to stable releases and which are for the next release?
[12:37] <jam> barry: http://webnumbr.com/ubuntu-package-import-failures.max%28800%29.min%28400%29
[12:37] <jam> [link] http://webnumbr.com/ubuntu-package-import-failures.max%28800%29.min%28400%29
[12:37] <MootBot> LINK received:  http://webnumbr.com/ubuntu-package-import-failures.max%28800%29.min%28400%29
[12:38] <jam> barry: bzr bugs generally go straight to released. plugin bugs go into needs-release
[12:38] <barry> jam: ah, i didn't know that!
[12:38] <jam> I think we just need to poke jelmer
[12:38] <jelmer> au!
[12:38] <jam> he did all that wonderful bug fixing, just needs to release it to the public
[12:39] <barry> c'mon jelmer, bask in the glory!
[12:39] <jelmer> yeah, I need to do a few more releases
[12:39] <barry> any other thoughts on bugs?
[12:40] <barry> [TOPIC]  * Alternate meeting times?
[12:40] <MootBot> New Topic:   * Alternate meeting times?
[12:42] <barry> so, 1100utc is doable for me, but it's way to early for slangasek.  i fear there's no way to have one single time that works for au, us-east, us-west, and euro.  otoh, it's hard enough to remember to meet at the same time (for me too!) so alternating will only make it worse.  i'm open to any thoughts.  what are your preferences?
[12:43] <jam> I prefer a same-time meeting
[12:43] <jam> but right now that is in my favor...
[12:44] <barry> jam: and 2100utc, or thereabouts is still bad for you, right?
[12:44] <vila> same here, Wednesday is less practical family wise though (shudder, one more constraint type ;-/)
[12:44] <jelmer> 1100utc works well for me too, as well as in the .au morning
[12:45] <barry> i talked briefly w/slangasek and he's okay if we keep a time more convenient to the bzr center of mass, so i guess for now we'll just keep it at 1100utc
[12:46] <jam> barry: 2100 is about 11pm. So it could work but not something I can do regularly
[12:46] <barry> jam: yep, and i think moving it an hour or so earlier starts to make it infeasible for pooie
[12:46] <barry> er, poolie
[12:47] <barry> okay, 1100utc it is
[12:47] <barry> [TOPIC] Any other business?
[12:47] <MootBot> New Topic:  Any other business?
[12:48] <barry> nothing really on my plate, anything else from y'all?
[12:48] <vila> You covered max's wonders earlier ?
[12:49] <barry> vila: ?
[12:49] <vila> diagnosis on import failures, bugs with recipes to fix, etc
[12:49] <barry> vila: yep
[12:50] <vila> ok
[12:50] <barry> okay then, i think we're done.
[12:50] <barry> #endmeeting
[12:50] <MootBot> Meeting finished at 06:50.
[12:50] <barry> thanks everybody
[12:53] <jelmer> thanks barry
[16:01]  * slangasek waves
[16:01] <mvo> hello
[16:01]  * stgraber waves
[16:02] <jhunt> o/
[16:02] <psurbhi> o/
[16:02] <slangasek> #startmeeting
[16:02] <MootBot> Meeting started at 10:02. The chair is slangasek.
[16:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:02] <slangasek> [TOPIC] lightning round
[16:02] <MootBot> New Topic:  lightning round
[16:02] <slangasek> let's dive right in :)
[16:02] <slangasek> $ echo $(shuf -e cjwatson barry doko csurbhi stgraber jhunt mvo ev vorlon bdmurray)
[16:02] <slangasek> mvo cjwatson stgraber doko csurbhi barry bdmurray ev vorlon jhunt
[16:03] <slangasek> mvo: how's it goin'/
[16:03] <mvo> jo
[16:04] <mvo> software-center: work on qml branch (basic UI works and animations etc are really cool and simple to do), work on a bunch of branch merges (backend refactor, weblive-x2go, lp790450-for-4.0, ...), add support for icon-download-url from s-c-agent, SRU for 4.0.3 that includes propoer pagination support
[16:04] <mvo> gdebi: work on gtk3 version and upload to oneiric
[16:04] <mvo> apt: fix wrong test for invlaid packages files
[16:04] <mvo> update-manager: make releasenotes display between check-release-update-gtk and update-manager consitent, port to oneiric vte, add profiles for natty->oneiric automatic testing
[16:04] <mvo> sponsor indicator-multiload
[16:04] <mvo> review/merge lp:~j-johan-edwards/archive-crawler/use-aptfile for improve archive-crasler (j-johan-edwards rocks!)
[16:04] <mvo> (done)
[16:05] <stgraber> oh right, no cjwatson today :)
[16:05] <stgraber> Looked at isc-dhcp-client-udeb to make sure it works for both DHCPv4 and DHCPv6.
[16:05] <stgraber> Got Software Center to play nicely with both x2go and qtnx, including proper status report and dealing with exceptions.
[16:05] <stgraber> Started looking at what would be needed to get a working Edubuntu by tomorrow (hopefully, not much)
[16:05] <stgraber> Played with xpra as a potential way of filtering/isolating X apps, to be used in Arkose for desktop app containing.
[16:05] <stgraber> Did a few merges (more to come)
[16:05] <stgraber> Looked at the new sssd and got a community member to take care of getting the missing build-dep in Ubuntu (and to Debian) so hopefully I should be able to upload the latest release to Ubuntu quite soon, fixing bug 757499 and bug 746981.
[16:05] <stgraber> Today I'm planning on fixing Edubuntu so we can get an alpha-1.
[16:05] <mvo> x2goooooo \o/
[16:05] <stgraber> Rest of the week will likely be spent working on Arkose. Porting it to pygi, lxc and get xpra integrated with it. Then work on getting test packages using it.
[16:05] <stgraber> I'll also probably spend a bit of time blogging on x2go, lxc (on armel) and arkose (once I get something working nicely).
[16:05] <stgraber> (done)
[16:06] <stgraber> yeah!
[16:06] <mvo> stgraber: there was a guy (ximion) interessted in using it for some packagekit releated project
[16:06] <mvo> it == arkose
[16:06] <stgraber> cool
[16:07] <slangasek> stgraber: isc-dhcp-client-udeb> AFAICS we should just drop udhcpcd in favor of this everywhere, shouldn't we?
[16:07] <stgraber> slangasek: yep, mentioned it to cjwatson and I guess we should just make netcfg depend on it, the code will then use it instead of udhcpc
[16:07] <stgraber> slangasek: then we'll need to teach netcfg about the -6 option to do both dhcpv4 and dhcpv6 (you need two instances of dhclient for that)
[16:08]  * slangasek nods
[16:08] <slangasek> so what's broken with edubuntu today?
[16:09] <stgraber> gnome-classic :)
[16:09] <slangasek> heh, alrighty
[16:09] <slangasek> no doko_ at the moment, so...
[16:09] <slangasek> psurbhi:
[16:09] <stgraber> I just did a seed change to include gnome-session-fallback and uploaded a new edubuntu-artwork to set it as default :)
[16:10] <psurbhi> *) changing the event handling for pivot event to an initctl command interface. Mostly done. But need to work on passing arguments to the real init (as the argument parser cuts off the --args which are not registered and in our case depending on the init the args could be anything)
[16:10] <psurbhi> *) working on an ext4 bug (but mostly working on the admin stuff before actually getting a chance to work on the bug :-/) wrote one patch for not marking inode dirty when filesystem is frozen. Testing that.
[16:10] <psurbhi> *) National holiday in Finland tomorrow.
[16:10] <psurbhi> (done)
[16:11] <barry> short week due to usa holiday; merges: python-numpy, python-support; worked on python 3.1 eradication; worked on a little aptdb tool (lp:~barry/+junk/aptdb); udd stakeholders meeting; done.
[16:11] <slangasek> psurbhi: when do you plan to set upstart-in-initramfs loose on us? :)
[16:11] <psurbhi> slangasek, i need to finish the argument parsing, then a little testing and then i will let it loose
[16:11] <psurbhi> hopefully next week end
[16:11] <psurbhi> or the beginning of the week after the next
[16:11] <psurbhi> :)
[16:11] <slangasek> sweet
[16:12] <james_w> barry, what's aptdb?
[16:12] <psurbhi> slangasek, provided the upstart patch is accepted
[16:12] <slangasek> a mouthful
[16:12] <psurbhi> by keybuk and James
[16:12] <slangasek> psurbhi: <nod>
[16:12] <barry> james_w: it a dumb little tool for parsing the _Sources file into a sqlite db so you can do sql queries on things.  i really dislike grep-dctrl ;)
[16:13] <james_w> heh
[16:14] <slangasek> barry: fwiw, the current round of CDs for alpha1 are coming in about 24MB oversized; the sooner we have a ballpark figure for the impact of python3, the better... :)
[16:14] <barry> the nice thing is that only takes about 4m on my box to parse and populate the db.
[16:14] <barry> slangasek: gotcha
[16:15] <slangasek> bdmurray:
[16:15] <bdmurray> branches for update-manager, meta-release and aptdaemon, finish teams in ubuntu bug control membership policy spec
[16:15] <bdmurray> uploading fix for LP: #769205 (python-pysnmp4) to lucid-proposed and updating the bug for the SRU process
[16:15] <mvo> \o/
[16:15] <bdmurray> launchpad greasemonkey script fixs for display dup count and date last updated, uploaded new version of firefox-lp-improvements
[16:15] <bdmurray> moving ftbfs milestones from alpha-1 to alpha-2
[16:16] <bdmurray> adding package person upload count code to ubuntu-qa-tools
[16:16] <bdmurray> handing off the ubuntu boot speed project to patrickmw
[16:16] <bdmurray> (done)
[16:16] <slangasek> bdmurray: what's the membership policy spec? (link?)
[16:17] <bdmurray> https://blueprints.launchpad.net/ubuntu/+spec/other-qa-o-ubuntu-bugcontrol-membership-policy
[16:17] <slangasek> thanks
[16:18] <slangasek> heh, it even shows up on http://status.chrisjohnston.org/ubuntu-oneiric/canonical-foundations.html now \o/
[16:18] <slangasek> ev:
[16:18]  * slangasek leaks beta urls into the channel :)
[16:18] <ev> Done:
[16:18] <ev> - Investigated the state of the gobject-introspected Cheese bindings, as well
[16:18] <ev>   as our own C-based approach.  The latter is slightly buggy, not properly
[16:18] <ev>   initializing gstreamer (though this can be worked around easily), and the
[16:18] <ev>   former, like so many other GI-based APIs seems to be at best a guessing
[16:18] <ev>   game.
[16:18] <ev> - Started the gobject-introspection migration of Ubiquity and port to GTK+3.
[16:18] <ev>   This has been slow going due to the lack of proper documentation, or even a
[16:18] <ev>   dump of the API.  Currently fighting unicode interaction in Gtk.ListStore.
[16:18] <ev>   Kill me now.
[16:18] <ev> - MIRs for python-xklavier and xvfb.
[16:18] <ev> - Added pyflakes checking to the check make target in ubiquity. This includes
[16:18] <ev>   code to filter out errors that we don't care about, but should massively
[16:18] <ev>   help avoid silly typo uploads - I hope.
[16:18] <ev> - Upgraded main development machine to Oneiric. Spent the morning fighting a
[16:18] <ev>   udev bug.  Thanks to jibel and pitti for discovering and fixing it.
[16:18] <ev> - Discussed the measuring installation failure / success proposal with mdz.
[16:18] <ev>   Replied to Kees on the technical-board mailing list, attempting to address
[16:18] <ev>   his concerns with the proposal.
[16:18] <ev> - Fought ubiquity dependencies to the death in trying to get a new version
[16:18] <ev>   out. Lost, but Colin caught an error in the unit tests that was the source
[16:18] <ev>   of the build breakage.
[16:19] <ev> TODO:
[16:19] <ev> - Build out more unit tests as I port ubiquity to GTK+3/PyGI/Python 3,
[16:19] <ev>   starting with full coverage of gtkwidgets.py.
[16:19] <ev> - Still need to reply to more of the discussion around installation failure /
[16:19] <ev>   success.
[16:19] <ev> - Need to figure out what the next steps are with respect to the automatic
[16:19] <ev>   crash reporting and database.
[16:19] <ev> - Need to sit down with mpt and work out what the long-term vision around
[16:19] <ev>   feedback collection, starting with cancelling the installation, will be.
[16:19] <ev>   This will help determine whether Mozilla Input / Feedback is overkill for
[16:19] <ev>   said task. Then obviously I need to finish deploying Mozilla Feedback
[16:19] <ev>   locally, modifying it along the way to suit our needs.
[16:19] <ev> - Need to follow up with John Lea and Ale on the Wubi design work, then start
[16:19] <ev>   integrating the migration stuff.
[16:19] <ev> (done)
[16:19]  * slangasek scrambles to hold the papers down on his desk as ev blows through
[16:19] <ev> lol
[16:20] <mvo> yeah, don't do this while I drink tea, dangerous to me equipement!
[16:20] <ev> haha
[16:20] <mvo> and my sympathies for the gtk3/gi, I feel the same when it comes to porting s-c
[16:21] <slangasek> ev: xvfb has been in main forever, what's the MIR there?
[16:22] <ev> hmm, maybe it wasn't xvfb then
[16:22]  * ev checks
[16:22] <ev> (do continue, I'll report back)
[16:23]  * slangasek nods
[16:23] <slangasek> me next
[16:23] <slangasek> short week due to US holiday
[16:23] <slangasek> getting the last of my multiarch deltas flushed to oneiric from ppa
[16:23] <slangasek> working with Debian maintainers to get multiarch landed upstream so we can get rid of our deltas
[16:23] <slangasek> finishing off spec approvals... behind on this, if you're still waiting for a spec, you can yell at me now
[16:23] <slangasek> following up on some tricky merges
[16:23] <slangasek> turning the cranks for alpha-1 this week
[16:23] <slangasek> EOF
[16:23] <slangasek> and if there are no questions... jhunt:
[16:23] <jhunt> Short week. Remainder: Upstart bzr merge hell.
[16:23] <jhunt> EOT
[16:23] <jhunt> Note quite that bad, but very painstaking. See
[16:23] <jhunt> lp:~jamesodhunt/upstart/1.3 on my lp code page for progress. Plan:
[16:23] <jhunt> finish natty merges into 1.3 branch and release Upstart 1.3. Then, add
[16:23] <jhunt> psurbhis initramfs changes, discuss oneieric plans on ML and then
[16:23] <jhunt> start coding!
[16:23] <jhunt> EOT (really this time :)
[16:25] <slangasek> should lp:upstart be redirected to lp:~jamesodhunt/upstart/1.3 now?
[16:25] <jhunt> well, we could redirect now, but that branch is changing very rapidly right now and isn't fully tested yet.
[16:26] <slangasek> well, does it build / run? :)
[16:26] <jhunt> I was planning to finish the merging, test thoroughly, update my upstart ppa with the code and invite feedback and then switch the link.
[16:26] <slangasek> as you wish :)
[16:26] <jhunt> "yes", but due to the number of changes, I'm not remerging into an ubuntu pkg for each change, building, and actually testing that a system boots with that commit.
[16:27] <slangasek> ok
[16:27] <jhunt> That has to happen, but I was planning to do the next round of such testing when I finish merging the visualisation code (prolly today/tomorrow AM)
[16:27]  * slangasek nods
[16:27] <jhunt> CI could be useful to me right now :)
[16:27] <slangasek> heh
[16:27] <slangasek> segway....
[16:28] <slangasek> [TOPIC] CI support from QA team
[16:28] <MootBot> New Topic:  CI support from QA team
[16:28] <slangasek> I sent out an email call for recommendations of packages the QA team could start doing CI on
[16:29] <slangasek> because they're keen to get continuous integration coverage of the system, and who are we to argue!
[16:29] <mvo> the auto-upgrade-tester stuff would be good
[16:29] <mvo> I would love to hand this off
[16:29] <slangasek> so if you have packages... like upstart... that you'd like CI for, let me know
[16:29] <slangasek> mvo: this is testing that upgrades run successfully from the previous release to the current dev release, yes?
[16:29] <psurbhi> I would like initramfs tested once the changes are in
[16:30] <mvo> slangasek: yes
[16:31] <slangasek> psurbhi: how do you think we can structure such tests?  Is it just to make sure the system boots to userspace after a change to the initramfs packages (upstart, initramfs-tools, busybox)?
[16:31] <psurbhi> slangasek, yes
[16:31] <slangasek> ok
[16:32] <psurbhi> but that needs to be done for desktop, servers with different configurations
[16:32] <psurbhi> like md array, lvm, crypted devices, none of these, etc
[16:32] <doko_> hi
[16:32] <ev> isn't this the wrong way around? Shouldn't we be coming up with a list of the things that should be tested and run under a CI system, rather than the tests that could be restructured under CI? Or am I missing the point entirely? :)
[16:33] <mvo> the apt testsuite would be another candidate indeed
[16:33] <slangasek> psurbhi: alright - I'll pass it on to QA that this is one of our target areas, if you can get me a list of things we need to test we can set them to work on getting the configs up
[16:34] <psurbhi> slangasek, sure, will do that.. thanks!
[16:34] <slangasek> ev: well, we don't want to rerun initramfs tests after *any* package has changed... just trying to get a feel for what we think we need tested when
[16:34] <ev> apologies, that was a bit poorly worded on my part
[16:35] <ev> at what step do we sit down and determine the things that we're not testing, and come up with a plan to test them
[16:35] <ev> l
[16:35] <ev> larger components, for example, like how do we test grub exactly
[16:35] <slangasek> so I've got initramfs, auto-upgrade-tester, apt testsuite.  If anyone has other ideas of packages we want QA to test for us, shoot me an email
[16:36] <slangasek> ev: let me add grub to the list then, we'll see what QA can figure out ;)
[16:36] <slangasek> doko_: hey there!  would you like to give a status update?
[16:36] <doko_> - filed MIR's, reviewed and promoted packages for component mismatches
[16:36] <doko_> - some merges
[16:36] <doko_> - built OpenJDK 7, now in the archive, JamVM bug triage
[16:36] <doko_> - GCC updates
[16:36] <doko_> - Linaro toolchain WG call
[16:36] <ev> slangasek: cool, thanks
[16:36] <doko_> not much interesting ...
[16:37] <slangasek> uninteresting GCC updates... that's good :-)
[16:37] <doko_> well, some wrong-code fixes =)
[16:38] <slangasek> any wrong code that we should be concerned about?
[16:39] <jhunt> anything armel related?
[16:39] <doko_> I don't know, libstdc++ was found mis-compiled
[16:39] <slangasek> ah, but who uses that
[16:40] <doko_> nothing armel related. we didn't have linaro updates after the initial one
[16:40] <slangasek> [TOPIC] AOB
[16:40] <MootBot> New Topic:  AOB
[16:40] <slangasek> Good news, bad news?
[16:41] <bdmurray> I'm still looking for insight regarding aptdaemon crash report quantities ... https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033302.html
[16:41] <slangasek> jhunt: I think finding that CA is not the blocker for upstart we thought it would be is good news :)
[16:41] <mvo> s-c qml branch is basicly working, can show categories, pkglist, details, install stuff search
[16:41] <ScottK> There's a python-defaults with 2.7 as default in experimental so it's easier for Debian people to test.  Another step along the way ...
[16:41] <ScottK> This is relevant for when we'll drop 2.6.
[16:42] <jhunt> slangasek: good point! It *has* simplfied the merge work.
[16:42] <barry> ScottK: \o/
[16:42] <slangasek> mvo, barry: any idea on bdmurray's aptdaemon issue?
[16:43] <slangasek> ScottK: how close is that to going to unstable?
[16:43] <barry> slangasek: not off the top of my head, but i can investigate a bit
[16:43] <mvo> bdmurray: I need to look into this
[16:43] <slangasek> ok, you two can thumb wrestle for the honor
[16:43] <ScottK> slangasek: I think the critical path item will be a transition slot from the release team.
[16:44]  * ScottK didn't formally ask for one yet, but has started discussions and research for the official bug filing.
[16:44] <bdmurray> okay, thanks
[16:44] <mvo> bdmurray: I suspect (correct me if I'm wrong) that actually writing the report (like aptdaemon is doing) is enough to trigger the code in u-n to fire up the GUI to report it even if the actual daemon is disabled
[16:44] <barry> ScottK: i haven't seen much progress on debian bug 622279
[16:45] <slangasek> ScottK: does that actually require a coordinated transition into testing?
[16:46] <ScottK> slangasek: It does require some coordination.  It's not exactly like a library transition, but we can end up tying multiple transitions together if we're not careful.
[16:46] <slangasek> ok
[16:46] <mvo> bdmurray: yeah, that seems to be it
[16:46] <ScottK> barry: Mostly the blockers are otherwise broken/we decided we aren't going to let it stop us.
[16:46] <barry> ScottK: excellent
[16:47] <ev> going to be attempting to create a status board in the office as a fun weekend project with Iain (http://hungfu.wordpress.com/2010/03/14/not-that-kind-of-bored/). Suggestions welcome for useful data points that would define how close we are to a finished Ubuntu release.
[16:48] <slangasek> other than a burndown chart? :)
[16:48] <bdmurray> mvo: hunh, I thought apport had to be running to detect and deal with a file in /var/crash
[16:49] <ev> slangasek: indeed, other than the burndown charts :)
[16:49] <ev> those are the obvious ones, perhaps
[16:49] <ev> though as it will be presumably be viewed by people in the office, they don't really care about things like release bugs
[16:49] <mvo> bdmurray: apport will detect crashes when it runs, but aptdaemon will bypass that by catching the crash directly, this is also the case with apt itself, so this explains the many reports it seems
[16:49] <ev> (and those are entirely unhelpful in the early stages anyway)
[16:50]  * slangasek nods
[16:51] <slangasek> #endmeeting
[16:51] <MootBot> Meeting finished at 10:51.
[16:51] <ev> thanks!
[16:51] <barry> thanks!
[16:51] <slangasek> alrighty... back to work
[16:51] <slangasek> thanks all :)
[16:51] <ScottK> ev: Isn't 'the release is finished' defined by 'the calendar says this is release day'?
[16:51] <stgraber> thanks!
[16:51] <jhunt> thx
[16:51] <ev> ScottK: don't get me started on that one :-P
[16:51] <ScottK> ;-)
[16:51] <mvo> thanks
[16:52] <mvo> oh, pucblic holiday tomorrow in germany!
[18:00]  * charlie-tca waves
[18:00] <charlie-tca> Let's get this Ubuntu QA team meeting rolling
[18:00]  * bdmurray waves
[18:00] <charlie-tca> #startmeeting
[18:00] <MootBot> Meeting started at 12:00. The chair is charlie-tca.
[18:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:00] <charlie-tca> As usual, the full agenda is available at https://wiki.ubuntu.com/QATeam/Meetings
[18:01] <charlie-tca> Previous Actions (all)
[18:01] <charlie-tca> Community Efforts/Testing
[18:01] <charlie-tca> Automated/Systems Testing
[18:01] <charlie-tca> Engineering Team Bug Status
[18:01] <charlie-tca> Other Topics
[18:01] <charlie-tca> Chair Selection
[18:01] <charlie-tca> since we can't all get the pages to load when we would like them to.
[18:01] <charlie-tca> [TOPIC] Previous Actions
[18:01] <MootBot> New Topic:  Previous Actions
[18:02] <charlie-tca> I do not recall any. Does anyone else know of a previous item we need to discuss?
[18:02] <charlie-tca> [TOPIC] Community Efforts/Testing
[18:02] <MootBot> New Topic:  Community Efforts/Testing
[18:02] <bdmurray> I believe hggdh wanted me to publish some code (to find number of packages uploaded by people) which I did
[18:02] <bdmurray> I put it in ubuntu-qa-tools for lack of a better idea
[18:02] <charlie-tca> Thank you
[18:03] <jibel> o/
[18:03] <charlie-tca> go ahead, jibel
[18:04] <jibel> A word about SRU testing and another about Oneiric Alpha1
[18:04] <jibel> SRU Testing: 7 new high importance bugs need verification this week
[18:04] <jibel> bug 728088 open-iscsi (Natty) High
[18:04] <jibel> bug 755608 ntrack (Natty) High
[18:04] <jibel> bug 772185 nux (Natty) High
[18:04] <jibel> bug 777759 casper (Lucid, Maverick, Natty) High
[18:04] <jibel> bug 778520 mdadm (Natty) Critical
[18:04] <jibel> bug 781874 aptdaemon (Natty) High
[18:04] <jibel> bug 784888 vm-builder (Natty) High
[18:05] <jibel> and we still need verification of
[18:05] <jibel> bug 695290 grub2 (Lucid, Maverick) High
[18:05] <jibel>     Requires dual RAID controllers
[18:05] <jibel> bug 778026 lirc (Natty) Critical
[18:05] <jibel>     Requires an Infrared Remote Control
[18:05] <jibel> The complete list is available at
[18:05] <jibel> [LINK] http://reports.qa.ubuntu.com/reports/sru/latest.html
[18:05] <MootBot> LINK received:  http://reports.qa.ubuntu.com/reports/sru/latest.html
[18:05] <jibel> and http://people.canonical.com/~ubuntu-archive/pending-sru.html
[18:06] <jibel> so please go there and test a SRU
[18:06] <jibel> any question about SRU testing ?
[18:06] <charlie-tca> Thank you very much. Let's see if we can get those SRU's done this week, everybody. :-)
[18:07] <jibel> ok, Oneiric Alpha 1 ISO Testing
[18:07] <jibel> Image were published very late to fix with udev, apt and ubiquity defects, and kubuntu images have been published a few hours ago only. So the image coverage is low:
[18:07] <jibel>  * Image Coverage       : 36.51% (23/63)
[18:08] <jibel> on the other hand no release blocker have been found at this stage of the testing.
[18:08] <jibel> The main issues discovered concern unity-2d:
[18:08] <jibel> bug 791213 , bug 791127
[18:08] <jibel> 2 very common crashes:
[18:08] <jibel> bug 788714 , bug 788710
[18:08] <jibel> a theming issue with nautilus: bug 784209
[18:08] <jibel> 7 reports need a confirmation. The complete list is available at http://reports.qa.ubuntu.com/reports/isotesting/oneiric/opened.html
[18:09] <jibel> especially bug 791121 which has been fixed yesterday but a tester is still facing it with the latest desktop build.
[18:09] <jibel> And we need more testing on real hardware or in VMs with 3D enabled to heavily test Unity (not 2D)
[18:09] <jibel> So, join us on #ubuntu-testing and help us to cover the remaining cases.
[18:10] <jibel> Thanks for your help!
[18:10] <jibel> ..
[18:10] <charlie-tca> Thanks, jibel . Any help we can get with testing these images would be greatly appreciatedQ!
[18:10] <charlie-tca> Any questions about alpha1 testing?
[18:11] <charlie-tca> [TOPIC] Automated/Systems Testing
[18:11] <MootBot> New Topic:  Automated/Systems Testing
[18:11] <charlie-tca> I'm still learning these new agenda items. Anyone to talk about automated testing?
[18:12] <charlie-tca> Okay, Maybe we will see someone before the meeting ends...
[18:12] <charlie-tca> [TOPIC] Engineering Team Bug Status
[18:12] <MootBot> New Topic:  Engineering Team Bug Status
[18:12] <charlie-tca> pedro_: ?
[18:12] <pedro_> yes? :-)
[18:13] <pedro_> not much to share, we had a great Compiz bug day on last Thursday so thank you guys for helping!
[18:13] <pedro_> and as a quick reminder this week we're having a bug day for Evolution: https://wiki.ubuntu.com/UbuntuBugDay/20110602
[18:13] <pedro_> so if you use/like/love that application and wanna learn a bit more about it, please join us tomorrow the *whole* day your timezone
[18:14] <pedro_> as always at the #ubuntu-bugs channel where the cool people hang ;-)
[18:14] <pedro_> ..
[18:15] <charlie-tca> Thank you, pedro_ . Any questions for Engineering Team?
[18:15] <bdmurray> I've nothing special to report
[18:16] <charlie-tca> Thank you, bdmurray.
[18:17] <charlie-tca> [TOPIC] Other Topics
[18:17] <MootBot> New Topic:  Other Topics
[18:17] <patrickmw> o/
[18:17] <xdatap1> o/
[18:17] <charlie-tca> go ahead, patrickmw
[18:17] <patrickmw> sorry, I'm late. I was on an urgent call.  Quick automation update:
[18:17] <patrickmw> Ubuntu Package Testing:
[18:17] <patrickmw> - Received package lists from Desktop and Server teams
[18:17] <patrickmw> * Currently creating the Jenkins job config files for easy import to the new CI server
[18:17] <patrickmw> Kernel SRU Testing:
[18:17] <patrickmw> - Autotest has been split into the individual test suites
[18:17] <patrickmw> - Original suites are compressed and live in a new project also contain Ubuntu patches (for testing)
[18:17] <patrickmw> * Currently testing that the patching and remote execution work as expected
[18:17] <patrickmw> ..
[18:19] <charlie-tca> Thank you for the update, patrickmw
[18:19] <charlie-tca> go ahead, xdatap1
[18:19] <xdatap1> thank you charlie-tca
[18:19] <xdatap1> It's about bug workarounds
[18:19] <xdatap1> For those who don't know me, my name's Paolo Sammicheli, community guy from Italian LoCo, involved in testing.
[18:19] <xdatap1> Last UDS in Budapest, while discussing ubuntu friendly program people expressed the idea that the workaround is an useful information from an end user point of view.
[18:19] <xdatap1> I though about it a litte and then, after chatting with people involved in QA I decided to draft a blueprint for proposing the idea.
[18:19] <xdatap1> https://wiki.ubuntu.com/BugsKnownWorkAround
[18:19] <xdatap1> After drafting the blueprint I was pointed to the following bug which was proposed back in 2006
[18:19] <xdatap1> https://bugs.launchpad.net/launchpad/+bug/54652
[18:20] <xdatap1> where somebody suggested me to raise the discussion on the launchpad-dev mailing list.
[18:20] <xdatap1> The discussion was not so long, you can read it by thread starting from here:
[18:20] <xdatap1> https://lists.launchpad.net/launchpad-dev/msg07174.html
[18:20] <xdatap1> As usual somebody thinks it's a nice idea, somebody else thinks it's not really necessary.
[18:20] <xdatap1> The thing is, I'm a bit lost on that mailing list. I'm not sure what to do also because I probably miss the big picture.
[18:20] <xdatap1> You (or better, We) guys are the guardians of the quality in ubuntu. Do we really think that this idea would be useful?
[18:20] <xdatap1> Otherwise I would stop bother the launchpad people with this thread.
[18:20] <xdatap1> :)
[18:21] <charlie-tca> I like the idea of a separate box for workarounds. It removes it from the jumble of the descrtip
[18:21] <charlie-tca> description, which can get quite involved
[18:22] <charlie-tca> anyone else have an opinion on this?
[18:22] <patrickmw> I don't think its really necessary.  I feel adding WORKAROUND: in the description field is adequate
[18:23] <bdmurray> I don't think a separate bit is necessary either and maybe adding a tag in addition to the description modification would be a good idea
[18:24] <charlie-tca> xdatap1: looks bad for adding a separate block
[18:25] <xdatap1> the goal, from a community point of view, would be to export it (forum, ask ubuntu, etc) and to search for it. How to implement it it's not really important, imho. If parsing the description would work it's ok
[18:25] <patrickmw> I like the tagging idea
[18:25] <xdatap1> do you think that the features it's needed?
[18:25] <xdatap1> apart the implementation
[18:26] <charlie-tca> I would recommend not pursueing it, just try to teach the triagers that it should be WORKAROUND: in caps at the bottom of the description, along with a tag?
[18:26] <bdmurray> before starting work it'd probably be a good idea to see how many bugs have workarounds
[18:26] <charlie-tca> Is there a way to search the description for it?
[18:27] <bdmurray> charlie-tca: I have my ways
[18:27] <charlie-tca> heh, yeah, I figured
[18:27] <patrickmw> bdmurray is the LP Wizard
[18:27] <charlie-tca> xdatap1: might want to get with bdmurray on it then.
[18:28] <xdatap1> charlie-tca, perfect. If I can help more just let me know
[18:28] <charlie-tca> The Workaround is needed, especially on a bug that gets tons of comments, since it can get buried fast in a comment
[18:28] <charlie-tca> Thanks for bringing that up
[18:28] <xdatap1> bdmurray, thanks in advance :)
[18:28] <charlie-tca> Anyone else have something to discuss?
[18:29] <bdmurray> charlie-tca: maybe we should document that as a thing to do for next meeting?
[18:30] <charlie-tca> bdmurray to find the numbers of bugs with WORKAROUNDS, so we can discuss a possible tag for them.
[18:30] <charlie-tca> sound right?
[18:30] <charlie-tca> [ACTION] bdmurray to find the numbers of bugs with WORKAROUNDS, so we can discuss a possible tag for them.
[18:30] <MootBot> ACTION received:  bdmurray to find the numbers of bugs with WORKAROUNDS, so we can discuss a possible tag for them.
[18:31] <bdmurray> well, I think just tagging them workaround is a good idea too
[18:31] <bdmurray> then repromote using workarounds in the bug description and see how many we have
[18:31] <charlie-tca> I do to. It would make them easier to search for, too
[18:31] <bdmurray> before working on exporting them somewhere else
[18:32] <charlie-tca> That sounds right to me
[18:32] <charlie-tca> and last but not least,
[18:32] <charlie-tca> [Next Chair]
[18:33] <charlie-tca> [TOPIC] Next Chair
[18:33] <MootBot> New Topic:  Next Chair
[18:33] <charlie-tca> Do we have any volunteers to chair the next meeting?
[18:34] <charlie-tca> It's not that hard, and you get the previous business action item, too!
[18:34] <charlie-tca> We all get to be anyway, too
[18:34] <bdmurray> I'll do it
[18:34] <charlie-tca> Thank you, bdmurray
[18:35] <charlie-tca> I really appreciate that
[18:35] <charlie-tca> [ACTION] bdmurray to chair next meeting, 2011-06-08
[18:35] <MootBot> ACTION received:  bdmurray to chair next meeting, 2011-06-08
[18:35] <charlie-tca> There being no more business,
[18:35] <charlie-tca> #endmeeting
[18:35] <MootBot> Meeting finished at 12:35.
[18:35] <charlie-tca> let's all get back to testing and work, right? :-)
[18:36] <pedro_> thanks!
[18:36] <xdatap1> thank you!
[18:36] <charlie-tca> You are welcome
[18:40] <skaet> Thanks all.