[06:43] <nealmcb> @schedule denver
[06:43] <ubotu> Schedule for America/Denver: 11 Sep 09:00: Server Team meeting | 11 Sep 13:00: Technical Board | 12 Sep 14:00: Edubuntu | 13 Sep 06:00: Desktop Team Development | 18 Sep 09:00: Kernel Team | 19 Sep 06:00: Edubuntu
[06:51] <ajmitch> far too early in the morning for me
[07:23] <nealmcb> ajmitch: I can imagine!
[09:27] <soren> @schedule Copenhagen
[09:27] <ubotu> Schedule for Europe/Copenhagen: 11 Sep 17:00: Server Team meeting | 11 Sep 21:00: Technical Board | 12 Sep 22:00: Edubuntu | 13 Sep 14:00: Desktop Team Development | 18 Sep 17:00: Kernel Team | 19 Sep 14:00: Edubuntu
[09:43] <Balkhog> @now
[09:43] <ubotu> Current time in Etc/UTC: September 11 2007, 07:43:06 - Next meeting: Server Team meeting in 7 hours 16 minutes
[02:37] <zul> @schedule montreal
[02:37] <ubotu> Schedule for America/Montreal: 11 Sep 11:00: Server Team meeting | 11 Sep 15:00: Technical Board | 12 Sep 16:00: Edubuntu | 13 Sep 08:00: Desktop Team Development | 18 Sep 11:00: Kernel Team | 19 Sep 08:00: Edubuntu
[02:39] <juliux> @schedule berlin
[02:39] <ubotu> Schedule for Europe/Berlin: 11 Sep 17:00: Server Team meeting | 11 Sep 21:00: Technical Board | 12 Sep 22:00: Edubuntu | 13 Sep 14:00: Desktop Team Development | 18 Sep 17:00: Kernel Team | 19 Sep 14:00: Edubuntu
[02:46] <Balkhog> @now
[02:46] <ubotu> Current time in Etc/UTC: September 11 2007, 12:46:28 - Next meeting: Server Team meeting in 2 hours 13 minutes
[04:44] <pschulz01> G'day
[04:58] <mathiaz> hi all
[04:58] <sommer> hello
[04:59] <pschulz01> sommer: mathiaz Howdy.
[04:59] <jdstrand> hi!
[05:00] <nealmcb> saluton!
[05:00] <soren> Hello!
[05:01] <mathiaz> alright... Time to get started
[05:01] <mathiaz> dendrobates won't be here
[05:01] <mathiaz> #startmeeting
[05:01] <MootBot> Meeting started at 14:52. The chair is mathiaz.
[05:01] <MootBot> Commands Available: [TOPIC] , [IDEA] , [ACTION] , [AGREED] , [LINK] , [VOTE] 
[05:02] <mathiaz> The agenda for today is here: https://wiki.ubuntu.com/ServerTeam/Meeting
[05:03] <mathiaz> hi keescook !
[05:03] <soren> Hi, Kees!
[05:03] <jdstrand> hi keescook !
[05:03] <mathiaz> [TOPIC]  Setup TeamReporting
[05:03] <MootBot> New Topic:  Setup TeamReporting
[05:04] <keescook> hiya folks!
[05:04] <keescook> that's what I get for being late.  ;)
[05:04] <mathiaz> jono started an effort to implement reporting for each team part of Ubuntu
[05:05] <mathiaz> the desktopteam, the kernelteam are already using it.
[05:05] <mathiaz> everything is explained here https://wiki.ubuntu.com/BuildingCommunity/TeamReporting
[05:05] <mathiaz> the first step is to Nominate one or more people to overlook the team reporting
[05:06] <mathiaz> I'd be happy to do that. Anyone else would like to help me ?
[05:07] <dantalizing> I'll help out
[05:07] <Zic> @schedule Paris
[05:07] <ubotu> Schedule for Europe/Paris: Current meeting: Server Team meeting | 11 Sep 21:00: Technical Board | 12 Sep 22:00: Edubuntu | 13 Sep 14:00: Desktop Team Development | 18 Sep 17:00: Kernel Team | 19 Sep 14:00: Edubuntu
[05:08] <pschulz01> I'm completely clear what get's copies where on the 22nd of each month.
[05:08] <mathiaz> dantalizing: great ! I'll contact you to see how we can work together.
[05:08] <soren> Rock!
[05:08] <dantalizing> ok
[05:09] <mathiaz> [ACTION]  mathiaz and dantalizing will look after TeamReporting
[05:09] <MootBot> ACTION received:  mathiaz and dantalizing will look after TeamReporting
[05:09] <mathiaz> [TOPIC]  Talk about specifications tracking and the need to clean them
[05:09] <MootBot> New Topic:  Talk about specifications tracking and the need to clean them
[05:09] <nealmcb> I sent out an email last night about this agenda item.  It agenda item started with my note about the outdated wiki "talk" page from 2005: https://wiki.ubuntu.com/ServerTeam/talkd
[05:10] <nealmcb> Ive had some frustration in the4 past - not easy to see which blueprints are current, what current status is
[05:10] <nealmcb> Even this Bug 111610: can't see what is proposed for sprint, but not accepted
[05:10] <ubotu> Launchpad bug 111610 in blueprint "let us see which blueprints have been proposed for a sprint" [Medium,Confirmed]  https://launchpad.net/bugs/111610
[05:10] <nealmcb> So one thing is I'd like to understand our process for working with blueprints and encourage folks to keep things more up-to-date
[05:12] <mathiaz> There a lots of blueprints related to ubuntu-server
[05:12] <nealmcb> I also not lots of interest for a long time in various ways to make it easier to set up and administer common services and wonder if we should start using a PPA to try out things like ebox
[05:12] <nealmcb> yup
[05:12] <soren> nealmcb: We haven't got a set process (apart from what Launchpad encourages).
[05:12] <mathiaz> but nobody really looked after them as there wasn't any ubuntu server team dedicated to that.
[05:12] <pschulz01> What's a PPA?
[05:12] <Kamping_Kaiser> pschulz01, personal package archvie iirc
[05:12] <nealmcb> e.g. who can assign the team to a blueprint?  who can change importance?
[05:12] <mathiaz> I agree that we need to clean things.
[05:12] <soren> pschulz01: Personal Package Archive. It's like your own personal Ubuntu derivative.
[05:12] <Kamping_Kaiser> launchpad lets you create them now.
[05:13] <pschulz01> Ta.
[05:13] <soren> Kamping_Kaiser: Only if you're a member of launchad beta tester team.
[05:13] <mathiaz> nealmcb: may be we could try to clean things out by little step.
[05:13] <Kamping_Kaiser> soren, i'm not a memeber of the team, and i'm pretty sure i have an otpion in my LP account
[05:13] <mathiaz> nealmcb: I remember having a hard time with ldap related things.
[05:13] <soren> Kamping_Kaiser: That's a *very* recent change, then.
[05:14] <nealmcb> soren: yup - in the last few weeks
[05:14] <soren> Much more recent than that.
[05:14] <soren> I don't think it'll actually let you, but it's off topic anyway :)
[05:15] <nealmcb> I've created a PPA
[05:15] <mathiaz> https://blueprints.launchpad.net/~ubuntu-server/ has a list of tracked blueprints
[05:15] <mathiaz> so the first step could be to go through the wiki pages and figure out which one are specification
[05:15] <mathiaz> then subscribe ubuntu-server to it.
[05:16] <mathiaz> so that we can get a list of specifications in one place.
[05:16] <mathiaz> after than we can start cleaning things.
[05:16] <soren> nealmcb: You're also a member of the beta tester team..
[05:16] <nealmcb> can any ubuntu-server member subscribe and unsubscribe  the team from a spec?
[05:16] <mathiaz> I think so
[05:16] <nealmcb> soren: right - that is what Kamping_Kaiser said
[05:16] <soren> nealmcb: I think any lp user can. :)
[05:16] <soren> Kamping_Kaiser: au contraire.
[05:17] <soren> whoops
[05:17] <nealmcb> soren: oops - I misread that - sorry
[05:17] <soren> nealmcb: Nope. Quite the opposite. He said he's not a member.
[05:18] <mathiaz> so what do you think about my proposed plan ?
[05:18] <nealmcb> mathiaz: one fertile place to look for blueprints to subscribe the team to is the list of all the specs of all the team members
[05:18] <soren> So... What do we do? Go through the specs and clean them up? I think it's a good idea.
[05:18] <nealmcb> https://blueprints.edge.launchpad.net/~ubuntu-server/+specworkload
[05:19] <nealmcb> the "spec workload"
[05:19] <mathiaz> the first step would be to go through the wiki pages tagged as CategorySpec and make sure that the one related to server have ubuntu-server subscribed
[05:20] <nealmcb> I think marking old specs as done or superceded by another spec  in their wiki page would also help
[05:20] <mathiaz> nealmcb: sure. That's also needed.
[05:20] <nealmcb> mathiaz: but only ones that are relatively current
[05:21] <mathiaz> nealmcb: I think we need to have the big picture first
[05:21] <mathiaz> nealmcb: and then from the list we can start purging/merging the specs
[05:21] <nealmcb> that would be a whole lot of specs....  perhaps we can do the big picture on a wiki page, rather than as team subscriptions?
[05:21] <nealmcb> easier to organize....
[05:22] <mathiaz> well. That would be another wiki page... and blueprints.lp.net is specifically made for that.
[05:23] <mathiaz> b.lp.net also help to keep track of dependencies
[05:23] <mathiaz> if the wiki page is a Spec, it should have an entry in LP
[05:23] <mathiaz> so it'S just a matter subscribing ubuntu-server to it.
[05:24] <nealmcb> I'm afraid we would end up with so many out-of-date specs that people would get lost or daunted.
[05:24] <mathiaz> nealmcb: yes. The second step would be two purge the spec list from b.lp.net
[05:25] <mathiaz> /two/too/
[05:25] <nealmcb> who can set priorities for specs?
[05:25] <soren> nealmcb: Owners of the spec and Ubuntu drivers.
[05:25] <soren> IIRC
[05:25] <nealmcb> how many ubuntu drivers are on the server team?
[05:26] <mathiaz> none IIRC
[05:26] <soren> none
[05:26] <soren> https://edge.launchpad.net/~ubuntu-drivers/+members
[05:27] <mathiaz> so - what'S the action on this topic ?
[05:28] <nealmcb> I guess I want to look at the options we've discussed a bit more
[05:29] <nealmcb> and how well the various tools would support blueprint triage
[05:29] <mathiaz> ok... We'll continue to discuss that on the ML
[05:29] <mathiaz> nealmcb: would you mind sending an email to continue this discussion ?
[05:29] <nealmcb> will do
[05:29] <soren> Right. We should also remember that the Launchpad team always is open to input. If we need the blueprint management to change to be useful, it should change.
[05:30] <nealmcb> yeah - I've got some bugs in :-)
[05:30] <nealmcb> exporting lp relationship data as xml would help also
[05:30] <mathiaz> [ACTION]  nealmcb will send an email to ubuntu-server ml about blueprints cleaning
[05:30] <MootBot> ACTION received:  nealmcb will send an email to ubuntu-server ml about blueprints cleaning
[05:30] <nealmcb> do we want to discuss PPAs also?
[05:30] <nealmcb> or later?
[05:30] <mathiaz> [TOPIC]  Update on the tasksel tasks
[05:30] <MootBot> New Topic:  Update on the tasksel tasks
[05:31] <soren> Right.
[05:31] <soren> The blueprint is https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntu-server-tasks
[05:31] <mathiaz> dendrobates wanted to talk about adding new tasks
[05:31] <soren> I've just linked it to my branch of the ubuntu seeds, where I've added the print-server task.
[05:32] <soren> https://code.edge.launchpad.net/~shawarma/ubuntu-seeds/ubuntu.gutsy.server-tasks
[05:33] <soren> If anyone has some good, concrete suggestions for new tasks, just tell me, or even create a branch of ubuntu-seeds of your own.
[05:33] <pschulz01> mathiaz: Are we discussing the blueprint itself?
[05:33] <mathiaz> you've just added a printserver ?
[05:33] <mathiaz> which package do you think should be added to the task ?
[05:33] <pschulz01> email server
[05:33] <pschulz01> openVPN server
[05:33] <soren> mathiaz: http://tinyurl.com/3czchw
[05:34] <soren> mathiaz: I've requested input from our printing expert, but he hasn't gotten back to me yet.
[05:34] <soren> pschulz01: Openvpn server is a good idea!
[05:35] <mathiaz> is openvpn in main ?
[05:35] <mathiaz> nope
[05:35] <soren> no
[05:35] <pschulz01> has
[05:35] <soren> pschulz01: This won't help you much, I'm afraid.
[05:35] <soren> Tasks are mere a selection of packages.
[05:35] <mathiaz> I don't think we can an openvpn task then
[05:36] <pschulz01> soren: Something I've been thinking about.. https://wiki.ubuntu.com/PaulSchulz/UbuntuServerDocumentation
[05:36] <soren> mathiaz: It could get promoted, I guess.
[05:36] <mathiaz> soren: hum... printconf is in universe
[05:36] <soren> mathiaz: YEs.
[05:36] <mathiaz> soren: so you'd have to get it into main before it gets in printer-server task
[05:36] <soren> mathiaz: It is also just a suggestion. If Till thinks it's a really good idea, we could file a MIR for it.
[05:37] <soren> mathiaz: Yes, we don't enable universe by default, do we?
[05:37] <soren> mathiaz: ..on servers?
[05:37] <mathiaz> soren: not for the cds.
[05:37] <mathiaz> on server yes.
[05:37] <soren> Oh, ok.
[05:37] <mathiaz> universe is enabled by default on universe since feisty
[05:37] <soren> Well.. It's no problem then.
[05:38] <soren> It could work, then.
[05:38] <nealmcb> so are you saying we can have tasks that use packages in universe?
[05:38] <mathiaz> hum... I don't think so.
[05:38] <soren> Well, technically yes. Politically... Dunno.
[05:38] <nealmcb> got it
[05:38] <mathiaz> Because tasks are provided with the cd
[05:38] <mathiaz> so packages have to be on the cd
[05:38] <soren> mmm....
[05:38] <soren> No.
[05:38] <Mithrandir> no, you should not have tasks that include packages in universe.
[05:38] <mathiaz> and we don'T ship universe packages on cd
[05:39] <soren> Mithrandir: Ok.
[05:39] <pschulz01> mathiaz: While I like the idea, of tasks, I this it could be done as an 'after the fact' installation step.
[05:40] <mathiaz> pschulz01: you can run tasksel after you've installed your system
[05:40] <mathiaz> soren: are the other packages in main ?
[05:40] <soren> mathiaz: AFAIR, yes.
[05:41] <pschulz01> mathiaz: That's OK.. but I installed two servers today which just need the the minimal server install.
[05:41] <soren> mathiaz: I'll check it before I go any further with it, of course.
[05:41] <mathiaz> soren: so you're waiting for feedback from our printing expert
[05:41] <soren> mathiaz: Yes.
[05:41] <mathiaz> soren: and then try to get a task added
[05:42] <soren> mathiaz: Yes.
[05:42] <mathiaz> soren: I don't know if it's too late in the release cycle for that.
[05:42] <soren> mathiaz: It's not.
[05:42] <soren> mathiaz: It needs to be soon, but it's not too late yet.
[05:42] <mathiaz> soren: great then.
[05:42] <nealmcb> when is the freeze on tasks?
[05:43] <soren> Well... Since tasks are really just an easy way to isntall a set of packages we already support... it's not very intrusive at all.
[05:43] <mathiaz> anyone else has a idea about packages that should be added to the print-server task ?
[05:44] <nealmcb> soren: I guess they need documentation, so certainly before string freeze
[05:45] <soren> nealmcb:Yes, I guess they are translatable strings.
[05:45] <pschulz01> soren: Have you set up a print-server with these packages?
[05:45] <nealmcb> soren: I meant install documentation, but yes
[05:45] <soren> pschulz01: Nope.
[05:46] <mathiaz> soren: Seems that you know what you've got to do.
[05:46] <mathiaz> let's move on.
[05:47] <mathiaz> [TOPIC]  Choose an official MTA postfix/exim
[05:47] <MootBot> New Topic:  Choose an official MTA postfix/exim
[05:47] <mathiaz> dendrobates asked to raise this point.
[05:47] <nealmcb> thanks, soren!
[05:47] <mathiaz> I'm not sure what he meants by that.
[05:47] <lamont> it probably refers to the fact that both are in main
[05:48] <soren> mathiaz: Well, for one thing it would be useful for knowing which MTA to install for the mail-server task :)
[05:48] <mathiaz> isn't that postfix ?
[05:49] <lamont> postfix was chosen pre-warty as the official MTA, installed in warty and hoary (and breezy???), then dropped since grandma doesn't need an MTA
[05:49] <mathiaz> keescook: do you have any issue with supported two MTA in main ?
[05:49] <soren> mailx depends on "exim4 | mail-transport-agent".
[05:50] <soren> lamont: Right, and since then we (allegedly) haven't had a preferred mta.
[05:50] <lamont> that's because it's synced from debian, and one specifies $real-package | $virtual-package
[05:50] <keescook> mathiaz: nope, (we already do)
[05:50] <pschulz01> To throw something in.. one 'complaint' I have heard recently is that 'mutt' requires postfix, when the end user wanted to use exim... the dependency is "postfix | mail-transport-agent"
[05:50] <soren> lamont: I know.
[05:50] <soren> lamont: But if we truly preferred postfix, we'd change that sort of thing.
[05:50] <lamont> pschulz01: that's not requiring postfix.  that's installing postfix if you don't have an MTA already
[05:50] <lamont> soren: I did once...
[05:50] <soren> pschulz01: Then it doesn't require postfix.
[05:50] <lamont> pschulz01: apt-get install mutt exim4 (or have exim4 installed before installing mutt)
[05:50] <soren> pschulz01: exim4 will fulfill the dependency too and not force postfix upon the user.
[05:51] <pschulz01> all: Ta.. I'll pass that on..
[05:51] <lamont> soren: the question is: do we care enough to for those packages _just_ to s/exim4/postfix/?
[05:51] <soren> I think actually the discussion arose at the sprint in July where Rick and I discussed that some packages said "postfix | m-t-a" and others said "exim4 | m-t-a"
[05:52] <lamont> Kamping_Kaiser: that's a different discussion
[05:52] <Kamping_Kaiser> lamont, ok
[05:52] <soren> Kamping_Kaiser: On a desktop?
[05:52] <soren> lamont: I don't. :)
[05:52] <lamont> (on a server it makes sense, on the desktop, it's lunacy, especially if it's grandma's desktop)
[05:52] <Kamping_Kaiser> soren, i'm thinking more of the servers actualy, but its somewhat aplicable to desktops
[05:53] <soren> Kamping_Kaiser: I'd love to discuss it at a different time :)
[05:53] <pschulz01> Kamping_Kaiser: It's another service that isn't needed on a desktop/workstation. I'm thinking of 'network appliance'.
[05:53] <lamont> (an MTA on the desktop, for the "typical" user means that eventually we fill up their disk with mail messages that they don't even know to read.
[05:54] <soren> To get back on track... Do we care enough to prefer one of the other?
[05:54] <sommer> for what it's worth I vote for Postfix as "official MTA"
[05:54] <pschulz01> lamont: exactlly.
[05:54] <lamont> soren: I cared enough to make the change when we were shipping postfix installed by default, and was then a big supporter of the "stop installing postfix by default" campaign
[05:54] <mathiaz> soren: so the issue is to fix packages which specifies ""exim4 | m-t-a" ?
[05:55] <mathiaz> sommer: what is documented in the ubuntu server guide ?
[05:55] <sommer> another point for Postfix is it's currently documented better than exim.
[05:55] <nealmcb> and what do we suggest in documentation, in ubotu and in the support channels
[05:55] <pschulz01> soren: Can the 'ubuntu-server' claim this decision, given that we are the ones that will be caring the most about it?
[05:55] <sommer> mathiaz: Postfix and Exim
[05:55] <pschulz01> soren: (do you think?_
[05:55] <lamont> s/happy/willing/  :)
[05:55] <soren> The advantage of doing an s/exim4/postfix/ in all cases would be that it avoids confusion between two users who don't care which m-t-a- they've got, but care about being able to exchange experiences about the m-t-a their system has chosen to provide them with.
[05:55] <mathiaz> pschulz01: I think we'll have to discuss that ubuntu-devel anyway
[05:56] <soren> pschulz01: Yes, I belive so.
[05:56] <pschulz01> mathiaz: Yes...
[05:56] <soren> pschulz01: For any other team, it's a service rather than a detail they need to specifically worry about.
[05:56] <soren> But yes, of course we need to run it by everyone else.
[05:57] <lamont> mathiaz: since desktop doesn't install an mta, we can assert that they don't care
[05:57] <soren> ..but my stance in that discussion is that it's our decision.
[05:57] <lamont> (as long as we don't force postfix over exim, which will cause um... issues)
[05:57] <lamont> s/will/would/
[05:57] <nealmcb> what does "force" mean there?
[05:57] <soren> lamont: Would adding postfix to a mail-server task be considered "forcing postfix over exim"?
[05:57] <mathiaz> soren: so you're suggestion is to s/exim/postfix/ in the package control file.
[05:57] <mathiaz> soren: ?
[05:58] <pschulz01> mathiaz: soren: It would be possible to argue the same on other packages as well.
[05:58] <soren> mathiaz: I don't have a strong postfix preference, but yes, I belive it would be a good idea to unify it.
[05:58] <pschulz01> mathiaz: soren: eg. kubuntu, edubutu and their desktop packages.
[05:58] <mathiaz> soren: ok. Could you send an email to ubuntu-devel to discuss that changes ?
[05:58] <soren> pschulz01: Huh?
[05:58] <soren> mathiaz: Sure.
[05:59] <Kamping_Kaiser> what about the ltsp (edubuntu) server?
[05:59] <nealmcb> default to postfix, but don't break things if user specifies exim4?
[05:59] <mathiaz> [ACTION]  soren will send an email to ubuntu-devel about using postfix as default package in control files.
[05:59] <MootBot> ACTION received:  soren will send an email to ubuntu-devel about using postfix as default package in control files.
[05:59] <pschulz01> nealmcb: +1
[06:00] <lamont> nealmcb: exactly
[06:00] <Kamping_Kaiser> nealmcb, sounds nice
[06:00] <mathiaz> [TOPIC]  Review ACTION points from previous meeting.
[06:00] <MootBot> New Topic:  Review ACTION points from previous meeting.
[06:00] <pschulz01> soren: Just arguing that thee will be other packages with similar logic.
[06:00] <soren> lamont: I.e. don't violate debian policy :)
[06:00] <lamont> backuppc, logcheck, mailman, mailx are the main packages affected
[06:00] <lamont> soren: yeah..
[06:00] <mathiaz> Previous meeting log is here: https://wiki.ubuntu.com/MeetingLogs/Server/20070828
[06:01] <Kamping_Kaiser> iirc debians default mta is exim4 isnt it?
[06:01] <lamont> yes
[06:01] <soren> Kamping_Kaiser: Sounds right.
[06:01] <mathiaz> DocDay was organised - The KnowledgeBase wiki page has been updated.
[06:01] <lamont> and that is precisely what leads to the Depends: line for debian (and synced packages)
[06:02] <mathiaz> sommer: thanks for updating the php5 documentation.
[06:02] <sommer> no problem
[06:02] <mathiaz> sommer: I've seen a couple of patches for the ubuntu server guide about it, right ?
[06:02] <Kamping_Kaiser> lamont, just wondering if its saner to default to exim4 because less packages would need changing (i have nfi, fwiw)
[06:03] <sommer> mathiaz: Yep, the first was a very minor update and the second was some content on php5-cgi
[06:03] <mathiaz> sommer: thanks for that.
[06:03] <sommer> it's currently being reviewed, I believe.
[06:03] <mathiaz> sommer: does the ubuntu server guide needs more change ?
[06:04] <sommer> welcome
[06:04] <mathiaz> sommer: how accurate is it for gutsy ?
[06:04] <sommer> the Dovecot part should be good...I haven't tested much else on Gutsy
[06:05] <sommer> OpenLDAP section is probably okay...now that I think about it
[06:05] <sommer> I can review the other packages if you want.
[06:06] <mathiaz> sommer: that's be great - if you could review some sections of the server guide.
[06:06] <pschulz01> sommer: link?
[06:06] <sommer> https://help.ubuntu.com/7.04/server/C/
[06:06] <pschulz01> sommer: Ta
[06:06] <mathiaz> is someone else interested in updating/reviewing the ubuntu server guide ?
[06:07] <sommer> that's for feisty anyway
[06:07] <pschulz01> mathiaz: Yes
[06:07] <mathiaz> pschulz01: great ! Could you coordinate with sommer on the section you'd like to review ?
[06:08] <Kamping_Kaiser> isnt string freeze tomorrow?
[06:08] <nealmcb> string freeze is thursday....
[06:08] <sommer> cool we should be able to cover more ground
[06:08] <pschulz01> sommer: I need to go through the entire document anyway.. wit a couple of new servers.
[06:08] <mathiaz> sommer pschulz01: and add an item in the Roadmap
[06:08] <Kamping_Kaiser> nealmcb, thats my tomorrow
[06:09] <nealmcb> :-)
[06:09] <sommer> mathiaz: sure I'll add links to what I'm working on
[06:09] <mathiaz> [ACTION]  sommer pschulz01 will start to review the ubuntu server guide
[06:09] <MootBot> ACTION received:  sommer pschulz01 will start to review the ubuntu server guide
[06:09] <nealmcb> we need someone in Hawaii to work on it :-)
[06:09] <mathiaz> [ACTION]  sommer will add an item to the Roadmap
[06:09] <MootBot> ACTION received:  sommer will add an item to the Roadmap
[06:10] <nealmcb> ...except for that little detail about it being UTC and all....
[06:10] <mathiaz> [TOPIC]  Review each section of the ServerTeam/Roadmap.
[06:10] <MootBot> New Topic:  Review each section of the ServerTeam/Roadmap.
[06:11] <mathiaz> nealmcb: how is the factoids update going ?
[06:11] <nealmcb> I got a list of the biggest outages in the roadmap
[06:11] <nealmcb> and a bit of text for 2 of them.  the mail discussion has helped with how to word them
[06:12] <nealmcb> I welcome suggestions, and will continue working on them
[06:12] <mathiaz> nealmcb: the list seems great ! Thanks for putting this up.
[06:13] <mathiaz> nealmcb: may be you could send an email to ubuntu-server with the list of some preliminary text for each fact ?
[06:13] <nealmcb> ok
[06:13] <mathiaz> [ACTION]  nealmcb will send an email to ubuntu-server with the proposed factoids.
[06:13] <MootBot> ACTION received:  nealmcb will send an email to ubuntu-server with the proposed factoids.
[06:14] <mathiaz> As for AppArmor, the kernel has been updated with the latest version.
[06:14] <mathiaz> I'm currently testing the user space update.
[06:14] <keescook> mathiaz: jj sent the kernel patch for syslog to kyle
[06:15] <mathiaz> But still have problems with the livecd, due to stacked file system.
[06:15] <mathiaz> keescook: Ok. I've pinged BenC which pointed me to kyle.
[06:15] <mathiaz> so the new userspace utils work with the kernel module
[06:16] <mathiaz> except for the aa-genprof tool
[06:16] <keescook> cool.  and this is from http://bazaar.launchpad.net/~mathiaz/apparmor/ubuntu-mathiaz/ tree, correct?
[06:16] <mathiaz> keescook: yes. everything is there.
[06:16] <mathiaz> upstream has released a tarbal for 2.1
[06:17] <mathiaz> actually it's a pre-release.
[06:17] <mathiaz> As I've been following their svn closely it should work well
[06:17] <keescook> excellent.  Looking at the changelog, what is this for:  * Remove apparmor-utils depends on bsdutils
[06:18] <mathiaz> keescook: it's a warning from lintian
[06:18] <mathiaz> keescook: bsdutils is part of base
[06:18] <keescook> oh, duh.  :P
[06:18] <mathiaz> keescook: so if you wanna depend on it, you need to depend on specific version
[06:18] <keescook> and you've totally dropped apparmor-modules-source?  Isn't it handy for helping the kernel team do merges?
[06:19] <mathiaz> I don't think so.
[06:19] <keescook> okay
[06:19] <mathiaz> kyle got the source from their svn tree.
[06:19] <keescook> I'll test this too, and upload it.
[06:19] <mathiaz> ok. cool.
[06:20] <mathiaz> Is there anything else ?
[06:20] <keescook> not from me.  :)
[06:21] <jdstrand> I'll mention since dendrobates is not here that I will be looking at ldap-auth-client and trying to finish it up
[06:24] <mathiaz> jdstrand: great. Thanks.
[06:24] <mathiaz> So the next meeting will take place in two weeks.
[06:24] <mathiaz> same time, same place.
[06:24] <nealmcb> thanks all
[06:24] <sommer> cool thanks all
[06:24] <mathiaz> thanks for stopping by.
[06:25] <jdstrand> bye!
[06:25] <mathiaz> #endmeeting
[06:25] <MootBot> Meeting finished at 16:16.
[06:26] <nealmcb> NOT
[06:26] <soren> I've filed a bug against mootbot about the time being off, by the way :)
[06:26] <pschulz01> Goodnight all!
[06:26] <nealmcb> soren: thanks - I was about to do the same thing
[06:26] <soren> nealmcb: :)
[06:28] <nealmcb> soren: as a subscriber to time-nuts@febo.com I'm a certified nut :-)
[06:28] <soren> nealmcb: I have no clue what that is :)
[06:29] <nealmcb> a list for folks that love not just ntp, but all kinds of high-precision time stuff
[06:29] <Balkhog> hi..
[06:30] <soren> nealmcb: Oh, I see.
[06:30] <soren> nealmcb: Yes, in that case, MootBot must make you cry :)
[06:34] <nealmcb> soren: yup
[06:42] <soren> @schedule Copenhagen
[06:42] <ubotu> Schedule for Europe/Copenhagen: 11 Sep 21:00: Technical Board | 12 Sep 22:00: Edubuntu | 13 Sep 14:00: Desktop Team Development | 18 Sep 17:00: Kernel Team | 19 Sep 14:00: Edubuntu | 19 Sep 22:00: Xubuntu Developers
[09:02] <Keybuk> mdz, mjg59, sabdfl: TB time?
[09:03] <mjg59> Keybuk: Sure
[09:04] <Keybuk> SMS'd the other two ...
[09:07] <Keybuk> mdz won't be around for another 20 mins, and no response from sabdfl
[09:07] <Keybuk> since two of the issues are yours, I don't think we have a reasonable Q to discuss them
[09:08] <mjg59> Yeah. Wait for mdz?
[09:09] <Keybuk> yes
[09:09] <Keybuk> let's defer until half past
[09:18] <soren> Since I haven't heard anything, I take it you won't be handling my core-dev application today?
[09:19] <Keybuk> soren: I've gotten completely confused and baffled as to what the core-dev process is now
[09:20] <soren> Keybuk: I can relate to that :)
[09:20] <soren> Keybuk: IIUIC, motu-council looks it over to  see if it's complete crack. If not, they forward to you. You're then supposed to invite the applicant to a TB meeting to do an interview.
[09:22] <soren> "The TB will review and respond, usually setting up an appointment to attend a meeting."
[09:23] <soren> https://wiki.ubuntu.com/NewDeveloperProcess
[09:23] <Keybuk> I guess we'll do it later then
[09:24] <soren> As in "not today"?
[09:24] <Keybuk> aha, an mdz
[09:24] <Keybuk> mdz: shall we start?
[09:24] <mdz_> surely
[09:24] <mdz_> who's here?
[09:25] <Keybuk> me and mjg59
[09:25] <mdz_> tried sabdfl?
[09:26] <Keybuk> sent an SMS
[09:26] <Keybuk> no response
[09:26] <mdz_> ok
[09:26] <mjg59> Hi
[09:26] <mdz_> so we discussed the compiz issue in some detail already, but we didn't take a decision
[09:27] <mdz_> knowing it is near and dear to his heart, I'm loathe to vote on it without him
[09:27] <mdz_> s/him/sabdfl/
[09:27] <mjg59> The majority of the feedback on the mailing lists appeared to be "If it causes problems, don't use it by default", but very little analysis of the issues appeared
[09:28] <mjg59> mdz_: On the other hand, our next meeting is two days before beta
[09:28] <mdz_> it didn't get as much of a response as I expected it would
[09:28] <mjg59> One technical issue that I've been made aware of since then - Xv doesn't work at all on 965 with compiz
[09:29] <mdz_> bug?
[09:29] <mjg59> I've discussed this with Intel, and it's not fixable.
[09:29] <mdz_> or something more insidious?
[09:29] <Keybuk> why isn't it fixable?
[09:29] <mjg59> They only support composited video with EXA
[09:29] <Keybuk> "not fixable" is a very terminal answer
[09:29] <Keybuk> X11esign flaw?
[09:29] <Keybuk> X11 design flaw?
[09:29] <mjg59> Issue with the architecture of the driver
[09:30] <Keybuk> so it's fixable, just with a large amount of work
[09:30] <mjg59> The textured video requires acceleration functionality that's disabled if XAA is used with composite
[09:30] <Keybuk> or by enabling EXA?
[09:30] <mjg59> Right. Intel won't do that work, and we have no docs
[09:30] <mjg59> EXA is the other option, but there are still stability issues with EXA and the tiling code in the 965 driver
[09:31] <Keybuk> it strikes me that we're repeatedly in a rock-and-hard-place situation:
[09:31] <Keybuk>  - drivers aren't good enough to support bling
[09:31] <mdz_> mjg59: if we took a late decision to change the compiz default, given that it's been the focus of a large chunk of our efforts for 7.10 and the community has been demanding it for a year, do you have a suggestion as to how we would message such a decision?
[09:31] <Keybuk>  - without requirements of bling, there's no incentive to make the drivers good enough
[09:31] <mjg59> Intel are workign on the basis that composited desktops won't be ready for rolling out until EXA is stable enough anyway, so it's not a concern
[09:32] <mjg59> mdz_: Simply that after spending a longer period evaluating it, we've decided that the technology still isn't quite ready
[09:32] <mdz_> mjg59: ...again
[09:33] <mjg59> As I've noted before, I'm disappointed that we got to this stage despite effectively no progress having been made on the technical issues in the intervening time
[09:33] <mjg59> I think that's a failure in our development process
[09:34] <Keybuk> what do you identify the failure as, specifically?
[09:34] <mjg59> Keybuk: The decision to target the spec at gutsy without having ensured that the reasons we failed to accept it for feisty had been rectified
[09:34] <mdz_> #@!$ xchat
[09:34] <mdz_> apologies
[09:35] <mjg59> mdz_: What did you last see?
[09:35] <mdz_> mjg59: we didn't decide to pursue it because we thought the issues were resolved
[09:35] <mdz_> we decided to push ahead, follow the bleeding edge, and see it through
[09:36] <mjg59> mdz_: That would seem understandable if we'd been putting any work into resolving those issues, but we haven't
[09:36] <mdz_> our users are early adopters, and support for this decision was strong
[09:36] <smurf> What are other bling-enabled distros doing? Ignore the problems?
[09:36] <mdz_> mjg59: and when you say "we", who do you mean?
[09:37] <mdz_> compiz?  x.org?  Michael?
[09:37] <mjg59> Most of the problems don't turn up with Xgl, so Novell don't have this problem. Red Hat aren't going to enable compiz for some time yet.
[09:37] <mjg59> mdz_: The Ubuntu development community
[09:37] <smurf> ah. Thx
[09:37] <mjg59> The amount of work that RH are contributing to this is moderate, but not enough to get it working properly in less than a year or so from now
[09:38] <Keybuk> you've just said above that the Ubuntu development community cannot help fix the issues
[09:38] <Keybuk> and that only Intel can
[09:38] <mdz_> we aren't exactly overflowing with graphics driver developers
[09:38] <Keybuk> (and they won't)
[09:38] <mdz_> here in the Ubuntu development community
[09:38] <mjg59> Keybuk: No, that's an issue with one specific driver. The EXA issues could mostly be fixed up by anyone with graphics experience, and that's starting to happen.
[09:39] <mjg59> mdz_: Indeed. So no matter how hard we press ahead in terms of the bleeding edge, none of the problems get solved and we're left with exactly the same issues that caused us to punt it in feisty
[09:39] <Keybuk> are some of those people running Ubuntu?
[09:39] <Keybuk> in which case, they're arguably members of our development community
[09:40] <mjg59> Keybuk: There are a moderate number of people at the X summit running Ubuntu, but most of the driver-side technical community seem to be using Fedora
[09:40] <Keybuk> have we, by positioning it as a feature for gutsy, motivated anybody to work on fixing the underlying issues?
[09:40] <mjg59> No
[09:40] <Keybuk> since that's the only real power we, the TB, have
[09:41] <mjg59> The fundamental issues are currently being worked on by RH staff and nobody else
[09:41] <Keybuk> why?
[09:41] <Keybuk> why are non-RH people not working on this?
[09:41] <mjg59> Nobody at XDS is running compiz
[09:41] <Keybuk> XDS?
[09:41] <mjg59> X Development Summit
[09:41] <mdz_> what used to be called XDC
[09:41] <mjg59> We get XDC and XDS each year
[09:42] <Keybuk> so the question remains, why isn't anybody interested in this enough to fix the issues?
[09:42] <mjg59> Because nobody who has the skills to fix it is interested in running the software
[09:42] <Keybuk> and why aren't they doing that?
[09:43] <mjg59> The general feeling in the X community is pretty much that compiz is not of high quality
[09:43] <mdz_> is it considered a bad idea?  or just uninteresting for some reason?
[09:43] <Keybuk> not of high quality because they haven't fixed the drivers? :p
[09:43] <Keybuk> or not of high quality for other reasons?
[09:43] <mjg59> The technical aspects of a composited desktop are interesting, but there are more fundamental issues that people want to fix first
[09:43] <mjg59> People want to get X up to the Win2K level before trying to match Vista
[09:44] <Keybuk> at GUADEC, the issues seemed to be input/output hotplug and input redirection
[09:44] <mjg59> Yes. Input hotplug is almost solved, and there are plans for input redirection
[09:44] <Keybuk> uh, insert "that people want to fix first" in there
[09:45] <Keybuk> are those still the issues, or are there additional issues before composited desktop?
[09:45] <mjg59> Novell are interested in working on input redirection, because that gets them to the point where Xgl basically works fully
[09:45] <mjg59> They have no real interest in working on aiglx right now, as far as I can see
[09:46] <Keybuk> why are we using AIGLX instead of Xgl?
[09:47] <mdz_> because keithp told sabdfl that we should
[09:47] <mjg59> It's the more elegant solution, and up until recently (I'm less sure about the present) the performance of it on intel was dire
[09:48] <mdz_> let's look at this from a slightly different angle
[09:48] <mdz_> rather than evaluating the merits of compiz itself
[09:48] <mjg59> Sorry, that is the performance of Xgl
[09:48] <Keybuk> mdz_: sure, I was just asking questions there since I don't really know much about the politics of this
[09:48] <mdz_> what is the effect we will have on Ubuntu if we make this change, vs. the effect we will have if we leave it alone?
[09:49] <mdz_> the first choice will, I'm sure, disappoint a lot of community members and result in a lot of bad press
[09:49] <mjg59> Is "this change" removing compiz or shipping it?
[09:49] <mdz_> the second will result in functional problems for some users
[09:49] <mdz_> mjg59: the change you propose, to disable it by default
[09:49] <mjg59> Bear in mind that most people consider the stable release to be the status quo
[09:50] <mjg59> (That is, no compiz)
[09:50] <mdz_> mjg59: AIUI, compiz isn't enabled on upgrade
[09:50] <mdz_> so nothing changes for them
[09:50] <mdz_> (either way)
[09:51] <mjg59> Some moderate proportion of people reinstall on updates
[09:51] <mdz_> a moderate proportion of people also install a release other than the current one
[09:51] <mjg59> Anyway, yes, it's clear to me that not providing compiz by default will be a publicity issue
[09:51] <mdz_> (other being older)
[09:52] <mdz_> I'm fairly certain I understand who the people are who would be disappointed by disabling it
[09:52] <mdz_> however, I don't feel that I have a good understanding of the people who are affected by the problems
[09:52] <mjg59> But I also question the media response to finding that there are obvious functionality issues
[09:52] <mdz_> how to characterize them, some feeling of their number
[09:53] <mdz_> casual desktop users?  not really
[09:53] <mjg59> I dislike the idea of basing the decision on "Which people will be more angry"
[09:53] <mdz_> that's not what I'm suggesting
[09:53] <mdz_> "whose interests are we representing?"
[09:53] <mjg59> The people we're most likely to alienate are going to be the more technical users
[09:54] <mjg59> Unless they all just turn compiz off, which is a possibility...
[09:54] <mdz_> I question whether it's obvious enough how to turn it off
[09:55] <Keybuk> before you suggest it, any functionality that has to first warn or remind you about it, clearly has something wrong with it
[09:55] <mjg59> I suspect that we're going to run into the same problem that we did last time
[09:56] <mdz_> I was not suggesting any such thing
[09:56] <mjg59> That is, discussing things at length without reaching a decision
[09:56] <Keybuk> that's like a form which is so complicated and unintuitive, that it has to pop up another dialog over top first telling you what you need to fill in
[09:56] <Keybuk> (yes canonical admin, I'm looking at *you*)
[09:56] <mdz_> Keybuk: what does mvo have to say about it?
[09:56] <Keybuk> mdz_: "eep" (paraphrasing)
[09:56] <mjg59> We need to decide what basis we're going to make the decision on
[09:57] <mdz_> Keybuk: what was the question?
[09:58] <mdz_> mjg59: there's not much guidance in the founding documents on that point
[09:58] <Keybuk> mdz: basically that we've done so much work to get compiz ready, that it seems annoying to abandon it now
[09:58] <Keybuk> especially since we've got little else to shout about gutsy
[09:58] <mdz_> but intuitively, this body is responsible for evaluating technical correctness and merit
[09:58] <mdz_> and I don't think there's much contention over this issue from a technical perspective: it's bleeding
[09:58] <mjg59> Yes
[09:59] <mdz_> that doesn't feel like a complete notion of our responsibility though
[09:59] <Keybuk> sabdfl is at vmworld with no internet
[09:59] <mdz_> I think we're also responsible for making such decisions on behalf of our users (and our potential users)
[09:59] <mjg59> But it also seems that the decision to press for compiz in gutsy was not especially based on technical correctness
[10:00] <mdz_> Keybuk: I tried to call him and didn't get through. does he have a phone?
[10:00] <mjg59> And in that case, I would feel less comfortable about making a decision on it
[10:00] <Keybuk> he responded to an SMS
[10:03] <mdz_> I have him on the phone now
[10:03] <mdz_> will get a response of some kind and relay it
[10:05] <Keybuk> mvo: read scrollback and comment :)
[10:06] <Keybuk> got to switch pcs so I can make some dinner
[10:06] <Keybuk> paste me anything below this line when I reappear
[10:06] <Keybuk> :p
[10:08] <nealmcb> Keybuk: didn't miss a things...
[10:11] <mdz_> (still on the phone)
[10:14] <mdz_> he is going to try to get online
[10:14] <mdz_> but in a nutshell, still supports having it enabled by default
[10:15] <mvo> I finished reading scrollback now and have little to add. the technical issues left (no redirected indirect rendering) are nothing we can fix at this stage we either have to accept it or try to workaround it by doing some hacks to try to detect when we have glx using apps that run in non-fullscreen mode
[10:15] <mdz_> mjg59: do you think there is any quantitative way we can assess whether it works well for most of our current users?
[10:15] <mjg59> mdz_: Not really, no
[10:15] <mdz_> I feel a bit doomed either way, not having much in the way of concrete data to work from
[10:15] <mvo> mjg59: I got positive feedback about basic video playback on a i965 but I can not confirm that myself
[10:16] <mdz_> mvo: of the issues mjg59 has raised, can you tell us if they seem to be encountered frequently by users?
[10:16] <mjg59> Some feedback on how many people are actually using it would be helpful, but since we don't enable it by default on upgrades it's quite possible that most of the people following gutsy aren't running it
[10:16] <mdz_> mvo: do you get many bug reports about them?
[10:16] <mdz_> mjg59: fair point
[10:17] <mdz_> if I consider this from a technical perspective, then I can only agree with mjg59
[10:17] <mdz_> correctness is not a question here
[10:17] <mdz_> it has bugs
[10:18] <mvo> we get a fair number of reports, but not that many about video/glx apps it seems. but its difficult to tell if people just bear with it because its still pre-beta or because they not encounter issues
[10:18] <mvo> indeed, it has bugs
[10:18] <mdz_> I do not think it has bugs which prevent people from using it
[10:18] <mdz_> but it does give some people a bad experience
[10:18] <mvo> and it will be less stable/reliable than metacity for sure (even if it itself would be bugfree it would trigger bugs in the drivers)
[10:18] <mdz_> is there anyone lurking in the channel who would like to speak up about their experience with compiz?
[10:19] <Mithrandir> I don't have a strong opinion either way, it worked fine for the half hour I cared to test it on my laptop.
[10:19] <Amaranth> Hi
[10:19] <Mithrandir> but I don't use it myself, since it doesn't support chained shortcuts.
[10:19] <mvo> Amaranth does a lot of bug triage on compiz
[10:20] <soren> I use it happily.
[10:20] <mvo> Mithrandir: is there a bugreport about this?
[10:20] <soren> I've set mplayer to use vo=x11. That works well enough.
[10:20] <ian_brasil> i tried to enable it on an ATI Technologies Inc Radeon R250 and it made hals the screen go wavy and the fonts to distort
[10:20] <Mithrandir> mvo: no, but metacity doesn't either, so I use openbox.  I understood it to be a design goal more than anything else, really.
[10:20] <mdz_> soren: eek! that's unaccelerated
[10:20] <mvo> Amaranth: what is your feeling about bugreport for glx artifacts and video issues?
[10:21] <mvo> Mithrandir: aha, ok :)
[10:21] <Amaranth> For compiz there are a bunch of little things (like most everything else) and a couple of 'big' issues. The xorg patch that breaks nvidia and intel/ati GL, and intel blitter not working with composite unless EXA is enabled
[10:21] <soren> mdz_: Indeed. It's better than nothing and the machine is beefy enough to handle it.
[10:21] <Amaranth> One of those we can fix, the other two need extensive driver work
[10:21] <mdz_> Amaranth: which are the two?
[10:21] <Amaranth> mvo: It's probably the most duped bug
[10:22] <Amaranth> mdz_: The intel video and intel/ati gl
[10:22] <mdz_> I'm finding it confusing to keep the different issues straight, honestly
[10:22] <beuno> Compiz in gutsy works great out of the box in my intel 945
[10:22] <Mithrandir> Amaranth: removing the xorg patch is contentious, since it's used by not only hildon, but also for inter-widget compositing in GTK.
[10:23] <Amaranth> Mithrandir: Then we need the xserver 1.4 and nvidia's upcoming driver release to fix this
[10:23] <Amaranth> Way too late for that
[10:23] <Amaranth> Or we could just use Xgl ;)
[10:23] <mdz_> I honestly don't think that the GL problems are a very big deal; 3D apps on Ubuntu are a tiny corner case
[10:23] <mvo> bug #130325 is about the compiz/nvidia/glx issue
[10:23] <ubotu> Launchpad bug 130325 in linux-restricted-modules-2.6.22 "[nvidia-glx]  3D GL apps crash X when using compiz due to unmaked ABI change (gutsy)" [High,In progress]  https://launchpad.net/bugs/130325
[10:23] <mdz_> I'm quite sensitive to video breakage, though
[10:24] <mdz_> I feel a bit uncertain about the general performance overhead compiz seems to introduce
[10:24] <mdz_> the network-manager passphrase dialog consistently displays behind my windows, but I think metacity did that as well
[10:25] <Amaranth> bug 111257
[10:25] <ubotu> Launchpad bug 111257 in xserver-xorg-video-intel "totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver" [High,Confirmed]  https://launchpad.net/bugs/111257
[10:25] <mdz_> I have no problems whatsoever with video though
[10:26] <mvo> both power and performance seems to be not that much of a issue from my experience. we patched the drivers to use xf86XVFillKeyHelperDrawable() so that basic video playback works
[10:26] <mdz_> my workspace keyboard shortcuts still don't work by default, but they do with rotate cube
[10:26] <mvo> even older machines can deal with the moderate requirements of our default settings
[10:27] <Amaranth> mdz_: we have a plugin for that, should have been enabled
[10:27] <mdz_> I see compiz using a substantial amount of CPU
[10:27] <mvo> mdz_: sorry for that, I will be in london next week, I would love to debug it there
[10:27] <mvo> (the keyboard shortcuts problem)
[10:27] <mdz_> mvo: I won't be here, but will try to reproduce it in a VM or something before I go
[10:27] <Amaranth> compiz won't work in a VM
[10:28] <Amaranth> When do you see it using a lot of CPU?
[10:28] <Amaranth> The only issue I've heard of is flash
[10:28] <Amaranth> And that chews CPU whether I use compiz or not
[10:29] <mdz_> it seems to use a steady 1% or so of my desktop and laptop CPUs just displaying top in a terminal
[10:29] <mdz_> its accumulated CPU time is almost as high as firefox's
[10:29] <mvo> mdz_: ok, good to know. I will put it up in my priorities than, I was kind of hoping that I could have a look directly at the machine
[10:29] <Mithrandir> Amaranth: flash is horrible due to its design.
[10:30] <Mithrandir> (it has an event timer that ticks)
[10:30] <mdz_> mvo: if necessary, I'll create a login for you on my desktop before I go
[10:30] <mdz_> mvo: can you really not reproduce this?  I just have my workspace shortcuts set to alt+1, alt+2, etc. and they aren't recognized in the default config
[10:30] <mdz_> but anyway, we're straying from the matter at hand
[10:30] <mdz_> mvo,Amaranth: you two are closest to the action here
[10:31] <mdz_> mvo,Amaranth: do you think this is good enough to be our default?
[10:31] <Amaranth> I think so, yes
[10:31] <mvo> within the limitations outlined in my mail to ubuntu-devel yes
[10:32] <Amaranth> It still has some rough spots but if we don't get it out there at some point it'll never get good enough
[10:32] <mjg59> Amaranth: The rough spots are issues that are not directly related to compiz
[10:32] <Amaranth> mjg59: I meant aside from those
[10:32] <mjg59> Shipping compiz won't make those problems get fixed faster
[10:32] <mdz_> the (precious few) reviews I've seen of Gutsy alphas have not mentioned compiz at all
[10:33] <mdz_> I suspect it simply wasn't enabled by default on their hardware
[10:33] <Amaranth> mjg59: The little things all over the place people have troubles with
[10:33] <Amaranth> mjg59: We'll never find all of them if we don't get more users
[10:33] <mvo> it is difficult to say how many people run google earth
[10:33] <mvo> in windowed mode
[10:34] <mvo> it comes down to: are we willing to accept the limitations and get the bling or keep it as it is without the bling
[10:35] <Amaranth> beuno: yay random button that users don't understand
[10:35] <Keybuk> mvo: google earth doesn't even work properly for me in full screen mode
[10:35] <mvo> as a middle-ground (assuming nvidia/xorg gets fixed) we could only enable it on nvidia as it everything should work there (including glx apps)
[10:36] <mdz_> mvo: let's be clear; we only get the bling by default for a minority of users anyway
[10:36] <mdz_> mvo: most users will need to explicitly turn it on or they won't see anything
[10:36] <Amaranth> nvidia, ati, and intel users who do a fresh install of gutsy
[10:36] <beuno> Amaranth, "Desktop Effects"?  Have it on by default if you wish, make it trivial to disable it before installing
[10:36] <mvo> I'm not sure about this, intel is quite common and older ati are not that uncommon either
[10:36] <mdz_> Amaranth: my understanding is "intel and some ATI"
[10:37] <Amaranth> mdz_: right, Radeon X800 and older plus X1050
[10:37] <mvo> and nvidia once people use restricted manager to install the driver
[10:37] <mvo> that is currently enough to enable it
[10:38] <mdz_> folks who enable the driver explicitly can easily enough turn it off if they aren't happy with the results
[10:39] <mdz_> (as with effects in general)
[10:39] <mvo> right
[10:40] <mdz_> mvo: if you can make a list of PCI IDs, yes
[10:40] <bryce_> I just had dinner with AMD tonight, and they were very interested in hearing what ATI issues with compiz exist currently
[10:41] <Amaranth> Other than fglrx+Xgl being the worst possible environment? :)
[10:41] <mdz_> I don't think there's too much more to be said about this, we're starting to go in circles
[10:42] <mdz_> mjg59,Keybuk: shall we take a vote?
[10:42] <mvo> bryce_: details like missing texture_from_pixmap ;)
[10:42] <Amaranth> Yeah, I think we've gone over it all
[10:42] <mjg59> mdz_: On what basis are we making the decision?
[10:42] <mdz_> mjg59: guts and glory
[10:42] <mjg59> Ha.
[10:42] <mdz_> go with your heart
[10:42] <mjg59> Ok. I go for not by default.
[10:43] <mdz_> sabdfl votes on by default
[10:43] <mdz_> (by proxy)
[10:43] <Keybuk> on (no guts, no glory)
[10:44] <mdz_> I vote on by default, largely due to the opinions of the engineers working on it, with a dash of "the only way out is through"
[10:44] <mjg59> Ok, we stick with what we have
[10:44] <mdz_> I hope it's for the best, this was a very difficult one
[10:45] <mdz_> and I'm not certain by any means, but we need to move ahead
[10:45] <mdz_> I'm perfectly happy to revisit this again if necessary
[10:45] <mdz_> e.g., if feedback from beta is dire
[10:45] <mjg59> Ok. Next up is automatix?
[10:46] <mdz_> mjg59: I want to thank you for speaking up for quality on this issue; I agree with most everything you've said on this issue and might have taken the same position myself
[10:46] <mdz_> right, automatix
[10:47] <mjg59> Has everyone read the writeup?
[10:47] <mdz_> I have
[10:47] <mdz_> I meant to go back and classify the issues by severity
[10:47] <mdz_> they range from "nitpick" through "killall -9 dpkg" with lots of in between
[10:48] <mjg59> I don't think there's really too much to say on this - there's a clear desire from the community for this functionality, and automatix fills it nicely. On the other hand, it's pretty obvious that it has the potential to screw up a user's system in ways that are basically impossible to detect
[10:48] <mdz_> I think it's clear that there are some problems which make its use questionable
[10:48] <mdz_> the question is what to do about it
[10:48] <Keybuk> what can we do about it?
[10:48] <mjg59> I believe update-manager will refuse to perform between-distro upgrades if automatix is installed?
[10:49] <mdz_> Keybuk: anything from "try to prevent its use" through "try to cooperate with them to produce a better result"
[10:49] <mvo> mjg59: currently it does not, but its a planed feature
[10:49] <Mithrandir> I think it's important to prevent this turning into some kind of an arms race.
[10:50] <Mithrandir> so when we do the "refuse to upgrade" thing, we need to tell why we are doing it: it's not to punish anybody, but because we realistically don't believe we can successfully upgrade the system.
[10:50] <mdz_> FWIW, I did invite the developer to the Gutsy UDS hoping to talk through this
[10:50] <mvo>  but I would certainly prefer to detect and undo any damage than to let users out in the cold (especially since I expect that there will be some "cleanup" tool that will just rmove the traces)
[10:50] <Keybuk> mdz_: trying to prevent use is a bit like asking them to put a sticker on the packet saying "use of this programme causes baby jesus to cry"
[10:51] <Keybuk> mdz_: he declined, didn't he?
[10:51] <mjg59> Working with our packaging system rather than outside it is pretty clearly a win
[10:51] <mjg59> Providing a boilerplate package that can download, install and track the contents of a tarball would possibly help here
[10:51] <mdz_> Keybuk: as I recall, he said he couldn't make it
[10:52] <mdz_> mjg59: isn't that approximately alien?
[10:52] <smurf> mjg59: One would think so, but your look at the thing suggests that at least one person thinks otherwise :-/
[10:52] <mjg59> mdz_: Yeah, but for software that can't be distributed
[10:52] <mjg59> Getting users to download a tarball and then run alien on it is harder
[10:54] <mdz_> mjg59: have you received any response from the automatix developer?
[10:54] <mjg59> No
[10:54] <mdz_> do you think it would be worthwhile to explicitly contact them and start a dialog?
[10:54] <mjg59> They've implied that they're working on a response, but also that they're very busy at the moment
[10:54] <mjg59> So yes, that might be worthwhile
[10:56] <mdz_> mjg59: I'm happy to ask that someone from the canonical community team speak to them if you'd prefer not to do it
[10:56] <mjg59> That also works
[10:57] <mdz_> ok, that's good enough for me
[10:57] <mdz_> sladen: tracker?
[10:58] <mdz_> I emailed Sebastien asking for his opinion prior to the meeting, but haven't heard back yet
[10:58] <mdz_> I think his is a key opinion to get
[10:58] <mjg59> If sladen's not here, I can cover the basic state as far as I can tell
[10:58] <mjg59> But yeah, I think we want feedback from seb
[10:58] <mdz_> I did find that the initial indexing made mutt basically unusable
[10:59] <mjg59> The move to purely sqlite should help that
[10:59] <Amaranth> Tracker is confusing, it worked great on feisty (aside from slowing down compiles)
[10:59] <Keybuk> I still find that tracker kills my machine
[10:59] <mdz_> anytime vi would sync anything, it would block for ages (>10 seconds)
[10:59] <mdz_> I also find that deskbar doesn't seem to search tracker
[10:59] <mjg59> But it's still lacking functionality like "Don't do mad stuff while on battery"
[11:00] <Amaranth> The blocking and such seems to be a kernel problem
[11:00] <mvo> I killed it when my ~/.cache/tracker went up to ~200mb or something
[11:00] <mdz_> given there's no entry in the menu for it, I'm not sure how folks are expected to search it?
[11:00] <mdz_> 874M    .cache/tracker
[11:00] <mvo> it seems to ignore that the space gets low and just keeps indexing
[11:00] <Amaranth> It's really fun downloading a map in a video game and having the extracting make the ipw3945 stall
[11:00] <mjg59> Disk use is hardly unexpected
[11:01] <mjg59> But it could pretty clearly be more intelligent about a lot of things
[11:01] <Amaranth> But tracker is the most obvious symptom
[11:01] <mjg59> Like not trying to index build directories in real time
[11:01] <mjg59> Amaranth: We're still lacking any real investigation that demonstrates that problem
[11:01] <mvo> mdz_: I think people search using the deskbar applet
[11:01] <Keybuk> what uses tracker?
[11:01] <mdz_> mvo: that doesn't work at all for me
[11:01] <mjg59> We need a simple testcase that performs well on feisty and poorly on gutsy
[11:01] <Amaranth> nautilus and deskbar
[11:02] <Amaranth> mjg59: simple is the hard part :)
[11:02] <Amaranth> mjg59: For me it's "sometimes downloading a map in $GAME breaks the whole system"
[11:02] <mdz_> on my laptop, deskbar crashes when I type into it
[11:02] <mjg59> Amaranth: The i/o patterns that tracker carries out aren't that complicated
[11:02] <mdz_> on my desktop, it offers me lots of web search options but doesn't search my files
[11:03] <Amaranth> mdz_: Could it be an upgrade issue?
[11:03] <mdz_> Amaranth: it certainly could be, why?
[11:03] <Amaranth> I mean, you have to turn the plugin on so unless the upgrade is overwriting your settings for what plugins to use you won't get tracker
[11:03] <ajmitch> mjg59: no, but it will take a very long time to index when you have a few million files
[11:03] <pochu> mdz_: there's a menu entry: Apps>Accesories>Tracker Search Tool. The other question is whether people is supposed to look there ;)
[11:03] <mjg59> ajmitch: That's not the point
[11:03] <mjg59> The argument is that something has changed in the kernel, and that this is why tracker is slower than in feisty
[11:04] <mjg59> But we don't have a benchmark to determine the veracity of that
[11:04] <mjg59> My measurements of tracker showed that it was entirely seek-bound
[11:04] <mdz_> pochu: aha, I certainly didn't look there
[11:04] <mjg59> That is, it was managing 20k/sec to disk because it was performing 80 seeks a second, which is the most my drive can maange
[11:04] <pochu> Neither did I, but I saw it in a bug report :)
[11:05] <Keybuk> the tracker problem seems to be to be closely related to the compiz problem
[11:05] <Keybuk> how much blood-loss do we accept while on the bleeding edge
[11:06] <Keybuk> do we want Ubuntu to be the latest and greatest technology
[11:06] <Keybuk> or are we starting to need to stand back from the new stuff, and instead worry about how much is wrong with it?
[11:06] <mdz_> tracker's effects affect many more users, and more drastically, I'd say
[11:06] <mjg59> Upstream has been receptive to our complaints, but it's not clear how fast they're being fixed
[11:07] <mdz_> it has a gconf key to turn it on/off, so it's trivial to change our mind
[11:08] <Keybuk> a fundamental issue is what level of maturity do we require for Ubuntu features?
[11:08] <mdz_> has anyone asked upstream whether they think they'll get there in the next few weeks?
[11:08] <mdz_> seb is in the best position to know, I expect
[11:09] <Amaranth> jamiemcc seems to be away
[11:09] <mdz_> Keybuk: more than "sabdfl", less than "consumer"
[11:10] <pochu> He said he was going to try to release 0.6.3 for tribe-6, so I'd expect it soon.
[11:10] <Keybuk> I'm also reminded of mjg59's earlier comments to the effect that if people don't use something, they won't fix it
[11:10] <Keybuk> which suggests if we ship tracker, it's more likely to get fixed anyway
[11:10] <Amaranth> Keybuk: That was me :)
[11:11] <mdz_> Keybuk: all indications are that our user base is somewhat more aggressive than conservative
[11:11] <Keybuk> Amaranth: err, were you being angry about it?  that might have confused me <g>
[11:11] <Amaranth> Keybuk: he was
[11:11] <mdz_> though we are peeking around the corner to less experienced users
[11:11] <Amaranth> mdz_: Been there for quite some time, you should hang out in #ubuntu for awhile :)
[11:12] <Amaranth> Although I suppose by the nature of the thing if they found #ubuntu they're 'aggressive'
[11:12] <mdz_> Amaranth: I think we mean different things by "experienced"
[11:12] <mdz_> someone who uses an IRC client, to me, is not a novice
[11:12] <Amaranth> I think gaim defaults to opening #ubuntu
[11:13] <Amaranth> Haven't seen unconfigured gaim in awhile
[11:13] <Keybuk> Amaranth: only if they create an IRC account in it?
[11:13] <Seveas> don't people who use mirc on windows count?
[11:14] <Seveas> there are quite a few of those, and they're very novice to linux
[11:14] <mdz_> Seveas: to linux, yes
[11:14] <Seveas> or chatzilla, following a link on the website
[11:14] <Amaranth> I think mdz means Dell users
[11:14] <mdz_> installing an operating system is not something that the average user attempts
[11:14] <Seveas> complete computer illiterates sometimes find #ubuntu :)
[11:15] <mdz_> it requires a certain adventurousness^Wreckless abandon
[11:15] <Keybuk> talking of wreckless abandon, perhaps there is a time for that, and a different time for careful footsteps
[11:16] <Keybuk> the latter being "LTS"
[11:16] <pochu> welcome jamiemcc :)
[11:16] <mdz_> jamiemcc: oh, hello. thanks for dropping by
[11:16] <jamiemcc> hi pochu
[11:16] <Amaranth> ah, there he is
[11:16] <mdz_> jamiemcc: we're interested in your opinion about tracker being on by default in Ubuntu 7.10
[11:17] <jamiemcc> mdz_: would like it in
[11:17] <Amaranth> of course :)
[11:17] <mdz_> jamiemcc: particularly in whether you think users will have a good experience
[11:17] <jamiemcc> depends if https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/135115
[11:17] <ubotu> Launchpad bug 135115 in tracker "tracker causing very high disk useage/thrashing (dup-of: 131094)" [High,Confirmed] 
[11:17] <ubotu> Launchpad bug 131094 in linux-source-2.6.22 "Heavy Disk I/O harms desktop responsiveness" [Undecided,Confirmed] 
[11:17] <jamiemcc> can it be fixed?
[11:17] <jamiemcc> a clean install fixes it
[11:17] <jamiemcc> upgrades do not
[11:17] <Amaranth> does it?
[11:18] <jamiemcc> for me and others
[11:18] <Amaranth> interesting
[11:18] <mdz_> jamiemcc: a clean install? that's odd
[11:18] <Amaranth> have you talked to the kernel team?
[11:18] <jamiemcc> amaranth no
[11:18] <jamiemcc> I am downloading tribe 3 to do a diff with tribe 5
[11:18] <jamiemcc> and trying to figure out what config setting is causing it
[11:19] <mdz_> jamiemcc: what about laptops indexing on battery life?  is that on the short term todo list?
[11:19] <mdz_> s/ life//
[11:19] <jamiemcc> yes we are aiming for next week
[11:19] <jamiemcc> https://bugs.launchpad.net/bugs/131094
[11:19] <ubotu> Launchpad bug 131094 in linux-source-2.6.22 "Heavy Disk I/O harms desktop responsiveness" [Undecided,Confirmed] 
[11:19] <jamiemcc> that is the bug that needs fixing
[11:20] <mdz_> jamiemcc: I will escalate 131094 with the kernel team
[11:20] <jamiemcc> ok thanks
[11:20] <Amaranth> if that is fixed laptops should not be a problem
[11:20] <Amaranth> not much of one anyway
[11:20] <jamiemcc> well we will still do battery pause
[11:20] <jamiemcc> we also have a monitor applet that needs polishing up
[11:20] <mjg59> jamiemcc: As I noted before, the poor performance I was seeing was entirely due to the fact that it was seeking heavily in the berkeley db file
[11:21] <mdz_> jamiemcc: do you happen to have a guess why the deskbar handler doesn't work for me?
[11:21] <jamiemcc> mjg59: we now use sqlite
[11:21] <mjg59> Which looked like a code issue, not a kernel issue
[11:21] <mjg59> jamiemcc: Right. I need to blow away my cache and force a full reindex with the current code
[11:21] <Amaranth> sqlite has been used since 0.6, no?
[11:21] <jamiemcc> for index we used qdbm previously
[11:21] <Amaranth> oh
[11:22] <mdz_> mjg59: how did you collect seek statistics?
[11:23] <mdz_> jamiemcc: I also have an issue where I have a large number of files which have been deleted out of my home directory (e.g., source trees) but still turn up in search results (spewing errors to stderr and creating empty list items)
[11:23] <jamiemcc> mdz_: thats a known issue
[11:23] <jamiemcc> which will be fixed shortly
[11:23] <Amaranth> this is the inotify limit, isn't it?
[11:23] <jamiemcc> by beta we should have most if not all of these issues resolved
[11:23] <mdz_> jamiemcc: ok, doesn't sound major, that's good enough fo rme
[11:24] <mdz_> any other questions around tracker?
[11:25] <Keybuk> nope
[11:25] <mjg59> mdz_: strace
[11:26] <Amaranth> so, wait to see where we are for beta?
[11:26] <mdz_> sounds like we are on track (snicker)
[11:27] <mdz_> any other business for the meeting?
[11:27] <mdz_> thanks everyone for staying around
[11:27] <mdz_> good night
[11:28] <Keybuk> nite