=== SpockVulcan is now known as AndrewMC [11:24] .c [11:25] .py [12:03] .rb [12:51] .rexx [13:00] persia, you about? [13:01] NCommander, ?? [13:02] rsalveti, you about? [13:02] GrueMaster, you about? [13:03] Present in body, caffeine will take care of the rest. [13:03] At this point it looks like you and I are the only folks from the team present [13:04] you have your faitfull kernel team representative... [13:04] Ah good enough [13:04] #startmeeting [13:04] Meeting started at 08:04. The chair is davidm. [13:04] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [13:04] Given that almost no one is here, it will be a quick meeting [13:04] [topic] kernel status [13:04] New Topic: kernel status [13:05] nothing to report as it was UDS last week. [13:05] still working on SGX driver in kernel. [13:05] beat me too it [13:05] :-) [13:05] Anything we need to take action on? [13:06] not that I can see. [13:06] OK thanks for the update [13:06] [topic] QA status [13:06] New Topic: QA status [13:06] GrueMaster, any thing to report? [13:06] Nothing new here as I was on vacation. [13:07] Missed UDS. Still trying to connect to gobby to review UDS notes. [13:07] Nothing else. [13:07] OK [13:08] I'm surprised ogra and persia are not here, but I guess they are at plumbers. [13:08] GrueMaster: https://wiki.ubuntu.com/UDSProceedings/N/ might help instead of Gobbby. [13:08] ok [13:09] ogra is traveling to plumbers today as I will be soonish [13:09] [link] https://wiki.ubuntu.com/UDSProceedings/N/ [13:09] LINK received: https://wiki.ubuntu.com/UDSProceedings/N/ [13:09] Yea, figured that. [13:09] [topic] Any other business [13:09] New Topic: Any other business [13:10] NCommander, is having connectivity problems and can't connect to Freescale :-( [13:10] You mean freenode? [13:10] GrueMaster, yes, bloody spelling corrector [13:10] heh [13:11] Freenode === bilalakhtar_ is now known as bilalakhtar [13:11] If there is nothing else from anyone then I'll call the meeting for today... [13:12] close the meeting going once........... [13:13] close the meeting going twice..... [13:14] #endmeeting [13:14] Meeting finished at 08:14. [13:15] Safe trip to Boston. [13:15] Thanks GrueMaster I hope to, I'll leave here in a couple of hours [13:58] \o [14:01] cjohnston, mdz: tb meeting? [14:01] is it now or in 1 h? [14:01] I'm good wit heither [14:02] kees: ITYM cjwatson :) [14:02] cjohnston: sorry :) [14:02] I updated the calendar to be +1h [14:02] which is what we usually do on DST [14:02] matter of definition; 1400 UTC? [14:02] mdz: so the tb meeting is tied to UK time, not UTC? when is it in UTC? [14:03] It's historically been tied to UK time [14:03] kees, that's how it's been historically, though the members were all on UK time the last time we discussed it I think ;-) [14:03] I could have slept another hour. [14:04] I have a priority call right now but could lurk if you want to start [14:04] it's the chair's decision [14:04] since the meeting is generally for other people, linking it to UTC makes more sense. [14:04] I'll wait an hour; we don't have half the board at the moment anyway. [15:01] pitti, mdz, cjwatson: tb meeting take 2? (still no sabdfl nor keybuk) [15:01] kees, sabdfl and I are on a conf call which should be wrapping up shortly. please go ahead and start [15:01] * pitti waves, take II [15:01] #startmeeting [15:01] Meeting started at 10:01. The chair is kees. [15:01] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:01] hi [15:01] [link] https://wiki.ubuntu.com/TechnicalBoardAgenda [15:01] LINK received: https://wiki.ubuntu.com/TechnicalBoardAgenda [15:01] [topic] action review [15:01] New Topic: action review [15:02] * Colin to ensure that documentation on nature of extras.ubuntu.com archive makes it into process docs, and ensure that ARB legality checks are synchronised with those of ubuntu-archive. [15:02] I haven't done this, largely due to UDS - please carry it over [15:02] okay, thanks [15:02] * to follow up with Brian on 174375 [15:02] afaiu, the work from the LP side on this is done now. [15:03] mdz: any notes on this? [15:03] hello techboard [15:03] kees, he mentioned to me at UDS that it was almost done [15:03] hey Mr. General of a verrry small countrrrry! [15:03] (bdmurray did) [15:04] I think there was one more thing which needed to be changed, and it was configuration rather than code [15:04] privet tovarisch [15:04] mdz: should this action be removed? [15:04] kees, yes ir [15:04] sir [15:04] heh, okay, noted. [15:04] [topic] Dynamic "per package upload permissions" for Debian Developers [15:04] New Topic: Dynamic "per package upload permissions" for Debian Developers [15:04] [link] https://lists.ubuntu.com/archives/devel-permissions/2010-October/000109.html [15:04] LINK received: https://lists.ubuntu.com/archives/devel-permissions/2010-October/000109.html [15:05] this would need soyuz support as well as our sign-off. [15:05] do we already have a proposal there, or do we start from just this mail? [15:05] I cannot find a TB propsal anywhere [15:05] i don't think this wants to be automated [15:06] I like the idea of allowing DDs Ubuntu uploads for their packages upon request, but they should at least confirm that they understand our release cycle and freezes [15:06] scripted for ease of execution, perhaps [15:06] and guidelined as policy [15:06] I also don't think it should be entirely automated, but I do think it should be easier than it is now [15:06] but i do think the DMB or an analog needs to engage with the DD in question [15:06] i. e. I'm happy to waive the detailled sponsor feedback, etc. [15:06] Could it be automated for DDs who are ~ubuntu-dev but not for other DDs, or are there ogre-model concerns? [15:06] how is this really different than just a sync request? [15:06] in particular I would like to take the "write up justification and attend IRC meeting" bit out of the equation, and perhaps have something more e-mail-based [15:06] cjwatson +1 [15:06] Debian developers aren't as used to the IRC-meeting bit as we are [15:07] +1 for folks already in ~ubuntu-dev, and +1 for bypassing the meeting cadence in favour of a straight email process [15:07] also, the primary point there is to understand how/that we need to merge and to obey feature/string freezes etc. [15:07] kees: I can easily imagine situations where the Debian developer wants to help out with the merge, say [15:07] or where they know that some different chunk of code is needed for Ubuntu [15:07] cjwatson: yeah, true [15:08] cjwatson: the edges of this system are a bit vague. I'm not sure I see an "easy" technical solution beyond the existing upload permissions. [15:08] kees: full automation would need Soyuz support, but if we had (say) the DMB in the loop then we could do it using our existing ACL facilities [15:08] should we anticipate differences of opinion, and ways to deal with them? for example, branding and cadence [15:08] although the scripting would be fiddly [15:09] differences of opinion is my main concern. I don't want to block on it because I don't want to assume bad faith, but I agree we need to think about it [15:09] we could pre-empt this with a nice form email to the DD when they were brought on, along the lines of "things to consider when working across both Debian and Ubuntu" [15:09] cjwatson: something like a script which adds ACLs to all packages where the requestor is in Uploaders: or XSBC-Original-Maintainer: or Maintainer: ? [15:09] perhaps simply make it clear up-front that this facility isn't so that Debian developers can revert deliberate Ubuntu changes they don't like [15:09] right [15:09] working here is working with us [15:10] pitti: probably somewhat interactive, but some kind of lplib-based thing, yes [15:10] 99.9% of participation would be good faith, i expect [15:10] I agree [15:10] I think that if a DD is involved enough to want to help with merges, then they're ready for per-package upload rights. I don't think its sane to have an automatic method for DDs to just upload their packages, though. [15:10] I agree [15:11] what about UDD permissions and DD's? [15:11] I think those are hooked off ArchivePermissions, and if they aren't then they should be [15:11] alright, sounds like a formal proposal should be emailed to TB? [15:12] sounds good [15:12] we should think about communication too [15:12] seems we already pretty much agree about the scope and shape of this? [15:12] yeah [15:12] details details details matter, proposal would make sure [15:12] perhaps talk with Stefano about whether this is appropriate for debian-devel-announce, etc. [15:13] I agree in general, devil in the details [15:13] [topic] Scan the mailing list archive for anything we missed [15:13] New Topic: Scan the mailing list archive for anything we missed [15:13] (debian-devel-announce> at a bare minimum I'm sure it would be OK for DeveloperNews, which is batched up and e-mailed to d-d-a every so often) [15:14] [link] https://lists.ubuntu.com/archives/technical-board/2010-October/000519.html [15:14] LINK received: https://lists.ubuntu.com/archives/technical-board/2010-October/000519.html [15:14] Micro release exception request for Chromium [15:14] BTW, I'll follow up to Sylvestre on the list and say that we're discussing this [15:15] I'm in support of the micro release exception for Chromium. fta acknowledged the need to not backport all packaging changes, etc, and I think that was the only remaining concern. [15:15] fta's analysis of past updates suggests he's fully on top of the SRU rationale and how it may map to Chromium [15:15] +1 from me [15:16] +1 from me as well (I think I already said so on the list) [15:16] yes, I thought this was more or less agreed on the list [15:16] the last time we discussed this we were just waiting for a formal proposal, so I'm fine [15:17] okay, I'll make note, we're at +4 which is sufficient. [15:17] anyone see anything else from the list that needs attention currently? [15:18] [topic] Quarterly Brainstorm review [15:18] New Topic: Quarterly Brainstorm review [15:18] [link] https://lists.ubuntu.com/archives/technical-board/2010-September/000493.html [15:18] LINK received: https://lists.ubuntu.com/archives/technical-board/2010-September/000493.html [15:18] so I've done a tiny bit of preparation on this [15:19] i.e. reviewed the brainstorm content and picked out some candidates [15:19] unsurprisingly, the content is dominated by client topics [15:19] as opposed to server [15:19] (not yet mid-november, but sure) [15:20] there is a server category, but there is so little there (http://brainstorm.ubuntu.com/server/most_popular_6_months/) that I'm not sure it is worth it [15:20] we could select now, and take action by mid-nov [15:20] we're doing this the first time so we could use the slack ;-) [15:20] agreed [15:20] shall I run through them? [15:20] should we do that in IRC or email? [15:21] (how many are there?) [15:21] we don't need to make decisions on them here, but I'd like to just discuss a bit so that we understand the scope [15:21] I pulled out the top 10 [15:21] based on 6-month popularity [15:21] #1 is power management [15:22] I think there is implicit acknowledgement that this could be improved [15:22] and some good work in progress which we can highlight [15:22] are we still doing so bad there? (except for this "load balancing tick" causing a million wakeups) [15:22] e.g. what Linaro is doing [15:22] pitti, I still need to take a lot of manual steps to get good battery life on an airplane [15:22] e.g. SIGSTOP to my web browser, USB autosuspend, etc. [15:23] hm; of course there's always more stuff that we can do, but it wouldn't have been the first thing that I had named on "what are the most pressing problems" [15:23] pitti, the point isn't to judge whether we agree or not, but to respond to an inquiry from our user base [15:24] mdz: right, no doubt here; as I said, I was just surprised [15:24] some thousands of people voted this up saying they were interested [15:24] so I suggest we ask someone to write up a few paragraphs about the state of things [15:24] #2 is about IP address conflicts [15:24] which seems a very niche problem to me [15:24] but I wonder if it's something which is more common than we realize [15:25] URL? [15:25] http://brainstorm.ubuntu.com/idea/25648/ [15:25] LINK received: http://brainstorm.ubuntu.com/idea/25648/ [15:25] my suggestion would be that we get some data, e.g. run a poll to ask people if they've ever had this problem [15:26] #3 is a suggestion to automatically select the username in gdm if there is only one choice [15:26] which seems very sensible to me, and is something we could pass on to the design team [15:26] sounds like autoipd isn't working? or education is needed about link-local and mDNS use of .local ? [15:26] My previous experience in moderate-sized corporate environments indicates that misconfigured DHCP can cause this to be very frequent. [15:26] #3 was discussed at length already actually [15:26] I'm fine doing a writeup for this [15:26] ok [15:26] kees: it's about manual IPs [15:26] i. e. a very niche problem IMHO [15:26] #4 suggests having a different icon for .deb packages, because they currently look a lot like zip files [15:26] pitti: right, there should be no reason to use manual IPs, but sure, people still do [15:27] but are actually something much more volatile [15:27] I don't know where the current icons come from, but we could certainly pass on this suggestion to the upstream for those icons [15:27] or to our artwork team [15:27] it's good feedback for MPT and we can accommodate it [15:27] if they happen to be the upstream, yes. I'm not sure [15:27] (for our default theme) [15:27] (the network bit) [15:28] this still makes me wonder how useful that prioritization is [15:28] we're also about to start work on a new icon theme [15:28] #5 is a suggestion to keep the system clock synchronized with internet time servers [15:28] upgrades with nvidia driver breaks for tens of thousands of users [15:28] which is interesting because, of course, we already do [15:28] I think #5 is just a bug - ntpdate is installed by default [15:28] and can accommodate the package icon piece too [15:28] cjwatson, I think it's more subtle than that [15:28] I've noticed it occasionally not working right for me, but have never got as far as investigating [15:28] mdz: the ntpdate pieces are clunky [15:28] I think people don't realize how it currently works [15:28] and also, there is a setting in the UI which asks if you want your clock synchronized [15:28] which does something different, which is NOT enabled by default [15:28] so maybe we give people the wrong impression [15:29] we do [15:29] so I think this certainly would benefit from a response, and possibly from some fine-tuning the UI [15:29] mdz: we'll actually remove that part (from gnome-system-tools) [15:29] #6 is a suggestion to "Help the user understand when closing a window does not close the app" [15:29] this could definitely use work, both in the UI and in the behaviour of ntpdate and in the relationship of that and ntpd [15:29] pitti, ok, so more cutting out than fine tuning ;-) [15:29] mdz: you missed one, "GNOME System Monitor lacks in-depth information" [15:29] this presumably refers to things like rhythmbox and banshee which have weird close button behavior [15:30] cjwatson, ah, sorry [15:30] and I don't think that configuring a local NTP server is an appropritate thing to prominently advocate on a desktop system [15:30] (with ntpdate already in place) [15:30] ntpdate currently runs only on ifup iirc [15:30] I'm not sure I understand that one; it seems like a solution in search of a problem [15:30] mdz: #6> there was a natty spec for this [15:30] well, we now have a way of showing that they are still running, which is a start [15:31] pitti, yes, I thought there would be some good links to respond with [15:31] any thoughts on the GNOME system monitor thing? let's call that #7 [15:31] http://brainstorm.ubuntu.com/idea/25887/ [15:31] LINK received: http://brainstorm.ubuntu.com/idea/25887/ [15:32] I think this is an "I can do this in windows" item [15:32] for the GUI power user [15:32] i'd prefer it to open as a tab in the same window [15:33] but yes, we could put that out as a call to action [15:33] if I were responding, I'd say "we'd be happy to see this added if someone is interested in implementing it" [15:33] and offer mentoring [15:33] +1 [15:33] right, should be rather straightforward to get this from /proc [15:33] #8 suggests that software centre should purge packages rather than just removing them [15:33] * kees nods [15:33] http://brainstorm.ubuntu.com/idea/24963/ [15:33] LINK received: http://brainstorm.ubuntu.com/idea/24963/ [15:33] I think we should pass this to the software-center folks for design wowrk [15:33] *work [15:33] for desktop, I would tend to agree about purge [15:33] it's not something I'd like the desktop team to do, though (since we have much bigger problems to attack) === dholbach_ is now known as dholbach [15:33] happy to mentor, though [15:34] it's obviously not as simple as something that can always be one way or the other [15:34] (well, obvious to me anyway :-) ) [15:34] my last stanza was for #7 (sorry, lagged) [15:34] kees: because it makes it easier to "reset" by removing and reinstalling? [15:34] it would be great to get someone knowledgeable about the inner workings of the packaging system to explain the subtlety a bit [15:34] and get input from the software centre team about what they think [15:34] and I think it relates to future work for integrating computer-janitor into s-c (although the item does note that c-j doesn't fill the need either) [15:34] it's definitely not a JFDI sort of item [15:35] no [15:35] I think the requestors know the difference between remove and purge, or they wouldn't be asking [15:35] sabdfl: yeah, it results in a slightly cleaner slate. for server, though, I think it is a marginally dangerous default. [15:35] but deserves a response [15:35] anyone admining a server can make smart choices [15:35] and isn't using software center [15:35] ... yet [15:35] :) [15:35] we don't need to debate it here, just getting an idea of what sort of response we might want to get [15:35] * persia mumbles about home NAS devices [15:35] continuing on [15:36] http://brainstorm.ubuntu.com/idea/25417/ [15:36] LINK received: http://brainstorm.ubuntu.com/idea/25417/ [15:36] mdz: was there anything about version controlled /etc? [15:36] making Ubuntu One sync status a bit more transparent [15:36] sabdfl, sort of [15:36] I think it's reasonable to want the system state to be visible wrt U1 file sync [15:36] and that we should pass this feedback on to the U1 team and get their take [15:36] yes [15:37] timely [15:37] the final one of these 10 is multimedia performance [15:37] which I have to say I'm wondering about myself as well [15:37] because some important use cases regressed for me in 10.10 [15:37] certain types of video playback (like DVD) are noticeably slower [15:38] under mutter only, or default desktop too? [15:38] I don't know about mutter [15:38] but definitely in desktop edition [15:39] okay, so response crafting via email, or as a TODO for discussion next time? [15:39] any guesses who might be able to look into this? [15:39] it might turn out to be a bug, or at least a "we're sorry" [15:39] though the comments are all over the map, including "pulseaudio is a waste of cpu" type stuff [15:39] I haven't seen any regressions. [15:40] did they have specific measurable instances? [15:40] there is one popular "solution" about regression testing multimedia performance [15:41] which will be video hardware sensitive, and require monitoring of CPU time, disk IO, etc. not a subtle thing to measure. [15:41] of course [15:41] remember, our primary goal here is to be more responsive [15:41] to listen and talk about the issues [15:41] we may or may not get to a solution [15:42] depending on all sorts of factors [15:42] but we should have the conversation publicly [15:42] I think we can take the rest of this to email [15:42] I'll take the action to write it up [15:44] [action] mdz to write up Quarterly Brainstorm review [15:44] ACTION received: mdz to write up Quarterly Brainstorm review [15:44] [topic] Check up on community bugs (standing item) [15:44] New Topic: Check up on community bugs (standing item) [15:44] nothing new there [15:44] the next step will be identifying individuals to write up the responses [15:44] [topic] other business [15:44] New Topic: other business [15:44] I would like to propose we tie the Tech Board meeting to UTC, and make it 1500. [15:45] only the creator can move it [15:45] and i think that was keybuk [15:45] no, it's on a calendar that several of us have write access to [15:45] ok [15:46] Why 1500? Last time it was UTC, it was 1400 (although that was years ago). [15:46] persia, our time zone distribution has shifted substantially [15:46] either time is fine with me [15:46] kees has to wake up at an ungodly hour for this time [15:47] Ah, that makes sense. [15:47] I don't mind having it a bit later [15:47] much later than 1500 isn't great for me on Tuesdays [15:47] at least when we're on summer time [15:48] same here, desktop meeting is at 1630 UTC [15:48] 1400 or 1500 UTC both WFM [15:49] 1500 will still be Too Early for me during winter timezones, but I'll live. better than 1400! :) [15:49] sounds like no one is very opposed to 1500. shall we make that official? who can change the calendar? [15:51] i don't think i can [15:51] clan says it appears at 1500 going forward [15:52] could be it's in US time? [15:52] we probably just get to move it around every time DST changes [15:52] anyway, we're agreed on the principle [15:52] mdz moved it earlier today [15:52] ok [15:52] is that a wrap? [15:52] I moved it, but if I hadn't, it would have stayed at the same UTC time [15:52] because that calendar is set for no DST [15:53] kees: thanks for stepping in as chair, clan told me it was me today, am i up next week? [15:55] sabdfl: I think so, yeah [15:55] sabdfl: we skipped the last meeting, so I was just up again [15:55] ok happy to take it [15:56] alright, that's everything [15:56] #endmeeting [15:56] Meeting finished at 10:56. [15:56] thanks! [15:56] thanks folks [15:57] thanks everyone === yofel_ is now known as yofel [17:57] hola [18:00] o/ [18:00] \o [18:01] \o [18:06] \o/ [18:07] yay for enthusiasm :) [18:07] o/ [18:07] _\o/_ [18:07] * SpamapS can only do the splits on IRC [18:08] uh....who is running the metting? [18:08] since ttx can't, i think it's zul! [18:08] there was some suggestion that it would be postponed for ttx.. ? [18:08] oh, postponed??? i thought he wanted to move it forward an hour [18:09] ive lost track [18:09] That would be the same time as the kernel-team meeting. :) [18:10] Or does moving forward mean making it later [18:10] ? [18:10] So, clearly, we are unclear on this. [18:11] yes...yes we are [18:11] so im volunteering SpamapS [18:12] * SpamapS hopes volunteering means "hugging" in Canadianese [18:13] nope means the same in Americanese [18:13] SpamapS: are you sure you hope it means hugging, /me would have hoped it meant zul was actually volunteering himself [18:13] fine...ill volunteer [18:14] start meeting [18:14] #startmeeting [18:14] Meeting started at 13:14. The chair is zul. [18:14] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [18:14] there we go [18:14] [TOPIC] Review ACTION points from previous meeting [18:14] New Topic: Review ACTION points from previous meeting [18:14] mathiaz to send a call for ideas on ubuntu to the puppet community [18:15] im assuming thats not done mathiaz ^^^ === cyphermox__ is now known as cyphermox [18:15] Actually I think it was done and he discussed it at UDS in his puppet sessions [18:15] cool... [18:15] next: [18:15] ALL to mark maverick assigned specs as "Implemented" or Deferred [18:15] i know i have to do mine [18:16] i've done mine... [18:16] well, carry over i guess :) [18:16] hallyn gets a cookie then :) [18:16] ttx would know. he always knows.