=== emgent is now known as enJoy === enJoy is now known as emgent === emgent is now known as enJoy === enJoy is now known as emgent === emgent is now known as enjoy === greeneggsnospam is now known as jsgotangco === enjoy is now known as enJoy === enJoy is now known as emgent === Varka_ is now known as Varka === asac_ is now known as asac === \sh_away is now known as \sh === johnc4511-laptop is now known as johnc4510-laptop === \sh is now known as \sh_away === WikiMan is now known as MatthewV === \sh_away is now known as \sh === mc44_ is now known as mc44 === mrevell is now known as mrevell-lunch === never|mobi is now known as neversfelde|mobi === mrevell-lunch is now known as mrevell [14:59] @schedule montreal [14:59] Schedule for America/Montreal: 13 Feb 08:00: Education Team | 13 Feb 16:00: Server Team | 13 Feb 17:30: Forum Council | 14 Feb 09:00: Desktop Team | 14 Feb 23:00: MOTU | 19 Feb 20:00: TriLoCo-Midwest === ubotu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 12 Feb 20:00 UTC: Technical Board | 13 Feb 13:00 UTC: Education Team | 13 Feb 21:00 UTC: Server Team | 13 Feb 22:30 UTC: Forum Council | 14 Feb 14:00 UTC: Desktop Team | 15 Feb 04:00 UTC: MOTU === \sh is now known as \sh_away === ubotu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 12 Feb 20:00 UTC: Technical Board | 13 Feb 13:00 UTC: Education Team | 13 Feb 19:00 UTC: Platform Team | 13 Feb 21:00 UTC: Server Team | 13 Feb 22:30 UTC: Forum Council | 14 Feb 14:00 UTC: Desktop Team === \sh_away is now known as \sh [19:37] @schedule chicago [19:37] Schedule for America/Chicago: 12 Feb 14:00: Technical Board | 13 Feb 07:00: Education Team | 13 Feb 13:00: Platform Team | 13 Feb 15:00: Server Team | 13 Feb 16:30: Forum Council | 14 Feb 08:00: Desktop Team [19:45] nixternal: hmm, where is that schedule set? the platform team meeting appears to be offset by 12h [19:46] the Fridge [19:46] slangasek: 13 Feb @ 01:00 UTC then? I will fix it for you [19:46] nixternal: should be 0700UTC, which is 0100 in America/Chicago [19:47] derr [19:47] I forgot I did Chicago :) [19:47] @schedule [19:47] Schedule for Etc/UTC: 12 Feb 20:00: Technical Board | 13 Feb 13:00: Education Team | 13 Feb 19:00: Platform Team | 13 Feb 21:00: Server Team | 13 Feb 22:30: Forum Council | 14 Feb 14:00: Desktop Team [19:47] I wonder why they did 21:00 [19:47] * nixternal checks fridge mail [19:48] It is weekly from 07:00 to 08:00 <-- Colin had it right, whoever added it to the fridge had it wrong [19:48] fixing now [19:48] fixed [19:49] cheers === ubotu changed the topic of #ubuntu-meeting to: Current meeting: Technical Board Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 13 Feb 13:00 UTC: Education Team | 13 Feb 19:00 UTC: Platform Team | 13 Feb 21:00 UTC: Server Team | 13 Feb 22:30 UTC: Forum Council | 14 Feb 14:00 UTC: Desktop Team [19:51] @schedule Paris [19:51] Schedule for Europe/Paris: Current meeting: Technical Board 13 Feb 14:00: Education Team | 13 Feb 20:00: Platform Team | 13 Feb 22:00: Server Team | 13 Feb 23:30: Forum Council | 14 Feb 15:00: Desktop Team === ubotu changed the topic of #ubuntu-meeting to: Current meeting: Technical Board Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 13 Feb 07:00 UTC: Platform Team | 13 Feb 13:00 UTC: Education Team | 13 Feb 21:00 UTC: Server Team | 13 Feb 22:30 UTC: Forum Council | 14 Feb 14:00 UTC: Desktop Team [19:56] Keybuk,mjg59: ping === cropalat_ is now known as cropalat [19:57] mdz: 乓 [19:58] I got a response rate of exactly 0% from my nag email [19:58] I've sent an SMS to sabdfl [19:58] mdz: lies [19:59] From: Scott James Remnant [19:59] To: Matt Zimmerman [19:59] Cc: Mark Shuttleworth , Matthew Garrett [19:59] Subject: Re: Tech board next week [19:59] Date: Fri, 08 Feb 2008 12:43:01 +0000 [19:59] Hi [20:00] Keybuk: I stand corrected [20:00] TheMuso: are you here? [20:00] mdz: Indeed I am. [20:00] ScottK,ScottK2: you? [20:00] Yes [20:01] lool? [20:01] Yup [20:01] mathiaz? [20:01] o/ [20:01] rtg? [20:01] yo [20:01] this will be a long meeting [20:02] thanks for coming [20:02] we are waiting on sabdfl [20:02] that's ok, I brought the crumpets, butter and toaster upstairs [20:02] Keybuk: lol [20:03] just phoned sabdfl, he swears he'll be here shortly [20:03] #startmeeting [20:03] Meeting started at 20:03. The chair is mdz. [20:03] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [20:03] [link] https://wiki.ubuntu.com/TechnicalBoardAgenda [20:03] LINK received: https://wiki.ubuntu.com/TechnicalBoardAgenda [20:03] mdz: he swears that he'll be here, or he swore and said he'd be here? :) [20:03] Keybuk: more whinged than swore [20:04] we'd best get started without him if we're going to get anywhere [20:04] [topic] ubuntu-core-dev application from Luke Yelavich: [WWW] https://lists.ubuntu.com/archives/motu-council/2008-January/000713.html [20:04] New Topic: ubuntu-core-dev application from Luke Yelavich: [WWW] https://lists.ubuntu.com/archives/motu-council/2008-January/000713.html [20:06] TheMuso: what do you see as the biggest problem right now for a derivative like Ubuntu Studio which does all of its work within the existing Ubuntu structure? [20:06] TheMuso: are any of your sponsors here to participate in the discussion? [20:06] mdz: Unfortunately, not that I know of. [20:06] evening all [20:06] TheMuso: that's ok, they all sent feedback to the list [20:07] [agreed] sabdfl is late [20:07] AGREED received: sabdfl is late [20:07] mootbot passed the turing test, i see [20:07] agenda? [20:08] Keybuk: Being able to adjust some settings that were originally designed to only be set for one use, and one use only. A good example is the GNOME sound scheme. Currently, this is set via some files in /etc.sound/events in several files, and not in gconf like one would expect. [20:08] We need to dpkg-divert the originals to place new ones to set our own sound scheme. [20:08] Then there is setting different settings in /etc/security/limits.conf for realtime priority for the audio group, however we've largely gotten around that one. [20:09] TheMuso: you dpkg-divert conffiles? :-o [20:09] sabdfl: https://wiki.ubuntu.com/TechnicalBoardAgenda [20:09] lool: (I pasted scrollback to sabdfl in /query) [20:09] mdz: Unfortunately, we have to. I wrote up a spec for UDSs, but it wasn't considered. I do not like it at all. [20:09] mdz: Ah, thanks; I was about to do this next [20:09] TheMuso: you're aware that doing so is not supported and does not always work correctly in upgrades? [20:10] TheMuso: which spec? [20:10] Mithrandir: Yes I am. [20:10] mdz: derivative-sound-schemes I *think* it is, I'd have to check to be sure. [20:11] https://wiki.ubuntu.com/DerivCustomSoundThemes [20:11] thats the one [20:13] TheMuso: were you involved in any other open source projects prior to Ubuntu? [20:14] mdz: Yes, I was. I used to maintain a package repository of Audio/Multimedia packages for Slackware, and was involved with an attempt at standardizing Slackware 3rd party packaging, before that fell through. I was also on the fringes of the GNOME Accessibility project, as a user, and tester. [20:14] TheMuso: what brought you here from slackware? [20:15] mdz: The packaging system for a start, and the fact that I recently had bought a new notebook, which took ages to configure for every install. This got frustrating, however the real breaker for me was attempting to set up cups on my server one day... [20:15] I had to crank up the debug log to max to find shared libraries were missing, which were X libs. [20:16] Since Slackware doesn't track dependencies. [20:16] ... [20:16] TheMuso: you joined MOTU about a year ago. from your point of view, how has the project changed since then? what's better, what's worse? [20:17] MOTU seems to be expanding quite a bit, which is great. There are so many packages that need attending to, its impossible to get to them all. [20:18] TheMuso: do you think it would be helpful to let folks manage a single set of packages, or do you think it's better to look for generalists in MOTU? [20:18] However, I fear we the MOTUs may get overun with contributors, and may not be able to handle them all. I.e we will have to spend our time sponsoring all the time, which may put some MOTUs off very quickly. [20:18] I am also concerned about the quality of some MOTUs work. We as a community are doing our best to address this however. [20:19] sabdfl: I think generalists are best, as then everybody gets experience with different packaging styles etc, which willhopefully produce higher quality work fro mthe MOTU. [20:19] We are potentially working on software for millions of people, and we have to get it right. [20:20] TheMuso: most of those packages, of course, come from Debian. what kind of tending do they need in order to fit well into Ubuntu? [20:22] mdz: For a start, there seems to be a push to add .desktop files to packages that have GUIs, but aren't in the menus. These are being done, and are being sent back up to Debian. There is also init scripts that need altering to work around /var/run as a tmpfs. Again, being sent back to Debian. [20:22] Then there are kernel module source packages, that may have to be changed to work with our kernels. [20:24] There is of course, times when changes to Ubuntu packages are not meant for debian, such as firefox/xulrunner stuff. [20:24] I haven't seen the details of those, but I do know about them. [20:25] * LaserJock notes that there are ~ 4k Ubuntu versioned source packages in Universe, 700+ of which are not in Debian, just for reference [20:25] TheMuso: what would be your top three list of things you'd like to change about the way ubuntu is structured, run, or organised? [20:26] TheMuso: do you have any ideas for how we might make that process more efficient, to make it easier for MOTU to work with many packages? [20:26] I'm badly lagged [20:27] sabdfl: Good question. To be honest, I haven't given it much thought, as I personally am happy with the way things are, however I personally feel there should be more in the way of ensuring prospecitve MOTUs can show what they know WRT packaging. For example, I don't think as a whole, we know enough about shared libraries, and how to package them properly. I won't deny being in the same boat. [20:27] thanks. other candidates might want to prep answers to that question, too [20:28] i wonder how we could rigorously test MOTU skills without building NM, or requiring folks to have gone through NM [20:29] mdz: Try and encourage inactive MOTUs back to help, and if possible, stagger the amount of newcomers, so that the existing newcomers have a chance to get their skills up, and become a MOTU. I haven't given it a lot of thought, as I am not sure what could be done without upsetting a part of the system somewhere. [20:29] people need to "learn on the job" at /some stage/. Debian sets that perhaps a little too far off; I don't think Ubuntu loses enourmously if somebody has stuck out MOTU for a while [20:31] sladen: Yes, but not if there is little time remaining to get an important fix in, and you're the only one who can do it, but don't know how, and don't do it properly. [20:33] was that only me, or a freenode problem? [20:33] No problem here. [20:33] level3 appears to be having issues === mdz_ is now known as mdz [20:34] last thing I saw was i wonder how we could rigorously... [20:34] some sort of glitch in the matrix === txwikinger2 is now known as txwikinger [20:35] ScottK2: I would call it challenging me. I'm enjoying this. [20:35] ugh wrong one [20:35] mootbot has it all: http://kryten.incognitus.net/mootbot/meetings/ubuntu-meeting.log.20080212_2003.html [20:35] mdz: Try and encourage inactive MOTUs back to help, and if possible, stagger the amount of newcomers, so that the existing newcomers have a chance to get their skills up, and become a MOTU. I haven't given it a lot of thought, as I am not sure what could be done without upsetting a part of the system somewhere. [20:35] TheMuso: should we up the ante? ;-) [20:35] keescook: thanks [20:35] sabdfl: Perhaps, but certainly we don't want to make things too discouraging. [20:36] So its a balance. [20:36] TheMuso: that wasn't exactly my question; we'll always be limited by the number of people involved in the project, and so are always interested in finding ways to help them work better [20:38] I just got an SMS from Keybuk, apparently he's affected by the network outage [20:38] mdz: Re-reading it then, I don't really have any ideas at this point. I thought the team idea would work, but from what I've read, it hasn't. [20:38] mjg59: are you still here? [20:38] Keybuk_: welcome back. http://kryten.incognitus.net/mootbot/meetings/ubuntu-meeting.log.20080212_2003.html [20:39] TheMuso: sorry about all this, but it's obviously beyond our control [20:39] mdz: Understandable. [20:39] I am [20:40] mjg59,Keybuk_,sabdfl: I think we need to call a vote and move on. any further questions for TheMuso? [20:40] none from me [20:40] assuming I'm here :) [20:40] everyone had a chance to review the links? [20:40] Keybuk_: you are [20:40] I have [20:40] sabdfl: ping? === Keybuk_ is now known as Keybuk [20:41] now we've lost sabdfl [20:41] it's like whack-a-mole [20:43] yay [20:43] where are we? [20:43] mjg59,Keybuk_,sabdfl: I think we need to call a vote and move on. any further questions for TheMuso? [20:43] everyone had a chance to review the links? [20:43] sabdfl: and then noticed you were offline [20:44] this is reminding me of an intarwebs 2.0 version of "who's on first?" [20:44] +1 on TheMuso from me [20:44] what's the mootbot voting magic incancation? [20:44] sudo mdz [VOTE] TheMuso for core-dev [20:45] * lool :) [20:45] [vote] ubuntu-core-dev application from Luke Yelavich: [WWW] https://lists.ubuntu.com/archives/motu-council/2008-January/000713.html [20:45] Please vote on: ubuntu-core-dev application from Luke Yelavich: [WWW] https://lists.ubuntu.com/archives/motu-council/2008-January/000713.html. [20:45] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [20:45] E.g. /msg MootBot +1 #ubuntu-meeting [20:45] oh good, MootBot didn't get confused [20:45] +1 [20:45] +1 received from mdz. 1 for, 0 against. 0 have abstained. Count is now 1 [20:45] +1 [20:45] +1 received from mjg59. 2 for, 0 against. 0 have abstained. Count is now 2 [20:46] +1 from me [20:46] +1 received from Keybuk. 3 for, 0 against. 0 have abstained. Count is now 3 [20:46] ...and sabdfl prevoted [20:46] #endvote [20:46] that never works [20:46] mdz: [endvote] does work [20:46] [endvote] [20:46] Final result is 3 for, 0 against. 0 abstained. Total: 3 [20:46] nixternal: thanks [20:46] np [20:46] TheMuso: welcome! [20:46] congrats TheMuso! [20:46] Thanks folks. I really really appreciate it! [20:47] [topic] ubuntu-core-dev application from Scott Kitterman: [WWW] https://lists.ubuntu.com/archives/motu-council/2008-January/000776.html [20:47] New Topic: ubuntu-core-dev application from Scott Kitterman: [WWW] https://lists.ubuntu.com/archives/motu-council/2008-January/000776.html [20:47] TheMuso: Congrats [20:47] [link] https://lists.ubuntu.com/archives/motu-council/2008-January/000776.html [20:47] LINK received: https://lists.ubuntu.com/archives/motu-council/2008-January/000776.html [20:47] <\sh> congrats TheMuso well done :) [20:47] welcome, TheMuso [20:47] Since I applied, Riddell has sponsored a number of Main uploads for me too. [20:48] He can't be here now, but earlier today said: " ScottK: but "I advocate ScottK for core-dev, he's very reliable for backports and motu activity and has done some important merges in main"" [20:48] I can vouge on that paste from #kubuntu-devel earlier [20:48] ScottK: how robust is amavis these days? [20:49] sabdfl: It's security record is VERY good. It is Weitse Venema's preferred way to integrate spam/virus stuff into Postfix and that speaks volumes. [20:50] well [20:50] indeed [20:50] I read the code once [20:50] but I feel much better now [20:51] would you suggest that amavis would be a good idea as a standard part of the ubuntu server mail stack? [20:51] Yes. [20:51] That's why I did ~a dozen MIRs to get it promoted. [20:52] what other features do you think would make for a killer mail stack? [20:52] Once you get to far out there are many many options. [20:52] and it's hard to generalize. [20:52] ScottK: there's been some muttering lately about the overhead of the MIR process. what do you think about it? do you think it could be streamlined while preserving the original goal? [20:52] I think that the mail server tasksel is pretty new. [20:52] mdz: It's painful, but I don't know a better way. [20:53] It does ensure someone is doing some research. [20:53] ScottK: what's painful about it? [20:53] Even for a simple perl module it takes ~ 30 minutes to an hour per package. [20:53] As I said earlier, amavisd-new took about a dozen MIRs because of dependencies. [20:54] ScottK: which parts of it are most time consuming? [20:54] So it adds up. [20:54] Researching security history is probably the longest, but also most important. [20:54] committing maintenance for more packages is something we need to do very carefully (hi keescook), but if we can make the diligence easier, I'm interested [20:54] Since packages can be named many different things ... [20:55] I don't have any great ideas. One advantage of the current process is someone has to really want it. [20:55] ScottK: what about SRU? [20:55] If a project has a real champion, odds are it's a better idea. [20:56] I've only done a very few in Main. In Universe I think we have a good balance now. [20:56] My biggest concern is it seems too inviting for end users to run with *-proposed enabled. [20:56] That's almost never a good idea. [20:56] I think it would be a plus if more people ran with -proposed [20:57] since those packages would see more testing before going to -updates [20:57] I think for more technical users, yes. [20:57] right, I mean members of the community, rather than casual users [20:57] We had a bad svn upload to proposed that got a large number of bug reports from people that I don't think had any business running proposed. [20:57] Yes. Agreed. [20:58] That's the source of my concern (my experience triaging that issue and answering the reports). [20:58] ScottK: what do you think Ubuntu Server is most lacking compared to more established server distros? [20:58] apart from, well, history :-) [20:58] My experience is primarily in mail servers. [20:58] In that area, I believe we are in pretty good shape overall. [20:59] We just need to mature the tasksel over time. [20:59] Postfix is one of the reasons I picked Ubuntu. [20:59] Running the same core on server and desktop is another. [20:59] ScottK: what sort of shape is our backport community process in at the moment? [21:00] It's pretty good. [21:00] We need more testers with more experience, but that will likely always be the case. [21:00] We will need more core-dev involvement (or relax the source backports rule) as Dapper continues to age. [21:01] ScottK: it seems that some enthusiasts want more of a "rolling release" rather than the stable releases we provide [21:01] Yes. I like the way we do it with. [21:01] do you think that's practical? is it really what they want, or would they be disappointed with the inevitable breakage? [21:01] I don't think it's practical. There's a balance and I think ours is pretty good. [21:02] You can run a stable foundation and pull needed new features from backports is a good combination. [21:02] do we get many requests from end users for backports? [21:02] Yes. That's where most of them come from. [21:02] or is it mostly those involved with the project who make the decisions? === arualavi_ is now known as arualavi [21:03] Lots of users asking, some of them testing, and then a few of us deciding. [21:03] I also think backports can provide some essential infrastructure for long term support of thing. [21:03] does the backports team look after security vulnerabilities which affect those packages? [21:03] We try to. [21:04] how do you find out about them? does the security team notify you? [21:04] It's much like universe in that respect. [21:04] I read the USNs. [21:04] There are packages I watch after (clamav in particular). [21:04] it seems things could slip through the cracks if they don't affect a released version [21:05] but I don't know how common that is, perhaps keescook would [21:05] Yes. That's quite true. [21:05] mjg59,Keybuk,sabdfl: further questions? [21:05] none from me [21:05] * jdstrand would like to point out that ScottK is very timely with his clamav updates [21:05] as far as backports? We haven't tended to track it. [21:05] nothing from me, thanks ScottK [21:05] * jdstrand is not core-dev yet (for the record) [21:05] [vote] ubuntu-core-dev application from Scott Kitterman [21:05] Please vote on: ubuntu-core-dev application from Scott Kitterman. [21:05] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [21:05] E.g. /msg MootBot +1 #ubuntu-meeting [21:05] +1 [21:05] +1 received from mdz. 1 for, 0 against. 0 have abstained. Count is now 1 [21:05] +1 [21:05] +1 received from sabdfl. 2 for, 0 against. 0 have abstained. Count is now 2 [21:06] +1 [21:06] +1 received from Keybuk. 3 for, 0 against. 0 have abstained. Count is now 3 [21:06] I think we may have lost mjg59 [21:06] no time to lose [21:06] [endvote] [21:06] Final result is 3 for, 0 against. 0 abstained. Total: 3 [21:06] ScottK: welcome! [21:06] ScottK: Congrats! [21:06] mdz: Thanks [21:07] TheMuso: Too. [21:07] [topic] ubuntu-core-dev application from Loic Minier [21:07] New Topic: ubuntu-core-dev application from Loic Minier [21:07] [link] https://lists.ubuntu.com/archives/motu-council/2008-January/000817.html [21:07] LINK received: https://lists.ubuntu.com/archives/motu-council/2008-January/000817.html [21:07] sabdfl: http://paste.debian.net/49057 [21:07] Séb sent this after Daniel's recommendation: https://lists.ubuntu.com/archives/motu-council/2008-January/000822.html [21:08] <\sh> ScottK, well done buddy :) congrats :) [21:08] Séb is by far my biggest sponsor [21:08] Thanks [21:08] BTW, TheMuso + ScottK: congrats :) [21:08] lool: Thanks. [21:09] lool: Thanks [21:09] Wurgh. Sorry about that, back now. [21:09] lool: you were involved in Debian for some time before Ubuntu. if you could make just one suggestion to all Debian developers regarding Ubuntu, and to all Ubuntu developers regarding Debian, what would they be? [21:10] lool: put another way, what do you think we understand least about one another? [21:10] thanks lool [21:10] I would suggest Debian Developers to steal more from Ubuntu; Ubuntu has many processes which can be envied, notably the "Spec" / blueprint concept which is running really nicely, but patches could also be taken more frequently [21:10] odd choice of paste service, under the circumstances :-) [21:11] To Ubuntu developers, I would like to suggest working hand in hand with Debian on all non-distinguishing topics; I think we can share most of our technical base, and would like distros to work more effectively together [21:12] lool: do you think it would help to work on some standard way of making technical decisions together? [21:12] do you have a suggestion how/on what? [21:12] mdz: Hmm, reading how you refined your question, I think many Debian folks see Ubuntu as a competitor or an enemy instead of a different offer for end users [21:13] it's all too easy to bring something up on a mailing list, get little or no response (or only dissent) and get stalled [21:13] it's important to us that we always keep moving and don't get blocked [21:13] mdz: I think it would help to take technical decisions, especially wide ranging ones or deep reaching ones together; the DEP concept floating around at the moment lets me think Debian folks see how the concept was successful with many groups [21:14] so while we would like for Debian and Ubuntu to stay aligned, we need some agility as well [21:14] Perhaps this will be ground on which to base cross-distros proposals [21:14] sabdfl: I tried to paste on ubuntu.com first, but it failed wrapping the text [21:14] sabdfl: You can note that down as an Ubuntu infrastructure improvement ;) [21:15] Keybuk: I'm sorry, which point(s) was your question aimed at? [21:15] lool: how to work hand-in-hand and what kind of topics? [21:16] mdz: I can only agree that Ubuntu was right at organizing itself to be able to differ on all topics; I mean to take the choice of having the possibility to change the whole distro instead of -- say -- try to work in Debian directly; I agree independance in decision making and technical changes is key [21:17] Keybuk: It's quite a large topic, but I can see some topics where convergence seems natural between the two distros: toolchain, or QA for example [21:17] These topics can be handled in many ways similarly for the two distros, and folks do share and exchange on these fronts [21:17] lool: it's easy to say we should work together on technical directions, but as mdz points out, there's no clarity on what that actually means, and how you keep moving forward on an idea [21:18] do you have specific suggestions in that regard? [21:18] On other topics, such as the kernel for example, there's no alignment at all [21:18] for example, if we want to consider moving to SMART as a default package manager, what would be the right process or venue to agree that with debian as opposed to simply executing it in ubuntu? [21:19] don't panic anybody, this is a thought experiment ;-) [21:20] I didn't think through as to what would moving to SMART imply; this is certainly a very long term discussion for which I'd try to gather interest in the Debian community first, perhaps explaining the concepts of SMART at Debconfs and proposing to mentor work on SMART [21:20] But I think there are more places where Debian and Ubuntu can truly share forces, such as packaging of base library which often carry little patching be it in Debian or Ubuntu [21:21] I like the idea of presenting more at debconf [21:21] we can't wait until debconf to make decisions, of course, but it would help to keep debian informed of what we're doing [21:21] It's kind of the software supermarket concept which has been frowned upon, but as I see it it could be applied to e.g. libraries or infrastructure packages [21:21] lool: DebConf*s* implies a multi-year process [21:22] sabdfl: SMART implies a multi-year process as I see it :) [21:22] realistically, moving to a new package manager framework probably is a multi-year process... [21:22] * lool fives mdz [21:23] mjg59: questions? [21:24] lool: What do you think of the Debian enhancement proposal work [21:24] ? [21:24] (I may have the precise name here wrong0 [21:24] ) [21:24] mjg59: mdz: I think it would help to take technical decisions, especially wide ranging ones or deep reaching ones together; the DEP concept floating around at the moment lets me think Debian folks see how the concept was successful with many groups [21:24] (I think that was referring to the same thing anyway) [21:24] Ah, ok, that does cover it [21:24] I did mention DEP shortly, and I think it's great Debian realized how useful such a process is [21:25] I'm not familiar with what's been discussed; is there a document which explains it? [21:25] Perhaps when it's around for a little while we will have some cross-distros proposals which will be declined as specs and deps at the same time [21:25] mdz: I think there is; as a result from the Extramadura discussions there were some links floating around [21:25] lool: declined? [21:26] defined, perhaps? :-) [21:26] Err expressed or defined; sorry, a Frenchism [21:26] that sounded uncharacteristically pessimistic, I thought [21:26] http://dep.debian.net http://lists.debian.org/debian-project/2008/01/msg00045.html [21:26] LINK received: http://dep.debian.net http://lists.debian.org/debian-project/2008/01/msg00045.html [21:26] thanks [21:26] mdz: see also http://dep.debian.net/deps/dep0 [21:27] Keybuk,sabdfl,mjg59: any further questions for lool? [21:27] none here, thanks [21:27] none from me [21:27] geser: thanks [21:27] I'm god [21:27] Sigh. [21:27] This keyboard is vexing me. [21:27] I'm good. Not god. [21:27] [vote] ubuntu-core-dev application from Loic Minier [21:27] Please vote on: ubuntu-core-dev application from Loic Minier. [21:27] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [21:27] E.g. /msg MootBot +1 #ubuntu-meeting [21:27] +1 [21:27] +1 received from mdz. 1 for, 0 against. 0 have abstained. Count is now 1 [21:27] +1 [21:27] +1 received from mjg59. 2 for, 0 against. 0 have abstained. Count is now 2 === juliux_ is now known as juliux [21:27] I feel that I should abstain, since lool reports to me [21:27] Private +1 vote received. 3 for, 0 against, 0 have abstained. Count is now 3 [21:28] sabdfl: was that you? [21:28] heh. private vote was me. [21:28] I hadn't noticed that feature before. apologies. [21:28] keescook: not a very good time to experiment with it [21:29] mdz: yup, sorry. [21:29] sabdfl: vote? [21:29] (there needs to be a way to define the "voting pool") [21:29] I suppose we could moderate the channel temporarily [21:30] so long as nobody gets clever and privmsg's it ;-) [21:30] we're not a large enough group to worry, surely? === \sh is now known as \sh_away === ubotu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 13 Feb 07:00 UTC: Platform Team | 13 Feb 13:00 UTC: Education Team | 13 Feb 21:00 UTC: Server Team | 13 Feb 22:30 UTC: Forum Council | 14 Feb 14:00 UTC: Desktop Team | 15 Feb 04:00 UTC: MOTU [21:30] Keybuk: it's been confused in the past, when someone is overenthusiastic [21:31] mjg59: if your keyboard vexes you, surely you should smite it? [21:31] It's an option [21:31] Keybuk: (+0 abstains, I believe) [21:32] I count 2 for, 0 against, 1 abstain, and sabdfl's vote pending [21:32] going to time out in a moment and consider it a vote among the 3 of us [21:32] [endvote] [21:32] Final result is 3 for, 0 against. 0 abstained. Total: 3 [21:33] [agreed] correction: 2 for, 0 against, 1 abstained. Total: 2 [21:33] AGREED received: correction: 2 for, 0 against, 1 abstained. Total: 2 [21:33] mdz: oh, you were telling me *how* to do it [21:33] heh [21:33] lool: congratulations [21:33] I was still hunting in the docs [21:33] mdz: Thanks [21:33] +1 [21:33] lool: congrats [21:33] lool: congrats. [21:33] Thanks! [21:33] well deserved [21:34] Wow, that fast [21:34] [topic] ubuntu-core-dev application from Mathias Gug [21:34] New Topic: ubuntu-core-dev application from Mathias Gug [21:34] mathiaz: still with us? [21:34] yes [21:34] lool: Congratulations [21:34] we're moving westward from here, so it shouldn't be so late for the remaining folks [21:35] [link] https://lists.ubuntu.com/archives/motu-council/2008-February/000855.html [21:35] LINK received: https://lists.ubuntu.com/archives/motu-council/2008-February/000855.html [21:36] mathiaz: could you answer the question i posed to TheMuso, about a top 3 list of things you'd like to see improved in the way ubuntu is structured, run or organised? [21:37] lool: Congrats! [21:38] sabdfl: I've recently though about ways to improve the number of contributors to the Server team. One thing I'd like to change is the put the sponsorship process in a more important place than becoming a MOTU. [21:38] mathiaz: what do you mean, in a more important place than becoming a MOTU? [21:39] sabdfl: whenever I'm faced with a potential contributor that would like to get his package in ubuntu, the anwser was to point them to become a MOTU [21:39] I've always found that MOTU is something that is heavily promoted. [21:40] However the barries to become a MOTU are high and some contributors turn away. [21:40] mathiaz: Congratulations. [21:40] I've sent an email about a mentoring proposal on ubuntu-server and got some private replies from people stating that they don't know where to start contributing [21:40] so, more important, or more accessible? [21:41] mathiaz: in other words, you think it should be easier / more encouraged to contribute before becoming a MOTU? [21:41] and would like to contribute somehow but not become a MOTU because it seems to high for them. [21:41] sabdfl: more accessible is a better world I think. [21:41] Sorry about that, I can't read. [21:41] i think i agree - MOTU is a wonderful team, of folks who make a huge contribution [21:41] generally, though, they care about the whole system, and are generalists [21:41] mdz: my point is that MOTU is not necessarly what you should aim for if start contributing to ubuntu [21:42] mathiaz: what if, say, someone could be granted commit privileges on a bazaar branch for a package, and contribute that way? [21:42] there is a class of people who care about a specific area, or category, or function, and we don't handle their contributions well [21:42] mdz: that would be much better [21:42] sabdfl: aggreed. I especially see this in the server team. [21:42] that would avoid the issue of upload privileges, and provide a natural sponsorship mechanism with low overhead [21:43] mdz: I'm all for this. [21:43] Something broadly along the lines of the Debian Maintainer policy? [21:43] mdz: I think it'd make more sense to have a middle ground between the team approach used in ubuntu and the maintainer approach of Debian [21:44] mjg59: in concept, yes, but with fine-grained access control via revision control, rather than a keyring [21:44] Sounds doable [21:45] * sabdfl would still like to see package-based upload permissions [21:45] sabdfl: I've met people wanting to get their application into ubuntu, but I was a bit unconfortable stating they should become a MOTU [21:45] but i can live with VCS [21:45] mjg59: the main problems are, 1) package source code isn't in revision control, and 2) the LP access control model for branches would mean a new team for every package [21:45] sabdfl: what if there was no upload? :) [21:45] Keybuk++ [21:45] s/dput/bzr tag/ [21:46] Keybuk: *nice* idea! [21:46] (or bzr something) [21:46] yeah, we should write a specification for that or something [21:46] *cough* [21:47] * ScottK kindly requests we not hard wire a particular VCS into our processes. [21:47] mathiaz: you were involved with gentoo before this, right? [21:47] mdz: as a user only [21:47] ScottK: DENIED [21:47] mdz: on of my previous job assignement was to build a web hosting using gentoo :/ [21:47] mathiaz: what do you miss about gentoo? [21:48] mdz: being able to take long coffee breaks while my systems are updating ;) [21:49] mdz: it's a distro usefull if you like to tweak your environement [21:49] mdz: and learn how things are working. [21:49] mathiaz: why? [21:49] mdz: so for personal education it's great. But I'd not use in a production environement. You always need to deploy binaries and make sure their qa is good. [21:50] mdz: you have to go through a whole manual install process - you get to learn how things are done then. [21:50] mathiaz: do you think it's possible for a distro to be both good for learning and good for production? [21:51] mdz: yes - that's what opensource is about. [21:51] mathiaz: so how could Ubuntu become better for learning? [21:51] mdz: in the case of gentoo, I'd say it lacks the production. [21:52] mdz: making easier for user to contribute. [21:52] I am much less interested in making gentoo better ;-) === cropalat_ is now known as cropalat [21:52] mdz: you start studying your system when you wanna fix a bug. [21:53] mdz: and the easier the fix will be accepted, the higher the chance are someone will take the time to fix it. [21:53] mdz: especially in companies where sysadmin maintain their own software [21:54] mdz: such as a webhosting company that has its own version of apache and php [21:54] mathiaz: it's pretty easy for people to send patches now. getting a good turnaround on them is much harder, though [21:54] even in Debian, which has many, many more developers, patches often fall on the floor [21:54] mdz: I'd like to tell them: send us your patches we'll integrate them ! [21:54] mathiaz: isn't that what the sponsorship process is? [21:55] mdz: yes. But it's not so widely used. [21:55] why not? [21:55] mdz: that goes back to my first argument. [21:55] mdz: there is also a lack of manpower on the other side of the queue. [21:56] mdz: I base my comments on the patches for server packages - as a side note. [21:56] which means we need more developers. so it is a circular argument :-) [21:57] again it sounds like that if the developers could get their patches in themselves, and someone just had to ack them, it would be easier? [21:57] Keybuk: you still need to review them. [21:57] Keybuk: especially if it's a new contributor. [21:58] that's certainly true [21:59] different question [21:59] how do you think Ubuntu Server and Ubuntu Desktop could be closer aligned? [21:59] Keybuk: I'd put that in a entreprise environment. [22:00] Keybuk: so authentication is key part here, with SSO. [22:00] SSO? [22:00] mathiaz: would a standardised approach to patch submission be a help? [22:00] single-sign on [22:00] Keybuk: Single Sign On [22:00] sabdfl: I think the sponsorship process is already good at this. [22:00] elaborate? [22:01] sabdfl: there are ressources on how you should submit patches and debdiff. [22:01] Keybuk: one great use case would be to deploy an Ubuntu Server and when adding new desktop you can authenticate using the accounts defined on the server. [22:02] would that authentication automatically apply to servers on the server as well? [22:02] servers on the server? [22:02] Keybuk: yes. [22:03] Keybuk: we've started to work on integrating postfix and dovecot so that they can leverage each other. [22:04] ...you'll set mdz off ;) [22:04] does anyone else have other questions? [22:05] not from me, I've read the feedback from the list [22:05] me also [22:05] mjg59 ? sabdfl ? [22:05] Keybuk: are you using french punctuation to help mathiaz feel at home? [22:06] :) [22:06] No, I'm happy [22:06] mdz: ¿no? [22:06] (and isn't that Spanish punctuation?) [22:07] sabdfl: stay awake, we have one more after this [22:07] and then we will be caught up [22:07] let's move to the vote [22:07] [vote] ubuntu-core-dev application from Mathias Gug [22:07] Please vote on: ubuntu-core-dev application from Mathias Gug. [22:07] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [22:07] E.g. /msg MootBot +1 #ubuntu-meeting [22:08] +1 [22:08] +1 received from Keybuk. 1 for, 0 against. 0 have abstained. Count is now 1 [22:08] +1, sustained good quality contributions, and anyone pitti trusts is OK by me [22:08] +1 [22:08] +1 received from mjg59. 2 for, 0 against. 0 have abstained. Count is now 2 [22:08] and for MootBot: [22:08] +1 [22:08] +1 received from mdz. 3 for, 0 against. 0 have abstained. Count is now 3 [22:08] [endvote] [22:08] Final result is 3 for, 0 against. 0 abstained. Total: 3 [22:08] mathiaz: welcome! [22:08] mathiaz: Congrats! [22:08] mdz: Thanks :) [22:09] * soren hugs mathiaz [22:09] rtg: still here? [22:09] mathiaz: Congrats. [22:09] yup [22:09] [topic] ubuntu-core-dev application from Tim Gardner [22:09] New Topic: ubuntu-core-dev application from Tim Gardner [22:09] yea mathiaz! [22:09] TheMuso: lool: Thanks - [22:09] [link] https://lists.ubuntu.com/archives/motu-council/2008-February/000861.html [22:09] LINK received: https://lists.ubuntu.com/archives/motu-council/2008-February/000861.html [22:09] My apologies for not attending any longer; I need to drive back home [22:10] lool: No problem [22:10] rtg: what has been the biggest challenge of Ubuntu kernel maintenance? [22:11] rtg: it's very unusual to join ubuntu-core-dev directly (rather than via MOTU) without a lot of prior packaging experience [22:11] sorry, +1 from me on mathiaz [22:11] Keybuk: learning the debian way. [22:11] mathiaz: Congratulations. (now) [22:11] mdz: I've been getting some excellent practice at packaging. [22:12] mdz: I notice that you dabbled in linux-meta. That one made my head hurt. [22:12] rtg: that one has grown many heads over the years [22:12] rtg: I'm familiar with your work on the kernel itself, but can you tell me more about the packaging work you've done? [22:13] One advantage I've had is that the packages I'm maintaining were relatively well structured. === doko_ is now known as doko [22:14] mdz: I started the packages for Hardy, based on the Gutsy stuff. [22:14] I also worked with Ben to break the lrm dependencies. [22:14] so that dist-upgrades don't drag lbm from one dist to the next. [22:15] rtg: do you have any interest in packages beyond the kernel? [22:15] let me rephrase, I broke the lbm dependencies. [22:15] In as much as the packages allow me to upgrade code and fix bugs, not really. [22:16] There are a number of packages outsire the core kernel that I need to deal with. [22:16] pci-ids, initramfs-tools, mosule-tools-init, etc. [22:16] s/mosule/module/ === _czessi is now known as Czessi [22:17] rtg: initramfs-tools has become pretty complex. how do you think it could be improved? [22:17] I feel that I understand packaging basics well enough to wade in and make changes without breaking anything. [22:17] mdz: I don't know about initramfs-tools enough to comment. [22:18] Most of my touches have been very light. [22:18] I do think its one I'm going to get familiar with pretty soon. [22:19] rtg: your situation is a good example of what sabdfl keeps talking about, where the existing process is a bit awkward [22:20] your focus is very much on a particular set of software (the kernel and surrounding parts), which also happens to live in main [22:20] mdz: I agree. I don't have the time or experience to be a MOTU. [22:20] Also, a great number of the folks I deal with are outside Debian. [22:20] it makes sense for you to be able to push kernel changes in, but the way that we've set the guidelines, we expect something quite different from people joining ubuntu-core-dev [22:21] in most cases, it makes more sense for folks to join MOTU first and work on packaging there, but if you joined MOTU, it probably wouldn't change your workflow at all [22:21] would you expect me to restrict my uploads to a core set of packages? [22:21] you'd still need to get the same kind of sponsorship [22:22] so I'm hesitant to recommend an incremental step which wouldn't make your life any easier [22:22] sabdfl: what are your thoughts? [22:23] rtg: in general, no [22:23] mdz: I think I lost the thread. Are you saying I don't need core-dev? [22:23] rtg: since ubuntu-core-dev carries privileges to touch *every* core package, we expect core developers to have demonstrated that they can work with a variety of non-trivial packages [22:24] we don't have the infrastructure to support this right now [22:24] rtg: I'm saying that you're highlighting a shortcoming of our existing team structure [22:24] the suggestion in the past has been to create the ability to approve someone as an uploader of a specific set of packages [22:24] they could collaborate with motu or core-dev on just those [22:24] in the past, we've sometimes dealt with this situation with a sort of limited mandate [22:24] mdz: That would work for me 'cause I'm really only interested in a few packages. [22:24] as their interest and ability expanded, they could become a full MOTU or core-dev [22:24] basically doing what sabdfl says, but with social mechanisms rather than technical ones [22:25] In practice, how many core-devs upload stuff just willy nilly? [22:25] don't they always cooperate with maintainers? [22:25] you'd be amazed! [22:25] especially since we don't really have designated maintainers [22:25] so it's not always clear who they should collaborate with [22:26] there is currently a shortage of kernel team members who can upload the kernel, and you've shown that you can do that, so I want to find an arrangement which would work [22:26] the kernel team already has a social mechanism in place for the packages we deal with. [22:26] it takes time for folks to learn the ubuntu way [22:26] I promise not to upload anything outside the sphere of my responsibilities. [22:27] rtg: it's true, part of what we want to be sure of is that a core developer won't make changes they're uncertain of without getting advice [22:27] I'd be too worried about stepping on someones toes. [22:27] rtg: which set of packages would that be? [22:27] see, even if we had a per-package mechanism, it would be pretty limiting [22:28] mdz: all of the kernel and dependent packages, plus a few related packages. [22:28] its a finite set. [22:28] Keybuk,mjg59: I'd appreciate your input on this as well, since it's not a straightforward case [22:29] I know it's late, but we're almost finished [22:29] Given that Tim can already commit to the kernel, I'm not convinced that letting him upload arbitrary packages is actually any more dangerous [22:29] it's true, he already has root on all of our boxen [22:30] but the same could be said of anyone with commit access to a package branch, and many upstreams, so it's an awkward precedent [22:30] mdz: I only have root on a few, not all. [22:30] I certainly agree that it would be advantageous to have a more fine-grained setup here [22:30] rtg: you commit changes to the source code for the kernel I run on all my computers :-) [22:30] But I'm not sold on the idea that we should block people from being able to get work done until that happens [22:31] mjg59: I agree, so I'd like to find a solution [22:31] mdz: I see your point. I guess I don't think deviously enough. [22:32] our attention is wandering due to the marathon meeting [22:33] Indeed [22:33] but I'm going to propose that we consider you for core-dev membership with a proviso for kernel work [22:33] rather than general package maintenance [22:34] that certainly works for me. [22:34] Keybuk,sabdfl,mjg59: is that workable? [22:34] +1 on the idea of a limited mandate. i have a separate question, for when this thread is done. [22:34] rtg: if you could spend a few days with linus, andrew morton, greg k-h, building a better process between upstream linux and distro kernel teams, what would you recommend? [22:34] I'd have no issue with it [22:34] +1 from me [22:34] ok, a vote then [22:35] sabdfl: I think Linus has a pretty good system in place. [22:35] Its messy, but it works for a large number of folks. [22:35] The distros should not be treated any different then the normal developer. [22:35] [vote] ubuntu-core-dev application from Tim Gardner, with the stipulation that it would specifically enable him to upload kernel-related packages (and he'll tread lightly elsewhere) [22:35] Please vote on: ubuntu-core-dev application from Tim Gardner, with the stipulation that it would specifically enable him to upload kernel-related packages (and he'll tread lightly elsewhere). [22:35] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [22:35] E.g. /msg MootBot +1 #ubuntu-meeting [22:35] +1 [22:35] +1 received from mjg59. 1 for, 0 against. 0 have abstained. Count is now 1 [22:35] +1 [22:35] +1 received from mdz. 2 for, 0 against. 0 have abstained. Count is now 2 [22:36] +1 [22:36] +1 received from Keybuk. 3 for, 0 against. 0 have abstained. Count is now 3 [22:36] sabdfl: your +1, as I interpreted it, was only for the idea of considering a limited mandate [22:37] sabdfl: could you vote on the application itself? [22:38] ok, sabdfl abstains [22:38] [endvote] [22:38] Final result is 3 for, 0 against. 0 abstained. Total: 3 [22:38] thanks, gentlemen. [22:38] rtg: thanks. if and when you think it's time, you can come back to us to revisit your mandate [22:38] mdz: we are gonna have to deal with this same issue for other kenel devs. [22:39] that's it for the applications. I suggest that we defer the remainder of the agenda to the next meeting due to the late hour [22:39] any objections? none? good [22:39] #endmeeting [22:39] Meeting finished at 22:39. [22:40] :p [22:45] thanks all [22:48] @schedule [22:48] Schedule for Etc/UTC: 13 Feb 07:00: Platform Team | 13 Feb 13:00: Education Team | 13 Feb 21:00: Server Team | 13 Feb 22:30: Forum Council | 14 Feb 14:00: Desktop Team | 15 Feb 04:00: MOTU [22:49] @schedule italy [22:49] @schedule rome [22:49] Schedule for Europe/Rome: 13 Feb 08:00: Platform Team | 13 Feb 14:00: Education Team | 13 Feb 22:00: Server Team | 13 Feb 23:30: Forum Council | 14 Feb 15:00: Desktop Team | 15 Feb 05:00: MOTU === profoX_ is now known as profoX`