=================================== #fedora-meeting: FESCO (2010-06-08) =================================== Meeting started by nirik at 19:30:07 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-06-08/fesco.2010-06-08-19.30.log.html Meeting summary --------------- * init process (nirik, 19:30:07) * notting kylem and cwickert all said they will be unable to attend today. (nirik, 19:30:41) * #351 Create a policy for updates - status report on implementation (nirik, 19:34:07) * LINK: https://fedoraproject.org/wiki/Package_update_acceptance_criteria (nirik, 19:36:04) * lmacken is working on a new bodhi version this week that will have the important packages and (possibly) the all other updates section implemented. (nirik, 19:39:10) * #385 Zim / zim package issues. (nirik, 19:40:29) * #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13 (nirik, 19:41:55) * ACTION: SMParrish will contact gcc maintainer and see what possible solutions to this problem are. (nirik, 20:08:44) * #388 request for e2fsprogs-libs-static (nirik, 20:10:15) * LINK: https://fedorahosted.org/fesco/ticket/388 (nirik, 20:10:15) * AGREED: yaboot can statically link here. (nirik, 20:13:09) * #391 F14Feature: MultipathInstall https://fedoraproject.org/wiki/Features/MultipathInstall (nirik, 20:13:28) * AGREED: feature is approved. (nirik, 20:15:06) * #390 F14Feature: LZMA_for_Live_Images https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images (nirik, 20:15:39) * AGREED: Feature is approved. (nirik, 20:18:34) * #392 F14Feature: https://fedoraproject.org/wiki/Features/libjpeg-turbo (nirik, 20:18:44) * AGREED: Feature is approved. (nirik, 20:23:19) * LINK: http://atkac.fedorapeople.org/libjpeg-turbo/libjpeg-turbo.spec (nirik, 20:24:34) * FES ticket updates - https://fedorahosted.org/fedora-engineering-services/report/6 (nirik, 20:25:57) * LINK: https://fedorahosted.org/fedora-engineering-services/ticket/24 that one (mmcgrath, 20:26:56) * #382 Implementing Stable Release Vision (nirik, 20:31:46) * LINK: https://fedorahosted.org/fesco/ticket/382#comment:6 (nirik, 20:32:27) * LINK: https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas (nirik, 20:47:57) * Open Floor (nirik, 20:49:28) Meeting ended at 20:54:26 UTC. Action Items ------------ * SMParrish will contact gcc maintainer and see what possible solutions to this problem are. -- 19:30:07 <nirik> #startmeeting FESCO (2010-06-08) 19:30:07 <zodbot> Meeting started Tue Jun 8 19:30:07 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:07 <nirik> #meetingname fesco 19:30:07 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:07 <nirik> #topic init process 19:30:07 <zodbot> The meeting name has been set to 'fesco' 19:30:07 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:28 <pjones> jola. 19:30:41 <nirik> #info notting kylem and cwickert all said they will be unable to attend today. 19:30:49 <mjg59> Afternoon 19:31:42 * nirik waits to see if we have quorum. ;) 19:32:25 * SMParrish here 19:32:41 <ajax> if i say i'm not here, can we skip it? 19:32:42 <nirik> ok, thats 5 at leasy. 19:32:59 * nirik can't type today. 19:33:06 <pjones> I'm definitely not here. No way no how. 19:33:12 <pjones> I'm someplace else. Probably at home. 19:33:40 <nirik> cool. Since pjones isn't here lets assign everything to him. ;) 19:33:58 <pjones> good luck with that ;) 19:34:07 <nirik> #topic #351 Create a policy for updates - status report on implementation 19:34:08 <nirik> .fesco 351 19:34:10 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 19:34:28 <nirik> so, I talked with lmacken... hopefully we can get something pushed out later this week... 19:34:34 <mjg59> \o/ 19:34:36 <pjones> yay 19:34:40 <nirik> for the critpath at least. 19:34:40 * mclasen walks in 19:34:56 <nirik> lmacken: does that include the other 2 tickets I filed... ? 19:35:16 <lmacken> nirik: potentially... I need to give them a Good Hard Look first. 19:35:31 <nirik> ok. 19:35:50 <nirik> I take it no one objects to implementing critpath and the 3rd section before autoqa is ready to land? 19:36:04 <nirik> https://fedoraproject.org/wiki/Package_update_acceptance_criteria 19:36:48 <mclasen> nirik: whats the 3rd section ? All other updates ? 19:37:17 <nirik> the Updates to 'important' packages and All other updates sections. 19:38:08 <pjones> yeah, I'm for that. 19:38:17 * nirik is too. 19:38:28 <SMParrish> I'm ok with it 19:38:33 <mclasen> +1 19:39:10 <nirik> #info lmacken is working on a new bodhi version this week that will have the important packages and (possibly) the all other updates section implemented. 19:39:42 <nirik> ok, any other thoughts/input on this? or shall we move along? 19:40:04 <mjg59> Guess we can move on? 19:40:08 <mclasen> thanks to lmacking for working on this 19:40:12 <mclasen> err, lmacken 19:40:16 <mjg59> And yeah, definitely 19:40:25 <nirik> agreed. ;) 19:40:29 <nirik> #topic #385 Zim / zim package issues. 19:40:29 <nirik> .fesco 385 19:40:31 <zodbot> nirik: #385 (Zim / zim package issues.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/385 19:40:41 <nirik> I'm just going to note here that things seem to be moving on this ticket ok. 19:40:59 <nirik> The Current Zim maintainer is going to allow the new submitter to update to the new version with the existing Zim package. 19:41:07 <nirik> So, nothing to see here. moving on. ;) 19:41:29 <mclasen> great 19:41:33 <mjg59> Yup, I think we're done there 19:41:34 <pjones> toldja. 19:41:34 <nirik> I'd like to hold the "Implementing Stable Release Vision" ticket to the end since it's likely to have longer discussion... 19:41:37 <pjones> ;) 19:41:55 <nirik> #topic #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13 19:41:55 <nirik> .fesco 387 19:41:55 <zodbot> nirik: #387 (compile list of supported CPUs and react to recent loss of support for Geode LX on F13) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/387 19:42:08 <nirik> so, this looks unfortunate for XO folks. 19:42:17 <SMParrish> yes it is 19:42:43 <ajax> i've asked this before and never really gotten a good answer: why are primitive x86s not treated as a secondary arch? 19:42:46 <SMParrish> IMO probably to late to change things for F13 but would like to see it corrected for F14 19:43:13 <mjg59> Well, we're kind of limited by the code that gcc outputs 19:43:22 <nirik> ajax: because no one would do the work and they would just die I suspect? 19:43:30 <ajax> mjg59: -march=i386 is a pretty good control for that. 19:43:37 <pjones> nirik: and that's an argument against? ;) 19:43:38 <Guest62041> I investigated this last night, it CAN be changed for F13. See bug report https://bugzilla.redhat.com/show_bug.cgi?id=579838 19:43:45 <mjg59> ajax: Yeah, we could output for 586 and optimise for 686 19:43:49 <ajax> well, i486 since pthreads, but. 19:43:50 <mjg59> s/686/core 19:43:57 <Guest62041> All the executables are OK, only glibc is borked. 19:45:11 <nirik> so, a) get gcc changed b) get glibc changed to not use that instruction c) get the kernel emulation of that instruction working/added, d) say we don't support this cpu anymore. 19:45:45 <mjg59> Previous attempts to implement missing instructions in the kernel have generally not been accepted by upstream 19:45:59 <pjones> 3 of those require us to mandate that people do work when we really are in no position to ask that. 19:46:03 <mjg59> There's several easy and wrong ways to do it. I don't know that anyone's done it in an upstream acceptable way. 19:46:11 <Guest62041> re a), this doesn't appear to be a gcc issue. gas is generating NOPL for .align opcodes, probably because the glibc build told it we were building for i686. 19:46:20 <SMParrish> (d) is not an option. Sugar has too much invested in working with Fedora for the XO-1 19:47:01 <pjones> c's pretty much a nonstarter. that leaves 'b', which sounds like loads of fun. 19:47:06 <mclasen> If it is just glibc, would a custom glibc build for olpc be an option ? 19:47:20 <mjg59> SMParrish: Well, I think (d) is certainly an option at our level. I'd think that it's the board's responsibility to determine whether supporting a third party is worth making technical compromises. 19:47:28 <nirik> yeah, upstream kernel or upstream glibc... which would more likely accept a fix? :) 19:47:45 <mjg59> Well, we could build glibc with different options 19:47:47 <Guest62041> olpc wants to be able to use the standard Fedora repos. 19:48:01 <mclasen> well, we are not talking about upstream fixes but about build configuration, no ? 19:48:07 <pjones> yeah, which is something we should try to encourage, not inhibit. 19:48:15 <SMParrish> mjg59: Fedora has alot invested with the Sugar folks as well. RH was on original sponsor of the program 19:48:19 <mjg59> But if there's a performance hit, compromising glibc seems like a poor choice 19:48:29 <ajax> i don't think d) is an option; we didn't intend to break geode in f13, so retroactively declaring it so is disingenuous. 19:48:51 <ajax> mjg59: .align isn't something i'd expect to be a performance path 19:49:00 <Guest62041> the 'performance hit' is on the No-ops that precede a loop start. Not in the inner loops. 19:49:00 <ajax> i mean, that's the dead space between functions, right? 19:49:09 <ajax> oh, loop align too, right. 19:49:12 <ajax> still, whatever. 19:49:26 <dsd_> its not entirely limited to glibc. there were some mentions of other packages 19:49:49 <dsd_> providing alternative packages might be an option, but as things progress in future it would probably be hard to control 19:49:53 <Guest62041> all the packages I found with nopl's were either generated from glibc sources, or were linked statically with glibc. 19:49:59 <mjg59> In an ideal universe, gcc would have a definition of 686 that matched reality 19:50:33 <SMParrish> dsd_: what is the best solution for you. Would an i586 subarch work? 19:51:28 <dsd_> i dont know too much about subarchs 19:51:44 <dsd_> subarch = secondary architecture? 19:51:48 <Guest62041> mjg59: competition in the cpu market is such a drag. Innovation that doesn't all go in one direction, bah. 19:51:54 <SMParrish> dsd_: yes 19:52:17 <mclasen> is autoqa in a position to do checks like 'no NOPL' on our binary rpms ? 19:52:29 <mjg59> Guest62041: So the difference would be (i) a glibc built with -march=586, and (ii) a rebuild of everything that statically links glibc? 19:52:38 <nirik> mclasen: I don't think so yet, but eventually I would think so. 19:52:50 <Guest62041> I think you are correct. 19:52:57 <ajax> mclasen: it certainly could. it has the binary payloads, and objdump knows how to disassemble. just needs writing. 19:53:05 <mjg59> So it would be a relatively small package overlay 19:53:10 <nirik> so, our glibc maintainer(s) aren't willing to work around this? I only see the one comment pointing to the kernel work... 19:53:14 <dsd_> SMParrish: i dont know enough about what "secondary arch" means to say really.. and i guess my newbie questions would be outside of the scope of this meeting 19:53:37 <Guest62041> Why build a sub architecture for three packages? Why not just fix glibc in the F13 repos? 19:53:57 <mjg59> Fix glibc how? 19:54:26 <Guest62041> fix its configuration so that it uses the i686 instruction set minus NOPL 19:54:30 <dsd_> can anyone say with confidence (perhaps with a solid reference) that nopl is the only i686 instruction unsupported by Geode LX? 19:54:43 <SMParrish> Guest62041: My fear is that over the next few years additional changes could be introduced which cause another issue with Geode 19:54:47 <ajax> dsd_: nopl, and cmov, and ... 19:55:02 <cjb> ajax: no, we have cmov. 19:55:08 <ajax> i don't know of a list of what's definitely excluded from geode 19:55:19 <Guest62041> there's a memory/memory CMOV missing, but we don't use it. 19:55:22 <Guest62041> ...yet... 19:55:24 <dsd_> i'm just wondering if we'll see the same thing again in 6 months time with another weird instruction 19:55:29 <ajax> probably. 19:55:37 <ajax> so when i said "why is this not a secondary arch" i was trolling 19:55:48 <ajax> it's because we don't actually have a meaningful secondary arch process 19:55:51 <Guest62041> testing on Geodes would let us figure out early enough if something does come up in 6 months. 19:55:54 <mjg59> So, I don't think changing glibc is a sensible plan here 19:55:57 <Guest62041> the problem was that the bug was reported and then ignored. 19:56:17 <mjg59> Because the code is correct, it just has undesirable effects on a given CPU 19:56:58 <nirik> which leaves what? kernel or seperate i586 versions. 19:56:59 <nirik> ? 19:57:03 <mjg59> And it's possible that updates *within* a release may cause applications that previously worked to suddenly contain these instructions 19:57:15 <cjb> in several years, the only sigill we've seen when running i686 distros on the LX is from NOPL. (And NOPL is interesting because it's not actually a documented insn in i686, which is perhaps why the Geode designers chose not to bother.) 19:57:17 <Guest62041> the high level question is: is the Geode LX a supported CPU? If so, glibc has a bug. If not, glibc is correct and the Geode has a, uh, problem. 19:57:37 <ajax> i think by inertia lx _is_ supported. 19:57:41 * nirik notes we are at 15minutes into this discussion. Votes to keep going? or ask for more data/wiki writeups of proposals? 19:57:42 <mjg59> So we either need to stop gcc emitting nopl or we need nopl to work on the geode 19:58:03 <mjg59> It's trivial to stop gcc emitting nopl - we just change the default architecture again 19:58:17 <mjg59> ...and rebuild the entire archive 19:58:28 <Guest62041> mjg59 ideally we'd fix it both ways -- patch the glibc makefiles, AND add a kernel workaround to avoid future problems 19:58:39 <mclasen> but it only seems to emit it for a handful of binaries now, so why rebuild everything ? 19:59:07 <Guest62041> mjg59: For some reason we don't yet understand, only glibc binaries are affected. Standard package build process doesn't produce NOPLs. 19:59:08 <mjg59> mclasen: Yeah, I guess ABI isn't going to be impacted, so we could scan the entire binary archive and just rebuild them 19:59:15 <nirik> folks? votes to keep going please? 19:59:20 <ajax> nirik: keep going 19:59:23 <mjg59> nirik: +1 19:59:26 <SMParrish> +1 19:59:29 * nirik is fine with going on. 19:59:46 <mjg59> My concern is that changing the architecture mid-release could trigger other issues 19:59:59 <cjb> I think that'd be great. (Scan and rebuild affected binaries, which we currently believe to only be glibc.) 19:59:59 <mjg59> Updates of some libraries may start using different codepaths 19:59:59 <nirik> mjg59: change it to what? i586? 20:00:02 <pjones> keep going, yes 20:00:13 <mjg59> nirik: Yeah, unless there's some more fine-grained architecture control I'm unaware of 20:00:22 <mclasen> cjb: plus static linkers of glibc ? 20:00:33 <mjg59> Perhaps we could convince upstream to do a 686-nopl 20:00:47 <mjg59> But, like I said, there's a risk inherent in doing this mid-cycle 20:00:47 <dsd_> mjg59: it could be done for F14, perhaps. (i dont think that would bother OLPC too much, but other LX users might think differently) 20:00:52 <mclasen> would that be i686-nonopl ? 20:01:03 <Guest62041> sounds like a nonopoly to me 20:01:04 <mjg59> The risk is lower if we just change the glibc spec file 20:01:27 <dsd_> or that. change arch for f14, hack glibc for F13 20:01:28 <mjg59> But there'd plausibly be a package update that broke things mysteriously 20:01:36 <ajax> i'm a little confused why we're talking about glibc; .align is a macro in gas. 20:01:51 <ajax> (i assume) 20:02:00 <mjg59> ajax: glibc or gcc? 20:02:20 <ajax> i think really all we can say at this point is that we think it's broken, and we need to figure out where. 20:02:30 <Guest62041> gcc generates .align sometimes, to line up loops on cache line boundaries. gas turns that into any of a dozen forms of NOP depending on what CPU was specified and tuned for. 20:02:43 <mjg59> Yeah, so when I say gcc pretend I said binutils 20:03:02 <Guest62041> But either gcc isn't generating .align for most packages, or gas is being passed different flags for most packages than for glibc. 20:03:08 <Guest62041> that's the part we don't understand. 20:03:29 * nirik thinks we should try and get gcc / glibc maintainers involved in this discussion... but not sure how best to do that. 20:03:34 <mjg59> Ok. Perhaps we should come back to this when the problem is better understood? 20:03:52 <nirik> something like: we want to support this cpu. How can we most easily and safely make it so? 20:04:25 <Guest62041> the CLOSED NOTABUG bug report has been reopened, so it should reenter the maintainers' radar. 20:04:34 <mclasen> did we definitively decide that we need to fix this in f13 and not tell olpc to use an overlay ? 20:04:47 <pjones> so we all agree we'd rather continue supporting this, right? and then mclasen's question was my next one. 20:04:50 <mjg59> mclasen: I think definitively deciding that depends on what's actually happening 20:05:12 * nirik wants to support this cpu... but needs more info on what changes could do that and how risky they are. 20:05:13 <mclasen> ok, so we are still trying to figure out if we _can_ safely and acceptably fix it in f13 20:05:18 <mjg59> It'd be desirable, certainly 20:05:24 <cjb> mclasen: I think the position is more that, since we thought it *was* a supported arch for the release, if we're going to drop it then that should happen with warning at the next release, not retroactively. 20:05:41 <SMParrish> +1 on continuing support and if possible fixing in F13 20:05:51 <pjones> cjb: I think that's fair, but I was asking about a stronger position of "we don't want to discontinue this" 20:05:55 <cjb> any suggestions for who to reassign the now-opened WONTFIX bug to? 20:05:58 <pjones> which it sounds like there's wide agreement on 20:06:19 <nirik> well, is a bug the best way to get input from gcc/glibc folks? or can we contact them more directly? 20:06:37 <pjones> the best thing is probably to find jakub on email or irc and ask him what can be done 20:06:46 <Guest62041> It's a bit of an odd position to say, let's desupport 1.5M in-use machines to get a <1% speedup on NOPs in libc. 20:06:51 <pjones> email might be preferable in that more of us can see it. 20:07:12 <pjones> (he's currently idle 10 hours on irc, so... probably not around) 20:07:27 <nirik> would someone be willing to take that action item and provide any info back to the fesco ticket/bug? 20:07:55 * mclasen can do that 20:07:55 <SMParrish> I will 20:08:03 * mclasen steps back quickly 20:08:25 <nirik> ha. 20:08:44 <nirik> #action SMParrish will contact gcc maintainer and see what possible solutions to this problem are. 20:08:49 <nirik> thanks SMParrish 20:08:53 <cjb> thanks all 20:08:54 <nirik> anything more on this now? 20:08:54 <Guest62041> thx to all 20:09:17 <nirik> cjb / Guest62041 / dsd_ : thanks for the input on the issue. ;) 20:09:38 <Guest62041> nice to know somebody's listening! 20:09:50 * nirik is sorry it happened and wasn't caught before release. ;( 20:09:56 <nirik> (well, wasn't acted on before release) 20:10:15 <nirik> #topic #388 request for e2fsprogs-libs-static 20:10:15 <nirik> https://fedorahosted.org/fesco/ticket/388 20:10:15 <nirik> .fesco 388 20:10:15 <zodbot> nirik: #388 (request for e2fsprogs-libs-static) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/388 20:10:24 <nirik> turns out I think this ticket can be closed... 20:11:05 <nirik> or I guess it's not against the right package. 20:11:17 <nirik> ie, yaboot should get approval for linking static. 20:11:36 <ajax> bootloaders are exceptional, yeah 20:11:46 <nirik> in any case, I am fine with this, it makes sense why it needs it. 20:12:06 <nirik> so, +1 here. 20:12:18 <nirik> +1 from notting in the ticket 20:12:22 <mjg59> Reading a shared object off a filesystem is hard if you need that shared object in order to read the filesystem, yeah 20:12:33 <ajax> +1 to exception for yabooy 20:12:38 <SMParrish> +1 20:12:38 <mjg59> +1 20:12:46 <ajax> also, the package spelled correctly 20:13:09 <nirik> #agreed yaboot can statically link here. 20:13:25 <nirik> now on to f14 feature fun! :) 20:13:28 <nirik> #topic #391 F14Feature: MultipathInstall https://fedoraproject.org/wiki/Features/MultipathInstall 20:13:28 <nirik> .fesco 391 20:13:29 <zodbot> nirik: #391 (F14Feature: MultipathInstall https://fedoraproject.org/wiki/Features/MultipathInstall) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/391 20:14:00 <nirik> +1 from notting in the ticket. 20:14:29 <nirik> +1 from here. Also not sure how many people will use it, but it's cool. ;) 20:14:31 <mjg59> I can't see any reason for anything but +1 here 20:14:36 <ajax> same, +1 20:14:39 <pjones> I'll be +1 on it I _guess_ 20:14:45 <pjones> but consider that to be under duress. 20:14:46 <SMParrish> +1 as well 20:14:56 <nirik> pjones: odd. I was expecting you to kibosh it. ;) 20:15:06 <nirik> #agreed feature is approved. 20:15:13 * mclasen added some comments on the feature 20:15:39 <nirik> #topic #390 F14Feature: LZMA_for_Live_Images https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images 20:15:39 <nirik> .fesco 390 20:15:40 <zodbot> nirik: #390 (F14Feature: LZMA_for_Live_Images https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/390 20:15:51 <pjones> mclasen: that comment kindof makes me want to punch people. 20:16:00 <mclasen> fine with me 20:16:06 <mclasen> as long as you don't punch the messenger :-) 20:16:30 <pjones> it's as if the people doing the work weren't consulted at all... oh wait ;) 20:16:53 <mclasen> I don't know that, and I didn't mean to imply that 20:17:02 <ajax> man i sure would like it if squashfs would grow interface-stable tools, ever. 20:17:12 <pjones> ajax: s/interface-// 20:17:26 <nirik> yeah. ;( 20:17:43 * nirik is +1 here, we can yank it if it doesn't land or turns out to not work or be slow or whatever. 20:17:48 <ajax> i think it's a reasonable thing to shoot for though. +1 20:18:03 * SMParrish agrees with nirik +1 20:18:11 <mjg59> Yeah, +1 20:18:14 <mclasen> +1 20:18:17 <nirik> it's a pity the upstreaming is going so slowly. It was first submitted for .32 I think... or .31 20:18:34 <nirik> #agreed Feature is approved. 20:18:44 <nirik> #topic #392 F14Feature: https://fedoraproject.org/wiki/Features/libjpeg-turbo 20:18:44 <nirik> .fesco 392 20:18:45 <zodbot> nirik: #392 (F14Feature: https://fedoraproject.org/wiki/Features/libjpeg-turbo) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/392 20:18:45 <brunowolff> Thanks. 20:18:58 <nirik> brunowolff: sorry for forgetting to cc you on that ticket. ;( I failed. 20:19:26 <nirik> +1 from notting on the ticket to libjpeg-turbo 20:19:34 <brunowolff> I knew that it was going to be discussed at the meeting because the wrangler changed the wiki page to indicate that. 20:19:44 <ajax> i love the "how to test" on this one. seeing artifacts is all jpeg _ever_ does. 20:20:28 <mjg59> It should produce identical output to libjpeg, right? 20:20:45 <nirik> +1 from me. Again we can back it out pretty easily since no rebuilding needs to happen. 20:20:52 <nirik> mjg59: yeah, should be. 20:21:07 <ajax> mjg59: i think there's some wiggle room there, but at least perceptually yes. 20:21:07 <mjg59> Yeah, so it should be pretty obvious if it's grotesquely broken 20:21:08 <mclasen> mjg59: yeah, that should be testable 20:21:09 <mjg59> +1 20:21:30 <mclasen> perceptual diff... 20:21:51 <ajax> istr one of the libjpeg replacements doing something different for iDCT which meant you got rescaling for free, but not pixel identical results. 20:21:57 <ajax> might be this one, might not. 20:22:04 <ajax> anyway, +1, looks plausible 20:22:36 <SMParrish> Easy to revert if we find issues later +1 20:23:19 <nirik> #agreed Feature is approved. 20:23:32 <mclasen> so, how is this going to work in practise btw 20:23:42 <mclasen> is libjpeg-turbo going to replace libjpeg ? 20:23:48 <pjones> we run out of time and move whatever is finished to next release. 20:23:53 <pjones> Oh, you meant that. 20:24:10 <mclasen> obsoletes/provides ? 20:24:20 <nirik> yes 20:24:23 <nirik> it does currently. 20:24:24 <pjones> obsoletes/provides is probably the way 20:24:34 <nirik> http://atkac.fedorapeople.org/libjpeg-turbo/libjpeg-turbo.spec 20:25:12 <nirik> ok, anything more on this? 20:25:57 <nirik> #topic FES ticket updates - https://fedorahosted.org/fedora-engineering-services/report/6 20:26:05 <nirik> mmcgrath: anything to report this week? 20:26:13 <mmcgrath> Just a few things 20:26:29 <mmcgrath> 1) we got a new contributor that knows C/C++ so that's good. 20:26:36 <mmcgrath> other then that there was one ticket /me gets it 20:26:56 <mmcgrath> https://fedorahosted.org/fedora-engineering-services/ticket/24 that one 20:27:09 <mmcgrath> josemm went through and wrote this but it's not so clear the data we're getting is particularly useful in that form. 20:27:32 <mmcgrath> nirik: did you have any additional thoughts on that? 20:27:33 <nirik> yeah, I'd like more idea on what we could look for for 'very active bugs' 20:28:06 <nirik> basically we want a way to note things that are hitting lots of users or have lots of activity, but not closed... so we could look at adding resources to get them fixed... 20:28:12 <mmcgrath> I'd think active bugs is less important then the number of cc's on a bug. 20:28:24 <mmcgrath> if lots of people care to watch it, they probably all want to know when its fixed. 20:29:09 <nirik> yeah, so perhaps just 'number of cc's'... but I'm not sure we can get that from bugzilla easily. 20:29:28 * mmcgrath isn't sure either 20:29:31 <mmcgrath> I be josemm knows :) 20:30:05 <nirik> If anyone else has any ideas or thoughts, chime right in. ;) 20:31:03 <nirik> well, we can keep poking at it... and perhaps josemm can find a way to do things for us. 20:31:09 <nirik> thanks mmcgrath. 20:31:32 <nirik> As always, feel free to file tickets or add info to them... 20:31:42 <mmcgrath> yup yup 20:31:46 <nirik> #topic #382 Implementing Stable Release Vision 20:31:47 <nirik> .fesco 382 20:31:48 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 20:32:07 <nirik> so, mclasen added some ideas last week... 20:32:20 <nirik> also poelcat would like us to come up with a timeline for implementation 20:32:27 <nirik> https://fedorahosted.org/fesco/ticket/382#comment:6 20:33:23 * nirik taps the mic. Is this thing on? :) 20:33:57 <ajax> oh, timelines. 20:34:14 <ajax> "man, i need to measure this somehow... but how?" 20:35:18 <pjones> yeah, they tend to be pretty bogus, especially when you're pretending they're schedules. 20:35:38 <nirik> also, it's hard to say much until we have a list of things we would like to implement. ;) 20:35:46 <ajax> i think mclasen's ideas are along the right track. but in saying that, i'm saying that i don't think we have tools to measure a lot of that. 20:36:04 <ajax> was re: hot bugs from the FES tickets above. 20:36:19 <nirik> yeah. 20:36:52 <poelcat> what i was trying to get at was a rough notion of when it will be implemented... a goal of some sorts 20:36:57 <poelcat> ? 20:37:01 <nirik> I think it might be worthwhile to list out things to implement for each bullet point in the Board vision... perhaps setup a wiki page to collect things ? 20:38:08 <ajax> yeah. it's probably worth trying to talk with the design people about what this would look like for a user trying to consume it. 20:38:09 <nirik> poelcat: yeah, but it's really hard to estimate that when we don't yet have a full list of things that we would like to implement? 20:38:46 <poelcat> nirik: even thinking really broadly? e.g. end of F14, or end of 2010, or ? 20:38:50 <ajax> some of that we already know, of course. things like abrt being able to tell you that your crash is fixed with a given update. 20:39:30 * poelcat subscribes heavily to the "if you shoot for nothing" principle 20:39:35 <nirik> poelcat: the thing is I bet some of them would be pretty short term/before f14, but some might not be until later... 20:40:29 <poelcat> true 20:41:23 <nirik> I can make a wiki page for a ideas container? 20:41:31 <ajax> sounds good. 20:41:44 <nirik> then we can have folks add to it and see which ones we can do at what time 20:41:44 <nirik> ? 20:41:55 <SMParrish> nirik: good idea 20:41:55 <ajax> i think we should be able to come up with which bits we're going to aim for by f14 and which will be later. 20:42:37 <nirik> yeah, so: before f14, f15 and 'pie in the sky' ? 20:42:59 <ajax> that sounds like a good start 20:43:16 <mclasen> if we do something before f14, it would be for f13 updates, yes ? 20:44:03 <pjones> nirik: that sounds about right, yeah 20:44:17 <pjones> mclasen: I don't see why not 20:44:21 <ajax> mclasen: well, or something to have ready for f14 gold. i guess those are different things. 20:44:24 <nirik> mclasen: good question... I think a number of these things could be addressed in all active streams. 20:47:57 <nirik> https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas 20:48:11 <nirik> please edit/add/fold/spindle/mutilate. 20:48:46 <ajax> excellent, thanks! 20:48:52 <nirik> any other thoughts on this for now? 20:49:28 <nirik> #topic Open Floor 20:49:35 <nirik> Anything for open floor? 20:49:43 <ajax> i do have the libiberty scanner running, but lord is it slow 20:50:08 <ajax> 9000 packages in F13, and i've got through 2000ish in the past two hours or so 20:50:09 <pjones> not really surprising. 20:50:28 <ajax> almost entirely blocked on read bandwidth to the lookaside cache 20:50:29 <pjones> that's actually faster than I would have predicted. 20:50:32 <nirik> cool. Update the ticket as you get info. ;) 20:50:48 * mclasen apologizes for being slightly unresponsive today, dueling meetings... 20:51:01 <pjones> I guess the last time I tried to do something like that was on a sun ultra 2 (and rh7.1...), so... 20:51:09 <nirik> ajax: any news on the mediawiki fun? 20:51:14 <pjones> mclasen: no worries, thanks for making an attempt on the scheduling 20:51:50 <nirik> mjg59: any update for https://fedorahosted.org/fesco/ticket/381 20:52:06 <mjg59> nirik: Nobody replied when I brought it up. I'll try harder. 20:52:14 <ajax> nirik: i think i'm coming down on the side of mediawiki. it's a worthwhile change in principle but i don't think the implementation is good enough to be carrying. still thinking. 20:52:17 <nirik> bummer. ;( 20:52:29 <nirik> ajax: ok. 20:52:46 <nirik> oh, does anyone object to me just closing https://fedorahosted.org/fesco/ticket/276 ? 20:52:55 <nirik> thats the 'include cacert.ca' 20:53:08 <ajax> boot it. 20:53:18 <nirik> cool. 20:53:21 * nirik has nothing else. 20:53:41 <pjones> keeeel 20:53:49 * mclasen ponders bringing up nss-softokn 20:53:53 <mclasen> nah 20:54:01 <nirik> mclasen: yeah, it's a mess. ;( 20:54:02 <mclasen> next week 20:54:04 <nirik> ok. 20:54:08 <pjones> we could argue about that in public for another week before you do that ;) 20:54:13 <nirik> Thanks for coming everyone! 20:54:26 <nirik> #endmeeting
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
