20080326

Agenda

Items we will be discussing:

Minutes

iscsi support

soren should have a working installer by then end of this week. faulkes- may have access to an iscsi device by then.

status action init script

mathiaz reminded that this work has been declined for hardy and is targeted for Intrepid. The solution would then be based on upstart. All of this should be discussed during a session at UDS.

owh added that some patches have already been prepared for the current init scripts. mathiaz suggested to add them to bugs in LP and forward them to Debian.

ACTION: owh to attach existing patches to bugs in LP and forward them to Debian.

Server Survey and Brainstorm

mathiaz asked whether the questions of the Server survey could be also put on Brainstorm. nijaba didn't see how this was possible. The questions in the survey are more about what the users are running in which environment rather than what users would like to see implemented.

Integration of dovecot and postfix via sasl

ivoks came up with a new solution to address this issue: create a new binary package from the dovecot source, dovecot-postfix-sasl, which postinst script would modify dovecot.conf to enable the sasl daemon. He also wanted to make sure that this was policy compliant. soren said that postinst scripts from a same source package can modify configuration files of other binary packages build from the same source.

mathiaz added that a FFexception should be asked to the release team and warned that it may be declined for hardy. ivoks said he will prepare a debdiff with the new solution and ask for a FFe. Even if the bug is rejected for hardy, it would be ready for integration when Intrepid opens.

ACTION: ivoks to attach a new debdiff to the LP bug and ask the release team about a FFe

Documentation and the server guide

sommer fixed a bunch of spelling mistakes reported by translators. mathiaz suggested to focus on the wiki pages on help.ubuntu.com/. The samba pages, especially dealing with AD integration, could be updated with regard to the arrival of likewise-open in hardy.

ACTION: sommer to start working on the wiki page related to samba and update the roadmap list.

Virtualization

keescook uploaded virt-clone that actually works.

keescook and jdstrand are now using kvm in hardy to do all the testing related to security updates, both for server and desktop. mathiaz wondered if this could be highlighted as a story/use case for virtualization in Hardy.

High-priority bugs list

kirkland suggested to do a short review of high-priority bugs related to the server team during the server meeting, so that members which bugs require most of the attention.

ACTION: mathiaz to update the meeting agenda to make sure we review high-profile bugs until release ACTION: mathiaz to compile a list of high priority bugs for the server team

Agree on next meeting date and time

nijaba said that Europe will switch to DST next week and wondered if the meeting could be moved one hour earlier. However that would be really early for Australia.

So the meeting will stay at 21:00 UTC.

Next meeting will be on Wednesday, April 2nd at 21:00 UTC in #ubuntu-meeting.

Log

Started logging meeting in #ubuntu-meeting
[22:02:23] <mathiaz> Today's agenda is located on this wiki page: https://wiki.ubuntu.com/ServerTeam/Meeting
[22:02:56] <mathiaz> If anyone would like to add point to be discussed, please update the wiki page
[22:03:21] <mathiaz> and I'll make sure your brilliant idea will be discussed during this meeting
[22:03:35] <mathiaz> [TOPIC] Review ACTION points from previous meeting.
[22:03:46] <soren> Uh, oh.
[22:03:51] <owh> :)
[22:03:53] <mathiaz> The previous meeting minutes: https://wiki.ubuntu.com/MeetingLogs/Server/20080319
[22:04:23] <mathiaz> [TOPIC] iscsi support
[22:04:41] <soren> Right..
[22:05:13] * michalski waves but must leave for cadets in 5 mins
[22:05:14] <soren> Erm... I forget if we covered this part of it, but slangasek said it'd be fine to do it even now that we're past beta.
[22:05:23] <soren> So we're doing it.
[22:05:28] <mathiaz> soren: yeah - we said that
[22:05:35] <soren> Ok.
[22:05:44] <mathiaz> faulkes-: did you manage to get access to your iSCSI hardware ?
[22:05:47] <soren> Ah, right last wednesday.
[22:06:09] <soren> WEll, I've been on holiday Thursday->Monday, so not a lot has happened since then.
[22:06:42] <soren> I'm still trying to wrap my head around what needs to be done to the installer, to make the resulting system figure out that it needs to mount stuff over the network.
[22:06:59] <mathiaz> soren: when do you think you'll get something ready for testing ?
[22:07:00] <soren> I'm probably going to ask someone with more experience in this area for pointers tomorrow or something.
[22:07:14] <soren> If we're lucky, by the end of this week.
[22:07:28] <mathiaz> soren: have you discussed with slangasek about a deadline to get it included ?
[22:07:35] <soren> Nope.
[22:07:44] <mathiaz> soren: I don't think we want to ship this just before RC
[22:07:59] <soren> I forget when that is.
[22:08:13] <mathiaz> soren: in two weeks and 1 day from now
[22:08:28] <soren> Ok. That should be plenty of time.
[22:08:31] <mathiaz> soren: RC is three weeks after beta, which was released last thursday
[22:08:49] <soren> Got it.
[22:10:00] <mathiaz> [TOPIC] status action for init script
[22:10:12] <mathiaz> kirkland: I think you've updated the Roadmap
[22:10:19] * michalski must go but will leave irc client on and review meeting afterwards
[22:10:31] <kirkland> mathiaz: yep. in brief, we've abandoned this item for Hardy
[22:10:32] <michalski> sorry mathiaz, dst
[22:10:36] <mathiaz> this whole point was deferred for after Intrepid
[22:10:44] <mathiaz> michalski: np
[22:10:53] <mathiaz> hum - for Intrepid sorry
[22:10:54] <kirkland> mathiaz: will work on in Intrepid, with Keybuk and upstart, possibly a blueprint for UDS Prague
[22:11:21] <kirkland> mathiaz: goal remains noble and important! :-)
[22:11:47] <owh> Is there any point in making the patches available for those admins wanting the functionality?
[22:11:49] <mathiaz> kirkland: great - we'll discuss that during UDS then
[22:11:57] <mathiaz> owh: I don't think so
[22:12:06] <mathiaz> owh: it's not worth taking the time to do it IMO
[22:12:20] <owh> mathiaz: They have already been written.
[22:12:33] <kirkland> owh: leave them attached to bugs in launchpad
[22:12:42] <kirkland> owh: if someone is so motivated, they should be able to find them there
[22:12:50] <mathiaz> kirkland: right - that's enough I think
[22:12:51] <kirkland> owh: and we may well revisit them come Intrepid
[22:12:53] <owh> kirkland: Should we add them all to the same lsb bug?
[22:13:16] <kirkland> owh: that, or link that one to the other bugs that contain such patches
[22:13:17] <mathiaz> kirkland: probably not - upstart doesn't use the system-v init script at all
[22:13:32] <kirkland> mathiaz: will the upstart conversion be COMPLETED in Intrepid?
[22:13:40] <owh> kirkland: Cool, we'll talk later.
[22:13:48] <kirkland> owh: fair 'nuff
[22:13:55] <mathiaz> owh: one thing you should do is send them to debian
[22:14:00] <owh> I'll action that for me for next week's meeting.
[22:14:04] <soren> kirkland: We need to to them all at once.
[22:14:06] <owh> mathiaz: And that too.
[22:14:15] <mathiaz> owh: if they're accepted there, we'll get them automatically during Intreprid
[22:14:26] <soren> kirkland: Well, that's not strictly true..
[22:14:28] <owh> mathiaz: Yup.
[22:14:31] <kirkland> mathiaz: good idea.
[22:14:43] <mathiaz> soren: all at once ?
[22:14:54] <mathiaz> soren: I thought it can be done a per package basis
[22:14:58] <soren> We need to start at one end and work our way to the other.
[22:15:16] <soren> We can't usefully just pick one init script, convert it, pick the next, convert it..
[22:15:17] <owh> mathiaz: Technically there is an lsb patch needed before the init script patches will work.
[22:15:30] <soren> We need to start at S01foo and work our way to S99 or the other way around.
[22:15:51] <kirkland> soren: we were thinking doing it massively in parallel, in that it's very small, compact work that a lot of minimally experienced developers can hack out
[22:15:55] <mathiaz> soren: hum - I see your point. Anyway that will be discussed during UDS
[22:16:01] <soren> Because from upstart's point of view, starting *all* of rc2.d/S* is just one event.
[22:16:06] <owh> soren: kirkland and I targetted those that are installed in hardy.
[22:16:17] <soren> So if we pick stuff out from the middle, we can't ensure the ordering.
[22:16:34] <mathiaz> [ACTION] owh to attach existing patches to bugs in LP and forward them to Debian
[22:16:44] <soren> kirkland: Cool.
[22:16:46] <owh> Yup
[22:17:05] <mathiaz> Great - let's move on.
[22:17:11] <soren> kirkland: It's just not very obvious, so I wanted to point it out just to be sure.
[22:17:25] <mathiaz> [TOPIC] Server Survey and Brainstorm
[22:17:52] <nijaba> not much new on that subject
[22:17:59] <mathiaz> So I was wondering how these two things were integrating together
[22:17:59] <nijaba> faulkes fixed the last 2 bugs
[22:18:14] <nijaba> and I packaged limesurvey
[22:18:27] <mathiaz> could the survey leverage the brainstorm site ?
[22:18:30] <nijaba> what do you mean integrating the 2
[22:18:43] <nijaba> how?
[22:18:49] <mathiaz> or some of the question of the survey be also presented on brainstorm ?
[22:18:55] <keescook> apologies: I continue not to have time to audit limesurvey -- it is at the top of my audit TODO list now, though.
[22:19:25] <nijaba> I don't really see how we could link the 2...
[22:19:27] <zul> keescook: I did a quick lookthrough for nijaba I didnt go to deep though
[22:19:58] <kirkland> mathiaz: I'm not seeing this either... you'd want to publish nijaba's survey questions as suggestions to brainstorm?
[22:20:00] <nijaba> zul: keescook is talking abut a secuorty audit
[22:20:03] <mathiaz> nijaba: I don't know how the survey is structured - can some questions be also posted to brainstorm ?
[22:20:09] <zul> nijaba: ah
[22:20:15] <mathiaz> kirkland: yes
[22:20:29] <mathiaz> I didn't mean link in a technical sense - more on the content
[22:20:35] <kirkland> mathiaz: the survey is more like "how do you use your linux server? what kind are they?" etc...
[22:20:46] <nijaba> mathiaz: really, brainstorm is totally different
[22:21:14] <kirkland> mathiaz: brainstorm is more like "i want a perpetual motion machine, can you please make ubuntu do one for me?"
[22:21:17] <nijaba> we don't ask and vote for ideas in the survey
[22:21:51] <mathiaz> nijaba: ok - so don't ask question such as "would you like to see better virtualization?" and so on
[22:21:54] <soren> Ooh! Oh! And a pony!
[22:22:13] <nijaba> mathiaz: no we don't
[22:22:24] <mathiaz> nijaba: it's more about what do you do with ubuntu server ? what is your environment... and so on.
[22:22:34] <owh> soren: No, the best one was: "I want Ubuntu to boot on an Apple TV without hacking."
[22:22:36] <nijaba> mathiaz: correct
[22:22:49] <mathiaz> nijaba: ok - thanks for the clarification.
[22:23:07] <mathiaz> I got a question from jono about that.
[22:23:14] <soren> owh: Fantastic.
[22:23:26] <nijaba> so invite jono to take a test drive of the survey
[22:24:13] <mathiaz> [TOPIC] integration of dovecot/postfix sasl
[22:24:24] <mathiaz> ivoks: so what's going on there ?
[22:24:39] <ivoks> mathiaz: i suggest creating new binary inside of dovecot source package
[22:24:57] <ivoks> which would depend on postfix and dovecot-common
[22:25:14] <ivoks> problematic part is; how to handle dovecot's configuration
[22:25:40] <mathiaz> ivoks: IIRC this was to get around the policy that a package cannot modify another package configuration files
[22:25:41] <ivoks> option one is to patch it so it doesn't fail when starting, if there's no postfix installed
[22:26:06] <ivoks> option two is to patch dovecot.conf with that new binary
[22:26:16] <ivoks> i'm not sure option two is leagal
[22:26:36] <soren> Why not?
[22:26:39] <owh> ivoks: What about shipping two configurations and launching with the appropriate one?
[22:27:23] <ivoks> owh: i was investigating if it is possible to include part of the configuration, but that is not possible
[22:27:26] <mathiaz> soren: well - you can't modify from postinst script the conffile of another package
[22:27:39] <owh> ivoks: I mean the init.d script can figure out how to start the application appropriately.
[22:27:41] <ivoks> mathiaz: well, we already do that in dovecot
[22:27:54] <soren> mathiaz: Another binary package? Sure you can.
[22:27:55] <ivoks> owh: but, what if user edits dovecot.conf?
[22:28:05] <soren> mathiaz: As long as:
[22:28:06] <mathiaz> ivoks: yes - that's write - we do that with -popd and -imap
[22:28:16] <soren> a) it's from the same source package
[22:28:17] <soren> or
[22:28:32] <soren> b) the owner package provides a tool to fiddle with it.
[22:28:41] * faulkes- gets coffee
[22:28:47] <ivoks> soren: can you give me a solid reference for a)? :)
[22:28:53] <mathiaz> soren: in our case if would a)
[22:28:59] <mathiaz> ivoks: dovecot does that
[22:28:59] <owh> ivoks: You can combine the parts into a running config file and launch with that.
[22:29:01] <soren> The purpose of that particular part of the policy is to make sure that anything that happens to conffile foo is under control.
[22:29:30] <soren> Sorry.
[22:29:34] <soren> Not conffile.
[22:29:36] <soren> config file.
[22:29:44] <ivoks> right, dovecot.conf isn't a conffile
[22:29:55] <mathiaz> dovecot.conf is handled via ucf
[22:29:58] <ivoks> right
[22:30:01] <soren> Right.
[22:30:22] <soren> If you're not using conffiles, it's your responsibility to make sure upgrades are handled sanely etc., etc.
[22:30:33] <ivoks> owh: not very easy...
[22:30:35] <soren> That's impossible if you're not controlling the changes to it.
[22:30:51] <mathiaz> ivoks: I think your proposal to create a new package dovecot-postfix-sasl binary package makes sense
[22:31:04] <mathiaz> ivoks: we're already doing similar things in -pop and -imap
[22:31:06] <soren> You can do that by providing a tool to do it (think postconf) or if it's all done by packages from the same source package.
[22:31:12] <ivoks> mathiaz: right, trough postinst
[22:31:39] <mathiaz> ivoks: you can probably base your patch on the code from -pop or -imap
[22:31:46] <ivoks> so, everybody in favour of modifying dovecot.conf trough new-binary's postinst?
[22:31:49] <mathiaz> ivoks: it's a perl command IIRC
[22:32:12] <owh> I'm not convinced its too complicated this late in the game.
[22:32:13] <ivoks> mathiaz: well, you have only one 'protocols' in dovecot.conf, but lots of 'server' and 'client'
[22:32:15] * soren dreams of dovecot providing a tool to do this sort of thing
[22:32:18] <mathiaz> ivoks: WFM - we're already doing it in the -pop and -imap packages
[22:32:48] <mathiaz> owh: good point - that was another issue I was about to raise
[22:32:56] <mathiaz> I'm not sure we'll get a FFe for that
[22:33:07] * owh got slapped down with a simple init script patch :)
[22:33:16] <mathiaz> It may be too late in the release cycle for that.
[22:33:26] <ivoks> mathiaz: imho, that's caused by bad FF process
[22:33:45] <owh> ivoks: What happens if you do nothing?
[22:33:46] <ivoks> mathiaz: we had patch for tasksel, and it was rejected in the last minute
[22:33:57] <ivoks> while, it was available for months
[22:34:01] <owh> ivoks: That is, if you make no changes, what breaks?
[22:34:02] <mathiaz> ivoks: right.
[22:34:08] <mathiaz> owh: nothing
[22:34:17] <mathiaz> owh: it's just a new feature
[22:34:24] <owh> What about adding a paragraph to the README?
[22:34:37] <mathiaz> owh: so the question is whether it will be tested enough
[22:34:39] <owh> Non-invasive, simple, etc.
[22:34:42] <ivoks> owh: we want to provide out of the box super mail server
[22:35:20] <mathiaz> ivoks: I think we should talk to the release team anyway
[22:35:22] <owh> mathiaz: So, make the README point to a wiki page.
[22:35:27] <ivoks> mathiaz: i agree
[22:35:36] <owh> s/README/README paragraph/
[22:35:55] <mathiaz> ivoks: so either you can detail your new proposal in the bug and ask the release team about it
[22:36:20] <mathiaz> ivoks: or provide a debdiff and attach it to the LP bug and talk to the release team
[22:36:31] <ivoks> mathiaz: i'll provide debdiff
[22:36:34] <owh> In terms of config file changes, how much effort is involved for a system administrator to make this work?
[22:36:43] <mathiaz> ivoks: in the event of refusal, we'd have a debdiff ready for intrepid
[22:37:03] <mathiaz> owh: well - the procedure is straightforward
[22:37:14] <mathiaz> owh: this is why we want to provide a package to do it ;)
[22:37:23] <ivoks> right
[22:37:28] <owh> I would be in favour of documenting it, providing a sample config perhaps and moving on.
[22:37:41] <sommer> owh: it's documented
[22:37:48] <mathiaz> owh: ^^ - yes
[22:37:51] <ivoks> owh: feature is documented and well known
[22:37:59] <mathiaz> owh: this step is automate it
[22:38:07] <ivoks> owh: it's stupid not to provide it by default, when everybody does it manually afterwards :)
[22:38:22] <owh> I understand that, but its a new feature.
[22:38:28] <owh> What ever you call it :)
[22:38:32] <ivoks> s/everybody/everybody that's aware of it/
[22:38:56] <mathiaz> [ACTION] ivoks to attach a new debdiff to the LP bug and ask the release team about a FFe
[22:39:00] <mathiaz> owh: yes.
[22:39:06] <owh> I'm not disagreeing with you, just putting up a fight that you're going to have in a few moments with the release team.
[22:39:07] <ivoks> deal
[22:39:17] <mathiaz> However, even if we don't get it in hardy, we'll get it into intrepid
[22:39:27] * owh is trying to help you strengthen your argument ;)
[22:39:39] <ivoks> mathiaz: ok
[22:39:39] <mathiaz> ivoks: just keep in mind that it may be rejected for hardy
[22:39:46] <ivoks> i'm aware of that
[22:40:35] <mathiaz> [TOPIC] Documentation and the server guide
[22:40:58] <mathiaz> sommer: Do you start to have feedback from the translators ?
[22:41:14] <sommer> mathiaz: yep, got a bunch of spelling mistakes fixed :-)
[22:41:20] <nealmcb> :-)
[22:41:26] <ivoks> :)
[22:41:51] <sommer> there's a bunch of ideas for intrepid in the server team idea pool as well
[22:42:00] <mathiaz> Now that the server guide is frozen for hardy, it may be worth spending some time on the wiki pages
[22:42:22] <sommer> mathiaz: yep, my plan is to work on the Samba sections I've been putting off... heh
[22:42:39] <mathiaz> sommer: is there any progress on the macros to be able to mark the release for which the wiki page is relevant ?
[22:43:09] <sommer> mathiaz: not sure, I can check on that though
[22:43:38] <sommer> I've heard rumors that the wiki install will be updated?
[22:43:39] <mathiaz> sommer: reading through the list of the wiki page on the roadmap, I'd suggest to start with AD integration
[22:43:54] <sommer> mathiaz: cool, will do
[22:44:07] <mathiaz> sommer: the arrival of likewise-open in hardy should make things much simpler to setup
[22:44:44] <sommer> that's been my experience :)
[22:44:49] <mathiaz> sommer: could you prioritize the list on the Roadmap and use numbered list instead of a bullet point list ?
[22:44:58] <sommer> mathiaz: sure
[22:45:10] * sommer has a thing for bullets
[22:45:30] <zul> oh dear :)
[22:45:39] <mathiaz> [ACTION] sommer to start working on the wiki page related to samba and update the roadmap list
[22:46:21] <mathiaz> [TOPIC] Virtualization
[22:46:29] <mathiaz> soren: anything new on this front ?
[22:47:37] * soren thinks
[22:47:44] <jdstrand> didn't a patch make it to allow for bridged networks to work right?
[22:47:57] <jdstrand> (and the wiki updated)
[22:47:59] <mathiaz> jdstrand: are you refering to hal's patch ?
[22:48:14] <keescook> bridged always worked okay (but was recently more well documented)
[22:48:17] <soren> Don't think so. Thursday->Monday holiday. Tuesday: Catch up on e-mail. Today: other stuff.
[22:48:20] <mathiaz> I was able to setup a bridge network for my server and it works well
[22:48:26] <keescook> the hal patch was for odd-ball interfaces (like my VLAN ifaces)
[22:48:27] * jdstrand is not sure what he is referring to, as he hasn't used bridged networking with kvm yet ;)
[22:48:35] <mathiaz> soren: right - I've forgot about this..
[22:48:45] <soren> mathiaz: :) No worries.
[22:48:53] <keescook> on the general virtualization topic, I uploaded a fix so that virt-clone would actually work. :)
[22:49:07] <sommer> keescook: sweet
[22:49:08] <jdstrand> keescook: oh and it works well! thanks!
[22:49:26] <soren> keescook: Ah, right. Thanks for that!
[22:49:32] <soren> keescook: Saved me the trouble :)
[22:49:35] <keescook> hehe :)
[22:49:42] <mathiaz> keescook: jdstrand so you guys are running all the security testing with kvm now ?
[22:50:02] <mathiaz> keescook: jdstrand it may be an interesting story to showcase somehow
[22:50:06] <mathiaz> nijaba: ^^
[22:50:13] <keescook> mathiaz: yup -- I used jdstrand's conversion tool and uninstalled vmware
[22:50:15] <nijaba> mathiaz: noted
[22:50:18] <jdstrand> yes
[22:50:31] <jdstrand> I have been fine tuning it
[22:50:50] <mathiaz> keescook: jdstrand and you're testing desktop apps with it
[22:50:57] <mathiaz> ie run with X
[22:51:01] <jdstrand> but I have i386 and amd64 and amd64/2 vcpus for all four releases and hardy
[22:51:09] <jdstrand> mathiaz: absolutely
[22:51:25] <jdstrand> I have ones with just 'ubuntu-standard' and others with 'ubuntu-desktop'
[22:51:51] <jdstrand> I now use virt-clone to clone one of my pristine vms so I can do development/patching
[22:52:14] <jdstrand> they are *very* handy
[22:52:19] <mathiaz> I think that is the main usage for of us, developers
[22:52:29] <mathiaz> so documenting it, the same way pbuilder and sbuild are, could be worth
[22:52:31] <keescook> mathiaz: yup, it's great.
[22:52:33] <jdstrand> and the combination of virt-clone, ubuntu-vm-builder and kvm is *awesome*
[22:53:02] <jdstrand> mathiaz: I think soren was woking on an sbuild-kvm
[22:53:05] <jdstrand> working
[22:53:13] <jdstrand> or at least thinking about it :)
[22:53:13] <soren> jdstrand: "working" is a bit of an overstatement.
[22:53:20] <soren> Precisely :)
[22:53:33] * jdstrand 'thinks' it would be a good idea
[22:53:42] <soren> I have a few ideas, but they've yet to be translated into actual code.
[22:53:55] <soren> It's intrepid material.
[22:54:02] <soren> (if I do it the way, I'm thinking about doing it)
[22:54:17] <mathiaz> Ok - I think that's all for the Roadmap/ReportingPage review
[22:54:18] <nealmcb> will there be a jeos iso for hardy 64-bit? or does vm-builder make the isos not that important?
[22:54:45] <mathiaz> nealmcb: jeos images are available for hardy IIRC
[22:54:51] <nijaba> nealmcb: no 64b -virtual kernel AFAIK
[22:54:53] <nealmcb> for i386, but not 64
[22:54:53] <jdstrand> ah yes-- iso testing in kvm worked great last week
[22:55:49] <mathiaz> nijaba: correct - I've asked for a amd64 flavour it was declined by the kernel team
[22:56:02] <mathiaz> nealmcb: yes - only i386 at the moment
[22:56:07] <nijaba> mathiaz: reasoning?
[22:56:12] <mathiaz> nealmcb: nothing will change for hardy
[22:56:17] <nealmcb> fine - I've always liked the vm-builder better
[22:56:18] <mathiaz> nijaba: too late in the release cycle
[22:56:25] <nijaba> mathiaz: ok
[22:56:44] <mathiaz> [TOPIC] Any other business
[22:56:53] <zul> nope
[22:56:57] <mathiaz> Anyone has come up with a great idea during this meeting ?
[22:57:08] <nijaba> nealmcb: but what we need is the 64b kernel, even with u-v-b
[22:57:10] <faulkes-> I'm still waiting on access to our colo to test our iscsi
[22:57:10] <kirkland> mathiaz: hmm, i had a thought....
[22:57:16] <faulkes-> I'm hoping for that to happen this week
[22:57:17] <owh> mathiaz: Just to note that the dovecot bug you asked me to look at I've handed back as it does not appear to relate to hardy.
[22:57:24] <nealmcb> nijaba: ooh - hmmm...
[22:57:35] <mathiaz> owh: yop - seen that. Thanks for the investigation
[22:57:59] <nealmcb> how important is 64 bit for virtualization?
[22:57:59] <mathiaz> owh: if you want to keep working on it, you'd have to figure out what's wrong in dapper
[22:58:06] <kirkland> mathiaz: with the 5-a-day push, and hardy beta testing ensuing, would it make sense for you or one of the other core members to bring forward a few high priority hardy server bugs in this meeting?
[22:58:17] <owh> mathiaz: In my spare life I'll think about it :)
[22:58:30] <kirkland> mathiaz: and look for volunteers to solve?
[22:58:39] <mathiaz> kirkland: good suggestion
[22:58:45] <kirkland> mathiaz: not making this a bug meeting, note.
[22:58:59] <mathiaz> kirkland: I'll try to compile a list of the high-profile bug for the server team
[22:59:08] <kirkland> mathiaz: but sift a few to the top, and throw out them out here
[22:59:10] <mathiaz> kirkland: I'll use the qa-server tag
[22:59:48] <mathiaz> kirkland: yes - I think it's important to have a new topic about high profile bug the close we get to release
[23:00:12] <owh> mathiaz: What about a general action point to review the hardy-qa bugs regularly.
[23:00:31] <mathiaz> owh: I'll update the meeting agenda
[23:00:42] <jdstrand> mathiaz, kirkland: here is one-- 155947
[23:00:57] <mathiaz> [ACTION] mathiaz to update the meeting agenda to make sure we review high-profile bugs until release
[23:01:02] <nealmcb> #155947
[23:01:09] <mathiaz> bug 155947
[23:01:12] <ubotu> Launchpad bug 155947 in libnss-ldap "ldap config causes Ubuntu to hang at a reboot" [Undecided,Confirmed] https://launchpad.net/bugs/155947
[23:02:11] <mathiaz> [ACTION] mathiaz to compile a list of high priority bugs for the server team
[23:02:22] <kirkland> jdstrand: yep, just that sort of thing
[23:02:41] <kirkland> without making this meeting a complete bug meeting :-)
[23:03:25] <mathiaz> [TOPIC] Agree on next meeting date and time.
[23:03:33] <mathiaz> Same time, same place, next week ?
[23:03:40] <nijaba> DST comes in next week in europe
[23:03:49] <nijaba> that will maje the meeting at 2300 CET
[23:03:57] <nijaba> a bit late...
[23:04:37] <owh> nijaba: If you make it any earlier, I'll be fast asleep.
[23:04:38] <mathiaz> nijaba: ok - so I guess can move back the meeting
[23:04:45] * owh is at UTC+9
[23:04:51] <nijaba> argh...
[23:05:13] <nijaba> ok, then, let's not change anything
[23:05:19] <owh> Unless of course you don't want my scintillating contributions :)
[23:05:33] <mathiaz> soren: ^^ ?
[23:05:34] * nijaba thinks we need owh
[23:05:59] * sommer likes things that scintillate
[23:06:47] * owh gets ready to rub hands to generate some static :)
[23:06:50] <soren> Let's move it an hour.
[23:06:51] <soren> That's fine.
[23:07:11] <mathiaz> soren: 2300 CET for you works ?
[23:07:25] <mathiaz> soren: we wouldn't move the meeting time
[23:07:25] <nealmcb> soren: did you read about owh/au time also?
[23:07:27] <soren> That keeps it at the local time that most of us agreed on back in the day.
[23:07:38] <soren> nealmcb: No, sorry.
[23:07:41] <mathiaz> soren: It'd stay at 21:00 UTC
[23:07:48] <soren> Oh, ok.
[23:07:54] <soren> Erm... Well, 2300 CET is ok.
[23:07:57] <soren> I don't sleep anyway.
[23:08:14] * nijaba wonders if soren *ever* sleep
[23:08:24] <soren> So does my wife.
[23:08:24] <nealmcb> soren is a bot
[23:08:30] <mathiaz> ok - so next week, same time - 21:00 UTC, same place
[23:08:40] <owh> nealmcb: A pretty smart one at that :)
[23:08:47] * nealmcb nods vigorously
[23:09:19] <nealmcb> Data with a soul....
[23:09:25] <mathiaz> Thanks all and shake well Beta to find all the bugs
[23:09:36] <nijaba> thanks mathiaz
[23:09:43] <owh> Thanks mathiaz
[23:09:56] <sommer> later on all
[23:10:15] <jdstrand> thaks mathiaz!
[23:10:19] <ivoks> sorry, i fall a sleep
[23:10:27] * nijaba signs off singing "shake it shake it, shake it good"
[23:10:29] <ivoks> bye all :)
[23:10:39] <mathiaz> #endmeeting
Meeting ended.

MeetingLogs/Server/20080326 (last edited 2008-08-06 16:59:47 by localhost)