Jan 30 09:58:05 --- jds2001 has changed the topic to: FESCo meeting --init Jan 30 09:59:01 --> scox_ (n=scox@nat/redhat/x-5ded45d166e5d0aa) has joined #fedora-meeting Jan 30 10:00:02 FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod Jan 30 10:00:13 * nirik is here. Jan 30 10:00:15 * sharkcz here Jan 30 10:00:24 * bpepple is here. Jan 30 10:02:45 hmm, any reason no one else is here? Jan 30 10:02:52 --> notting (n=notting@redhat/notting) has joined #fedora-meeting Jan 30 10:03:07 jds2001: they saw the agenda? ;) Jan 30 10:03:22 hehe :D Jan 30 10:03:55 --> jmoskovc (n=Mozkum@nat/redhat/x-ba4b45f0849c71d8) has joined #fedora-meeting Jan 30 10:04:31 well i guess with notting here we have enough to get started, even though I don't like having just 5..... Jan 30 10:04:42 --> j-rod (n=j-rod@static-72-93-233-3.bstnma.fios.verizon.net) has joined #fedora-meeting Jan 30 10:04:53 ahh, theres #6 :D Jan 30 10:05:07 jds2001: I pinged notting and j-rod in internal irc Jan 30 10:05:08 <-- lfoppiano has quit ("Ex-Chat") Jan 30 10:05:16 sharkcz: thx Jan 30 10:05:25 (fwiw, I'm over on #fedora-devel and #fedora-kernel most of the time too) Jan 30 10:05:31 but thank you sharkcz :) Jan 30 10:05:42 j-rod: np Jan 30 10:05:51 --> markmc (n=markmc@83-70-64-220-dynamic.b-ras1.srl.dublin.eircom.net) has joined #fedora-meeting Jan 30 10:06:07 --- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets Jan 30 10:06:12 .fesco 28 Jan 30 10:06:14 jds2001: #28 (Stronger Hashes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/28 Jan 30 10:06:14 <-- che has quit (Read error: 110 (Connection timed out)) Jan 30 10:06:56 any questions for mitr on this? Jan 30 10:07:16 <-- petreu has quit ("( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )") Jan 30 10:07:29 where are we with it? Jan 30 10:07:32 mitr: is there any update on the status? thats a low % and hasnt been updated in a while Jan 30 10:07:51 * nirik doesn't like the 'no preupgrade from f9->f11'. thats going to bite a lot of people. Jan 30 10:07:59 nirik: There are way too many packages to ever get 100% :) Jan 30 10:08:19 nirik: yeah, I find that a little troubling, too. Jan 30 10:08:30 can we push a rpm update for f9 w/the hash change backported? Jan 30 10:08:35 nirik: The difficult (RPM-related) parts are almost done: patch for rpm exists, createrepo/yum use SHA-256 already, a patch for koji exists as well. Jan 30 10:08:40 notting: panu said we can't. Jan 30 10:08:57 is it possible for F10? Jan 30 10:09:04 then we hold off on this til F12? Jan 30 10:09:17 so that we can upgrade from lowest maintained -> current? Jan 30 10:09:24 * notting takes the action item to harass panu Jan 30 10:09:26 er, preupgrade Jan 30 10:09:42 I assume since it's rpm, that would also apply to yum upgrades... Jan 30 10:09:52 Right. Jan 30 10:10:20 <-- fbijlsma has quit (Read error: 110 (Connection timed out)) Jan 30 10:10:58 --> jjmcd (n=jjmcd@75-134-169-186.dhcp.bycy.mi.charter.com) has joined #Fedora-Meeting Jan 30 10:11:00 like it or not, lots of folks do yum upgrades. Jan 30 10:11:19 any status on rsync/scp or backup tools? I don't see any of those on the tracker bug. Jan 30 10:11:50 scp probably already supports this, only needs non-default configuration. Jan 30 10:12:13 rsync does not support SHA-256, that's #483056 Jan 30 10:12:30 bacula supports SHA-256 for verifying restored backup files, amanda doesn't do any verification AFAICS. Jan 30 10:12:48 --> jmoskovc` (n=Mozkum@nat/redhat/x-b300f5dd3423c106) has joined #fedora-meeting Jan 30 10:13:28 mitr: if the backport's too big, why not push back 4.6 with some config changes? Jan 30 10:14:16 notting: I didn't think of that and didn't ask. Jan 30 10:14:25 or can we do everything but rpm for now, and then push the rpm change as jds2001 said in a later release? Jan 30 10:15:39 notting: I assume the stricter rpmbuild (--fuzz 0) could be a problem. Jan 30 10:15:47 mitr: that has to be configurable Jan 30 10:15:51 nirik: That's possible. Jan 30 10:16:15 it's configurable in a spec, so should be fine in /etc/rpm/macros or whereever Jan 30 10:16:27 well, I am all for this feature, but I would like to find a way to not mess up preupgrade/yum upgrades from f9... Jan 30 10:17:01 same here, but not sure how to vote like that :D Jan 30 10:17:27 how about we defer and mitr works on some way to make that happen and we revisit next week? mitr: would that be ok? Jan 30 10:18:02 the release notes need a note about the .rpmnew thing for sure. Jan 30 10:18:06 * j-rod likes nirik's suggestion Jan 30 10:18:06 nirik: I'd prefer immediate approval of course :) but it is probably a good idea. Jan 30 10:19:08 oh, I almsot forgot - nirik your turn for summary this week :) Jan 30 10:19:12 nirik: A release note is on my todo list already. Jan 30 10:19:21 jds2001: oh. ok :) Jan 30 10:20:22 +1 to nirik's suggestion Jan 30 10:20:39 +1 to nirik's suggestion, defer til next week. Jan 30 10:20:46 +1 to defer Jan 30 10:20:46 +1 here also to nirik's suggestion. Jan 30 10:21:03 +1 also to my suggestion. Oh wait... :) Jan 30 10:21:31 i see five +1's that we defer to next week, so I'll keep it on the schedule. Jan 30 10:21:56 <-- drago01 has quit (Remote closed the connection) Jan 30 10:22:03 .fesco 36 Jan 30 10:22:05 jds2001: #36 (Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/36 Jan 30 10:22:53 +1 to ArchitectureSupport Feature. Jan 30 10:23:03 any questions? Jan 30 10:23:17 dgilmore had a concern that this would break the XO. I'm not 100% clear on that. Jan 30 10:23:20 dgilmore brought up XO - cjb told me that it should work OK with i686 packages Jan 30 10:23:40 <-- jmoskovc has quit (Read error: 110 (Connection timed out)) Jan 30 10:23:45 * nirik notes this will be unpopular with the i586 folks, but it's not clear how many there are. Jan 30 10:23:51 but afaik it lacks things like mmx? Jan 30 10:23:54 XO is now using the i686 live image Jan 30 10:24:00 ok. Jan 30 10:24:23 jds2001: as there are eleventy-billion separate 32-bit streaming instructions, i don't think gcc emits them by default Jan 30 10:24:54 (mmx, sse, sse2, sse3, whatever-the-amd-ones-are) Jan 30 10:25:25 cool, +1 here then. Jan 30 10:25:27 Two years ago the i586 folks were talking embedded. Jan 30 10:25:35 *embedded systems Jan 30 10:25:55 abadger1999: going by the stats we have available, the i586 userbase is miniscule Jan 30 10:26:07 Jan 30 10:26:15 I have some i586 machines here... but they are off in the garage awaiting recycling. ;) Jan 30 10:26:16 less than 1% wasn't it? Jan 30 10:26:18 but embedded probably wouldnt show up in any of those stats Jan 30 10:26:26 * abadger1999 gets ready to junk his three old i586 boxes. Jan 30 10:26:28 bpepple: much less. .04% Jan 30 10:26:47 (of active hosts) Jan 30 10:26:48 anyhow, +1 from me... Jan 30 10:26:57 +1 Jan 30 10:27:03 reaffirms his +1. Jan 30 10:27:06 i think this might be unpopular among the "ZOMG Fedora only support new hardware!" crowd. Jan 30 10:27:13 but +1 anyways Jan 30 10:27:20 +1 from me Jan 30 10:27:32 * nirik notes there will be yelling from alan cox most likely. Jan 30 10:27:33 jds2001: 'new' is a relative term here :) Jan 30 10:27:36 --> mxcarron (n=maxime@fedora/Pingoomax) has joined #fedora-meeting Jan 30 10:27:42 notting: :) Jan 30 10:28:06 I got an i686 in '98 ... Jan 30 10:28:17 yeah, my first was in '97 Jan 30 10:28:28 --> J5 (n=quintice@nat/redhat/x-9432fbbf87c974a4) has joined #fedora-meeting Jan 30 10:28:55 i see five +1's, so we've approved the architecture support feature. Jan 30 10:29:20 unrelated, it may lead to lots of queries in #fedora/etc about x86_64 kernels on i686 installs. Jan 30 10:29:21 and anybody can start i586 as secondary arch Jan 30 10:29:30 notting: this will require a mass rebuild? Jan 30 10:29:44 nirik: yep. and if we decide to undo it, will require another :/ Jan 30 10:29:45 yes, but a few other things on the agenda today will too. Jan 30 10:29:47 * davej gets ready to nuke the 586 kernel from orbit. Jan 30 10:29:49 nirik: I think we're already going to be doing one for the new gcc anyway. Jan 30 10:30:07 notting / bpepple: yeah, just want that all to get coordinated to have just the one. ;) Jan 30 10:30:16 exactly, wanted to make sure to get this approved/disapproved before we start the gcc4.4 mass rebiuld Jan 30 10:30:20 nirik: right. Jan 30 10:30:22 yep. Jan 30 10:30:39 .fesco 37 Jan 30 10:30:42 jds2001: #37 (Crash catcher - https://fedoraproject.org/wiki/Features/CrashCatcher) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/37 Jan 30 10:31:26 --> fbijlsma (n=fbijlsma@ip-77-25-165-204.web.vodafone.de) has joined #fedora-meeting Jan 30 10:31:32 <-- fbijlsma has quit (Remote closed the connection) Jan 30 10:31:40 <-- mitr (n=mitr@popelka.ms.mff.cuni.cz) has left #fedora-meeting ("Leaving") Jan 30 10:31:46 where are we on this, 10% looks worrisome. Jan 30 10:31:49 is CrashCatcher already in? or under review? or not yet written? Jan 30 10:31:52 --> kital (n=Joerg_Si@fedora/kital) has joined #fedora-meeting Jan 30 10:32:08 and how does it actually work, out of curiosity? Jan 30 10:32:11 it's in-progress Jan 30 10:32:20 yes, we already have some code Jan 30 10:32:24 (there's a lot more detail on the fedorahosted page) Jan 30 10:32:36 <-- iarlyy has quit (Read error: 113 (No route to host)) Jan 30 10:32:38 and we are abel to detect a crashing C program and show an systray icon Jan 30 10:32:44 *able Jan 30 10:33:01 * dgilmore is here Jan 30 10:33:17 I was trying to push it to fedorahosted today, but I had some difficulties with git :( Jan 30 10:33:17 notting: rpm correctly refuse to install i686 rpms Jan 30 10:33:37 dgilmore: are you running the i586 kernel at the time? Jan 30 10:34:01 crap, got side-tracked... tardy +1 to the arch change thing Jan 30 10:34:13 notting: whetever kernel olpc ships Jan 30 10:34:23 jmoskovc`: how usable is this going to be for f11? It sounds like you are in pretty early development... perhaps f12 would be a better target? Jan 30 10:34:24 notting: however the cpu is not i686 compatiable Jan 30 10:34:39 Hi, I don't mean to be difficult here, but are you aware that i686 only effectively kills LTSP clients? Jan 30 10:34:48 I didn't know this was being voted on. Jan 30 10:35:00 dgilmore: cjb says it works Jan 30 10:35:07 warren: sorry for the late agenda. Jan 30 10:35:08 notting: he is wrong Jan 30 10:35:23 nirik: we should be able to get backtrace from core dump and send it to BZ (or somewhere) Jan 30 10:35:29 jds2001: was it voted to drop i586 kernel and userspace or only kernel build? Jan 30 10:35:29 notting: there is a reason the rpm has a .geode rpm Jan 30 10:35:35 * nirik guesses this means we should revisit the i586 thing again? Jan 30 10:35:35 --> iarlyy (n=iarlyy@mail.libertynet.com.br) has joined #fedora-meeting Jan 30 10:35:44 notting: it sits between i586 and i686 Jan 30 10:35:52 yeah, lets go back :) Jan 30 10:35:53 warren: if we drop the kernel, there's no point in keeping the userspace around Jan 30 10:35:56 jmoskovc`: is there any filtering on that? or it just always sends them? Jan 30 10:35:59 notting: right Jan 30 10:36:03 the geode cpu is i586 + the cmov extention Jan 30 10:36:27 Are we dropping i586 builds because it was adding actual maintenance burden? Jan 30 10:36:27 how about we finish the CrashCatcher feature, and then go back Architecture feature? Jan 30 10:36:29 if we consider that to be i686 then rpm will need to be told so Jan 30 10:36:43 dgilmore: what specific instructions? as he's the XO/OLPC software guy, i figured he has a handle on it Jan 30 10:36:50 nirik: yes there will be (at least we'd like to have it), we're goign to have a mtg with tools team to help us with duplicate checking of coredumps Jan 30 10:37:04 bpepple: +1 Jan 30 10:37:13 notting: (looking back at the earlier conversation) stats wont include smolt reports from innumerable thin clients Jan 30 10:37:34 warren: innumerable is a meaningless number without stats, though Jan 30 10:37:39 notting: sure. Jan 30 10:38:09 +1 to CrashCatcher feature. Jan 30 10:38:22 --> zprikryl (n=zprikryl@ip4-83-240-81-87.cust.nbox.cz) has joined #fedora-meeting Jan 30 10:38:23 jmoskovc`: and would this be opt in or default? ie, would users need to go install CrashCatcher or are you saying it should be default installed? Jan 30 10:38:37 Hi Jan 30 10:38:39 * dgilmore wonders how it will report to Bugzilla Jan 30 10:38:50 especially when the user does not have an account? Jan 30 10:39:06 nirik: the main idea was to have it as default in alfas and betas Jan 30 10:39:15 --> drago01 (n=linux@chello062178124130.3.13.univie.teleweb.at) has joined #fedora-meeting Jan 30 10:39:22 * dgilmore likes the idea, but wonders how it will work in practice Jan 30 10:39:31 jmoskovc`: is there a package for it under review? it would need to be added into the collection, right? Jan 30 10:39:35 jds2001: will fesco go back to discuss i586? Jan 30 10:39:49 warren: sure, when we're done with crashcatcher Jan 30 10:39:55 jds2001: If this is a final vote, then LTSP and k12linux effectively ends with Fedora 10. Jan 30 10:39:58 dgilmore, you have to have a fedora account, anonymous reports will not be allowed Jan 30 10:40:09 dgilmore, bigzilla account Jan 30 10:40:14 zprikryl: fedora account doesnt mean bugzilla account Jan 30 10:40:29 zprikryl: they are dispariate systems Jan 30 10:40:31 nirik: ?? we dont have an rpm yet Jan 30 10:40:52 zprikryl: are we planning to make uses sign up for multiple accounts to use this system? Jan 30 10:41:00 s/uses/users/ Jan 30 10:41:19 jmoskovc`: well, I am just worried that this is too early for f11... we already have passed Alpha... I like the idea a lot, I just don't know if it's ready for this cycle. Jan 30 10:41:30 --> ChitleshGoorah (n=chitlesh@fedora/ChitleshGoorah) has joined #fedora-meeting Jan 30 10:41:37 nirik: me neither :) Jan 30 10:42:05 warren: so, k12linux only supports 10-year old hardware? Jan 30 10:42:20 s/only// Jan 30 10:42:22 notting: most of the hardware people are still using today are i586 Jan 30 10:42:23 I would prefer it to get developed in this cycle and all working, then we can add it in early in f12 and use it for alpha/beta there at least... Jan 30 10:42:28 nirik, jmoskovc: imho we can finish version 1.0.0 :-).... but it will be hard Jan 30 10:42:47 notting: and some of the top selling thin clients today are geode and another no-name brand of i586 Jan 30 10:42:48 I guess we could always do that later in this cycle if it's not ready. Jan 30 10:42:48 warren: *today*. so why would the project end? they'll be using better hardware tomorrow Jan 30 10:42:49 jmoskovc`: will it be in a testable state by the Beta? Jan 30 10:43:16 bpepple: beta is in March, right? Jan 30 10:43:20 http://fedoraproject.org/wiki/Releases/11/Schedule Jan 30 10:43:24 notting: the clients outlive the server since software bloat on the server doesn't necessarily mean the client doesn't work anymore. Jan 30 10:44:00 jmoskovc`: march 3rd is feature freeze. Jan 30 10:44:02 jmoskovc`: yeah, it would need to be in a testable state by March 3rd. Jan 30 10:44:08 so lets talk about one thing at a time. Jan 30 10:44:11 --> cebbert (n=cebbert@fedora/cebbert) has joined #fedora-meeting Jan 30 10:44:29 notting: I would suggest dropping i586 only for F12+, to give a chance for CentOS6 to have one usable release for legacy hardware to be usable for a number of years thereafter. Jan 30 10:44:30 lets get back to crashcatcher, finish that, and then we can talk about architecture support Jan 30 10:44:40 zprikryl: can wa make it? Jan 30 10:44:50 jmoskovc`, I think so Jan 30 10:45:00 --> mdomsch (n=Matt_Dom@cpe-70-124-62-55.austin.res.rr.com) has joined #fedora-meeting Jan 30 10:45:28 I'm fine with approving this, and if it's not in a testable state by Beta we push it to F12. Jan 30 10:45:33 if you guys think you can, I am +1... we can always bump back to 12 Jan 30 10:45:38 yeah Jan 30 10:45:45 +1 here, review at Beta Jan 30 10:45:52 +1 to that as well Jan 30 10:46:00 +1 Jan 30 10:46:17 zprikryl / jmoskovc` : do remember to keep the feature page updated with your progress. ;) Jan 30 10:46:37 nirik: ok, we'll try :) Jan 30 10:46:37 +1 to crashcatcher Jan 30 10:46:42 nirik, ok ok :-) Jan 30 10:47:06 i see five +1's, so we've approved the crashcatcher feature, and will review at beta. Jan 30 10:47:22 also you might get your rpm package into the review queue sooner rather than later... even if it's not too complete... so you can get it reviewed and in. Jan 30 10:47:33 ok, back to Jan 30 10:47:36 .fesco 36 Jan 30 10:47:39 jds2001: #36 (Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/36 Jan 30 10:48:15 Key question here... Jan 30 10:48:18 * nirik thanks zprikryl and jmoskovc` for coming and providing us info. Jan 30 10:48:26 Is i586 creating actual maintenance burden? Jan 30 10:49:02 so, while the geode cpu is i586 +cmov extention. it is technically not i686, but can run i686 optimised code as long as the only cpu extention used is cmov. Jan 30 10:49:10 by keeping i586 in the kernel it's adversely affecting performance for the majority of our users. Jan 30 10:49:29 so i just booted my xo into fedora Jan 30 10:49:37 it's an extra kernel, extra glibc, openssl, etc. builds. it pessimizes some bits of performance, it causes arguments on the mailing lists from people who think fedora should target older cpus (i'd argue that's not part of our mission) Jan 30 10:49:39 --- stickster_mtg is now known as stickster Jan 30 10:49:43 OLPC shoves i686 glibc and openssl on at image compose time. they are never upgradeable Jan 30 10:49:56 it claims it is Linux localhost.localdomain 2.6.27.5-94.fc10.i686 #1 SMP Mon Nov 10 15:51:55 EST 2008 i586 i586 i386 GNU/Linux Jan 30 10:50:20 jds2001: because it technically is i586 Jan 30 10:50:34 jds2001: but a big feature of i686 is cmov which the geode has Jan 30 10:50:50 it just doesnt have the rest of the cpu instructions added in i686 Jan 30 10:51:21 we can make rpm install i686 rpms on a geode Jan 30 10:51:42 oh, all RPMS will be rebuilt to .i686.rpm as well? Jan 30 10:52:04 im scared that we will end up using instructions that just wont work on a geode cpu Jan 30 10:52:25 we could also build everything .i586 and .i686 but the mirrors will kill us Jan 30 10:52:25 dgilmore: but if glibc and openssl don't (and they're built with -march=i686), why would other things randomly? Jan 30 10:52:37 notting: corner cases Jan 30 10:53:01 notting: and more likely with things the use multimedia based instructions Jan 30 10:53:25 things that use multimedia instructions that aren't using run-time tests are already broken, as you have different ones for amd and intel Jan 30 10:53:55 dgilmore: Are you saying that OLPC builds glibc and openssl as -march=i586 and makes them nonupgradable or that they test the specifc i686 versions and then make those non-upgradable. Jan 30 10:54:10 --> neverho0d (n=psv@vpn-pool-78-139-211-172.tomtel.ru) has joined #fedora-meeting Jan 30 10:54:19 notting: will optimising for i686 though turn off support for i586 checking Jan 30 10:54:34 shouldn't... you have to do this stuff by hand anywaty Jan 30 10:54:40 abadger1999: im saying they shove fedora's i686 glibc and openssl packages in Jan 30 10:54:56 abadger1999: and rpm correctly refuses to update the rpms Jan 30 10:55:10 ah okay. Jan 30 10:56:17 --> ffesti_ (n=ffesti@e179167053.adsl.alicedsl.de) has joined #fedora-meeting Jan 30 10:56:21 What exactly was voted upon earlier? Jan 30 10:56:27 <-- jmoskovc` has quit ("Leaving") Jan 30 10:56:32 kernel/glibc/openssl only? Or all packages become i686.rpm? Jan 30 10:56:34 warren: um, read the feature page? Jan 30 10:56:39 warren: https://fedoraproject.org/wiki/Features/ArchitectureSupport Jan 30 10:56:40 https://fedoraproject.org/wiki/Features/ArchitectureSupport Jan 30 10:56:48 i think that there will be cases where fedora on the XO will blow up if its i686 only. Jan 30 10:56:56 but without trying we will not know Jan 30 10:57:11 warren: the feature is for all packages Jan 30 10:57:16 warren: All packages. basically changes to default compiler flags Jan 30 10:57:30 so I assume adding a .i586 repo/branch/etc would be beyond pain? Jan 30 10:57:38 nirik: yes. Jan 30 10:57:56 nirik: yeah, the mirrors would probably revolt. ;) Jan 30 10:58:00 nirik: effectively secondary arch Jan 30 10:58:27 nirik: we could have koji build everything for .i686 and .i586 and we could even not push the i586 and have it for a fall back in case things go bad Jan 30 10:58:54 but mirrors would be really really mad if we added all the i586 and i686 content Jan 30 10:59:02 * nirik runs a mirror and wouldn't care... but yeah, I'm sure some would. Jan 30 10:59:25 I understand the benefits of doing this, I am just pointing out that the smolt statistics do not even come close to representing the scope of fedora hardware we will no longer be able to support. Jan 30 10:59:58 this is just as bad as deciding to release only DVD images Jan 30 11:00:07 well, I still think that i586 as secondary arch is doable Jan 30 11:00:23 cebbert: as kernel maintainer you don't mind building i586? Jan 30 11:00:24 sharkcz: its totally doable Jan 30 11:01:14 hell, i586 probably has a better chance of flying as a secondary arch than any other currently-being-attempted secondary arch Jan 30 11:01:29 warren: is there some subset of packages that lstp uses? ie, not everything just X server/kernel? or ? Jan 30 11:01:37 warren: I proposed we get rid of the 686 kernel and have only 586 and PAE kernels for 32-bit Jan 30 11:01:44 cebbert: huh? Jan 30 11:01:49 nirik: generating list Jan 30 11:02:25 cebbert: 686 <=> 586 ?? Jan 30 11:02:33 i686 w/pae -> kernel-PAE Jan 30 11:02:42 i586 and i686 w/o pae -> kernel.i586 Jan 30 11:02:46 i would like to see a fall back plan if .i686 optimisation fails on the gedoe Jan 30 11:03:02 dgilmore: it's in the contingency section of the feature page Jan 30 11:03:23 Could we please reconsider dropping i586 for F12 instead? I mean, why now? Jan 30 11:03:24 dgilmore: is there any way to test that without commiting ourselves? "some things might break" doesn't sound easy to test. Jan 30 11:03:26 --> hpachas-PE (n=hpachas@200.37.120.18) has joined #fedora-meeting Jan 30 11:03:37 sorry about the process question, but how long do these fesco meeting last normally? (waiting for our feature to be discussed before going to dinner) Jan 30 11:03:50 notting: id like something inbetween Jan 30 11:03:50 mjw: 1 to 2 hours. Jan 30 11:03:54 mjw: 2 hours, but what feature is that? Jan 30 11:03:57 mjw: 2 hours... but we have a full schedule, so who knows? Jan 30 11:04:17 notting: like building .i686 and .i586 but ignoring the .i586 until we determine its needed Jan 30 11:04:20 <-- zprikryl has quit ("Leaving") Jan 30 11:04:26 41, systemtap static probes. But I can stay it out another hour. OK. Jan 30 11:04:40 So...Jakub's original email was very keen to move to -march=i486 but gave -march=i586 asan option. Jan 30 11:04:45 dgilmore: that sounds painful Jan 30 11:04:47 mjw: we can do that next, should be fast i think. Jan 30 11:04:50 Why not -march=i486? Jan 30 11:05:20 abadger1999: hmm, something must have changed, it was his team years ago that said i386 instructions with i686 optimized code was faster than i586. Jan 30 11:05:32 warren: I think that was -mtune Jan 30 11:05:36 Rather than -march Jan 30 11:05:53 nod Jan 30 11:05:55 But I could be misremembering. Jan 30 11:06:26 dgilmore: would building i586 and i686 for everything add a burden to storage and build servers? Jan 30 11:06:30 or gcc did changed Jan 30 11:06:49 Jakub's message: https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01661.html Jan 30 11:06:54 * warren reads Jan 30 11:06:54 --> cwickert (n=chris@fedora/cwickert) has joined #fedora-meeting Jan 30 11:07:10 <-- kulll_ has quit ("Leaving") Jan 30 11:07:15 warren: yes Jan 30 11:07:40 warren: it is effectively adding another arch Jan 30 11:07:42 --> kulll (n=kulll@203.82.91.34) has joined #fedora-meeting Jan 30 11:08:02 Has FESCO considered Jakub's recommendation of -march=i486 or i586 instead of this? Jan 30 11:08:26 That seems to be very reasonable, not a burden on infrastructure, and wont break geode. Jan 30 11:08:43 I mean Jakub recommended this for a reason? Jan 30 11:09:18 --> CheekyBoinc (n=CheekyBo@fedora/CheekyBoinc) has joined #fedora-meeting Jan 30 11:10:08 because fedora is about providing the latest free and open source software, and being a platform for innovation, and you don't innovate by pessimising for 10-year-old hardware? Jan 30 11:10:13 https://bugzilla.redhat.com/show_bug.cgi?id=200330 Jan 30 11:10:14 Bug 200330: high, medium, ---, jakub@redhat.com, CLOSED RAWHIDE, i686 openssl broken on AMD Geode Jan 30 11:11:28 notting: 10 year old is an improvement over the current 15 or 20 year old? Jan 30 11:12:07 notting: Well.... you do when the latest software is meant to take old, obsolete hardware and turn it into a productive, cost-saving computing environment for your school. Jan 30 11:12:07 So finding a way to support scrap hardware no longer supported by Microsoft or Apple is explicitly not an innovation? Jan 30 11:12:11 i486 or i586 for all packages sounds very reasonable. Could we please consider this for F11 and reconsider for F12? Jan 30 11:12:36 --> sdziallas (n=sebastia@p57A2E311.dip.t-dialin.net) has joined #fedora-meeting Jan 30 11:12:45 notting: how much benifit do we loose doing that? just i586 instead of i686? and drop i586 in f12? Jan 30 11:12:54 notting: many popular thin clients selling today are still not i686, due to very low per-unit cost when they buy thousands... Jan 30 11:12:57 abadger1999: but is Fedora the best choice for that? Jan 30 11:13:01 ... why does leaving i586 in f11 help? Jan 30 11:13:20 (rhel5 does not ship a i586 kernel. rhel6 certainly won't) Jan 30 11:13:47 <-- SmootherFrOgZ has quit (Read error: 60 (Operation timed out)) Jan 30 11:13:55 How does RHEL come into this? Jan 30 11:13:57 warren: what cpu's typically are they using? Jan 30 11:14:17 true I guess... it does allow more time for 'upgrade your hardware or switch distros', but there will always be some that won't. Jan 30 11:14:32 bpepple: Well... when I was working on ltsp I certainly wanted to run Fedora on them :-) Jan 30 11:14:52 * jds2001 notes that CentOS5 *does* ship an i586 kernel. Jan 30 11:15:07 tibbs|h: " notting: I would suggest dropping i586 only for F12+, to give a chance for CentOS6 to have one usable release for legacy hardware ..." Jan 30 11:15:07 I would guess due to folks wanting it? Jan 30 11:15:13 davej: Vortex86 System on Chip (video and CPU and motherboard chipsets all on one die) at the low end and Geode GX2 or Geode LX. Jan 30 11:15:23 abadger1999: yeah, but I always thought CentOS or RHEL with longer support cycles worked better for those types of installations. Jan 30 11:16:21 bpepple: Usually, people wanted newer end-user apps.... the labs are desktop machines.... just run as thin clients. Jan 30 11:16:51 bpepple: Thin clients tend to out live the servers. Jan 30 11:16:51 http://wiki.laptop.org/go/Geode_instruction_set Jan 30 11:16:53 abadger1999: then the thin clients can still run an older release Jan 30 11:16:57 bpepple: So we tried the CentOS based ltsp but customers were interested in Fedora or Ubuntu on the thin client. Jan 30 11:17:07 notting: the current older release has kernel and X drivers from 2004. Jan 30 11:17:31 abadger1999: yeah, I guess I'm projecting what I'd be willing to support if I was in charge of installing that. ;) Jan 30 11:18:06 abadger1999: wait, they wanted newer end-user apps, so they wanted the thin client base to be newer? that makes no sense (or they misunderstand how thin clients work) Jan 30 11:18:21 -march=i586 minimum is an improvement in of itself. Jan 30 11:18:22 --> spoleeba (n=one@fedora/Jef) has joined #fedora-meeting Jan 30 11:18:24 warren: you want to have both client and server side be the same Fedora? Jan 30 11:18:28 warren: if you hardware is that old....? Jan 30 11:18:53 dgilmore: that implies that -march=i686 should work, if the base CPU insn set is i686/ppro Jan 30 11:19:35 notting: yes. but ive been told in the pas that is not true. and the cpu itself says its not true. as does the bugrepot i posted earlier Jan 30 11:19:55 notting: i think we need to get a more definitive answer Jan 30 11:20:01 warren: Please correct me if I'm wrong... the current ltsp build system builds the ltsp client from the current server packages, yes? Jan 30 11:20:08 abadger1999: yes Jan 30 11:20:18 abadger1999: chroot is installed from the same fedora repo Jan 30 11:20:29 dgilmore: which was fixed, and shouldn't be an issue. interetsingly, it also says "In our benchmarking tests using the EEMBC benchmark, -march=i686 scored the highest" Jan 30 11:21:20 --- laubersm is now known as laubersm_afk Jan 30 11:21:29 notting: So that's the problem. In the olden days, the ltsp client and ltsp server could have been separated but these days, the ltsp build infrastructure ties them together at one level. Jan 30 11:22:17 <-- fab has quit (Remote closed the connection) Jan 30 11:22:20 old LTSP had its own glibc, kernel and userspace built from source tarballs to build the chroot. Basically Linux from scratch. They abandoned that in favor of building the chroot from the distro's own packages. Jan 30 11:22:54 notting: RHEL6 will rebuild all packages to i686.rpm? Jan 30 11:23:02 --> fab (n=bellet@bellet.info) has joined #fedora-meeting Jan 30 11:23:18 warren: don't know. but if they're only building an i686 kernel, why wouldn't they? Jan 30 11:23:52 warren: would there be enough interested people in the lstp community to get i586 running as a secondary arch? Jan 30 11:23:58 We didn't build everything with -march=i486 even though the kernel only supports 486+ Jan 30 11:24:38 * abadger1999 notes only 40 minutes left.... Jan 30 11:25:13 yeah, we need to resolve this. There's still a lot on the agenda. Jan 30 11:25:21 want to table this for next week and have more discussion? Jan 30 11:25:26 notting: +1 Jan 30 11:25:37 Mass rebuild needs to block on this. Jan 30 11:25:38 notting: +1. More info on olpc would be good. Jan 30 11:25:42 nirik: I decided in this past week that I achieved my goal with LTSP in Fedora and I'm moving on to other parts of the distro to prepare for RHEL6. LTSP will only pull upstream changes into Fedora from now on. I'm training an upstream developer to do fedora packaging. (I could use another Fedora developer to help survise.) It was my intent to let it coast in maintenance mode into a CentOS6 release which was the goal of my past year. Jan 30 11:25:49 Just so people are aware of that too. Jan 30 11:26:02 abadger1999: correct. Jan 30 11:26:23 I think the gcc stuff isn't ready for the rebuild yet either. Jan 30 11:26:24 there is one problem with this some people install 32bit because they want to use 32bit kernel modules (binary only stuff or ndiswrapper) Jan 30 11:26:49 but they can just install kernel.i686 from the repos Jan 30 11:27:18 nirik: CentOS6 based LTSP will likely be the last long term support release of this decade old design. If it has i586 kernel, then it can support pretty much all usable thin client hardware from the beginning of LTSP through modern intel/radeon supported by Fedora's modern drivers (modulo bugs). Jan 30 11:27:38 drago01: i am... not concerned... about those users Jan 30 11:27:48 nirik: So I suppose someone will go through the effort of rebuilding all RHEL6 packages as i586 for this, but it wont be well maintained therefter. Jan 30 11:28:13 drago01: other people may feel differently, i'm sure Jan 30 11:28:25 warren: rhel5 didn't support i586 Jan 30 11:28:26 notting: yeah and there is a workaround , but might be worth adding to the rel notes Jan 30 11:28:31 jds2001: I know. Jan 30 11:28:33 ok, let's table this for now, and bring the discussion to the mailing list, and plan to make a decision at next week's meeting. Jan 30 11:28:40 warren: the i586 support in centos5 was done by centos. Jan 30 11:28:48 jds2001: but the feasibilty of doing it is very different if all packages are i686. Jan 30 11:29:03 warren: understood :) Jan 30 11:29:21 If RHEL6 has decided on i686 everywhere then I don't care what Fedora 11 decides. Jan 30 11:29:25 well, there may be enough interest for those folks to make a i586 secondary arch... time will tell. Jan 30 11:29:51 * nirik has no idea what RHEL6 will do. Jan 30 11:30:06 ok, let's table this for now, take discussion back to the last, discard the previous vote. Jan 30 11:30:16 sound reasonable? Jan 30 11:30:19 fesco's private list? Jan 30 11:30:29 no, of course not. Jan 30 11:30:45 fedora-devel ? Jan 30 11:30:49 yeah Jan 30 11:30:50 warren: devel list should be fine, though I'm sure there will be a lot of noise about it. Jan 30 11:31:34 alrighty. sorry about the disruption. Jan 30 11:31:45 I totally understand the desire and benefits of this. Jan 30 11:31:50 alright, let's get the systemtap folks able to eat dinner :) Jan 30 11:32:02 .fesco 41 Jan 30 11:32:07 jds2001: #41 (SsytemTap Static Probes - http://tinyurl.com/btqjno) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/41 Jan 30 11:32:12 warren: np. Jan 30 11:32:39 sorry, be back in 5-10. question - you have to patch your userspace to support this? Jan 30 11:33:00 --> fche (n=fche@elastic.org) has joined #fedora-meeting Jan 30 11:33:03 yeah, you have to put .d files in aiui Jan 30 11:33:14 notting, yes, a user space package needs to be recompiled to support it. Jan 30 11:33:58 just recompile, or put instrumentation in and recompile? Jan 30 11:34:10 the instrumentation is already in there - we just need to activate it Jan 30 11:34:11 mjw: are you going to have this testable by feature freeze? still at 5%? Jan 30 11:34:16 So, we will be providing patches for packages that want to support it. For example for postgres to support this we will supply a patch for the spec file to add BuildRequires: systemtap-sdt-devel and a configure --enable-dtrace Jan 30 11:34:51 nirik, yes, we certainly plan to. Jan 30 11:35:00 right, but package foo with function bar() we won't be able to trace bar() Jan 30 11:35:08 without doing something special to the foo package Jan 30 11:35:25 or am i misunderstanding? Jan 30 11:35:50 Put in 5% since we need to get a new system upstream release and put the new subpackage systemtap-sdt-devel in first. Jan 30 11:36:03 We have some test builds (outside the repo of course) already though. Jan 30 11:36:11 jds2001, yes, you misunderstand :) Jan 30 11:36:12 cool. +1 from me. Jan 30 11:36:13 jds2001, this is for static instrumentation that upstream developers have already put into their code Jan 30 11:36:24 jds2001, That is actually already possible with fedora 10! Jan 30 11:36:26 jds2001, we can already do dynamic instrumentation via debuginfo Jan 30 11:36:27 +1 from me also. Jan 30 11:36:52 http://gnu.wildebeest.org/diary/2008/11/27/observe-systemtap-and-oprofile-updates/ Jan 30 11:37:02 +1 Jan 30 11:37:05 +1 Jan 30 11:37:06 ^ fedora 10, doing simple user space tracing. Jan 30 11:37:07 fche: awesome, the last time I used stap it was for kernel stuff Jan 30 11:37:10 +1 from me. Jan 30 11:37:18 But that is on function level. Jan 30 11:37:34 +1 Jan 30 11:37:50 i see six +1 Jan 30 11:37:52 <-- londo_ has quit (Remote closed the connection) Jan 30 11:38:02 This feature is about adding support on a higher level in applications itself, by reusing upstream dtrace marker support and enabling systemtap to recognize it. Jan 30 11:38:10 so we've approved the SystemTap static probes feature Jan 30 11:38:13 * mjw stops hyping then :) Jan 30 11:38:18 mjw: hotness, thx :D Jan 30 11:38:46 no way we're going to get to nearly everything on the agenda. Jan 30 11:39:00 but this is going to stack up into a pile o' doom. Jan 30 11:39:02 thanks guys Jan 30 11:39:03 mjw: thanks for taking the time to answer our questions. Jan 30 11:39:22 thanks for coming mjw / fche Jan 30 11:40:02 i guess i'll move on to a feature that we need to approve today or doom happens. Jan 30 11:40:07 .fesco 42 Jan 30 11:40:09 jds2001: #42 (GCC 4.4 - https://fedoraproject.org/wiki/Features/gcc4.4) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/42 Jan 30 11:40:17 jds2001: lets try and get thru a few more, and then if need be we can do a special session next week? Jan 30 11:40:44 nirik: sounds good Jan 30 11:41:28 +1 to gcc feature. Jan 30 11:41:30 +1 here, but again, lets do only the one mass rebuild once we have in all the things that require it. ;) Jan 30 11:41:43 yeah, that's why i wanted to get to it today Jan 30 11:41:43 +1 Jan 30 11:41:45 nirik: agreed. Jan 30 11:42:02 +1 Jan 30 11:42:02 +1 Jan 30 11:42:08 +1, but we can't do a mass rebuild without closing out the other feature Jan 30 11:42:18 right Jan 30 11:42:23 * nirik nods Jan 30 11:43:04 --> cjb (n=cjb@pullcord.laptop.org) has joined #fedora-meeting Jan 30 11:43:13 i see 6 +1's, so we've approved the GCC4.4 feature. The mass rebuild will wait until Architecture Support is worked out. Jan 30 11:43:35 cjb: the topic was tabled for reconsideration next week, too much indecision this week Jan 30 11:44:08 Hi, warren mentioned you are/were talking about i586. I asked our Geode expert at AMD, who says that OLPC's LX should be compatible with 686 instructions. (And that seems borne out by when we've booted standard Fedora media on the XO.) Jan 30 11:44:11 warren: okay, great Jan 30 11:44:34 <-- markmc has quit ("Leaving") Jan 30 11:44:45 cjb: thanks for the update. Jan 30 11:44:47 cjb: discussion on this topic should be on fedora-devel-list until the next meeting. Jan 30 11:44:53 so, my input as OLPC software dude is that we're probably okay with dropping 586, but it would be great if someone heled us test that everything's looking okay first. I can't get Rawhide to boot on an XO at the moment. Jan 30 11:44:55 Jan 30 11:45:02 or rather, . :) Jan 30 11:45:11 anything else we absolutely need to cover this week? Jan 30 11:46:04 jds2001: when is our deadline for approving features? Jan 30 11:46:17 well, I was hoping we would hit on renaming and ovm, but oh well, if we don't have time we don't. Jan 30 11:46:18 feature freeze, 3/3 iirc Jan 30 11:46:43 nirik: yeah, i thought renaming would be a long protracted thing. Jan 30 11:46:49 good, couldn't remember what it was. Jan 30 11:46:51 it could be. Jan 30 11:46:53 should we hit the non-feature thing about vmware? Jan 30 11:46:59 yeah, and ovm Jan 30 11:47:27 .fesco 35 Jan 30 11:47:29 jds2001: #35 (vmware-requirements, and other 'crutch-for-proprietary-software' packages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/35 Jan 30 11:48:32 so this was a review request for a metapackage to pull in vmware's requirements. Jan 30 11:48:39 IMO it's rpmfusion stuff Jan 30 11:48:44 i guess the question is if we want to allow such things. Jan 30 11:48:57 yeah, I'm leaning the same way. Jan 30 11:49:20 jds2001: /me says no Jan 30 11:49:42 * notting votes -1 to it ... we should not be adding packages solely to deal with broken third-party packages Jan 30 11:49:46 * nirik also says no too Jan 30 11:49:50 -1 here also. Jan 30 11:49:53 -1 Jan 30 11:49:56 -1 Jan 30 11:49:57 just to be clear Jan 30 11:50:19 -1 here Jan 30 11:50:50 i see five -1,'s so we will not allow the vmware-requirements package into Fedora. Jan 30 11:51:08 Is this a specific rejection of this package, or a general rejection of the concept? Jan 30 11:51:35 * notting was voting -1 to the concept. not speaking to metapackages in general, though Jan 30 11:51:35 good question. Jan 30 11:51:43 Could we perhaps get a guideline, or should these things be examined on a case-by-case basis? Jan 30 11:52:14 I guess the question is: Does something like this "enhances the OS user experience" or not. Jan 30 11:52:21 i think case-by-case. Jan 30 11:52:22 * dgilmore thinks that any meta-package that has the goal of fixing brokenness in 3rd party packages is a nogo Jan 30 11:52:23 * bpepple was also voting -1 to the concept. Jan 30 11:52:30 * jds2001 too. Jan 30 11:52:48 3rd party packages shouldn't be "fixed" by Fedora, IMO Jan 30 11:52:59 I say no, because we should consider our user experence to be based on our packages/free software, not any 3rd party thing we don't ship. Jan 30 11:53:03 but metapackages I think we'd have to visit case-by-case. Jan 30 11:53:07 if that makes sense. Jan 30 11:53:13 Though to play devil advocate, haven't we shipped some stuff to fix flash? Jan 30 11:53:26 bpepple: iirc, fesco voted to drop that Jan 30 11:53:27 jds2001: i know we have one for fedora-ds Jan 30 11:53:37 notting: ah, forgot. Jan 30 11:53:43 I think metapackages is another discussion... Jan 30 11:53:48 it is. Jan 30 11:54:08 generally metapackages probbaly should be fixed by adding a comps group Jan 30 11:54:13 so the guideline would be "no packages to fix 3rd party packages brokeness" Jan 30 11:54:24 jds2001: +1 Jan 30 11:54:33 if so, then that answers the ovm thing as well, right? Jan 30 11:54:48 not really, i dont think. Jan 30 11:55:14 ok, lets take that seperate. Sorry for derailing things. Jan 30 11:55:25 well, we're done here. Jan 30 11:55:43 .fesco 13 Jan 30 11:55:45 jds2001: #13 (FESCo needs to determine whether ovm is acceptable content) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/13 Jan 30 11:55:52 nirik: i think our guidelines are very clear for ovm. we need some free tool to use the data in. Jan 30 11:56:30 thats what I thought as well... but I was confused to what we really agreed to. Jan 30 11:56:38 yeah, we have iverilog right now. https://admin.fedoraproject.org/pkgdb/packages/name/iverilog Jan 30 11:56:46 jds2001: but it can't use it, can it? Jan 30 11:56:54 I really do not understand why they object so stronly to getting iverilog in Jan 30 11:56:54 supposedly this thing has some hope of working with iverilog, but it can't use it *right now* Jan 30 11:57:22 and from what I saw from the link that was posted, iverilog upstream has higher priorities than supporting this content. Jan 30 11:57:42 I think that provides somewhat of a bad user experence if we allow ovm in now. Jan 30 11:58:07 yeah, "hey look at this neat thing! Oh wait, I can't actually use it" Jan 30 11:58:13 yum install ovm iverlog. 'oh, it doesn't work.' I need to go buy $EXPENSIVE tool Jan 30 11:59:04 <-- kulll has quit (Read error: 110 (Connection timed out)) Jan 30 11:59:32 so we have nothing that can use it, nothing that appears to be on the way to being able to use it. Jan 30 11:59:54 --> kulll (n=kulll@203.82.91.34) has joined #fedora-meeting Jan 30 12:00:26 --> openpercept (n=openperc@117.199.112.16) has joined #fedora-meeting Jan 30 12:00:34 so, where are we? (aside from over time)? anyone have any other thoughts? Jan 30 12:00:53 jds2001: i propose that we continue to not allow it in. that when it can be used with free tools in some capacity we will warmly welcome it then. Jan 30 12:01:03 dgilmore: +1 Jan 30 12:01:07 +1 Jan 30 12:01:27 +1 Jan 30 12:01:29 +1 Jan 30 12:01:36 <-- openpercept (n=openperc@unaffiliated/openpercept) has left #fedora-meeting Jan 30 12:02:42 +1 Jan 30 12:03:23 i see five +1's (well six assuming dgilmore votes for his own proposal), so we continue to not allow ovm until some suitable consumer is in Fedora. Jan 30 12:03:31 yes im +1 Jan 30 12:03:47 <-- kulll has quit (Client Quit) Jan 30 12:04:11 alright, what times are folks available next week for a special session to clear this monstrosity of an agenda? Jan 30 12:04:51 hold on call from $DAYJOB Jan 30 12:05:12 jds2001: this time +-1 hour any day Jan 30 12:05:43 <-- cjb (n=cjb@pullcord.laptop.org) has left #fedora-meeting ("ERC Version 5.3 (IRC client for Emacs)") Jan 30 12:06:17 jds2001: Any day next week works for me. Jan 30 12:06:42 --> balor (n=balor@gimili.plus.com) has joined #fedora-meeting Jan 30 12:06:43 OK, I'll throw something out on the fesco list and try and work out a time. Jan 30 12:06:44 * nirik is mostly open as well... Jan 30 12:06:50 how about tuesday? Jan 30 12:06:52 mon 10-12, tues noon-2.. Jan 30 12:07:01 both are bad for me. Jan 30 12:07:15 * jds2001 is available wednesdays and fridays, most of the time. Jan 30 12:07:17 wed? Jan 30 12:07:31 --> kulll (n=kulll@203.82.91.34) has joined #fedora-meeting Jan 30 12:07:39 i have physical therapy from ~11-2 on monday, tuesday thursday Jan 30 12:07:46 <-- CheekyBoinc has quit ("Use Fedora Linux -> fedoraproject.org ++ www.cheekyboinc.de ++") Jan 30 12:07:49 wednesday works for me, any point after 11est Jan 30 12:08:37 ^ works for me also. Jan 30 12:08:39 alright Jan 30 12:08:59 * jds2001 will sned something out for wednesday Jan 30 12:09:00 * nirik is fine with that Jan 30 12:09:13 there is an empty slot on Wed ;-) Jan 30 12:09:20 i cant do wedesday Jan 30 12:09:31 oh, right - forgot about that. Jan 30 12:09:57 * notting can also do monday after 2pm/releng, but that's probably a bit late for sharkcz Jan 30 12:10:29 i cant do monday or thursday either Jan 30 12:10:38 how about friday at 12EST? Oh, wait. Jan 30 12:10:50 actually can do thusday Jan 30 12:10:57 helps to look at the right calander Jan 30 12:11:36 we'll work it out on the list. Jan 30 12:11:50 Hopefully have atime by monday so I can announce it. Jan 30 12:12:13 nirik: you got the summary, just as a reminder :) Jan 30 12:12:36 * jds2001 ends the meeting in 5 Jan 30 12:12:44 -- MEETING END -- Jan 30 12:12:53 yep. Been writing it up as we go... will send it out in a few here. Jan 30 12:12:55 thanks for coming to a long meeting :) Jan 30 12:13:09 whoops. i was just going to suggest that for future meetings we do non-feature things before features ,just to make sure they get handled Jan 30 12:13:34 notting: we can do that. I was just following bpepple's format :D Jan 30 12:13:38 yeah, I think thats a good idea... some of them could be more pressing.