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