| === smoser` is now known as smoser | ||
| === gpc is now known as IdleOne | ||
| === steveire_ is now known as steveire | ||
| === kenvandine_ is now known as kenvandine | ||
| === Quintasan_ is now known as Quintasan | ||
| === transitlogger is now known as apachelogger | ||
| === apachelogger is now known as randalogger | ||
| ogra_ | fnop | 15:54 |
|---|---|---|
| * ppisati waves | 15:57 | |
| * davidm_ waves back at ppisati | 15:59 | |
| NCommander | #startmeeting | 15:59 |
| MootBot | Meeting started at 09:59. The chair is NCommander. | 15:59 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 15:59 |
| * NCommander kicks the wiki | 16:00 | |
| NCommander | http://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110602 | 16:00 |
| MootBot | LINK received: http://wiki.ubuntu.com/MobileTeam/Meeting/2011/20110602 | 16:00 |
| * davidm_ waves at NCommander | 16:00 | |
| NCommander | [topic] Action Item Review | 16:00 |
| MootBot | New Topic: Action Item Review | 16:00 |
| NCommander | [topic] ogra to trim down desktop seed on ARM | 16:00 |
| MootBot | New Topic: ogra to trim down desktop seed on ARM | 16:00 |
| ogra_ | not yet ... A2 | 16:00 |
| NCommander | c/o'ing | 16:01 |
| * davidm_ arm is tired of waving | 16:01 | |
| NCommander | [topic] ogra to follow up with Linaro on binutils segfault | 16:01 |
| MootBot | New Topic: ogra to follow up with Linaro on binutils segfault | 16:01 |
| ogra_ | hmm | 16:01 |
| * NCommander waves back at davidm_ | 16:01 | |
| * ogra_ cant remember what exactly that was | 16:01 | |
| NCommander | off hand, I think you had to deal with the bug with bintuils segfaulting | 16:01 |
| NCommander | */captian obvious* | 16:01 |
| ogra_ | lol | 16:01 |
| ogra_ | that much i would have guessed :) | 16:01 |
| ogra_ | anyway, havent done that | 16:02 |
| ogra_ | c/o | 16:02 |
| NCommander | k | 16:02 |
| NCommander | [topic] Standing Items | 16:02 |
| MootBot | New Topic: Standing Items | 16:02 |
| NCommander | [link] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html | 16:02 |
| MootBot | LINK received: http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel.html | 16:02 |
| NCommander | [link] http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-1.html | 16:03 |
| MootBot | LINK received: http://people.canonical.com/~platform/workitems/oneiric/ubuntu-armel-oneiric-alpha-1.html | 16:03 |
| NCommander | hrm | 16:03 |
| NCommander | I think we're off the trendline a bit :-P | 16:03 |
| ogra_ | yeah, i'll fix that | 16:03 |
| ogra_ | just waited until we have all specs in | 16:03 |
| ogra_ | is anyone missing anything from the tracker ? | 16:03 |
| ogra_ | please tell me now | 16:04 |
| NCommander | ogra_: I'll add sometihng after you fix it | 16:04 |
| NCommander | :-P | 16:04 |
| * ogra_ whacks NCommander | 16:04 | |
| NCommander | (all the specs have work items, checked that this morning and added a few more) | 16:04 |
| ogra_ | looks like GrueMaster has a really boring cycle | 16:04 |
| ogra_ | nothig to do really | 16:04 |
| * GrueMaster suffers a massive aneurysm looking at the number of tasks overall assigned to him. | 16:05 | |
| ogra_ | do you really expect to finish 48 WIs ? | 16:05 |
| ogra_ | we should see that we get this lower | 16:05 |
| NCommander | They're all relatively small | 16:05 |
| ogra_ | and somehow move WIs to other tema members where possible | 16:05 |
| NCommander | i figured I could write one massive work item | 16:05 |
| ogra_ | *team | 16:05 |
| NCommander | 'Test Ubuntu Server:' | 16:05 |
| NCommander | or a lot of little small ones which could be distributed | 16:06 |
| ogra_ | well, a WI needs to at least take a day | 16:06 |
| NCommander | ogra_: I disagree | 16:06 |
| ogra_ | if you have like 10min tasks for WIs the amount indeed rises | 16:06 |
| ogra_ | NCommander, thats the definition, i didnt make it up | 16:06 |
| NCommander | they aren't 10m tasks, but I suspect one or two a day could be done reasonably | 16:06 |
| NCommander | and again, GrueMaster can help delgate his work items to interested parties | 16:07 |
| davidm_ | ogra_, we may have to adjust our definition as we have to make sure items get tracked for this cycle closely | 16:07 |
| * NCommander knows theres people out there with vested interested in PXE, ARM server, etc. | 16:07 | |
| davidm_ | I'm OK with 1/2 wi if they are tracking things we need to track | 16:07 |
| davidm_ | 1/2 day that is | 16:08 |
| ogra_ | davidm_, well, but 48 seems like an awful big number | 16:08 |
| ogra_ | we never managed to get more than 20-25 done per release | 16:08 |
| ogra_ | (per person that is) | 16:08 |
| NCommander | ogra_: our work items are usually something like 're-implement the world' | 16:08 |
| ogra_ | (7 days) | 16:08 |
| ogra_ | (sorry, couldnt resist :P) | 16:08 |
| NCommander | I also broke GrueMaster's QA spec in two specifically because the -qa- one should be medium priority | 16:09 |
| ogra_ | anywayx, move ... | 16:09 |
| davidm_ | ogra_, I know but I asked NCommander to make them finer for the ARM server stuff | 16:09 |
| NCommander | things we care about, but we can ship broken | 16:09 |
| davidm_ | and GrueMaster will likely have some help | 16:09 |
| NCommander | [topic] Kernel Status (cooloney, rsalveti, ppisati) | 16:10 |
| MootBot | New Topic: Kernel Status (cooloney, rsalveti, ppisati) | 16:10 |
| ppisati | nothing exciting except for a boatload of CVE fixes for every release/flavour (lucid/[fsl-imx51|mvl-dove], maverick/ti-omap4, natty/ti-omap4) | 16:10 |
| NCommander | \o/ | 16:10 |
| GrueMaster | BTW: All (3) of my A1 WI are done. Just updated the bp. | 16:10 |
| NCommander | CVEs are awesome | 16:10 |
| NCommander | er | 16:10 |
| ppisati | :) | 16:11 |
| NCommander | CVE FIXES are awesome | 16:11 |
| ppisati | actually i'm wonderting when we'll get the TI .39 drop | 16:11 |
| NCommander | ppisati: I think ogra still looking for the virgin sacirfice | 16:11 |
| NCommander | ;-) | 16:11 |
| ppisati | :) | 16:11 |
| ogra_ | me ? | 16:12 |
| GrueMaster | ppisati: Do you have an omap3 (beagle/beagleXM)? bug 791552 is for you. | 16:12 |
| ubottu | Launchpad bug 791552 in linux (Ubuntu) "No USB support on beagle/beagleXM" [Undecided,New] https://launchpad.net/bugs/791552 | 16:12 |
| ogra_ | nah, i'm to aged for that virgin stuff | 16:12 |
| * NCommander leaves that where it falls. | 16:12 | |
| ppisati | GrueMaster: ouch, didn't notice it | 16:12 |
| ppisati | GrueMaster: ok, i'll add to the backlog | 16:12 |
| ogra_ | i could need some kernel guy to look at ac100 though :) | 16:12 |
| GrueMaster | Just filed yesterday. | 16:12 |
| * NCommander needs a kernel guy for the mx5 too :-/ | 16:12 | |
| ogra_ | you have an mx5 ? | 16:13 |
| ogra_ | just use a linro kernel | 16:13 |
| ogra_ | *linaro | 16:13 |
| NCommander | ogra_: well yeah. it doesn't work. | 16:13 |
| ogra_ | there should exiost one | 16:13 |
| NCommander | hence why I need a kernel guy | 16:13 |
| ogra_ | ah | 16:13 |
| NCommander | :-P | 16:13 |
| ogra_ | well, my kernel isnt in the archive yet, so you go first :P | 16:13 |
| NCommander | ppisati: so all the CVE fixes are in *-security now? | 16:14 |
| ogra_ | we're just discussing to switch to .38 first before i upload | 16:14 |
| ppisati | NCommander: nope, but i'm pushing a lot of stuff | 16:14 |
| ppisati | NCommander: next cycle | 16:14 |
| NCommander | ppisati: awesome | 16:14 |
| ppisati | ogra_: .38 for tegra? | 16:14 |
| ogra_ | ppisati, yes | 16:14 |
| * ppisati hopes to get the ac100 soon :) | 16:15 | |
| ogra_ | we're currently at .37 | 16:15 |
| ogra_ | ppisati, oh, that would be awesome | 16:15 |
| ogra_ | we really lack a person who knows kernel development | 16:15 |
| ppisati | ogra_: davidm told me he pushed one to me | 16:15 |
| ogra_ | even more awesome ! | 16:15 |
| * ogra_ hugs davidm_ | 16:15 | |
| ppisati | davidm_: ah, btw, can you keep me on the list for the new TI hw when it comes? thanks | 16:16 |
| NCommander | can I move? | 16:17 |
| ppisati | yep | 16:17 |
| NCommander | [topic] ARM Porting/FTBFS status (NCommander, janimo) | 16:17 |
| MootBot | New Topic: ARM Porting/FTBFS status (NCommander, janimo) | 16:17 |
| davidm_ | I will keep the entire team in line for new hardware as it arrives | 16:17 |
| ppisati | davidm_: cool | 16:17 |
| janimo | no news, I was working on WIs | 16:17 |
| * NCommander has nothing to report as I've been dealing with humans | 16:17 | |
| ogra_ | looks okayish ... | 16:17 |
| ogra_ | at least the images built | 16:17 |
| NCommander | I think this is the first time we hit A1 | 16:17 |
| ogra_ | nope | 16:17 |
| GrueMaster | Natty was. | 16:18 |
| janimo | I am glad to see package maintainers applying arm bits and not leaving it all to us | 16:18 |
| ogra_ | we did hit it the last two releases | 16:18 |
| NCommander | oh yay | 16:18 |
| ogra_ | GrueMaster, maverick too iirc | 16:18 |
| janimo | some natty poatches that were dropped get reapplied without our intervention | 16:18 |
| GrueMaster | Maybe for omap3. | 16:18 |
| ogra_ | well, this time its omyp4 only :) | 16:18 |
| NCommander | I think we missed maverick due to an ill-timed openoffice rebuild | 16:18 |
| ogra_ | *omap | 16:18 |
| NCommander | but off-topic | 16:18 |
| NCommander | universe is in a sorry mess | 16:18 |
| GrueMaster | You're going to have all that fixed by EOW, right? | 16:19 |
| ogra_ | yes, we need more community involvement | 16:19 |
| ogra_ | we should have specs for that for next UDS | 16:19 |
| GrueMaster | :P | 16:19 |
| ogra_ | with more HW availability in the community, we should work out strategies how to get them more involved | 16:20 |
| NCommander | arm-p-free-beer-for-every-bug-fixed | 16:20 |
| NCommander | That will solve the problem. | 16:20 |
| ogra_ | hard to deliver though | 16:20 |
| NCommander | To be delivered at UDS R | 16:20 |
| NCommander | :-) | 16:20 |
| NCommander | anyway | 16:21 |
| NCommander | [topic] ARM Image Status (ogra, NCommander) | 16:21 |
| MootBot | New Topic: ARM Image Status (ogra, NCommander) | 16:21 |
| NCommander | ARM Image Status (ogra, NCommander) | 16:21 |
| NCommander | $#!@#! | 16:21 |
| ogra_ | omap4 is fine | 16:21 |
| NCommander | I think we kinda already did this one | 16:21 |
| ogra_ | omap3 is screwed | 16:21 |
| ogra_ | and GrueMaster and NCommander rock !! | 16:21 |
| ogra_ | tzhanks guys for making A1 happen without me | 16:22 |
| GrueMaster | This I know. | 16:22 |
| GrueMaster | :P | 16:22 |
| NCommander | Thank GrueMaster. | 16:22 |
| * NCommander only did paperwork | 16:22 | |
| ogra_ | ac100 iamge is new and up on http://people.canonical.com/~ogra/tegra/2.6.37 | 16:22 |
| GrueMaster | I noticed that LibreOffice is in the A1 netbook image. Works good too. | 16:22 |
| ogra_ | (and now bugfree) | 16:22 |
| ogra_ | thanks to NCommander and Daviey for helping to identify the bugs | 16:23 |
| NCommander | GrueMaster: right, but now when someone opens libreoffice, we'll miss a milestone :-/ | 16:23 |
| NCommander | ogra_: heh | 16:23 |
| NCommander | er | 16:23 |
| NCommander | builds libreoffice | 16:23 |
| ogra_ | well, with the panda cluster it should at least get better | 16:23 |
| * NCommander salutees GrueMaster for his hard work on that | 16:24 | |
| NCommander | ogra_: but more the images skew when libreoffice is uploaded | 16:24 |
| NCommander | I'm (in my 'free' time) working on making LP less brain dead in this respect | 16:24 |
| NCommander | but its slow going | 16:24 |
| ogra_ | didnt you have a spec for it ? | 16:24 |
| ogra_ | and do you have to do it alone | 16:25 |
| ogra_ | ? | 16:25 |
| NCommander | I have a placeholder | 16:25 |
| NCommander | Short of someone evelating this internally, I'm not expecting any help on this | 16:25 |
| ogra_ | NCommander, well, infinity should be around soon | 16:26 |
| ogra_ | he should be able to do a bit of soyuz stuff | 16:26 |
| NCommander | I'm hoping that since we're over the A1 hump, I might find enough free time to get this implemented and save us a TON of pain | 16:26 |
| NCommander | ogra_: TBH, I'd prefer to implement it myself, its a good unwind project | 16:26 |
| ogra_ | NCommander, then shove some of the other WIs over to him | 16:27 |
| NCommander | Will do | 16:27 |
| ogra_ | no matter how you do it, it would be really really good to have it fixed this cycle | 16:27 |
| NCommander | I'm working towards loadbalancing the team. A lot of GrueMaster's work items will get moved onto janimo and infinity | 16:27 |
| ogra_ | and if we need to make some spare time for you to do it, we should be able to find a way | 16:27 |
| * janimo overflows with joy | 16:27 | |
| ogra_ | lol | 16:28 |
| ogra_ | anyway, nothing more for images here | 16:28 |
| NCommander | janimo: that's -65334 tears of happiness :-) | 16:28 |
| NCommander | [topic] QA Status (GrueMaster) | 16:28 |
| MootBot | New Topic: QA Status (GrueMaster) | 16:28 |
| GrueMaster | Spent most of the day yesterday just trying to file a sensible bug report on the broken omap kernel. | 16:29 |
| janimo | NCommander, my hapiness is a short apparently | 16:29 |
| GrueMaster | We need to have apport installed on the headless images. | 16:29 |
| janimo | long long is preferred | 16:29 |
| ogra_ | GrueMaster, tricky since we dont have a seed | 16:30 |
| ogra_ | (and i dont really want to maintain one) | 16:30 |
| GrueMaster | Other than that, I did some basic boot tests on the images for A1, and dabbled a little in some of the apps that are on the netbook image for omap4. | 16:30 |
| ogra_ | might have to change for the server images though | 16:30 |
| NCommander | ogra_: er, we could just add apport-cli to livecd-rootfs */hack* | 16:31 |
| GrueMaster | Well, the issue I had was that usb support was non-existant. It would initialize and recognize the onboard usb hubs, but nothing that was attached from there. | 16:31 |
| GrueMaster | So no network support. | 16:31 |
| ogra_ | NCommander, well, sure | 16:31 |
| ogra_ | NCommander, but i assume our server images should have apport by default anyway | 16:31 |
| NCommander | ogra_: one would hope so | 16:32 |
| NCommander | hopefully the migration to live-helper will be done | 16:32 |
| GrueMaster | We should have some way of adding some minimal stuff anyways. wifi on omap4 is non-existant on headless. | 16:32 |
| NCommander | I 'look' forward to implementing support for live headless images | 16:32 |
| NCommander | ogra_: as much as I hate to say it, I think we need a headless seed | 16:32 |
| ogra_ | GrueMaster, yes, the basic wifi apps arent in minimal ... nor is wpa-supplicant | 16:33 |
| NCommander | begin crying now | 16:33 |
| ogra_ | NCommander, i disagree | 16:33 |
| * ppisati kicks an omap3 kernel compilation... | 16:33 | |
| ogra_ | i think we need a server seed and images for it | 16:33 |
| NCommander | ogra_: adding packages to livecd-rootfs isn't going to scale :-P | 16:33 |
| ogra_ | and leave the headless image as is :) | 16:33 |
| NCommander | ogra_: er, didn't we agree we wanted both? | 16:33 |
| ogra_ | right | 16:33 |
| NCommander | I think yo umight be missing the point | 16:33 |
| * ogra_ would rather make the headless images unofficial and move forward with server here | 16:34 | |
| ogra_ | instead of having to mintain extra hacks for headless | 16:34 |
| GrueMaster | Headless is next to useless without some base level of packages installed. | 16:34 |
| janimo | although server != minimal which headless was supposed to be | 16:34 |
| NCommander | We're getting offtopic | 16:34 |
| GrueMaster | True. | 16:34 |
| NCommander | [topic] ABO | 16:34 |
| MootBot | New Topic: ABO | 16:34 |
| NCommander | Now we're on topic | 16:34 |
| NCommander | we | 16:35 |
| NCommander | *er | 16:35 |
| ogra_ | heh | 16:35 |
| NCommander | [topic] AOB | 16:35 |
| MootBot | New Topic: AOB | 16:35 |
| ogra_ | nothing here | 16:36 |
| ogra_ | shoot it down :) | 16:36 |
| ogra_ | (unless someone else shouts) | 16:36 |
| NCommander | I'd actually like to propose to returning on reporting individual spec status | 16:36 |
| NCommander | Er, sorry, individual's status | 16:36 |
| ogra_ | returning ? | 16:37 |
| NCommander | (my brain is kinda fried) | 16:37 |
| NCommander | We used to do it when we were called the Embedded Team | 16:37 |
| ogra_ | did we ever drop it (beyond nobody doing it i mean) | 16:37 |
| NCommander | We used to do NCommander's status, ogra's status | 16:37 |
| ogra_ | when were we called the embedded team ? | 16:37 |
| NCommander | Back when we dealt with Moblin. It was the MobileAndEmbedded Team | 16:37 |
| NCommander | (according to the wiki anyway) | 16:37 |
| ogra_ | heh | 16:38 |
| * ogra_ only knew it as mobile team, but well) | 16:38 | |
| ogra_ | you mean reporting personal status in the meeting ? | 16:38 |
| NCommander | yeah | 16:38 |
| ogra_ | instead of wikipage ? | 16:38 |
| NCommander | I realize there is a time concern | 16:38 |
| NCommander | No, both | 16:38 |
| ogra_ | that will eat a *loT* of extra time | 16:39 |
| ogra_ | when we did that our meetings were like 1.5h and longer | 16:39 |
| NCommander | I know. | 16:39 |
| ogra_ | thats why we dropped it | 16:39 |
| NCommander | hrm | 16:39 |
| NCommander | right | 16:39 |
| NCommander | I forgot that bit | 16:39 |
| NCommander | shutting up now | 16:39 |
| ogra_ | so find something else to drop | 16:39 |
| ogra_ | to compensate ... | 16:39 |
| ogra_ | :) | 16:39 |
| NCommander | One other point | 16:40 |
| NCommander | bah | 16:40 |
| NCommander | Daviey isn't around | 16:40 |
| ogra_ | Daviey is around | 16:40 |
| NCommander | I wanted to get some cross-reporting between Ubuntu ARM and Ubuntu Server | 16:40 |
| NCommander | not in this channel | 16:40 |
| NCommander | oh | 16:40 |
| NCommander | bah | 16:40 |
| * ogra_ takes away NCommanders blindfold | 16:40 | |
| NCommander | I hate autocomplete | 16:40 |
| NCommander | And I'd like to find some volunteers to attend the weekly server team meeting | 16:41 |
| NCommander | and some volunteers from the server team to attend ours regularly | 16:41 |
| * GrueMaster hides | 16:41 | |
| NCommander | (the meeting is 16:00 UTC on Tuesday) | 16:41 |
| GrueMaster | Same time as the linaro meeting. | 16:42 |
| ogra_ | thats wed. | 16:42 |
| ogra_ | or not ? | 16:42 |
| NCommander | No, the sync meeting moved to Tuesday as I found out | 16:43 |
| ogra_ | ah, no, mixed it up with the porting jam | 16:43 |
| Daviey | o/ | 16:43 |
| NCommander | that's an unfortunate choice of timezone | 16:43 |
| NCommander | er | 16:43 |
| NCommander | time | 16:43 |
| NCommander | oh hai Daviey | 16:43 |
| Daviey | hello! | 16:43 |
| NCommander | Daviey: we're trying to get some cross-pollination going between teh ARM and server meetings | 16:44 |
| Daviey | NCommander: funny you say that! :) | 16:44 |
| Daviey | NCommander: have you witnessed one of the -server meetings? | 16:44 |
| NCommander | I'd like to add a 'ARM Server' sectoin to our meeting page, with someone present from the Ubuntu Server Team | 16:44 |
| NCommander | Daviey: I haven't had opportunity | 16:44 |
| Daviey | NCommander: I'm wondering if it would be a better fit for someone arm to join a server meeting? | 16:44 |
| Daviey | Or format has sections for each 'interest' area. | 16:45 |
| Daviey | QA, Kernel, Community, Documentation | 16:45 |
| NCommander | as does ours (although ATM, we're quite generalized) | 16:45 |
| Daviey | We would happily add an Arm section :) | 16:45 |
| NCommander | My plan was to add a Server section | 16:45 |
| Daviey | NCommander: ok.. I think the thing that is a challenge.. I'm not quite sure if Oneiric ARM server is a Server project or an ARM project? | 16:46 |
| NCommander | Daviey: its both | 16:46 |
| NCommander | I don't want to hold the meeitng open, so why don't we take this offline, and then drop a notice with the next {Server,ARM} Meeting Reminder email | 16:47 |
| Daviey | NCommander: Okay, just for information... the interested parties in ARM on the server team are myself, zul and hallyn. | 16:47 |
| NCommander | [action] Daviey and NCommander to discuss cross-server/ARM team meeting | 16:47 |
| MootBot | ACTION received: Daviey and NCommander to discuss cross-server/ARM team meeting | 16:47 |
| Daviey | NCommander: sounds good. | 16:47 |
| NCommander | #endmeeting | 16:47 |
| MootBot | Meeting finished at 10:47. | 16:47 |
| === jelmer_ is now known as jelmer | ||
| === robrt` is now known as robrt`` | ||
| === robrt`` is now known as robrt` | ||
| mdz | #startmeeting | 18:56 |
| MootBot | Meeting started at 12:56. The chair is mdz. | 18:56 |
| MootBot | Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] | 18:56 |
| mdz | [link] https://wiki.ubuntu.com/TechnicalBoardAgenda | 18:56 |
| MootBot | LINK received: https://wiki.ubuntu.com/TechnicalBoardAgenda | 18:56 |
| kees | \o | 18:57 |
| mdz | pitti isn't online, so I assume he isn't going to make it | 18:59 |
| mdz | sabdfl declined in the calendar | 18:59 |
| mdz | cjwatson is online, but he's on holiday, so he presumably won't be here | 18:59 |
| kees | is 3 quorum? | 18:59 |
| * mdz nods | 19:00 | |
| mdz | we've regarded it as such in the past | 19:00 |
| kees | yeah, that's my memory too | 19:00 |
| mdz | [topic] Action review | 19:00 |
| MootBot | New Topic: Action review | 19:00 |
| mdz | Persia to see if Bryce is willing to serve as LP stakeholder for Ubuntu | 19:00 |
| mdz | I've asked bryce asynchronously for an update | 19:01 |
| mdz | [topic] ffmpeg vs. libav | 19:01 |
| MootBot | New Topic: ffmpeg vs. libav | 19:01 |
| mdz | I guess this was discussed some at the last meeting, which I wasn't present for | 19:01 |
| mdz | the notes said that we wanted to hear from Reinhard, and he's responded now | 19:01 |
| mdz | [link] https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html | 19:01 |
| MootBot | LINK received: https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html | 19:01 |
| kees | right. given that I've seen both sides of this, I think I'm satisfied to stay where we are: libav | 19:02 |
| kees | trying to track ffmpeg would require a dedicated maintainer, and Ubuntu does not seem to have anyone willing to do that currently. | 19:02 |
| kees | I only see downsides to switching from libav. | 19:02 |
| mdz | libav is the status quo, so we would need a justification to switch away from it | 19:03 |
| kees | right, and I don't see anything significant to do that currently. | 19:03 |
| mdz | it's all feeling a little bit cdrecordish to me | 19:04 |
| mdz | Keybuk, any thoughts? | 19:05 |
| kees | bryce: we're looking at https://wiki.ubuntu.com/TechnicalBoardAgenda and have "Persia to see if Bryce is willing to serve as LP stakeholder for Ubuntu". can you speak to this at all? | 19:05 |
| mdz | <bryce> sure, I'd be happy to help | 19:06 |
| Keybuk | mdz: I don't believe I have the necessary background | 19:06 |
| Keybuk | all I saw was flamewar | 19:06 |
| bryce | kees, yes we spoke a couple UDSes ago, and yes I'd be happy to help | 19:06 |
| kees | bryce: ah-ha, perfect. thanks! | 19:06 |
| kees | Keybuk: did you have additional questions based on the techboard thread? | 19:07 |
| Keybuk | kees: I didn't see anything in the techboard thread that led me to have technical questions | 19:07 |
| Keybuk | nothing suggested ffmpeg was technically better, so I don't see any need to dispute the current maintainer decisions | 19:07 |
| Keybuk | <insert joke about the community council being the one that deals with childish disputes :p> | 19:08 |
| kees | Keybuk: okay, so you're okay with status quo too. | 19:08 |
| mdz | OK, so this came in as an inquiry from an upstream developer, suggesting that what the Ubuntu maintainer had done was not in the best interest of our users | 19:08 |
| mdz | I haven't heard of any complaints from our users about it yet | 19:08 |
| Keybuk | mdz: it came from the upstream developer of a package we weren't using though, right? | 19:08 |
| mdz | Keybuk, yes | 19:08 |
| Keybuk | I must admit, I wrote that of us "how dare Ubuntu not use *my* software, and use something else" | 19:09 |
| mdz | if someone wanted to maintain the other fork in Ubuntu as well, and make both available to users, that wouldn't seem unreasonable to me | 19:09 |
| Keybuk | and then failed to find any technical argument from the author as to why we should | 19:09 |
| Keybuk | mdz: agree | 19:09 |
| mdz | but if the maintainer chose to follow libav, the TB can't tell them whether they should package something else | 19:09 |
| mdz | they should be regarded as different software at this point | 19:10 |
| mdz | one is packaged for Ubuntu, the other is not yet (but would be welcome) | 19:10 |
| mdz | kees, does that seem like a reasonable position to you? | 19:10 |
| kees | mdz: yup. | 19:10 |
| mdz | OK, I'll follow up on the list | 19:10 |
| Keybuk | to me also | 19:10 |
| mdz | [action] mdz to summarize consensus on libav/ffmpeg to the mailing list | 19:11 |
| MootBot | ACTION received: mdz to summarize consensus on libav/ffmpeg to the mailing list | 19:11 |
| kees | they would have colliding binary packages, though | 19:11 |
| mdz | kees, that could presumably be fixed in packaging | 19:11 |
| * kees nods | 19:11 | |
| mdz | [topic] Set series RM to ubuntu-release? | 19:11 |
| MootBot | New Topic: Set series RM to ubuntu-release? | 19:11 |
| mdz | [link] https://bugs.launchpad.net/ubuntu-community/+bug/174375/comments/21 | 19:11 |
| MootBot | LINK received: https://bugs.launchpad.net/ubuntu-community/+bug/174375/comments/21 | 19:11 |
| ubottu | Ubuntu bug 174375 in Launchpad itself "Distribution drivers permissions may need redesign" [Low,Triaged] | 19:11 |
| mdz | the bug mentioned there is now fixed | 19:11 |
| mdz | so in theory we should be able to set the series release manager to ubuntu-release | 19:12 |
| kees | let's do it and see what breaks? | 19:12 |
| mdz | let's tell people that we're doing it, and then do it, and see what breaks :-) | 19:12 |
| mdz | any volunteers? | 19:12 |
| kees | seems like it should be coordinated with skaet at least? | 19:13 |
| mdz | yse | 19:13 |
| mdz | yes | 19:13 |
| kees | I'm not entirely comfortable volunteering myself for this since these discussions have mostly been involved people doing archive admin work, so perhaps cjwatson? | 19:14 |
| kees | s/been //g | 19:14 |
| mdz | we can push this to the next meeting where cjwatson is here | 19:14 |
| mdz | it's not urgent | 19:14 |
| kees | ok | 19:14 |
| mdz | [topic] Measuring installation success/failure | 19:14 |
| MootBot | New Topic: Measuring installation success/failure | 19:14 |
| mdz | [link] https://lists.ubuntu.com/archives/technical-board/2011-May/000857.html | 19:15 |
| MootBot | LINK received: https://lists.ubuntu.com/archives/technical-board/2011-May/000857.html | 19:15 |
| mdz | [link] https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033194.html | 19:15 |
| MootBot | LINK received: https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033194.html | 19:15 |
| kees | aiui, ev is looking for a TB "blessing" for this data gathering. | 19:15 |
| mdz | I like the general idea of gathering data which will give us an indication of how effective our installer is | 19:15 |
| kees | I generally do too. I remain unconvinced that the proposed data gather is substantially useful, though. | 19:16 |
| kees | *gathering | 19:17 |
| mdz | Evan wasn't crystal clear about what he wanted decided | 19:17 |
| mdz | and several issues have cropped up in the discussion | 19:17 |
| mdz | Keybuk was concerned about how the collected data would be shared | 19:17 |
| mdz | kees, I think that's a valid concern, but perhaps not something for the TB to decide | 19:17 |
| mdz | I think it's Evan's responsibility to make it useful, and our responsibility to set policy for what's permissible | 19:18 |
| kees | mdz: that's fair | 19:18 |
| mdz | kees, and FWIW I would recommend to evan that he consider your advice carefully :-) | 19:19 |
| mdz | so the policy questions I think are regarding what data is collected, and what we do with it | 19:20 |
| kees | right. I don't want to get us into the trap where we approve "meaningless data collection" since it's harmless, and then end up on an unregulated slippery slope of "harmful" data collection just happening without review. | 19:20 |
| mdz | what is proposed to be collected is a GUID | 19:20 |
| kees | right, it's a random number. I have no problem with that. | 19:21 |
| mdz | ah, right, he did specify how it would be generated (uuidgen) | 19:21 |
| mdz | so it's random | 19:21 |
| mdz | that ID is associated with an installation attempt which was started | 19:21 |
| mdz | specifically, a Ubiquity installation attempt | 19:22 |
| mdz | it's then used to report back that the installation succeeded | 19:22 |
| mdz | the user implicitly shares their IP address in the process, of course | 19:23 |
| mdz | what's the worst thing that could be done with that information? | 19:24 |
| kees | the correlation of guid to IP can also be seen as an identity leak, since it could be used in the future | 19:24 |
| Keybuk | you could use the table of IPs collected to discern which Fortune 500 companies were using Ubuntu | 19:25 |
| kees | if we did not save the IP on the server side, and did not keep the GUID after install success on the client side, I think that would be okay | 19:25 |
| Keybuk | since they tend to have public IP blocks | 19:25 |
| mdz | kees, agreed, but ideally we wouldn't have to ask for that trust | 19:25 |
| mdz | kees, what's the identity leak? | 19:26 |
| kees | mdz: if the guid is saved on the client and the IP is saved on the server, it can be used to look up from what IP a given system was installed from. it's pretty minor, obviously. | 19:27 |
| kees | (assuming the server data is public) | 19:27 |
| mdz | the GUID would only be saved on the client until the next time it connected to the network | 19:27 |
| mdz | according to evan's proposal | 19:27 |
| Keybuk | if the IP is saved on the server, the information could be used by Canonical Support Sales to identify potential customers and sell support contracts to them | 19:27 |
| kees | right, I was stressing that it is important that guid be removed on the client. | 19:28 |
| Keybuk | if the IP is saved on a public server, it could be used by other support companies, or competitors | 19:28 |
| mdz | I didn't notice if there was discussion of how this impacts OEM installs | 19:28 |
| mdz | we definitely wouldn't want a UUID getting stored on factory installed systems | 19:28 |
| mdz | Keybuk, is there anything evil that Canonical could do that Canonical can't do by virtue of controlling DNS for archive.*.ubuntu.com already? | 19:29 |
| Keybuk | mdz: no, likewise Canonical already collects the IPs of booting Ubuntu machines, and could use that information for the same purposes | 19:30 |
| Keybuk | I'm just answering the question from a perception POV | 19:30 |
| mdz | there are surely already places where Ubuntu systems generate random numbers and send them over the network | 19:30 |
| mdz | like TLS connections | 19:30 |
| mdz | has anyone considered whether this could be done without generating a UUID? | 19:31 |
| mdz | it seems like it could | 19:31 |
| kees | the ephemeral keys in TLS aren't saved by the server usually | 19:31 |
| kees | but they're connection-based, so they don't survive the install. | 19:32 |
| mdz | http://installreport.ubuntu.com/start followed by http://installreport.ubuntu.com/finish, divide finishes by starts? | 19:32 |
| MootBot | LINK received: http://installreport.ubuntu.com/start followed by http://installreport.ubuntu.com/finish, divide finishes by starts? | 19:32 |
| mdz | MootBot, you are too clever for your own good | 19:32 |
| ScottK | I was one of the objectors to this. I don't think we should be collecting data from users that's not needed for system operation without opt-in. | 19:33 |
| kees | mdz: right. | 19:33 |
| ScottK | I'm also on a very laggy connection, so if it seems like I'm running behind, that may be why. | 19:33 |
| mdz | ScottK, do you want a copy of the meeting log up to this point? | 19:33 |
| ScottK | mdz: I have it. | 19:34 |
| Keybuk | ScottK: I do agree with mdz that the usefulness of this data is only interesting if it's implicit | 19:34 |
| kees | since ev is not here, perhaps continue this on the TB list? | 19:34 |
| ScottK | Keybuk: I agree that opt-in compromises the utility, but I think without opt-in it's not appropriate. | 19:34 |
| mdz | ScottK, what is the data that you don't feel should be collected in this case? | 19:35 |
| ScottK | Also I think the opt-out mechanism he proposed was sufficiently convoluted that it's equivalent to not having one. | 19:35 |
| ScottK | mdz: I don't think it's appropriate to engage in any user data collection without consent. | 19:35 |
| mdz | ScottK, I understand, but that isn't what I asked | 19:36 |
| ScottK | There are some things that one could inherently collect like how many people hit security.ubuntu.com for updates, but that's needed to make the system work. | 19:36 |
| mdz | ScottK, what data would be collected from users if we went ahead with this proposal? | 19:36 |
| ScottK | mdz: I'm objecting to the entire thing being opt-out. | 19:36 |
| kees | ScottK: do you see having a system hit "http://installreport.ubuntu.com/start" and .../finish as a problem? | 19:38 |
| mdz | I think ScottK is lagging as he warned he might | 19:39 |
| ScottK | I think that's less of a concern since there's not really any information being transmitted beyond hitting the server. I'd need to think about it. | 19:40 |
| mdz | it's not strictly necessary to make the system work, but I think I would argue that there is (indirect) benefit to the user | 19:40 |
| mdz | if the data is used to improve the quality of the installer | 19:40 |
| ScottK | It's a slippery slope. | 19:40 |
| mdz | ScottK, yes it is | 19:40 |
| mdz | so we're treading cautiously | 19:40 |
| ScottK | I feel like needed to make the system work versus data we'd like to have is a bright line. | 19:41 |
| mdz | unless someone convinces me otherwise, I think that the use of a UUID is not essential to the objective, and so I don't think we need to be concerned about potentially identifying information | 19:41 |
| ScottK | Once you cross it, how to you define the limit? | 19:41 |
| mdz | I think we can distill it to the point where the only information being shared is whether Ubuntu was installed successfully or not | 19:42 |
| kees | hm... do-release-upgrade fetching installer-specific things when it runs, does ubiquity do anything like that on install? maybe we're already hitting a url. | 19:42 |
| mdz | kees, yes | 19:42 |
| mdz | I'm pretty sure | 19:42 |
| kees | so then we're half way there. we just need an on-first-boot url. that's less obvious to me, though. | 19:43 |
| mdz | ScottK, I think we can set limits which make sense | 19:43 |
| kees | ScottK: agreed -- I think having a direct operational benefit is the key. | 19:43 |
| mdz | kees, not quite. I think we need to store some state, and only hit the "finish" URL if we successfully hit the "start" one | 19:43 |
| ScottK | mdz: OK. I'd like to see the policy for the limit made first. | 19:44 |
| mdz | fair enough. let's try to steer away from the technical implementation | 19:44 |
| mdz | I'm comfortable assuming that we can get to a point where virtually no incidental information is shared, other than what we're trying to collect | 19:44 |
| kees | I would agree. if there is a reason why guid would be required, that should be a separate issue. | 19:45 |
| mdz | so the question is: is it OK to report back whether the installation succeeded or failed? | 19:45 |
| ScottK | I think taking a step back from this use case, I think having a general policy in place is important. | 19:45 |
| maco | mdz: how do you report failed? | 19:45 |
| ScottK | Why is this OK, but not popcon by default? | 19:45 |
| mdz | possible answers include: yes (unconditionally), no (unconditionally), yes (but only opt-in), yes (but only with opt-out) | 19:45 |
| mdz | maco, it's implicit | 19:45 |
| maco | mdz: what's the difference between failed and cancelled? | 19:46 |
| mdz | maco, we're taking it as a given that this is possible, and we can have a separate technical discussion about how to do it | 19:46 |
| kees | in general, I disagree with opt-out. | 19:47 |
| mdz | ScottK, popcon is problematic for a few reasons, not least because there is a lot of identifying information there | 19:47 |
| kees | opt-in is UI-noisy and doesn't give ev what he's really after | 19:47 |
| ScottK | mdz: I agree, but I think someone needs to define the limit of what's OK for opt-out. | 19:47 |
| mdz | ScottK, but to play devil's advocate, our default web browser shares similar information without the user's consent | 19:47 |
| mdz | or rather, with their implicit consent, depending on how you look at it | 19:48 |
| mdz | kees, I agree that it's a UI wart, but why doesn't it give evan what he's after? | 19:48 |
| mdz | because not enough people would click the button? | 19:48 |
| ScottK | mdz: I would argue that doing so it a bad thing and the best that can be said about it is it represents a compromise that we have to live with. | 19:48 |
| kees | I would support "yes" if I could see an immediate benefit to the user. I still don't see one beyond the weak "maybe we have improved the installer" thing. | 19:48 |
| kees | mdz: because the numbers would then have an additional variable of "who clicked it" | 19:49 |
| mdz | ScottK, I don't think we have to live with it, but we do, and our users don't seem to mind | 19:49 |
| ScottK | How many of our users really know? | 19:49 |
| mdz | kees, unless that correlates somehow with success or failure of the installation, it doesn't seem relevant | 19:49 |
| Keybuk | mdz: they're probably completely unaware of it | 19:49 |
| mdz | Keybuk, exactly | 19:49 |
| Keybuk | the key there is whether the information is sufficiently non-identifying that they never *need* to be aware of it | 19:50 |
| mdz | Keybuk, I think a good test is whether, if they *did* know, they would mind | 19:50 |
| Keybuk | ie. if Firefox collected everyone's browsing histories and published them | 19:50 |
| Keybuk | it's something you would want to be aware of | 19:50 |
| mdz | and I don't know the answer to that, honestly | 19:50 |
| mdz | but it's testable | 19:50 |
| ScottK | The existence of branded Firefox packages given the constraints on them is making the (arguable) best of a difficult situation. | 19:50 |
| Keybuk | but Firefox collecting histograms about the average time a DNS lookup takes -> only Firefox cares | 19:50 |
| mdz | Keybuk, what about sharing which extensions you have installed, and which versions? | 19:50 |
| Keybuk | (and any Firefox developer, and anyone doing DNS work, and anyone optimising web sites, etc.) | 19:51 |
| Keybuk | but fundamentally not the user | 19:51 |
| mdz | sharing which web pages you're visiting in order to check for phishing attempts? | 19:51 |
| ScottK | mdz: I would think that would most appropriately be opt-in. | 19:52 |
| mdz | ScottK, I'm not sure it's realistic to come up with a general policy at this point, given there are so many subtleties to this topic | 19:52 |
| Keybuk | sharing everything you type into the awesomebar to third parties? :p | 19:52 |
| mdz | it hasn't come up enough times that it's problematic to handle on a case by case basis | 19:52 |
| mdz | Keybuk, sharing things you START to type into the box, in Chrome's case :-) | 19:52 |
| ScottK | mdz: Perhaps, but I think we need a line in the sand beyone which the TB won't go. | 19:52 |
| Keybuk | mdz: I was just looking at the data we collect, as it happens :D | 19:52 |
| mdz | ScottK, I think we already have such a line drawn at collecting PII, by way of precedent, and I would be comfortable making that explicity | 19:53 |
| mdz | s/ity$/it/ | 19:53 |
| ScottK | What's your definition of PII then? | 19:53 |
| mdz | I'm not sure of the best way to specify that. number of bits? | 19:54 |
| mdz | there is always going to be room for interpretation | 19:54 |
| mdz | and it can be really hard to tell | 19:55 |
| kees | I think PII remains a judgement call, even if we explicitly declare it out of bounds | 19:55 |
| mdz | I agree | 19:55 |
| mdz | I think we have to punt on this for the time being; we aren't going to come to a conclusion in this meeting | 19:56 |
| mdz | but we can try to get to some other topics | 19:56 |
| mdz | we can continue the discussion by email | 19:56 |
| * ScottK agrees (re punting) | 19:56 | |
| mdz | [topic] Policy proposal for partner repository | 19:56 |
| MootBot | New Topic: Policy proposal for partner repository | 19:56 |
| mdz | [link] https://lists.ubuntu.com/archives/technical-board/2011-May/000875.html | 19:56 |
| MootBot | LINK received: https://lists.ubuntu.com/archives/technical-board/2011-May/000875.html | 19:56 |
| kees | I was curious how this differed from -extras | 19:57 |
| kees | (policy-wise) | 19:57 |
| mdz | kees, is there a written policy for extras which could be shared with partner? | 19:57 |
| kees | mdz: I couldn't find it when I looked earlier this week | 19:57 |
| kees | I think we should check with allison | 19:57 |
| mdz | I'll CC her into the email discussion for input | 19:58 |
| mdz | my view on this is that we'll never get a policy like this right the first time, and it will need to be updated as time goes on | 19:58 |
| kees | beyond that thought, nothing jumped out at me. | 19:58 |
| mdz | if there is a problem, we'll change the policy to prevent further problems of that kind | 19:58 |
| kees | right | 19:58 |
| kees | I'd also be curious to get archive admin opinions on this, since we may be missing some additional implicit things | 19:59 |
| mdz | it doesn't reference the Debian or Ubuntu policy manual, and it probably should | 19:59 |
| mdz | any other comments → email | 20:00 |
| mdz | [topic] ubuntu-techboard celebrity in Launchpad | 20:00 |
| MootBot | New Topic: ubuntu-techboard celebrity in Launchpad | 20:00 |
| mdz | https://lists.ubuntu.com/archives/technical-board/2011-May/000907.html | 20:00 |
| mdz | [link] https://lists.ubuntu.com/archives/technical-board/2011-May/000907.html | 20:00 |
| MootBot | LINK received: https://lists.ubuntu.com/archives/technical-board/2011-May/000907.html | 20:00 |
| kees | seems like we're not ready to drop this, pending additional bug fixes | 20:00 |
| mdz | if james_w says we can't do this yet, then I say we don't do it yet | 20:00 |
| kees | right | 20:00 |
| mdz | we're out of time | 20:01 |
| mdz | is there anything else urgent? | 20:01 |
| mdz | [topic] AOB | 20:01 |
| MootBot | New Topic: AOB | 20:01 |
| mdz | ok, thanks all | 20:01 |
| mdz | #endmeeting | 20:01 |
| MootBot | Meeting finished at 14:01. | 20:01 |
| kees | thanks mdz! | 20:03 |
| === yofel_ is now known as yofel | ||
| === Sarvatt_ is now known as Sarvatt | ||
| === xeros_ is now known as xeros | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!