=== noy_ is now known as noy === JasonO_ is now known as JasonO === noy__ is now known as noy === yofel_ is now known as yofel === ghostcube_ is now known as ghostcube [11:59] poke barry [12:00] jam: hi! [12:00] hi [12:00] Riddell: hi! [12:00] see, I *can* make it to meeting [12:00] meetings [12:00] \o/ [12:00] :) [12:00] #startmeeting [12:00] Meeting started at 06:00. The chair is barry. [12:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [12:00] hello everyone and welcome to this week's udd steering committee meeting. who's here today? [12:01] hi all [12:01] hi [12:01] hi [12:01] Hi [12:01] moi [12:01] [LINK] https://wiki.ubuntu.com/DistributedDevelopment/20110504 [12:01] LINK received: https://wiki.ubuntu.com/DistributedDevelopment/20110504 [12:01] hello [12:02] * poolie prods vila [12:02] it's probably a little early for slangasek :) [12:03] hi [12:03] hi! [12:03] poolie: vila isn't in the channel [12:03] let's go? [12:03] okay! [12:03] what a great uds [12:03] [TOPIC] action items [12:03] New Topic: action items [12:04] poolie: it was! [12:04] * jam to propose/report plan for quilt imports [12:04] now, i know there was an idea that maybe there was a better/easier way to accomplish the same goal w/o looms? [12:04] i don't think jam specifically sent a plan about it [12:04] barry: no specific progress. Focused on other things, but I think this is still one of the "we need to get to this soon" for UDD [12:04] there was some interesting discussion about this along the lines of [12:05] maybe we should just do the merge in a similra way and at least as well as people do by hand [12:05] and then later move to looms [12:05] so that would be basically, take the patches off the wt, reapply them merging as you go [12:05] I think there was also a question of whether we could just write a helper that could stitch together quilts as part of post-merge stuff [12:05] right [12:06] i guess we should have an action to make a specific proposal nad decisiono on this [12:06] it is a compromise [12:06] but perhaps a good intermediate one [12:06] poolie: though it might also lead to something that allows us to merge looms, which we also don't have yet [12:06] indeed [12:06] at least, leads us to exploring the area, even if the exact code isn't usable [12:07] do people want to discuss it here and now or should we just leave the item to make a proposal [12:07] poolie: i agree. i think we should remove jam's action item and replace it with one to study the feasibility of merge helper instead. [12:07] jelmer, would you take that? [12:07] poolie, already in my queue :) [12:08] bug 608675 [12:08] cool [12:08] Launchpad bug 608675 in bzr-builddeb "merge-package should have support for manipulating quilt v3 patch stacks" [High,In progress] https://launchpad.net/bugs/608675 [12:08] next? [12:08] I think the infrastructure we'd add to support that would be useful for some other kinds of custom merges, so even if it's not used by udd in the long term it's still a useful investment for bzr. [12:08] yes [12:08] jelmer: awesome. jam: any objections to removing your action item? [12:08] barry: fine with me [12:08] well, regarding looms, I already encountered bugs with just trying to use the same loom on my desktop and my laptop, i.e. just pushing looms has already some rough edges, I think I understand enough now to write failing tests for it [12:08] [ACTION] jelmer to study the feasibility of merge helper (bug 608675) [12:08] ACTION received: jelmer to study the feasibility of merge helper (bug 608675) [12:09] vila: as i mentioned to poolie, i'm somewhat conflicted, because aside from udd, i'd still love to see great support for looms :) [12:09] right [12:10] vila, poolie is there an action item lurking there for next time? [12:10] however, perhaps we should skew mor etowards shorter dependency chains [12:10] barry: me too, I think properly working looms would be really nice for this [12:10] oh, what I meant was that I will work on that as I definitely want better loom support [12:10] not blocking quilt support on getting great looms, including in lp etc [12:10] right, let's get rid of the rough edges first [12:11] poolie: +1 [12:11] sounds good. no action item then, but if you have some good stuff to report next time, we'll definitely make time for that [12:11] it's partly the lp dependency that tips the scales for me [12:11] tehy are supported but you can't properly viwe or review them yet [12:11] k [12:11] yep [12:12] okay, this one's done but just ftr: [12:12] * poolie to send link to plenary proposal. all to help finish that [12:12] [12:12] just to be clear, the oaction here is that jelmer will make a more detailed proposal about doing it this one [12:12] yes, i'm happy it was done [12:12] seemed pretty popular [12:12] jml and james_w also did cool presesntations [12:12] yep, both were great. definitely check out the online videos (not sure if they're up yet) [12:13] [TOPIC] * UDS-O session review [12:13] New Topic: * UDS-O session review [12:13] * https://blueprints.launchpad.net/udd/+spec/foundations-o-udd-planning [12:13] * https://blueprints.launchpad.net/udd/+spec/foundations-o-udd-onramp [12:13] notes at http://summit.ubuntu.com/uds-o/meeting/foundations-o-udd-onramp/ [12:13] and http://summit.ubuntu.com/uds-o/meeting/foundations-o-udd-planning/ [12:14] thanks [12:14] these were also good [12:14] the onramp session was less onramp and more feedback. i was really happy to see a general enthusiasm and buy-in for udd. [12:14] yes, definitely a step up since last time [12:14] i should probably take an action to send a condensed form of these [12:14] good idea [12:15] [ACTION] poolie to send condensed summary of uds sessions [12:15] ACTION received: poolie to send condensed summary of uds sessions [12:15] there are a bunch of things but it seemed there was agreement the most useful immediate thing was to get all imports working [12:15] thats also a nice simple clear goal [12:16] there was a run-down of the top failures, and none of the really big ones seemed intractable [12:16] so i propose to have the canonical-bazaar team do that first [12:16] iirc, fixing those would slash the failures roughly in half [12:16] right [12:16] do we want to timebox that effort? [12:17] some have been fixed this week [12:17] mm [12:17] Of the failures, the one most obviously in need of design is how to handle multiple source tarball packages [12:17] one good arbitrary time would be the next Canonical quarterly planning cycle [12:17] which would be [12:17] ... the start of august? [12:17] There are 66 multiple source tarball failures [12:18] so the goal is only "hard" failures left by the start of August? [12:18] maxb: what's the underlying cause of those? [12:18] pretty much [12:18] barry: The importer specifically omits support for them [12:18] or no failures left, except those with an explanation why it's not worth doing? [12:18] i think there is some kind of effect where the importer is seen as scary to change [12:18] or, not in the normal queue of things people look at [12:19] i'd like to crack that [12:19] poolie: wasn't getting all the imports working a goal many quarters ago? [12:19] yes, but there were too many other goals at the same time [12:19] fair enough. [12:19] so, this time for sure [12:20] poolie: perhaps we can have an action item for next time which would be a summary of the current importer failures and a rough HARD/NOTHARD classification, along with # of failures each would fix? [12:21] good idea [12:21] also, let's keep score every week of the count [12:22] great idea. who can i give that to? [12:22] http://webnumbr.com/ubuntu-package-import-failures [12:22] LINK received: http://webnumbr.com/ubuntu-package-import-failures [12:22] barry: I can try [12:22] The top failure right now is fallout from packagers doing push --overwrite --- that's a hard one, because it will involve a fair bit of looking at individual branches [12:22] Riddell: awesome, thaks [12:22] vila: there's also a graph at the bottom of http://package-import.ubuntu.com/status/ [12:22] er, thanks [12:23] [ACTION] Riddell to give summary of current failures w/HARD/NOTHARD classification [12:23] ACTION received: Riddell to give summary of current failures w/HARD/NOTHARD classification [12:23] right, honestly, none of them got the scale right though ;) [12:23] any other feedback on the uds sessions? [12:24] hm [12:24] spiv: but we could/should probably fix the one at p-i.u.c [12:24] i would like suggestions on organizational or other hacks we can do to get the right attention on udd [12:25] vila's link with spikes flattened somewhat: http://webnumbr.com/ubuntu-package-import-failures.below%283000%29 [12:25] i guess the other big thing at uds was discussion of bfbia [12:25] which seemed generally welcomed... [12:25] poolie: right, i should have included a link to that, sorry [12:25] but probably.. .better to get this done first then think about it [12:25] spiv: \o/ [12:26] if we do well, we may still have a prototype by uds-p [12:26] Why do we allow --overwrite for those branches? [12:26] poolie: that would rock. i want to convince ScottK by the sheer awesomeness of the feature :) [12:26] spiv, we simply have no way to prevent it afaik [12:27] poolie: that'd be neat :) [12:27] jelmer: well, setting append_revisions_only=True on those branches would at least discourage it? [12:27] indeed :) [12:27] doing that across all launchpad by default would be nice [12:27] there's a bug for that [12:28] shall we move on? [12:28] [TOPIC] * Package importer progress [12:28] New Topic: * Package importer progress [12:28] not sure there's much more to say about that one [12:29] so... [12:29] [TOPIC] * Bugs of interest: [12:29] New Topic: * Bugs of interest: [12:29] pretty much covered it [12:29] poolie: probably could be an action item. We could just go to the importer and do a for loop, since the james_w user can write to all those branches [12:29] seem slike we still got through a lot of bugs [12:29] [LINK] http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.htm [12:29] LINK received: http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.htm [12:29] you probably saw john's blog post [12:29] for $branch in branches: bzr config -d$branch append_revision_only=True [12:29] [LINK] http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html [12:29] LINK received: http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html [12:29] jelmer: heh, thanks [12:30] once again, stunningly impressive [12:30] the pqm machine is having a tough week :) [12:30] jam: does --overwrite honor append_revisions_only ? [12:30] :D [12:30] jelmer: I can't say without testing [12:31] one thing that sticks out there is the number of nonreleasede fixes [12:31] but it would still handle the primary case [12:31] perhaps we need bzr-svn etc releases? [12:31] most people don't --overwrite all the time [12:31] (or the data may be old) [12:31] poolie: not to mention that jubany is on 2.3 ? [12:32] vila: wasn't there an action to get that updated? [12:32] is it now? [12:32] it's not released yet [12:32] just checked, 2.3.1 [12:32] we could file an rt about that? [12:32] jelmer: quick testing: "bzr push --overwrite" > bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the [12:32] append_revisions_only setting on branch "C:/Users/jameinel/dev/,tmp/x/". [12:32] so, mostly: jml, james_w, barry, is there anything you think we should be doing but are neglecting? [12:33] jelmer: so yes, append_revisions_only refused --overwrite [12:33] poolie: bug 609187 ;) [12:33] Launchpad bug 609187 in Ubuntu Distributed Development "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Triaged] https://launchpad.net/bugs/609187 [12:33] jam: oh, great ! And what if you specify it in locations.conf ? [12:33] jam: ah, interesting [12:33] mm good idea [12:33] jam: I should add a test for that and fix bzr-svn/bzr-hg/bzr-git :) [12:33] oh, there's a related thing [12:33] jam: Thanks [12:33] which is that lp has been on a fairly old bzr for a while [12:34] In that case, we need a --really-overwrite before we can turn on append_revisions_only for UDD branches, as the importer needs to be able to overwrite the branch if it detects a collision [12:34] and the bug that blocks upgrading is now fixed [12:34] so, we can push that through [12:34] vila: it has the same affect, but it won't affect *anyone else* [12:35] maxb, we could potentially override append_revisions_only = False for the importer using locations.conf [12:35] maxb: the importer could temporarily unset that flag, push --overwrite, reset it. [12:35] jam: bah, sorry, badly worded. What if the remote branch has append_revisions_only=True, but you say a_r_o = False in locations.conf [12:35] vila: I would guess it would override [12:35] :-/ [12:35] just like all our other things do [12:35] vila: That seems sensible - if somebody really wants to override they can always just edit .bzr/branch/last-revision [12:36] vila: bzr has always been about consenting adults [12:36] I'm not sure if bzr+ssh will get in the way, and the remote bzr will refuse [12:36] that takes a bit more to test [12:36] yup, that's a flaw in our config scheme I think, this settings are under the server responsability and we should somehow require some special powers to change/override them [12:36] jam: :) [12:36] k [12:36] so after lp is running a new bzr, we can start doing something towards a warning message [12:36] maybe I should look at bug 609187 [12:37] what else? [12:37] Launchpad bug 609187 in Ubuntu Distributed Development "users are not warned when branching ubuntu:foo (or lp:ubuntu/foo) and the package import of foo is out of date" [High,Triaged] https://launchpad.net/bugs/609187 [12:37] that's the one [12:37] jelmer: that would be really great. it would really simplify the docs and give people peace of mind [12:37] hope you don't mind... [12:37] [ACTION] jelmer to look into bug 609187 [12:37] ACTION received: jelmer to look into bug 609187 [12:37] [LINK] https://launchpad.net/bugs/609187 [12:37] LINK received: https://launchpad.net/bugs/609187 [12:38] let's move on [12:38] we'll talk about it here [12:38] [TOPIC] AOB [12:38] New Topic: AOB [12:39] any good news, or other interesting items folks have? [12:40] we fixed a ton of bugs [12:40] srus are proceeding [12:40] riddell is getting some bugs fixed [12:40] 2.4 is going to be much faster for many things thanks to jam [12:41] i think that's it [12:41] thanks for coming guys [12:41] on that note [12:41] #endmeeting [12:41] Meeting finished at 06:41. [12:41] thanks everyone [12:42] thanks barry [12:44] thanks barry === TheDaniel0108 is now known as Daniel0108 === Quintasan_ is now known as Quintasan [16:00] gooooooooooood afternoon [16:00] hello [16:00] * slangasek waves [16:00] good morning too! :) [16:00] #startmeeting [16:00] Meeting started at 10:00. The chair is slangasek. [16:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [16:01] * stgraber waves [16:01] hi [16:02] [TOPIC] lightning round [16:02] New Topic: lightning round [16:03] hiya [16:03] $ echo $(shuf -e cjwatson barry doko csurbhi stgraber jhunt mvo ev vorlon bdmurray) [16:03] csurbhi barry vorlon ev jhunt cjwatson mvo doko bdmurray stgraber [16:04] is psurbhi here? [16:04] does "UDS week" count as "what I did last week" ? [16:04] barry: looking for csurbhi; do you want to start? [16:04] mvo: oh, but what did you do with the *rest* of your week? :) [16:04] starting on launchpad py27 ppa; udd stakeholders meeting; uds-o work items; pep 382 planning. todo: more of the same. done. [16:05] surely UDS only accounts for about 80 hours of your time... [16:05] csurbhi1: hey there, you're next :) [16:05] haha :) [16:05] jhunt is on holiday IIRC [16:05] yep [16:05] *) eye balled the ext4 mmapped patches [16:05] *) set up kvm for mdadm bugs - going through the old patchsets and testings [16:05] (done) [16:05] i had a very small week [16:05] was on a holiday on monday and tuesday [16:05] * slangasek nods [16:06] let's see, what have I done... [16:08] dealing out blueprint drafting to people; working to get an upstart sprint going this cycle; started drafting of my own blueprints [16:08] that's about it... [16:08] ev: [16:10] must be fire drill time ;P [16:10] cjwatson: [16:10] So far this week I have: [16:10] * worked on a bunch of transitions, as described on ubuntu-devel; swathes of associated archive admin [16:10] * started conversion from livecd-rootfs to live-build, since the ARM team feel blocked on this and we'd better do it early - this is very time-consuming, but making progress [16:10] * packaged GRUB 1.99, and landed some previously approved post-1.99 patches upstream [16:10] * done a handful of merges [16:10] * not written up any specs (yet) [16:10] To do: continue with live-build work, write up foundations-o-great-cd-debate, ensure that my carried-over work items from natty make it onto the current tracker, get oneiric CD builds going [16:10] ev: (jump in again when you're ready) [16:10] -- [16:12] livecd-rootfs to live-build - interesting, hadn't gleaned that this was an outcome of UDS [16:12] mvo: [16:12] last week: UDS [16:12] this week: spec drafting, sofware-center SRU to fix review-stats loader bug, [16:12] some early profiling for dpkg on btrfs (https://wiki.ubuntu.com/AptBtrfsSnapshot), SoC work for apt, software-center code cleanup, [16:12] refactor for the road ahead, update-manager: fix UnitySupport bug [16:12] rest of the week: specs work, finish software-center pyflakes-clean branch [16:12] (done) [16:13] cjwatson: out of curiosity, how did you debug 683904 (the memtest86+ grub fix). I saw the diff, but was wondering what kind of debug machinery you used to find the actual problem? [16:13] (oh, and I'm on vac on friday, just fyi) [16:14] doko: [16:14] gcc-4.6 Linaro merge, openjdk-6 update (for armel jamvm test rebuild), some merges, no drafting yet [16:14] done [16:14] bdmurray: [16:14] apols, ready now [16:15] ev: go ahead; then bdmurray [16:15] Short week; was at a conference until Saturday. [16:15] Done: foundations-o-ubiquity, foundations-o-ubiquity-lvm-luks, [16:15] foundations-o-wubi, foundations-o-ubiquity-advanced-partitioner, [16:15] foundations-o-automated-ubiquity-testing have the appropriate workitems set [16:15] (may add one or two more). [16:15] Call with Rick to discuss 12.04 work. [16:15] Call with Patrick Wright to brain dump the ubiquity automated testing [16:15] infrastructure so that he might reimplement it in the datacenter. [16:15] Email to ubuntu-devel on measuring success/failure in the installation: [16:15] https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033194.html [16:15] Requested that the tech board look into it tomorrow (hi cjwatson ;)): [16:15] https://lists.ubuntu.com/archives/technical-board/2011-May/000857.html [16:15] Raised the need for a proper crash database that doesn't block on Launchpad [16:15] for the implementation with Pete, Kate and pitti. [16:15] Started looking into kexec for Wubi and Linaro LAVA for QA. [16:15] Raised the need for a minimal session (akin to ubiquity-dm) for Bulletproof-X [16:16] did that actually work? Should end with "proposal." [16:16] (done) [16:16] success/failure ++ [16:17] "proposal"? [16:17] I want that for upgrades as well, once ev did all the hard work to add the server and push it through :) [16:17] mvo: once I reproduced it in qemu, I attached gdb and sat there dividing-and-conquering until I got down to a reasonable chunk of code, and then single-stepped it; no rocket science I'm afraid, just a slog [16:18] slangasek: ideas around an actual developer summit, rather than a contributor summit. Targeted at 3rd party ISVs. Think Mix or WWDC. [16:18] cjwatson: anything in particular you needed to do in qemu to trigger it? for me in kvm it wouldn't actually reboot but go into memtest86+ [16:18] More than that, obviously, but that was the big takeaway from the session [16:18] cjwatson: even without rocket science, still pretty impressive work :) [16:18] I'm not sure, I think I was partially just lucky [16:18] * mvo likes the word slog [16:18] ev: ah, I think maybe the answer to '< ev> did that actually work? Should end with "proposal."' is 'no', because that didn't make any sense to me :) [16:19] oh, rubbish [16:19] I usually try both kvm and qemu -no-kvm for this kind of thing [16:19] well then: http://paste.ubuntu.com/609561/ [16:19] (done) ;) [16:19] heh [16:19] bdmurray: [16:19] thanks cjwatson, I will make a mental note for the future, I just tried kvm [16:23] research into foundation's team packages, uds-o spec drafting, support team bug triage, arsenal testing and improvements [16:23] and stgraber: [16:23] Post-UDS drafting for a few specs, worked on/sponsored a few SRUs and upgraded to oneiric. [16:23] Also started working on an IPv6 test setup to simulate pretty much all cases of "working" IPv4 and IPv6 setup (static4, static6, dhcpv4, dhcpv6, radvd). [16:23] And for the last 10 minutes or so, have been looking at sssd 1.5.7 which seems easy to package except for a new non-packaged build-depends (ding-libs) making everything a lot harder ... [16:23] (done) [16:24] btw, traditionally the lightning report covered the previous week, should we keep this? this time of course it would have meant "uds" for most of us, so I mixed in bits of this week to make it more interessting. [16:24] stgraber: ah, quick, get 1.5.7 packaged and into universe ASAP so that whoever files the MIR has to deal with ding-libs instead of you [16:24] ;) [16:25] I normally described Wednesday-afternoon through Wednesday-morning in my lightning round [16:25] slangasek: sounds like a good idea ;) [16:25] cjwatson: same here [16:25] very easy to calculate with gtimelog :) [16:25] bdmurray: just to know: how did you determine the "foundation's team packages"? [16:25] yeah, I was thinking of it the same way as cjwatson and barry [16:25] slangasek: there's a PPA with both ding and the new sssd here: https://launchpad.net/~fabricesp/+archive/experimental/+packages (in what looks like a pretty good state) [16:26] ok, thats fine with me, I will just update my reporting [16:26] [TOPIC] UDS "debriefing" [16:26] New Topic: UDS "debriefing" [16:27] dbriefing? [16:27] doko: I've created a preliminary list that needs reviewing. I looked at people.getSubscribedPackages()? in the lp api and looked at the -changes mailing list for L->O for things team members have uploaded (using the number of times uploaded). [16:27] on that note, I wonder if we should talk a bit about UDS, and what everyone's interesting/surprising takeaways were [16:27] or what you're excited about for this cycle [16:28] like python3 only on the CD for 11.10, right? :) [16:28] * barry hits backspace [16:28] MEASUREMENT :) [16:28] * slangasek gets out the bathroom scale [16:29] I found mpt's plenary very inspirational, and will push hard to implement as much of that as I can [16:29] lots of positive support for udd [16:29] hahaha [16:29] and bfbia [16:29] (or can encourage others to) [16:29] community, community, community [16:29] delete wiki pages! [16:29] * ScottK stares at barry. [16:29] funny thing [16:29] (seriously, having face-to-face time with the contributors is so energizing) [16:29] I found several pages under help.u.c that I want to delete, but I don't have perms [16:30] ScottK: it's gonna be so awesome, you'll be totally convinced :) [16:30] * ScottK waits for it to solve a problem he's actually having. [16:30] Note that the existing functionality does that in a very good way. [16:31] ScottK: so did my 20" crt :) [16:31] heh [16:31] this may be vacuous, but the most interesting/surprising conversations for me were the ones I didn't expect to have [16:31] suggesting once again that underscheduling is better than overscheduling [16:32] ++ on that [16:32] +1 [16:32] I got a chance to go to quite a few server sessions, the occasional desktop session, and the odd completely random session, and I think that was helpful [16:32] agreed. my only regret was not getting out to actually see much of budapest :/ [16:32] (it's been a while since I got a chance to tour around much) [16:32] barry: I agree, I think we scheduled too much in the evenings this time [16:33] it was worse at the Canonical Summit [16:33] yes, I noticed some very good cross-pollination with Linaro in a few areas this time - in particular around debug symbols, gdbserver kinds of things [16:33] yeah, though I find with going away every three months I lose my energy for tourism, anyway [16:33] You will stay in the building, you will sit in your assigned dinner seat. [16:33] ev: speaking of which, i think you're supposed to fill us all in on what happened at the some-hands [16:33] (finally booked for Dublin; travelling by rail and ferry ++) [16:34] (the trip across north Wales is gorgeous) [16:34] barry: *hand waves* eleventy billion users [16:34] shortest summary EVAH [16:34] hahaha [16:34] we're going to run our users in VMs then? [16:34] our users are *in* the cloud [16:34] I'll sort that out of band; I have a notebook full of random scribbles and drawings of cats [16:34]