[05:09] <LaPulgaAtomica_> Buenas noches a todos
[15:04] <drubin> '
[15:59] <mvo> hello
[16:00] <ev> hiya
[16:02] <robbiew> o/
[16:02] <robbiew> #startmeeting
[16:02] <MootBot> Meeting started at 10:02. The chair is robbiew.
[16:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:04] <robbiew> [TOPIC] Lightning Round
[16:04] <MootBot> New Topic:  Lightning Round
[16:04] <robbiew> barry: ?
[16:04] <barry> gtimelog 0.4.0, repackaged, ppa, uploaded; python bugs: 9807 (pyconfig.h and Makefile), 9877 (sysconfig); udd work: wiki gardening, stakeholders meeting, bzr-debuntu plugin; general bug triaging; emacs 23.2 ffe testing; lpbug 434431 (cj icon); review bug 637955 merge proposal. (done)
[16:04] <robbiew> thnx
[16:05] <robbiew> cjwatson: ?
[16:06] <cjwatson> hi, sorry, give me a second - having network difficulties
[16:06] <robbiew> cjwatson: np...we'll come back to you
[16:06] <robbiew> doko?
[16:07] <doko> * more handling of component mismatches, file MIR's, bug reports, ... people really should not be al
[16:07] <doko> lowed to pre-promote, the kubuntu guys seem to be very eager about this
[16:07] <doko> * llvm-2.8 updates
[16:07] <doko> * OOo update, armel builds now, but not in the lucid backport
[16:07] <doko> * some more ~20 armel package fix
[16:07] <doko> * file bug report about armel build failures, get preprocessed source, forward to Linaro
[16:07] <doko> * get the armel-cross-toolchain into maverick, helping hrw
[16:07] <doko> * some python3 uploads
[16:07] <doko> done
[16:08] <robbiew> doko: it appears that the fix for the fullscreen presentation in OOo broke other things...did that get officially released, or was that just in a test ppa
[16:08] <doko> -proposed
[16:09] <Riddell> pre-promotion is done because the MIR team is lacking in members and we were told to do so
[16:09] <robbiew> ah..okay
[16:09] <cjwatson> ready when you are
[16:09] <doko> --
[16:10] <doko> Riddell: it doesn't help to subscribe the MIR team three months after filing the bug ...
[16:10] <cjwatson> shall I go now?
[16:10] <robbiew> cjwatson: yes...please
[16:10] <cjwatson> done: fixed regression from ntfs-3g update; wubi fixups for grub, hopefully fixing upgrades; dmraid fixes in grub; almost done with /lib/init/rw work in sysvinit; pushed Windows interop fix in grub out for testing; working on some grub 1.99 release blockers, e.g. re-enabling grub-extras
[16:10] <cjwatson> todo: consolekit VT activation fixes; finish various bits of WIP; bug catchup treadmill, but not much more on my list is critical so I have some space
[16:10] <cjwatson> --
[16:10] <cjwatson> (probably some more archive catchup as well to help doko out)
[16:11] <robbiew> cjwatson: thnx
[16:11] <robbiew> ev?
[16:12] <ev> * fixing installer bugs - please let me know if it's failing for you in any serious way.
[16:12] <ev> * Trying to get ubiquity reporting 0 errors in pyflakes, pychecker or pylint so that we can run it as a build step
[16:12] <ev> * figuring out how to best set up and utilize this installer testing under Hudson stuff in anticipation for the hardware arriving tomorrow (can partimage/ntfsclone the copy of windows back over for resize tests, or cheat and mkfs.ntfs)
[16:12] <ev> * working on setting up fakechroot to create an environment for testing individual ubiquity/d-i component interactions
[16:12] <ev> (done)
[16:12] <Riddell> there shouldn't be any outstanding ~ubuntu-archive bugs, I did the last ones this morning
[16:12] <barry> ev: "Trying to get ubiquity reporting 0 errors in pyflakes, pychecker or
[16:12] <barry>      pylint so that we can run it as a build step" -- good luck :)
[16:12] <ev> barry: tell me about it
[16:13] <doko> Riddell: maybe we should discuss this, but I think it's wrong to promote things when the security team has concerns which are not addressed
[16:13] <doko> srtp again ...
[16:13] <ev> pyflakes was mostly easy
[16:13] <barry> ev: let me guess: pylint?
[16:14] <robbiew> ev: thnx
[16:14] <Riddell> doko: as I say I've been told to pre-promote them this cycle for lack of an active MIR team
[16:14] <robbiew> mvo: ?
[16:14] <ev> barry: yeah, verbose does not begin to describe pylint.  I think we have *some* hope with pychecker, but I worry about changing the code for the sake of making pychecker happy.
[16:14] <mvo> misc bugfixing; misc i18n fixes; software-center: add screenshots-by-version support, fix where-is-it for kde/purchased apps, ui improvements to the buy-something, update-manager fixes, debug upgrade failure with xserver-xorg-input
[16:14] <cjwatson> yeah, I noticed some cases in our previous work where changes to make pychecker happy actually actively broke stuff
[16:14] <mvo> (done)
[16:15] <barry> ev: we can take this off-line, but the trick is going to be basically suppressing tons of warnings either in the code or in your pylint.rc file.  so much fun :/
[16:15] <ev> cjwatson: indeed, and I'm actively trying to avoid that :)
[16:15] <ev> though wildcard imports was the source of much of the feedback, and those were easy enough to fix
[16:16] <barry> ev: suppress, suppress, suppress ;)
[16:16] <ev> barry: indeed :/
[16:16] <ev> hahaha
[16:16] <robbiew> psurbhi: around?
[16:16] <psurbhi> yeah
[16:16] <psurbhi> 1) worked on mdadm bugs (550131, 541058) related to map files and auto assembly. Have created a bzr branch with patches tested, kept at https://code.launchpad.net/~csurbhi/+junk/mdadm.fixes. Still looking at the path which gets "" assignment (earlier unknown). Also looking in neil browns git repo for fixes to other mdadm bugs. Some bugs do seem related to older mdadm versions.
[16:16] <psurbhi> 2) looking at how lvm manages the array when the name changes due to auto assembly. Also investigating why autoassembly is failing for some users. Need to check if fixing the map file bugs helps anyone in this.
[16:16] <psurbhi> 3) created a small mdadm document that says what features are currently supported and what to not expect to work correctly in 2.6.7.1, what patches are in queue (sponsorship requested). Shall upload this soon (after completion)
[16:17] <psurbhi> done
[16:17] <psurbhi> ..
[16:17] <robbiew> thnx
[16:18] <robbiew> [TOPIC] 10.10 Bugs
[16:18] <MootBot> New Topic:  10.10 Bugs
[16:18] <cjwatson> can somebody volunteer to look at psurbhi's mdadm fixes branch and see what of it should be sponsored for maverick?
[16:18] <cjwatson> please
[16:19] <psurbhi> also a patch attached to bug 617725
[16:19] <psurbhi> could go in
[16:19]  * robbiew can voluntell if needed
[16:19] <robbiew> ;)
[16:19] <psurbhi> cjwatson, robbiew, thanks a lot
[16:20] <robbiew> mvo: can you help with this?
[16:21] <mvo> I can, its not ideal, but I can give it a try
[16:21] <mvo> software-center-buy-something is in the final iteration, today is the day when we want to lift the restriction
[16:21] <mvo> so that purchase is open for anyone
[16:21] <psurbhi> mvo, thanks! please let me know if you want something from me..
[16:21] <mvo> sure
[16:22] <robbiew> I don't think it needs to be done today, does it?
[16:23] <robbiew> psurbhi: ^
[16:25]  * robbiew must be talking to himself in here
[16:25] <mvo> :)
[16:26] <robbiew> [TOPIC] AOB/Good News?
[16:26] <MootBot> New Topic:  AOB/Good News?
[16:26] <psurbhi> robbiew, no
[16:26] <robbiew> psurbhi: thnx
[16:26] <barry> i'm seeing lots of crashes in gnome-keyring-daemon.  it's an assertion that apport cannot report.  not seeing any obvious dups in the tracker but there are lots of open crashes there.  has anybody else seen this?  i may have to spend some time investigating. :/
[16:27] <robbiew> hmm...I haven't seen that
[16:27] <barry> i'm on amd64
[16:28] <barry> anyway.  if not, i'll look into it
[16:28] <robbiew> barry: I have an amd64 running 64bit, no problem with that...if I run into it, will let you know
[16:29]  * mvo hasn't seen this either
[16:29] <cjwatson> good news: wubi upgrades no longer make the system unbootable
[16:29] <barry> robbiew, mvo k, thx
[16:29] <robbiew> heh...\o/
[16:29] <cjwatson> (haven't completed a full upgrade yet, but I upgraded just grub-common/grub-pc/lupin-support and it (a) still boots (b) uses a new grub to boot
[16:29] <cjwatson> )
[16:29] <robbiew> cjwatson: I suppose I should move on the releases.ubuntu.com/wubi hosting then
[16:30] <barry> cjwatson: i have a win7 vm i can do wubi tests on if you need
[16:31] <cjwatson> barry: I have win7 on real hardware
[16:31] <cjwatson> more testing doesn't hurt of course
[16:31] <barry> cjwatson: cool.  i have an msdn account (thx to psf) and can bring up vms for any windows os you need
[16:31] <cjwatson> I'll remember that, may be useful
[16:31] <barry> cjwatson: np.  i'll take a look at wubi
[16:31] <robbiew> barry: cool...I think marjo and QA would be interested in that too
[16:32] <barry> robbiew: +1 will let marjo know
[16:32]  * psurbhi shall shoot an email to friends to try out wubi :) 
[16:32] <doko> cjwatson: what needs to be done regarding archive cleanup before the release? I'm a bit scared about the demotions
[16:32] <cjwatson> doko: I can work on the demotions; really just getting *-mismatches and NBS clean
[16:33] <doko> ok, currently writing the two remaining MIRs
[16:34] <doko> let me know how I can help with NBS
[16:35] <robbiew> okey dokey
[16:36] <robbiew> #endmeeting
[16:36] <MootBot> Meeting finished at 10:36.
[16:36] <robbiew> thx all
[16:36] <mvo> thanks!
[16:36] <barry> robbiew: thanks!
[18:28] <inkvizitor68sl> hi all
[18:28] <inkvizitor68sl> whom i can contact to ask about pack of CDs for Ubuntu Install Fest ?
[18:33] <akgraner> inkvizitor68sl, see PM
[19:57] <highvoltage> Hi! I hav ea conference call with a client when the Edubuntu meeting starts, so I'll be at least a few minutes late, feel free to start without me :)
[20:15]  * stgraber waves
[20:15] <stgraber> anyone around ?
[20:17] <stgraber> ok, I guess we can wait for highvoltage then ;)
[20:18] <stgraber> though an edubuntu meeting is relatively pointless if that's only mgariepy, highvoltage and I considering that we are all 2m away in real life ;)
[20:19] <czajkowski> heh
[20:20] <stgraber> hey czajkowski
[20:20] <stgraber> how's it going ?
[20:21] <czajkowski> not bad , keeping busy. yourself
[20:22] <stgraber> good, quite busy recently. Looking forward to UDS to catch up on a few Ubuntu things I haven't quite had the time to work on recently (and seeing everyone again)
[20:22] <czajkowski> yes looking forward to it alright
[20:25]  * highvoltage morphs back into existence
[20:26] <highvoltage> jcastro asked if we want to do an educationaly OW session
[20:26] <highvoltage> I declined because I didn't find the last two sessions that I hosted particularly exiting
[20:26] <highvoltage> anyone else want to do it perhaps or have any ideas?
[20:27] <stgraber> well, it was great to have it on the schedule just to show that we are alive, though I tend to agree that they weren't particularly crowded
[20:29] <vmlintu> maybe I should attend to find out what I could do..
[20:30] <highvoltage> I started working on installation instructions for 10.10, it's viewable already, although not linked, if anyone wants to provide feedback it's over here: http://edubuntu.org/documentation/10.10/installation-guide
[20:30] <highvoltage> vmlintu: :)
[20:30] <highvoltage> vmlintu: I think what we need in Edubuntu is a wiki page with to-do list items that we maintain on a weekly bases
[20:30] <highvoltage> *basis
[20:31] <highvoltage> that way, if someone pops in and says "hey! I want to help but I don't know what to help with" then there's something we can point them to.
[20:32] <ScottK> highvoltage: Feel free to copy https://wiki.kubuntu.org/Kubuntu/Todo if it's useful.
[20:32] <highvoltage> ScottK: that's very nice, thanks!
[20:32] <ScottK> You're welcome.
[20:32] <highvoltage> kubuntu always seems to be 2 steps ahead everyone else :)
[20:33] <highvoltage> (brb)
[20:36]  * mhall119 is here
[20:36] <stgraber> hey mhall119
[20:36] <highvoltage> hey mhall119
[20:37] <vmlintu> sometimes following what is actually happening on the development front is quite hard from here, I have to say
[20:37] <highvoltage> I don't think I have anything else for this week, nothing I can think of now at least :)
[20:37] <mhall119> highvoltage: couldn't we use LP's bug tracker for that?
[20:37] <mhall119> or blueprints
[20:37] <mhall119> the to-do list I mean
[20:37] <highvoltage> vmlintu: *nod* I'd like to hear more about that if you have any comments, or even suggestions on how we can improve
[20:38] <stgraber> bugs might do the trick for some stuff, blueprint is usually too much paperwork (unless it's an actual feature that needs to be developed and for which that kind of tracking is useful)
[20:38] <highvoltage> vmlintu: I'm going to blog about recent changes today, but it has all been said in previous irc meetings though
[20:39] <mhall119> I'll be honest, I haven't been keeping up with edubuntu
[20:39] <mhall119> I've had a hard time keeping up with anything, work, school, life...
[20:39] <mhall119> I'm hoping UDS-N will help me focus on the next cycle
[20:40] <highvoltage> mhall119: indeed, I'd suggest that things that need to be done have a bug assosiated to it, I think it would be nice though to have a wiki page that summarises them
[20:41] <highvoltage> mhall119: I think it's normal for people to get out of sync regularly, ubuntu projects move *fast* and a lot of things happen
[20:41] <highvoltage> I don't think there's anyone in the project that actually keeps up with *everything* that happens in more or less real time
[20:43] <highvoltage> mhall119: I don't know if that's what you were talking about :)
[20:43] <highvoltage> I know you've been somewhat busy
[20:44] <highvoltage> it's nice that this time round, we'll pretty much all be at UDS, so we'll be able to get some of the stuff like the desktop-profiles stuff done for qimo at least :)
[20:44] <stgraber> yep, and having the ltsp hackfest just after will also ensure having some time (including mgariepy's) for anything were we need some kind of teamwork ;)
[20:46] <highvoltage> anything else? I think we can move back to #edubuntu :)
[20:46] <stgraber> Nothing to add here for that meeting
[20:47] <highvoltage> ok... /me > #edubuntu
[20:49] <mhall119> highvoltage: I'm definitely looking forward to develing an actual roadmap for Qimo
[22:14] <oso_> Buenas tardes
[22:58] <james_w> go team win
[22:59] <thumper> hi james_w
[22:59] <james_w> hi thumper
[22:59] <james_w> how are you?
[22:59] <thumper> frustrated, you?
[22:59] <james_w> a bit of that too, been hitting fragile code all day
[23:00]  * thumper nods
[23:00] <james_w> what's the source of you frustration?
[23:00] <thumper> the private xmlrpc server
[23:00] <thumper> timing out weirdly
[23:00] <thumper> and I have no idea why
[23:00] <james_w> hmm, fun
[23:00] <barry> hi guys, ready to meet?
[23:00] <james_w> private being for code imports?
[23:00] <james_w> hi barry
[23:00] <lifeless> being internal to the dc
[23:00] <thumper> james_w: yes, and the smart server (and mailman)
[23:00] <lifeless> code imports is one client
[23:01] <thumper> I'd love to blame mailman, but not sure if I can
[23:01] <thumper> hi barry
[23:01] <thumper> we miss you
[23:01] <thumper> come back
[23:01] <barry> is rockstar and poolie here?
[23:01] <barry> thumper: aw, thanks man!  i miss you guys too
[23:02] <thumper> barry: rockstar isn't coming
[23:02] <thumper> barry: I'm here for code
[23:02] <barry> thumper: awesome
[23:02] <barry> and there's poolie!
[23:02] <poolie> hi barry!
[23:02] <barry> hi!
[23:02] <poolie> hi all
[23:02] <thumper> hey
[23:02] <barry> let's start, i can smell dinner cooking :)
[23:02] <barry> #startmeeting
[23:02] <MootBot> Meeting started at 17:02. The chair is barry.
[23:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[23:03] <barry> welcome to the kickoff meeting for udd stakeholders.  all are welcome to join
[23:03] <barry> [TOPIC] agenda
[23:03] <MootBot> New Topic:  agenda
[23:03] <barry> https://wiki.ubuntu.com/DistributedDevelopment/20100922
[23:04] <poolie> good agenda
[23:04] <james_w> indeed
[23:04] <barry> poolie's making a mumble room for us
[23:05] <poolie> backchannel in Ubuntu/Ubuntu Distributed Development on mumble
[23:05] <poolie> technology! :)
[23:06] <barry> techmology (sic)
[23:06] <poolie> no additions to the agenda? next topic?
[23:06] <thumper> as long as it is only a backchannel
[23:06] <thumper> as NZ doesn't like mumble
[23:06] <poolie> remember to use the mute button or push-to-talk
[23:06] <barry> [TOPIC] * Planning for UDS-N
[23:06] <MootBot> New Topic:  * Planning for UDS-N
[23:06] <barry>    * How many sessions do we need? (e.g. an educational one for new users, a dev one for planning Natty work)
[23:06] <barry>  
[23:06] <lifeless> whats AOB?
[23:07] <poolie> "any other business"
[23:07] <barry> lifeless: any other business
[23:07] <james_w> we got some good feedback last time from a session dedicated to that
[23:07] <poolie> i think one planning session would be good,
[23:07] <barry> so, we definitely want to do a developers session.  does it make sense to do an evangelizing/educational session too?
[23:07] <poolie> maybe one feedback session
[23:07] <barry> poolie: would the feedback session be the developers session?
[23:07] <poolie> Charline from DX (or something like that?) will be at UDS and i'm trying to arrange for her to do some user studies of people actually doing UDD
[23:08] <thumper> I think an educational session is needed
[23:08] <poolie> or using bzr or launchpad
[23:08] <james_w> If we have specific things to discuss in more detail then a UDS session is appropriate. I would think that general planning might be obsoleted by these meetings?
[23:08] <poolie> that's probably not a session as such
[23:08] <barry> poolie: +1 for charline doing that study
[23:08] <james_w> yeah, and talking to developers outside sessions is always valuable
[23:08] <barry> james_w: definitely
[23:08] <poolie> mootbot: action: poolie to confirm charline to do user studies
[23:09] <poolie> we could also line up some attendees to participate
[23:09] <barry> [ACTION] poolie to confirm charline to do user studies
[23:09] <MootBot> ACTION received:  poolie to confirm charline to do user studies
[23:10] <poolie> feedback sessions can be good, but not everybody feels comfortable speaking about their experience in a big room
[23:10] <poolie> or they may simply not remember what they want to say
[23:10] <poolie> can we do this better?
[23:10] <poolie> is there another example of a feedback-type session that's worked really well?
[23:11] <james_w> I think the need for work planning sessions may become obvious from our discussions today and over the next month
[23:11] <poolie> mm
[23:11] <poolie> if it's mostly work planning between the people already active in udd, it may not strictly need to be at a session
[23:11] <barry> is it enough just to make sure folks know how to contact the mlist or stakeholders?  e.g. pvt feedback which we can turn into bugs, blueprints, etc?
[23:11] <james_w> yeah
[23:11] <poolie> otoh having it on the schedule allows interested people to turn up and propose changes to the agenda
[23:11] <poolie> or just find out about it
[23:12] <james_w> barry: I think that's a good start, and talking to people to encourage them and get feedback in an individual setting will help
[23:12] <slangasek> poolie: include in the session a clearly identified "if you have other feedback, contact/click [...]"?  That way you grab any feedback from folks who think of what to say afterwards or are shy
[23:12] <james_w> but I think feedback session can be useful to draw some people out of the woodwork
[23:12] <barry> poolie: yep.  it provides an outlet for people who may be interested, or have dabbled, but don't focus on it that closely
[23:13] <poolie> ok
[23:13] <james_w> 1 year ago it was basically mathiaz listing problems he had, as most people in the room hadn't used it in anger, but 6 months ago there was broader participation
[23:13] <slangasek> and then have that in the gobby doc on the projector, etc., and announced > 5min before end of session
[23:13] <poolie> right, it does seem to be slowly building up
[23:13] <barry> +1
[23:13] <poolie> i don't know if we'll get around to it but it would be kind of cool to have a poster in the foyer
[23:13] <poolie> as another way to prompty people to talk to us
[23:14] <barry> that's a good idea.  i can talk to robbiew about that
[23:14] <poolie> he's going to draw the poster? :-) or just about whether he's ok with it
[23:14] <barry> whether it's okay, where to put it, etc
[23:14] <thumper> I think having a gobby feedback file lowers the barrier for people to comment/complain
[23:14] <poolie> thanks
[23:14] <thumper> there will be people that will write but not talk
[23:15] <poolie> right, we can try to cover all channels
[23:15] <barry> [ACTION] talk to robbiew about getting a poster to prompt people to contact us re: udd feedback
[23:15] <MootBot> ACTION received:  talk to robbiew about getting a poster to prompt people to contact us re: udd feedback
[23:15] <barry> thumper: cool
[23:15] <slangasek> thumper: frustratingly, sometimes these are people who are remote and have given us no other way to contact them for follow-up questions ;)
[23:16] <poolie> so we want an educational session, a feedback session, a planning session
[23:16] <poolie> anything else?
[23:16] <barry> so, one feedback session for sure.  what about a separate educational session?  get the stakeholders to put together a short demonstration about how all the pieces fit together?
[23:16] <james_w> I think that would be a good ide
[23:16] <poolie> i think a short demo would be good
[23:16] <poolie> that may actually draw other good feedback
[23:16] <poolie> "i tried that but ....."
[23:16] <james_w> for one thing it forces us to look at the on-ramp
[23:16] <thumper> slangasek: I think all you can do to address that is to indicate clearly that to best get things changed we need contact details :)
[23:16] <thumper> slangasek: although people will still leave that out
[23:17] <slangasek> ack
[23:17] <thumper> barry: +1 on an educational on-ramp type session
[23:17] <barry> excellent. and a planning session if we think it's worth it by the time we get there
[23:17] <james_w> +1
[23:17] <slangasek> +1
[23:17] <barry>    * Who will register and lead the sessions?
[23:17] <barry>    * Which track should it be in?
[23:17] <barry>  
[23:18] <barry> i'll register the sessions
[23:18] <poolie> [action] poolie to organize a foyer poster (assuming it will be
[23:18] <poolie> (you get what i mean)
[23:18] <barry> i do, but mootbot doesn't :)
[23:18] <barry> [ACTION] poolie to organize a foyer poster (assuming it will be
[23:18] <MootBot> ACTION received:  poolie to organize a foyer poster (assuming it will be
[23:18] <UndiFineD> what will be the IRC channels for UDS ?
[23:18] <poolie> snort
[23:18] <james_w> UndiFineD: #ubuntu-uds
[23:18] <poolie> are there going to be as many tracks as LaHulpe? that was pretty enormous
[23:19] <james_w> we are moving to something slightly different this time I think
[23:19] <barry> UndiFineD: there will be session channels based on the track that the session is in.  it'll all be up on the wiki by that time
[23:19] <slangasek> so one thing happening this time is that UDS is being organized by "theme" rather than "track"
[23:19] <james_w> though I don't know if many people understand what that will be
[23:19] <UndiFineD> ah that's good to know :)
[23:19] <slangasek> (but using all the existing summit code :)
[23:19] <poolie> istr someone talking of there already being a draft schedule somewhere?
[23:19] <slangasek> http://summit.ubuntu.com/uds-n/
[23:19] <MootBot> LINK received:  http://summit.ubuntu.com/uds-n/
[23:20] <slangasek> mind the falling tracebacks, though
[23:20] <james_w> in a debug method no less
[23:20] <poolie> heh
[23:20] <barry> wfm :)
[23:20] <poolie> so i guess they would be "Development Process?"
[23:20] <slangasek> anyway, that shows the current 'themes' that have been proposed
[23:20] <slangasek> poolie: I think so
[23:21] <james_w> http://uds.ubuntu.com/tracks/
[23:21] <MootBot> LINK received:  http://uds.ubuntu.com/tracks/
[23:21] <lifeless> win 38
[23:21] <poolie> perhaps something under "Application Developers" about just general non-packaging use of bzr/lp, tutorial and/or feedback
[23:21] <barry> yep, makes the most sense given what's there
[23:21] <james_w> with a different list
[23:21] <barry> yay
[23:21] <james_w> poolie: I think that would be appreciated
[23:21] <james_w> so +1 on development process if it is one of the tracks
[23:22] <poolie> barry would you be so kind as to register that too while you're at it; me as lead
[23:22] <james_w> otherwise some sort of "other, misc" I guess
[23:22] <barry> james_w: agreed.  poolie you mean, register a session on general bzr/lp usage?
[23:22] <slangasek> ah, so which set of themes is authoritative :/
[23:22] <poolie> barry, yes, in the "application developers" stream
[23:23] <barry> [ACTION] barry to register general bzr/lp session in "app devs" theme
[23:23] <MootBot> ACTION received:  barry to register general bzr/lp session in "app devs" theme
[23:24] <poolie> thanks
[23:24] <barry> i guess these things will get settled in the next couple of weeks.  we can look again at our next meeting for track/registration specifics (if there's no obvious candidates)
[23:24] <poolie> jameinel and myself will be there from bzr, plus about one person from each lp subteam
[23:24] <barry> i think we know what udd sessions we want though, shall we move on?
[23:24] <poolie> agree
[23:25] <barry> poolie: awesome
[23:25] <james_w> yes
[23:25] <barry> [TOPIC]  * What are the top three things we need to add to make UDD more attractive to established devs?
[23:25] <MootBot> New Topic:   * What are the top three things we need to add to make UDD more attractive to established devs?
[23:25] <barry>  
[23:25] <barry> in bazaar; in lp?
[23:25] <james_w> that's Ubuntu developers?
[23:25] <barry> james_w: yes i think so
[23:26] <barry> although i have a dream that everyone is an ubuntu developer :)
[23:26] <james_w> :-)
[23:26] <james_w> I guess not everyone is established though
[23:26] <lifeless> review process
[23:26] <james_w> I wonder if there are any Ubuntu devs watching that might like to weigh in as well
[23:27] <slangasek> git round-trip support?
[23:27] <lifeless> just to say, I think having the review stuff - queues, notification, landing stories improved would probably help a lot
[23:27] <lifeless> but thats wearing my motu hat.
[23:27] <barry> lifeless: what specifically needs improving?
[23:27] <slangasek> dunno, maybe that's not actually all that relevant to UDD / established Ubuntu devs, but it's something I hear a lot :/
[23:27] <lifeless> barry: spend a day in REVU
[23:28] <james_w> lifeless: could you join the dots there please?
[23:28] <poolie> lifeless: #ubuntu-revu?
[23:28] <lifeless> poolie: its a webapp
[23:28] <lifeless> james_w: ok.
[23:28] <james_w> slangasek: I believe it is on the way
[23:28] <lifeless> so, motu gets a lot of new packages -many more than main -
[23:28] <poolie> you mean, look at REVU for a smoother review workflow than is offered by lp?
[23:28] <lifeless> and there is a complex review process needed to vet the package.
[23:29] <lifeless> Its a (slight) superset of the stuff needed when an upstream release is made of an existing package.
[23:29] <lifeless> and the LP review process for package branches doesn't handle either scenario (new, upstream-release) well.
[23:29] <poolie> there's another related question which is: how do we best communicate what we are doing, and what we think needs doing next
[23:29] <lifeless> poolie: yes, look at REVU, its /much/ more comprehensive - showing the diff is only a small fraction.
[23:29] <poolie> this meeting, and the list, perhaps are enough
[23:30] <poolie> thumper: ^^ :)
[23:30] <slangasek> lifeless: would that encompass, say, having branch perms change with the state of the freeze and letting archive admins / release team / SRU team land changes by merging?
[23:30] <barry> poolie: though we do want to reach out to folks not on the udd list
[23:30] <lifeless> slangasek: its in the broad topic I'm talking about, yes.
[23:30] <thumper> poolie: yes, we know we don't handle package review very well
[23:31] <lifeless> basically we have a generic nice tool (Merge proposals) but we need to have a generic nice tool *for packages* too.
[23:31] <barry> lifeless: in your happy world, would lp eventually replace revu?
[23:31] <poolie> barry, that's true
[23:31] <lifeless> and there are lots of angles; I haven't done a pareto analysis to say which bit should be done first.
[23:31] <thumper> lifeless: there is work in progress to split the code-review from the proposal-to-merge
[23:31] <lifeless> barry: hell yes.
[23:31] <slangasek> lifeless: that's *my* killer feature for UDD... but I don't think it's possible to achieve unless we're already flipping the switch for building packages from branches
[23:31] <thumper> with the intention to make the review part usable elsewhere
[23:31] <lifeless> thumper: that work is unrelated to me.
[23:31] <barry> lifeless: that's what i wanted to hear! :)
[23:31] <thumper> like package reviews
[23:31] <thumper> is that unrelated?
[23:31] <ajmitch> lifeless: I'd be happy to kill off REVU, too :)
[23:32] <lifeless> thumper: but they are still branch reviews
[23:32] <lifeless> thumper: so I don't think splitting it helps at all
[23:32] <slangasek> lifeless: since otherwise you make the freeze reviewer do all the uploads & package signing besides
[23:32] <thumper> hmm..
[23:32] <lifeless> thumper: I'm not saying 'keep it unsplit' I'm saying 'its on a different dimension'
[23:32] <lifeless> slangasek: exactly.
[23:32]  * thumper nods
[23:32] <james_w> slangasek: so that would be a vote for building from branches?
[23:33] <james_w> (as a prerequisite for your vote for the landing of changes as a release/SRU team member)
[23:33] <slangasek> james_w: yesyesyes
[23:33] <slangasek> :)
[23:33] <james_w> ok
[23:33] <lifeless> I find a good way to join dots in situations like this is to take someone - say slangasek - and watch what they do to do a review during freeze; at the first non-well-integrated bit, hit the stop button, go away, fix it.
[23:33] <lifeless> :)
[23:33] <poolie> so one lateral approach to this would be to see what is necessary to make revu present the same ui/workflow on top of branches
[23:33] <lifeless> (given that we have an overall vision already)
[23:33] <slangasek> actually, thinking on it, -proposed might be the very place to trial build-from-branch
[23:33] <poolie> i don't know if that's at all feasible
[23:33] <slangasek> once we're ready for such a trial :)
[23:33] <james_w> poolie: should be feasible yes
[23:34] <barry> who's responsible for revu?
[23:34] <james_w> poolie: except that it has some tie-ins to source packages, and so you have to deal with arbitrary code execution, or take as input a branch and a source package
[23:35] <slangasek> barry: community members
[23:35] <ajmitch> barry: I'm one of the revu admins
[23:35] <slangasek> it's revu.ubuntuwire.com
[23:35] <ajmitch> rainct has hacked on it quite a bit, branch is on lp:revu
[23:35] <barry> ajmitch: hi.  i wonder if, as a revu admin, it would make sense to pull you in as a udd stakeholder?
[23:35] <ajmitch> barry: sure
[23:36] <slangasek> so another thing that's been on my list for a while that only just now surfaced in my brain... tools for local partial mirrors of bzr package branches
[23:36] <james_w> so far I have seen 1) better review of package branches (revu, new upstream etc) 2) build-from-branch for PRIMARY
[23:36] <barry> ajmitch: that would be cool.  i'll add your name to https://wiki.ubuntu.com/DistributedDevelopment/Meetings
[23:36] <slangasek> I have a local source mirror of Ubuntu main; I can't easily do the same for the branches AFAIK
[23:36] <poolie> right, i can see how that would help a lot
[23:36] <james_w> 3) interacting with git
[23:37] <james_w> there must be more than that :-)
[23:37]  * ajmitch had written up some stuff about branch mirrors somewhere, will take a look for it
[23:37] <barry> james_w: well, there are some lower level pet peeves of mine :)
[23:37] <poolie> any particular bugs that bite?
[23:38] <poolie> we'd heard previously that resolving some conflicts were difficult
[23:38] <poolie> speed/memory usage on huge trees
[23:38] <poolie> oh, speed of accessing launchpad?
[23:38] <james_w> v3 quilt packages IMO
[23:38] <barry> i'm thinking about the whole looms/packaging branches story
[23:38] <barry> and loom threads <--> patch system
[23:39] <poolie> that would be good
[23:39] <poolie> to me that's the likely next bit of feature work, together with colocated branches
[23:39] <poolie> obviously there are a few entangled bits there
[23:39] <barry> i suspect nested branches will be part of that solution too
[23:39] <barry> poolie: yeah
[23:39] <lifeless> nested-loomed branches.
[23:40] <lifeless> head-asplode
[23:40] <lifeless> barry: I'm not convinced - at all - that you want debian/ to be a nested branch.
[23:40] <barry> lifeless: the real goal there is i think better integration with debian, so that we can get our changes to them
[23:40] <lifeless> barry: I think that that would be a mistake.
[23:40] <james_w> and just this second we have https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/libvirt/maverick-201009222219/+merge/36394 to illustrate my point
[23:41] <poolie> how about issues of mergeability between packaging branches and upstream
[23:41] <barry> james_w: lovely
[23:41] <poolie> or reliability of imports?
[23:41] <barry> poolie: yes, to both, definitely
[23:41] <poolie> i guess generally i'd like to get a sense for where our users want the more_fixes:more_features slider to be set
[23:42] <james_w> both ends at once
[23:42] <barry> lifeless: i've been struggling with the right model and try different things each time.  i'm not positive nested branches are right either, but the current situation isn't ideal.  but i'm very open to suggestions.  i just want the work flow to be much smother
[23:42] <poolie> yeah i thought so :)
[23:42] <barry> er, smoother (freudian slip)
[23:42]  * ajmitch thinks reliability of imports is a big one for adoption of udd - people give up if the branch is several revisions behind
[23:43] <slangasek> how are we on archive coverage in UDD (i.e., import failures)?  My general impression is that trying to use UDD and running into a package that's not imported / not up-to-date kills any enthusiasm they might've had
[23:43] <barry> yep, and i'm perfectly happy prioritizing bugs/features so we can knock out the biggest roadblocks first
[23:43] <slangasek> ah, ajmitch is on the same wavelength :)
[23:43] <slangasek> so in that respect I think the slider needs to be heavily towards 'bugs' right now
[23:44] <slangasek> er, 'fixes'; no more bugs please ;)
[23:44] <poolie> slangasek, barry: james may correct me but i believe the import success rate is above 95% but below 100%
[23:44] <james_w> we have 725 packages out of date right now
[23:44] <poolie> so if people access many packages, they may hit that discouraging situation of finding one out of date
[23:44] <barry> poolie: that roughly jives with my own experience of finding missing or out of date source branches
[23:45] <james_w> unfortunately they aren't uniformly distributed across the set of all packages
[23:45] <slangasek> IME the chance of a package being out of date is much, much higher if it's a package that's frequently touched in Ubuntu
[23:45] <poolie> james_w: out of about 20k?
[23:45] <poolie> right
[23:45] <james_w> poolie: ~17k
[23:45] <slangasek> ... and particularly if it's a package I've touched because I tend to use 'bzr co' instead of 'bzr branch' :/
[23:45] <barry> james_w: is it at all correlated to vcs's or upstream hosting provider?
[23:46] <poolie> we did make a graph <https://lpstats.canonical.com/graphs/UddSourcePackagesWithoutBranches/> (canonical-only for technical reasons, sorry)
[23:46] <poolie> currently reading 0
[23:46] <james_w> the latest failure appears to be because slangasek just pushed a bzr-git branch to lp:ubuntu/armel-cross-toolchain-base
[23:46] <poolie> but this is the number of packages with no import branch at all
[23:46] <slangasek> james_w: oh, does that break things?  Neato!
[23:46] <poolie> which is not quite the same as them being up to date
[23:46] <slangasek> james_w: I have two more of those coming ;)
[23:46] <poolie> i could make a better graph that somehow runs the hottest-100 tool
[23:46] <james_w> barry: not really. More correlated to the size of package/number of uploads
[23:46] <poolie> or indeed perhaps just one that parses that number out of the package-import output
[23:47]  * barry nods
[23:47] <poolie> james_w would that be reasonable to use? the number on the home page that's currently 725?
[23:47] <james_w> slangasek: it's not broken as much as asking for a human to check because from it's point of view it just went from one history to another entirely
[23:48] <james_w> poolie: two concerns, the first being asking the tool for the count isn't going to be entirely accurate, the second being that parsing the webpage probably isn't the cleanest way of doing it
[23:48] <slangasek> james_w: ok, so that's the intended effect then :)
[23:48] <james_w> I have no problem with us graphing that number, and could probably even have the tool do it itself
[23:49] <barry> so, just to bring this topic around, i think we need a well-defined way to identify the problems and publicize our priority for fixing them.  certainly the wiki can be the latter if we can keep it gardened
[23:49] <poolie> james_w: perhaps i'll graph that as an intermediate step then arrange for our hottest100 verifier (which isn't limited to the hottest100) to be graphed
[23:49] <barry> i guess lp:udd for bugs for getting issues into the system
[23:49] <james_w> poolie: fwiw there's already a script on jubany that will output relevant numbers in cricket format
[23:49] <poolie> [ACTION] poolie to get a better graph of package import failures
[23:50] <poolie> is that going to work?
[23:50] <barry> and i will capture what's been identified above
[23:50] <poolie> or it has to be Mr Barry?
[23:50] <barry> [ACTION] poolie to get a better graph of package import failures
[23:50] <MootBot> ACTION received:  poolie to get a better graph of package import failures
[23:50] <james_w> barry: yes, udd for any bugs related to this at all
[23:50] <poolie> ok
[23:50] <poolie> so there's some useful feedback there
[23:50] <james_w> I'm happy to move them to more appropriate places as needed
[23:50] <poolie> some of these things are more like tasks; this doesn't totally fit lp's "bug in a package" model
[23:50] <poolie> but we can do it
[23:50] <barry> poolie: mootbot is not your friend :)
[23:51] <poolie> and people seem to generally agree with a slant towards removing bugs that block what's available now
[23:51] <barry> sounds good
[23:51] <poolie> and on performance it sounds like, more would be nice but it's not generally the most pressing issue?
[23:52]  * ajmitch would love to see LP having mirrors of branches somewhere other than the UK, but that's another topic :)
[23:52] <james_w> I would appreciate someone thinking through with me making the import service more reliable
[23:52] <lifeless> move it to the main LP infrastructure
[23:53] <lifeless> there's -lots- of machinery for reliability there.
[23:53] <poolie> heh
[23:53] <barry> ajmitch: connectivity to my corner of the USA doesn't seem too bad :)
[23:53] <lifeless> including scheduling, reporting and alterting
[23:53] <UndiFineD> ajmitch, what is the size of LP ?
[23:53] <slangasek> poolie: well, "need partial mirrors" was a proxy for "performance sucks when I have to download the full branch fresh from launchpad to work on an arbitrary package" :-)
[23:53] <ajmitch> barry: right, it's something I've ranted about before but haven't written up how I think it could possibly work
[23:53] <poolie> btw jam has a branch up that when landed will cut a bit over 2s overhead off opening an ssh connection to lp
[23:53] <barry> lifeless: do you know someone on lp who can make that happen? <wink>
[23:53] <thumper> UndiFineD: size of what? code base, number of branches, size of branches?
[23:53] <james_w> lifeless: it has scheduling and reporting
[23:54] <thumper> james_w: who reads the reports?
[23:54] <UndiFineD> thumper, any info that is relevant to mirroring
[23:54] <poolie> i'd like to break down the inertia that p-i is just james's thing
[23:54] <barry> poolie: i *always* use a shared repo
[23:54] <james_w> thumper: anyone who uses the webpage, I don't know if anyone else looks at them regularly
[23:54] <james_w> https://dev.launchpad.net/Code/PackageImporter
[23:54] <poolie> i think some other people have sent you patches?
[23:54] <poolie> but not very much
[23:55] <james_w> jam has sent a few
[23:56] <barry> shall we move on to the next topic?
[23:56] <lifeless> james_w: its up to you; I think you'd be less of a special case if it ran as part of th eoveral LP stack is all
[23:56] <lifeless> james_w: I'm not suggesting making it use the DB or anything.
[23:56] <james_w> lifeless: see the wiki page above
[23:56] <poolie> barry, yes, let's move on
[23:56] <thumper> barry: you have 3 minutes :)
[23:56] <james_w> plus, it would be nice to work out why LP now likes to do this every so often: http://package-import.ubuntu.com/status/remote-tty.html
[23:57] <lifeless> james_w: yes yes ;)
[23:57] <lifeless> oh that 401 is interesting.
[23:57] <barry> thumper: we might go a little over.  i'm going to skip the critical bugs item because i think we've mined that in this topic (without identifying specific bugs)
[23:57] <barry> [TOPIC]  * How do we promote and evangelize UDD to the wider Ubuntu developer community?
[23:57] <barry>  
[23:57] <MootBot> New Topic:   * How do we promote and evangelize UDD to the wider Ubuntu developer community?
[23:57] <barry> certainly a uds session is a start
[23:58] <barry> i've blogged about it, so that reaches two other people
[23:58] <ajmitch> consistent, clear documentation on how to do common tasks (what's there is pretty good)
[23:59] <james_w> the documentation could certainly be improved. I consider what's there to be a bare minimum
[23:59] <barry> ajmitch: i think they are pretty good howtos now (maybe could use a bit of gardening).
[23:59] <james_w> I think some pictures would help