16:00:42 #startmeeting Server Working Group Weekly Meeting (2014-02-25) 16:00:42 Meeting started Tue Feb 25 16:00:42 2014 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:42 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:47 #meetingname server-wg 16:00:47 The meeting name has been set to 'server-wg' 16:00:51 #topic Roll call 16:01:05 * nirik is here, but gonna grab some coffee, so back in a min. 16:01:06 sgallagh's double booked today, so he's asked me to run the meeting... 16:01:08 * mizmo here (Máirín Duffy) 16:01:16 who else is around? 16:01:21 .hellomynameis adamwill 16:01:23 adamw: adamwill 'Adam Williamson' 16:01:23 Hello all 16:02:15 i believe quorum is 5? 16:02:42 davidstrauss: ping 16:05:11 well, if we wait for nirik to get back from coffee and we count sgallagh as present, we'd have 5, I guess. 16:05:54 Hello 16:05:56 Sorry, double-booked. Will be attending, but slow. 16:06:04 back 16:06:11 * mizmo has to leave at a quarter of 16:06:14 OK, well, I guess we can try and go ahead with this number 16:06:20 mizmo: er, is that :15 or :45? 16:06:48 #topic Target roles for F21 16:07:01 I think we could call this one based on the list votes 16:07:59 yep. seems clear cut and fine to go with those 2. 16:08:11 Yes, I haven't fully tallied them yet (including mitr's latest), but it looks pretty firmly agreed (and with PostgreSQL as the winner for DB) 16:08:25 we've got solid majorities for domain controller for 'primary blocker target', database server for 'secondary target' and pgsql for 'database of choice' 16:09:03 do we do an #agreed for that then? 16:09:07 yup, doing it 16:09:39 #agreed Domain Controller is accepted as the "primary blocker target" role for Fedora 21 (+9/-0) 16:10:04 #agreed Database Server is accepted as the "secondary target" role for Fedora 21 (+9/-0) 16:10:29 Did we get all +9? 16:10:35 sgallagh: yeah, looks like it 16:10:39 oh good 16:11:03 (btw i'm doing some wiki gardening atm) 16:11:11 #agreed PostgreSQL is accepted as the "initial" database for Fedora 21 (7 pgsql, 1 mariadb, 1 abstain) 16:11:18 mizmo: Much appreciated. 16:11:30 OK, moving on 16:11:53 #topic Install media and high-level view of default packages 16:12:33 First question: do we need (or care about) any media besides netiso? 16:12:54 * nirik is fine with netiso + our packages (so it could be used to install locally too) 16:12:58 Isn't this already resolved in https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Delivery_Mechanisms ? 16:13:08 netninstall + offline ISO 16:13:09 depends if anyone does offline installations without a site repository, I suppose 16:13:29 #info PRD states "Fedora Server will produce two main installation resources, a netinstall image and an offline install iso image that allows one to install and configure featured roles offline." 16:13:29 yes 16:13:40 there are folks who do offline installs without a repo available 16:13:56 mitr: good catch - though we can choose to only do the netinst iso for f21 if we want, i guess 16:13:58 adamw: It's not a "site repository" (which would be fairly feasible), it's "control of the PXE server" (which may not) 16:14:06 We left the presence of Roles ambiguous in the PRD there 16:14:20 Does the offline media include Roles or just the base install? 16:14:52 so, both of these are non-live media, i'm assuming 16:14:54 I don't think we should do 2 media... 16:14:59 we have no use for live 16:15:09 PRD says "allows one to install ... roles offline". I'm not sure we need _all_ roles off-line; we do need the PXE server off-line :) 16:15:13 do we care at all about the CD size target? 16:15:38 if not, then it seems pretty simple: do a netinst and an image with both roles 16:15:41 (at least for f21) 16:15:43 i dont think we should as long as it fits on a reasonably priced usb stick 16:15:44 mitr: we just need base stuff + whatever is needed for our roles... 16:15:48 adamw: I think no live install, no CD size limitation (but perhaps a DVD size limitation, though I hope we are far from breaching that) 16:15:49 adamw: Let's call a vote on that? 16:15:51 (or just the DC role if we don't get database server role done) 16:16:07 mitr: yeah, i'd expect we'd be way under DVD size, and server admins can afford a 4GB USB stick 16:16:19 I suppose we could toss some other non role server stuff on there if we wanted... but that would be gravy/scope creep 16:16:25 Proposal: Server full-install image should be kept within 4GB 16:16:40 eh, i'd be okay with DVD size (4.7GB) 16:16:43 nirik: Sorry, I was assuming a PXE / domain controller will eventually happen, not proposing to add PXE if we don't have a role yet 16:16:46 nirik: I'd prefer to explicitly refuse that. 16:16:49 mitr: ah right. 16:16:55 sgallagh: thats fine to with me. ;) 16:16:57 yeah, product focus! 16:16:58 sgallagh, +1 to 4.7gb proposal 16:17:07 adamw: I'd rather keep it to 4.0GB for purposes of USB sticks 16:17:09 sgallagh: +1 (big enough not to worry about 4G vs. 4.7G) 16:17:10 sure, dvd size is fine. I sure hope we are very far from it tho 16:17:25 sgallagh, +1 to 4 gb proposal too lol 16:17:38 OK, i'll +1 4GB as an initial target and we can re-consider if we turn out to be close to it (I doubt we will, but couldn't say for sure) 16:17:45 adamw: Sounds good to me 16:18:12 nirik: you OK with 4GB for now? 16:18:16 sure, we have bigger fish to fry. ;) 16:18:45 #agreed initial maximum size for offline ISO is 4GB (+5/-0) 16:18:50 ok, so: 16:19:57 * nirik waits for adamw's so... 16:19:58 proposed #agreed Fedora 21 deliverables will consist of a network install ISO image capable of deploying the roles we consider ready for release, and an ISO image capable of deploying the roles we consider ready for release without a network connection 16:20:19 note: I'm saying "an image", but we haven't yet considered the topic of arch (and neither has any other WG, i don't think...) 16:20:30 adamw: +1 16:20:41 adamw: +1 16:20:42 wait... 16:20:54 the 'and' there... thats 2 seperate images? 16:20:58 from a QA perspective, one 'extra' image seems doable (I'm assuming that in practice the netinst will wind up being our current netinst and effectively shared between products, but we can wave that hand later) 16:21:05 that seems really silly to me. 16:21:10 One's a netiso, the other is the "big" iso. 16:21:13 nirik: well, the point of netinst is that it's small 16:21:25 nirik: if the offline image goes over 700MB it'd also be our hedge for CD media 16:21:25 how big do you think our roles are going to be? 16:21:29 Possibly just boot.fp.o 16:21:30 don't know 16:21:46 I can't possibly think they would be 300MB+? 16:21:56 400 I guess. 16:22:00 we could try and spin up some test images, but i suck at building DVDs and we have a week,. 16:22:02 the net iso is about 300 now 16:22:15 adamw: +1 16:22:17 I really think roles are going to be small... 16:22:17 i don't think current netinst contains a single package, though. 16:22:31 so, if there's more than a 400MB package load, we might go over CD size. 16:22:36 I was actually thinking of the "tiny" image as being closer to boot.fp.o than the current netinst. 16:22:46 sgallagh: hum, okay. 16:22:57 what about in the proposal we set size limits. if offline roles requires > x MB, then two media 16:23:08 mizmo: I'd be ok with that... 16:23:16 sgallagh: although i think pretty much all of the size of netinst.iso is the initramfs + anaconda itself. so if you have those two things, the size is kinda wired in. 16:23:21 What we actually mean is "something that can be started from PXE", not specifically "an ISO image that is small and can download packages from elswehre", don't we? 16:23:29 I just think it's silly to ship a 400MB netinstall and a 400mb 'non netinstall' thats pretty much exactly the same thing. 16:23:36 IOW, we _could_ have a single ISO + the PXE-required kernel and config 16:24:08 sgallagh: you were thinking of basically a kernel and initramfs and a PXE config on an image? 16:24:09 mitr: I was thinking that... iso + vmllinuz/initramfs as we have always done 16:24:24 adamw: Yes, that's what I was thinking 16:24:39 how would the non net install be the same size as netinstall? i dont understand :-/ 16:24:51 mizmo: i don't think it can be, but it could also be 'quite small' 16:25:06 well, it could be very close... 16:25:18 mizmo: nirik is suggesting that it might be only a few MB larger, at which point it's not sensible to separate them 16:25:28 making the minimal 'image' be a boot.fp.o thing is kinda an interesting idea as it gives the potential to update the installer, I guess. 16:25:29 But I'm talking about a more substantial difference. 16:26:01 the roles are only going to take a small bit? by roles you're including the packages req for the roles right? 16:26:23 sgallagh: Actually, even if the "net" install required say a 1.5 GB download, would that be a problem? A minimal install would not have to install everything, but if it would save us one deliverable to test, might be worth it) 16:26:34 mizmo: I think they're likely bigger than nirik is assuming, but we're likely talking dozens rather than hundreds of MB 16:27:04 the postgresql-server package is 3.8MB 16:27:20 nirik: plus all the dependencies, starting from scratch 16:27:25 sure... 16:27:27 sgallagh, i guess if we're starting with 2 roles only, right? but as time goes on there's gonna be more roles - so maybe we should do the proposal in terms of max size we allow to have one image for the long-term prospect of having more and more roles 16:27:34 nirik: IIRC, FreeIPA plus deps ends up being a little south of 200MB, IIRC. 16:27:39 but I really really don't see this being 100's of MB. 16:27:52 sgallagh: that surprises me. ok 16:27:59 nirik: Mostly dogtag 16:28:08 The "minimal install" core is larger than any of the roles in any case 16:28:24 do we consider the offline or online image our 'primary' thing? 16:28:27 huh, those dogtag packages are very small. 16:28:43 i kinda like the offline image myself, as it's a single thing you can just download and use and you're done. 16:28:46 nirik: Hmm, maybe I misremember 16:28:53 if we all agree on having the offline image for f21, i guess we can at least do a #agreed for that 16:29:20 adamw: +1 for a "complete" offline image 16:29:40 +1 to offline image for f21 16:29:46 sure. +1 I agree. 16:29:49 proposed #agreed one deliverable for Fedora 21 will be a 'traditional install' style ISO image capable of deploying the roles we consider ready for release without a network connection 16:29:50 (well, complete as possible without net) 16:30:07 (traditional install is contrasted to live install) 16:31:35 mitr: ? 16:32:03 adamw: +1 16:32:05 (Sorry, thought that was already recorded as an agreed thing) 16:32:10 I guess as we add more roles I can see the netinstall and offline diverging... so we could just do a traditional netinstall from the start... 16:32:10 #agreed one deliverable for Fedora 21 will be a 'traditional install' style ISO image capable of deploying the roles we consider ready for release without a network connection 16:32:34 sgallagh: is there a particular advantage to doing a super-minimal ISO beyond the 'perhaps possible to update the installer' thing? 16:32:39 unless we want to dump netinstall in favor of boot.fp.o images... thats an interesting idea... 16:32:41 ultimately those bits are going to be needed one way or another 16:32:55 (or some other super-minimal 'media' / deliverable) 16:33:01 boot.fedoraproject.org 'images' are ipxe with a scipt built in 16:33:02 nirik: That was pretty much where I was going. 16:33:25 the script tells them where to grab kernel/initramfs and what to pass it. 16:33:59 there's a number of types of images too. 16:34:26 http://boot.fedoraproject.org/download 16:34:57 I'd also like to discuss the boot.fp.o topic with the other Products 16:35:07 the thing that worries me slightly with my QA hat on is that f21 is very likely to wind up having a netinst.iso anyway one way or another, and if that's not our other deliverable, we're throwing another on the testing pile 16:35:10 So we would require the users to set up PXE with an image that goes off to boot.fp to see which kernel to download? Why not just tell the users to set up PXE with the real kernel and and save one indirection? 16:35:12 Because it would be really nice if we only have one that cna be used to deploy any of the products 16:35:13 so i'd at least like the advantages to be clear 16:35:19 sgallagh: that would be nice 16:35:44 there are environments where PXE is not allowed 16:35:46 mitr: no local pxe is needed... you dl the image, boot it and it starts 16:35:59 * mizmo could rattle off several 16:36:20 nirik: If I'm downloading something and manually inserting boot media, might as well download the full image 16:36:28 the other thing we can do is handwave this for now if we want to move on and discuss the next topic 16:36:51 mitr: that's kind of my thought, except the "updatable installer" angle. i've never quite got the point of b.f.o. 16:37:01 mitr: Network-constrained environments like being able to download only the exact packages they care about 16:37:31 mitr: sure. 16:37:32 sgallagh: For Server, I'm more worried about network-connectivity-limited data centers than bandwidth constraints - might be wrong 16:37:58 adamw: Who would sign up to do the testing of the updated installer? 16:38:07 sure. 16:38:09 anyhow, I'm fine with a traditional netinstall. I think we need more thought on boot.fp.o and if it gets us enough to deal with 16:38:28 adamw: FWIW, Server was the only one with a "network install" deliverable. No idea what this means WRT non-Product users wanting network install. 16:39:15 proposed #agreed we also plan a minimal deliverable of some kind for Fedora 21, which could be a 'traditional' netinstall image or a boot.fedoraproject.org-style deliverable: this requires further consideration 16:39:20 mitr: it may depend on if we as server working group want to tweak the installer defaults or add spokes or whatever. 16:39:34 mitr: i was expecting we'd have one and it'd be 'owned' by base wg or no wg at all. 16:39:58 So.... 16:40:00 Proposal variant 1) No change to existing decision: in addition to a full traditional ISO, we will produce a netinstall ISO as is currently done (i.e. ISO with anaconda, no RPMs) 16:40:02 Proposal variant 2) We will document how to boot a full installation from PXE based on the traditional ISO, and test that as a supported deliverable 16:40:12 mitr: we don't have an existing decision 16:40:19 i've just done a 'fudge' proposed agreement 16:40:33 adamw: The PRD calls for a netinstall iso. We are essentially revisiting that. 16:40:38 * mizmo votes for variant 1 fwiw 16:40:38 oh, right. 16:41:02 adamw: +1 to your "plan for", but I'd rather settle this now, this will not become clearer later 16:41:08 so, we now have three live proposals, which is bad. and i don't think mitr's proposal 2 is actually what sgallagh was talking about. 16:41:13 I'm for variant 2) above 16:41:19 mitr: why won't it become clearer later? sgallagh's proposal is kind of a new one we hadn't thought about before. 16:41:28 it'd be good to have more details/implications of that. 16:41:32 i'm certainly still digesting it. 16:41:32 mitr: It calls for netinstall, but it was (IMHO) ambiguous whether it was a traditional netinstall.iso vs. just being able to install over the network 16:41:47 sgallagh: true 16:41:54 mitr: in your proposal 2 thta means we don't care about netinstall? all our deliverable is the 'offline' iso? 16:42:08 nirik: we care about installing over the network, but not about delivering a small image 16:42:09 mitr: aiui sgallagh's plan was for the other deliverable to be a very minimal image in the boot.fedoraproject.org style, not just a different way of installing from the variant ISO. 16:42:33 so yours is effectively a new proposal - that we support the style but not with a different deliverable. 16:42:35 adamw: OK, let's defer this for more discussion (... a specific #action?) 16:42:44 mitr: that was my proposed #agreed, essentially. 16:42:48 proposed #agreed we also plan a minimal deliverable of some kind for Fedora 21, which could be a 'traditional' netinstall image or a boot.fedoraproject.org-style deliverable: this requires further consideration 16:42:53 mitr: I guess I'd be ok with that... then leave netinstall for base 16:42:58 right 16:43:05 hum, let me amend it a bit 16:43:35 proposed #agreed we also plan a minimal deliverable of some kind for Fedora 21, which could be a 'traditional' netinstall image, a boot.fedoraproject.org-style 'anacondaless' image, or just a variant method of deployment from the 'full' deliverable: this requires further consideration 16:43:58 sure. 16:44:00 adamw: You convinced me, +1 16:44:34 any other votes? 16:44:47 +1 for the proposal, and we can discuss more on list 16:45:06 sgallagh: mizmo: ? 16:45:16 +1 from me 16:45:16 Sorry, double-booking it right now 16:45:19 Reading scrollback 16:45:30 mizmo: do you have to leave now? 16:46:00 adamw: +1 16:46:08 adamw, i do 16:46:10 * mizmo turns into a pumpkin 16:46:14 #agreed we also plan a minimal deliverable of some kind for Fedora 21, which could be a 'traditional' netinstall image, a boot.fedoraproject.org-style 'anacondaless' image, or just a variant method of deployment from the 'full' deliverable: this requires further consideration 16:46:17 bye mizmo-out 16:46:18 OK, we're under quorum now 16:46:21 byebye :) 16:46:28 we didn't get through everything, so should we schedule another meeting? 16:46:32 bummer. I was going to suggest xfs default filesystem. ;) 16:46:38 or agree to have sgallagh schedule one? 16:46:40 So we don't have voting population, but should we still discuss things? 16:46:41 yeah, I think so... later in the week. 16:46:48 we could keep talking things over, sure 16:47:03 what did you have in mind with 'high level view of default packages'? 16:47:03 Seems a waste to lose fifteen minutes of discussion at least 16:47:26 adamw: Start talking about what basic functionality (pre-Roles) means 16:47:42 I.e. "Is SSHD installed and running by default?" Cockpit? 16:48:32 +1 sshd installed and running and reachable. I guess if we are depending on cockpit to configure things, it should be installed and set to start in some default state. 16:48:48 hi 16:48:54 so math is hard, i dont actually have to go until 12:45 16:48:56 * mizmo facepalm 16:49:20 I kind of think these are dictated by the Roles; without a running application the infrastructure doesn't mean much. Still, we can take an educated guess :) 16:49:22 +1 to sshd 16:49:27 Well, I want Cockpit to be the preferred way, but it needs to be doable via API as well 16:49:34 So that's the hard requirement in my mind. 16:49:44 Cockpit is a firm "very-nice-to-have" for that 16:50:32 mitr: Well, we need to figure out what we need to support the roles 16:50:38 That's really what I mean here 16:50:47 mizmo: d'oh :) 16:50:52 sgallagh: right. we need that as yet to be written dbus listening thingie... 16:50:57 Re: Cockpit running by default ... I'm leaning towards "yes", but it would be good to air it on the mailing list just to make sure there won't be an explosion of outcry 16:51:38 sgallagh: seems like there's two levels there: what's needed to support 'roles in general', and what's needed to support a specific role 16:51:49 sure 16:51:49 though i suppose what's needed to support a role is part of that role. meh. 16:51:58 I was just going to say that 16:52:15 So let's focus on "roles in general" 16:52:24 i think cockpit running by default is fine for any path where you're explicitly deploying the fedora server product. 16:52:27 there's also: default fs, firewalld or not, NM (but I guess we need quorum to vote on that) 16:52:33 So clearly the first problem there is the D-BUS configuration listener for roles 16:52:40 +1 to sshd, holy crap is that annoying that we dont do that anymore 16:52:48 nirik: we have quorum again now mizmo isn't leaving, but perhaps we shouldn't vote on everything with minimal quorum 16:52:57 mizmo: we do do it, but just not on live. ;( 16:53:12 adamw: I'm fine with us voting and being willing to backtrack with new information 16:53:15 OK 16:53:30 do we want a vote on sshd/cockpit? 16:53:34 nirik, huh i installed f20 with dvd and didnt get it :-/ had some annoying initial firewall config too 16:53:47 mizmo: weird. I thought it was still on on dvd installs. ;( 16:54:02 do we enable password login or not for sshd by default? 16:54:26 adamw: PAM login, I think 16:54:38 mizmo: iirc all our default firewall zones have 22 open 16:55:15 cfv: sshd installed, running and enabled by default when deploying Fedora Server 16:55:18 well, there was some talk a while back about ways to get keys on new installs... if those pan out I'd be fine restricting to keys, but if not, we need passwords at least initially. 16:55:18 +1 for me 16:55:23 +1 16:55:31 +1 16:55:50 adamw: We have to right now (no domain client support in the installer GUI). Having sshd running always but usable only on kickstart installs doesn't make sense 16:55:57 So +1 if this is a vote 16:56:11 yeah, i went with 'cfv' this time. i like to switch things up. :P 16:56:20 mizmo: ? 16:57:39 " +1 to sshd, holy crap is that annoying that we dont do that anymore" 16:57:41 so: 16:58:01 #agreed sshd will be installed, enabled and running by default when deploying Fedora Server 16:58:54 sorry driveby cubing 16:59:05 adamw, the fierwall config that had me annoyed related to printing 16:59:15 ah, following in linus' hallowed footsteps :P 16:59:26 so, i have been hacked via brute force password guess 16:59:33 so i would be against password ssh logins by default 16:59:50 cfv: cockpit installed, enabled and running (is that appropriate terminology for cockpit?) by default 16:59:54 well, there's no other way to get in initially currently. 16:59:57 we had talked in anaconda about letting you set up the system without a password 17:00:08 we do need to focus for f21 17:00:10 (unless we have a way to easily pull in ssh keys) 17:00:20 adamw: +1 17:00:23 if that's something we feel sufficiently strongly about to commit to building it for sure as part of f21 dev... 17:00:25 adamw: Well, socket-activated rather than "running" 17:00:28 why dont we have some kind of keyserver thing like we do for ntp 17:00:34 I'm not sure I want to commit to that part of it today 17:00:35 so you pulls the keys down from a server 17:00:55 I *do* want to commit to building the D-BUS API that Cockpit would be talking to, though 17:01:02 mizmo: monkeysphere. ;) 17:01:02 sgallagh: sorry, i'm crossing streams 17:01:19 trusted keys can be part of a freeipa deployment too...there's various ways to do it, but i'm not sure we can rely on any of them 17:01:35 Right, but we still need a way to install FreeIPA in the first place. 17:01:43 There will always be a bootstrapping problem 17:01:43 (and, er, anaconda isn't capable of making a system a freeipa client yet anyway) 17:01:49 mizmo: We have that, it's called cloud-init , but it's also a horribly insecure thing to use if the user things there isn't one 17:01:54 sgallagh: anaconda's supposed to be able to do it, but no-one's written it yet. 17:02:01 We have some ideas on how to solve this with OpenLMI, but they won't be ready for F21. 17:02:16 adamw: re: cockpit - bring it up on the ML, I'll probably be +1 in a week 17:02:19 there used to be an "Advanced..." button on the user creation tab which did nothing at all 17:02:33 should we add some kind of freeipa / openlmi key sharing integration to the cool ideas wiki page 17:02:37 adamw: Actually, that used to work, then broke 17:02:45 sgallagh: in newUI, i mean. 17:02:50 oh 17:02:53 mizmo: that sounds like the right venue for it, yup 17:02:58 mizmo: yes 17:03:02 mizmo: That's already covered in Use Case 3 AFAICT 17:03:17 mitr: what do you need to be +1 to cockpit? 17:03:18 or a clever way to pull your ssh keys from fas. :) 17:03:20 ...aaand we're over time 17:03:20 * nirik runs 17:03:21 I'll happily explain the plan to anyone who wants to listen, but it's a longer explanation than we want here right now 17:03:35 adamw: opportunity for non-voting members to voice their opinion 17:03:42 mitr: OK 17:03:42 adamw: I'm +0 on Cockpit right now. 17:03:43 mitr, this is a bit more nuanced though it'd have to be during install 17:03:54 a thought: do we want to enumerate our really basic requirements, like desktop WG did? 17:03:54 mizmo: Explicitly adding this as one of the things that should be a part of the domain would make sense to write down, yes 17:04:00 do we have any that are *different* from desktop WG? 17:04:43 https://fedoraproject.org/wiki/Server/Polish_Ideas #3 here is how i added it 17:04:44 adamw: Do you mean the core services stuff? 17:04:46 I think some of them we should... like filesystem/etc. 17:04:53 I'm going to send an email with my thoughts on that this afternoon 17:04:56 sgallagh: yeah, basically 17:04:58 OK, cool 17:05:06 looking forward to it 17:05:15 There are a few that don't make sense, but many of them do 17:05:21 that was more or less my take, yeah 17:05:25 i'd like to see as much convergence as possible 17:05:29 (again with my qa hat on) 17:05:39 ack 17:06:28 #action sgallagh to send out a mail regarding 'core dependencies' for discussion 17:06:31 yeah, we should only diverage where it makes good sense for our product. 17:07:10 should we wrap things up for now? i think we got some useful stuff decided at least, and we seem to have reached a natural point where we need more extensive basis for discussion (like a nice solid mailing list strawman) 17:07:26 do we want another meeting later this week? 17:07:56 probably a good idea 17:08:02 maybe we should schedule it on list, though 17:08:12 sgallagh: do you want to do that, or should someone else take it? 17:08:19 * adamw is in not-volunteering-for-anything-at-all mode atm 17:08:32 (aka "oh shit i have a gigantic backlog" mode) 17:08:49 perhaps friday... to allow list discussion time before hand. 17:09:34 anyhow we can decide on list. 17:10:10 Can we just reuse the "server overflow meeting" date from last time instead of waiting on whenisgood? 17:10:20 Sorry, I'm back (and reading backtrace again) 17:10:23 mitr: when was that, do you recall? 17:10:41 last overflow meeting was thursday 17:10:43 Thurstday 4PM my time 17:10:43 november 19 17:11:10 Which is 10am eastern I think 17:11:25 I'll send out a whenisgood for Thursday and Friday. 17:11:35 thursdays are already meetingorama for me, but I can try and make it 17:11:56 We'll see what has the highest overlap 17:12:00 sounds good 17:12:01 fridays are really hard for me 17:12:14 #action sgallagh to send a whenisgood for a follow up meeting later this week to discuss the rest of the things we have to settle 17:12:50 Also, if two meeting times come up with a large overlap, I have no problem scheduling two meetings. 17:12:54 Since we have limited time... 17:13:04 Anyway, let's see what happens. 17:13:25 #action sgallagh to send whenisgood request for Thursday/Friday 17:13:39 i did that already :) 17:13:40 never mind 17:13:51 #undo 17:13:54 OK, let's wrap up! thanks for coming, everyone 17:14:03 sgallagh: i don't think I #chair'ed anyone, so you're talking to dead air :) 17:14:12 ... 17:14:26 Ok, thank you very much for chairing, adamw 17:14:31 Much appreciated 17:14:40 sorry i forgot to do backup chairs, i always forget that 17:14:44 #endmeeting