18:30:10 <nirik> #startmeeting FESCO (2010-10-20)
18:30:10 <zodbot> Meeting started Wed Oct 20 18:30:10 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:30:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:30:11 <nirik> #meetingname fesco
18:30:11 <zodbot> The meeting name has been set to 'fesco'
18:30:11 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
18:30:11 <nirik> #topic init process
18:30:11 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
18:30:19 <mjg59> Afternoon
18:31:09 <nirik> I think notting was going to be traveling today.
18:31:13 <pjones> yeah
18:31:21 <nirik> not sure if mclasen was going to be able to make it or not.
18:31:30 <ajax> 
18:31:38 * SMParrish here
18:33:04 <nirik> ok, I see ajax, kylem, mjg59, nirik, and pjones here. mclasen, notting, cwickert absent.
18:33:31 <nirik> so, I guess lets go ahead...
18:33:36 <nirik> #topic Updates policy / Vision implementation status
18:33:36 <nirik> .fesco 351
18:33:36 <nirik> .fesco 382
18:33:37 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
18:33:41 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
18:33:50 <nirik> our fine updates topic.
18:33:58 <nirik> SMParrish: any news on stats gathering?
18:34:58 <SMParrish> nirik: Unfortunately no.  Been a hectic week here (
18:35:05 <nirik> yeah, I know the feeling.
18:35:21 <nirik> would anyone have time in the upcoming week to help work on it? perhaps adding a few folks could get it moving along?
18:36:01 <SMParrish> Help would be appreciated.  I will be out of town all weekend attending OLPC-SFO so I wont have time until I get back on Tuesday
18:36:15 * nirik is also going to be traveling from tomorrow->sunday.
18:37:48 <ajax> i'd volunteer but my week is pretty booked as it is
18:37:56 <nirik> ok, well, I guess we will get to it as we get time. Perhaps we could brainstorm some in ticket? or ask luke what is generated now and go from there?
18:38:13 <SMParrish> nirik: sounds like a good idea
18:38:32 <nirik> ok.
18:39:01 <nirik> Also, we have pending here: enforcement (save for last) and possibly doing a enhancement/features repo... (cwickert was going to work on that)
18:39:25 <nirik> anything else on updates for now? or shall we move on?
18:40:22 <nirik> ok, moving on then...
18:40:37 <nirik> #topic #475 fesco ok with kde-sig requesting custom f12 koji target to make an unofficial kde-4.5 update?
18:40:38 <nirik> .fesco 475
18:40:38 <zodbot> nirik: #475 (fesco ok with kde-sig requesting custom f12 koji target to make an unofficial kde-4.5 update?) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/475
18:40:58 <ajax> go wild.
18:41:06 * rdieter lurks for any questions
18:41:07 * nirik has no particular issue with it.
18:41:26 <ajax> i'm generally in favor of targetted koji tags like that
18:41:34 <mjg59> Yes, I think this is a good plan
18:41:40 <nirik> rdieter: would it build from some other branch? or ?
18:42:10 <dgilmore> as teh person who looks after koji, i do think we need to consider the stroage and extra load that it will cause
18:42:18 <rdieter> nirik: I'm going to try that first yeah, but will do whatever it takes
18:42:50 <ajax> dgilmore: do we have any guidance on what kind of added loads are acceptable for this kind of thing?
18:42:51 <mjg59> dgilmore: If it's an issue, then I think we should ask the board for resources to support this
18:43:03 <rdieter> dgilmore: I promise to --background everything
18:43:18 <dgilmore> rdieter: that really doesnt matter
18:43:19 <mjg59> dgilmore: This kind of thing is a natural outcome of the updates policy - I'm pretty certain that we'll be seeing more examples of updates like this
18:43:40 <dgilmore> im fighting a loosing fight to keep more than 10% free on /mnt/koji
18:43:49 <dgilmore> the builds take up disk space
18:43:52 <dgilmore> and KDE is big
18:44:00 * nirik gets a phone call.
18:44:09 <mjg59> dgilmore: Ok. Should we be asking the board for more disk?
18:44:09 <SMParrish> dgilmore: If I understand it tag will be temporary
18:44:19 <rdieter> dgilmore: when we're done, I don't mind garbage collecting it all, if that matters
18:44:32 <dgilmore> for something not officially part of fedora i have issue with the extra disk space it will use
18:44:34 <pjones> we should get rid of CDs in F15 so we don't use as much space.
18:44:49 <mjg59> dgilmore: ^ re board
18:44:50 <dgilmore> pjones: they dont live on that filesystem
18:45:11 <dgilmore> nfs01.phx2.fedoraproject.org:/ 9.9T  8.6T  857G  92% /mnt/koj
18:45:44 <dgilmore> rdieter: builds would all have to manually be untagged to get properlly cleaned up
18:46:23 <dgilmore> mjg59: its not just the disk on /mnt/koji  but also its backup
18:46:43 <dgilmore> i can allocate more disk to /mnt/koji  but then we can not back it up
18:46:58 <nirik> dgilmore: is that scratch builds too?
18:46:59 <rdieter> dgilmore: sure, I was planning on untagging it all when done anyway
18:47:20 <dgilmore> nirik: scratch builds last for only 2 weeks
18:47:46 <nirik> yeah, I know, but was just wondering if we could move them off that fs... since backing them up seems pointless to me.
18:47:47 <dgilmore> all im asking is that people dont just say sure do it sounds great
18:48:01 <dgilmore> but that they consider the ramifications of yoru actions
18:48:02 <mjg59> dgilmore: If you're resource constrained then we need to provide more resources
18:48:07 <mjg59> dgilmore: Because we're going to have more of these
18:48:52 <nirik> well, or if we could split them out somehow so they don't affect things like backups, etc.
18:49:41 <dgilmore> nirik: not possible
18:49:47 <nirik> bummer.
18:50:25 <nirik> anyhow, could we handle this particular request? builds for f12, untagged/removed after they are all done?
18:50:31 <dgilmore> all the builds land under /mnt/koji/packages except for scratch builds which go to /mnt/koji/scratch
18:50:50 <dgilmore> nirik: if they get untagged they will get removed by koji-gc
18:50:58 <dgilmore> after a time period
18:52:09 <dgilmore> thats all
18:52:11 <nirik> right, so can we do this now? or do we need to look at trying to get more resources? or ?
18:53:04 <ajax> we could get actual numbers for this
18:53:06 <dgilmore> you can do it  just be aware that /mnt/koji is a finite resource
18:53:25 <dgilmore> and im contsantly batling to free up space on it
18:53:36 <nirik> dgilmore: yeah, agreed that we should consider these requests carefully, not free for all.
18:53:44 <dgilmore> ajax: we have 857G free right now
18:54:18 <dgilmore> if we get more disk for its backup i can increase the space there. but its still finite
18:54:23 <ajax> dgilmore: that sounds like an issue we need to continue to address.  it'd be interesting to know what the worst offenders are (or if it's just a matter of a million paper cuts)
18:54:31 <nirik> so, any objections to granting this specific request and looking perhaps at more resources at the same time?
18:54:42 <mjg59> +1
18:54:42 <ajax> nirik: fine with me
18:54:45 <SMParrish> +1
18:54:50 <dgilmore> ajax: kernel
18:55:03 <ajax> heh, not surprised.
18:55:16 <dgilmore> though KDE uses alot also
18:55:27 <nirik> openoffice?
18:55:29 * dgilmore did look it up 6 months or so ago
18:55:38 <dgilmore> OOo uses alot also
18:55:48 <dgilmore> I get some numbers together if anyone is intrested
18:55:48 <nirik> anyhow, sounds like we want to grant this and try and come up with more resources moving forward.
18:55:55 <nirik> dgilmore: that might be good.
18:55:59 <ajax> dgilmore: please.
18:56:23 <nirik> #agreed request granted. Please untag when done. Will try and gather more resources for koji disk moving forward.
18:56:44 <nirik> ok, so we have some f15 features:
18:56:46 <nirik> #476 F15Feature: LZMA_for_Live_Images - http://fedoraproject.org/wiki/Features/LZMA_for_Live_Images
18:56:46 <nirik> .fesco 476
18:56:48 <zodbot> nirik: #476 (F15Feature: LZMA_for_Live_Images - http://fedoraproject.org/wiki/Features/LZMA_for_Live_Images) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/476
18:57:12 <mjg59> +1 to this, given that it's conditional on the kernel patches
18:57:16 * brunowolff is here for questions
18:57:17 <kylem> yeah.
18:57:24 <mjg59> I can't see any reason to say no
18:57:26 <nirik> right. +1 here too... hopefully the patches land this time.
18:57:35 <kylem> bruno has been really helpful with the squashfs stuff, it's really only contingent on the upstreaming of the squashfs patches.
18:58:06 <nirik> nice. Other votes?
18:58:56 * nirik sees +2 so far?
18:59:01 <pjones> I'm +1 but only because I think lzma squashfs images are good for us in other places.
18:59:19 <kylem> hrm, do we use squashfs on the non-live images as well?
18:59:22 <ajax> +1, easy backout, nice win if it does work.
18:59:39 <nirik> kylem: sorta
18:59:48 <nirik> ie, all the rpms on there are xz compressed.
19:00:18 <nirik> we could possibly move initramfs to use it, but then I'm sure that would break xen domU again. ;)
19:00:26 <kylem> right.
19:00:29 <ajax> xen can htfu
19:00:38 <pjones> nirik: also install.img is squashfs, though with any luck it will go away.
19:00:56 <nirik> so, so +4? or kylem were you a +1 above?
19:00:57 <kylem> ahh.
19:01:01 <kylem> i am +1 yes
19:01:15 <nirik> #agreed This feature is approved.
19:01:26 <nirik> thanks for all the work on this brunowolff
19:01:31 <nirik> #477 F15Feature: systemd - http://fedoraproject.org/wiki/Features/systemd
19:01:31 <nirik> .fesco 477
19:01:32 <zodbot> nirik: #477 (F15Feature: systemd - http://fedoraproject.org/wiki/Features/systemd) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/477
19:01:51 <kylem> pjones, ah, so this would be helpful for reducing our cd space consumption that we're currently dealing with? :)
19:02:13 <mjg59> +1 to systemd, given that it's implemented
19:02:19 <pjones> kylem: possibly, yeah
19:02:20 <nirik> +1 here. I see no reason not to go for it in f15.
19:02:47 <ajax> +1 to systemd again
19:02:59 <SMParrish> +1 as well for F15
19:03:12 <pjones> oh sure, why not, +1
19:03:17 <nirik> #agreed This feature is approved.
19:03:18 <kylem> +1.
19:03:37 <nirik> #478 F15Feature: var-run-tmpfs - http://fedoraproject.org/wiki/Features/var-run-tmpfs
19:03:37 <nirik> .fesco 478
19:03:38 <zodbot> nirik: #478 (F15Feature: var-run-tmpfs - http://fedoraproject.org/wiki/Features/var-run-tmpfs) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/478
19:04:08 <mjg59> The rest of the world has already been doing this
19:04:11 <nirik> yep.
19:04:18 <nirik> sounds good to me. Make it so. +1
19:04:19 <mjg59> So, again, +1
19:04:29 <ajax> +1, sure, why not
19:05:03 <kylem> +1 (why does a one line addition to fstab need to be a feature)
19:05:49 <SMParrish> +1
19:05:50 <nirik> some coordination between maintainers, some docs/press about the change that would confuse some small number of people.
19:05:57 <nirik> #agreed This feature is approved.
19:06:21 <nirik> #topic Open Floor
19:06:29 <nirik> Look, it's a short meeting. ;)
19:06:34 <ajax> \o/
19:06:35 <kylem> cool.
19:06:40 <nirik> anyone have anything for open floor today?
19:06:48 <pjones> yeah, I think we should get rid of CDs for F15.
19:07:07 <nirik> ...again. ;)
19:07:14 <pjones> F14 i386 disc1 didn't work without dropping the PAE kernel.
19:07:29 <ajax> by which you mean, the split media set (and not netinst)?
19:07:36 <pjones> The split media stuff is all complete hacks, and there are plenty of deficiencies in it
19:07:38 <pjones> ajax: yeah
19:07:49 <pjones> I think it should be DVD or netinst with nothing in between.
19:07:52 * nirik is ok with that in principal. I'm sure people will complain.
19:08:09 <ajax> their suffering is caused by desire...
19:08:19 <nirik> there would also be live media thats still cd sized.
19:08:27 <mjg59> Yeah
19:08:28 <pjones> yeah.
19:08:35 <ajax> well, maybe.  we've toyed with making live media bigger than a CD before
19:08:37 <nirik> (well, provided there is something like the spins sig and we make them for f15)
19:08:45 <ajax> maybe one of these days we'll man up and do it
19:08:49 * hicham hated the 5 or 6 CDs that used to be offered for install
19:08:54 <mjg59> When we hand out media, it's DVD
19:09:13 <mjg59> I'd be amazed if anyone uses the split set
19:09:25 <mjg59> And couldn't just use netinst instead
19:09:36 <nirik> yeah
19:09:38 <nirik> http://torrent.fedoraproject.org:6969/
19:10:14 <nirik> more than 10-1 cd to dvd
19:10:39 <ajax> that's higher than i would have expected.  but not enough higher to change my mind.
19:10:53 <mjg59> So as many people downloaded the source DVD as downloaded the CD set, roughly
19:10:55 <pjones> that's for i686 - x86_64 is the other way
19:10:57 <nirik> anyhow, perhaps we should float the idea to rel-eng/other groups ? or did we want to vote now...
19:11:21 <ajax> pjones: no?  63700:7012 for DVD:CD for amd64
19:11:48 <mjg59> ajax: nirik said cd to dvd
19:11:53 <pjones> ajax: hence "the other way"
19:11:55 <Oxf13> oh h ai
19:11:56 <mjg59> I think he was mistaken
19:12:08 <ajax> anyway.  ack to the concept, if some other group has a problem with it they can have a problem with it.
19:12:36 <Oxf13> releng has no problem with dropping split media
19:12:40 <Oxf13> in fact, we'd strongly urge it
19:12:54 <nirik> perhaps there will be less flame this time...
19:12:55 <Oxf13> fragile code base that breaks often in ways that are rather non-obvious
19:13:07 <Oxf13> boatloads of duplicated content on mirrors to pass around
19:13:11 <ajax> qa even gets one less test case!
19:13:25 <Oxf13> ajax: one multiple less
19:14:10 <nirik> ok, so sounds like we could vote on it now? or do we want to gather more flames^w info and vote next week?
19:14:19 <ajax> votey vote vote vote.
19:14:28 <ajax> +1 die split media die this isn't windows 3.1
19:14:39 <kylem> but but but but floppies
19:14:43 <mjg59> Yeah, this is as bad as getting boxes of 40 floppies
19:14:46 <mjg59> +1 to death
19:14:58 <SMParrish> +1 to getting rid of them
19:14:59 <nirik> +1 for dropping split media. We can point people to boot.iso or any live spins that are cd sized.
19:15:16 <nirik> #agreed Will drop split cd media in f15.
19:15:20 <mjg59> kylem: ?
19:15:22 <mjg59> Ok
19:15:27 <mjg59> Well, that was easy
19:15:28 <nirik> ok, anything else today?
19:15:31 <kylem> +1.
19:15:31 <Oxf13> plenty of time for the community to respond and time to revisit before alpha.
19:15:35 * pjones is +1
19:15:36 <mjg59> It's amazing what we can get away with when we don't announce it in advance
19:15:42 <kylem> can jigdo just sort this out for the 10 people who care?
19:15:47 <Oxf13> since we're in a killing mood, how about we kill spins too?
19:15:52 <nirik> kylem: doubtfull
19:15:56 <Oxf13> kylem: oh god, jigdo
19:15:59 <Oxf13> please no more.
19:16:03 <kylem> lol.
19:16:30 <kylem> Oxf13, in the sense that they could take the netinst, and add a local cache of packages to it somehow.
19:16:59 <kylem> meh, i don't care, i don't even owna  machine with an optical drive rigth now. ;-P
19:17:14 <Oxf13> for that to work, we'd have to have created the split media to run jigdo against.  Defeating the purpose :)
19:17:30 <kylem> lol. fair.
19:17:39 <nirik> The folks who want split media (or so I heard last time we did this): poor network connect, old machine with no dvd drive.
19:17:53 <kylem> should i ask if we can drop !PAE while we're on this roll? :)
19:18:00 * kylem ducks.
19:18:32 <mjg59> Given that Pentium M is almost always on i855 and that doesn't work, I can't see any real harm...
19:18:33 <nirik> I'd like to see a list of what cpus that drops before voing on it. It's unclear to me which... does that kill OLPC?
19:18:34 <kylem> (i'm only kidding. really. don't vote on it, i don't not dare you. ;-P)
19:18:55 <kylem> nirik, dunno cjb is in taipei and my geode is off atm.
19:19:14 <nirik> right, so I think if you want file a ticket with more info and we can revisit next week?
19:19:23 <kylem> nirik, we can discuss it at a future meeting, the impact of keeping it isn't that bad.
19:19:27 <kylem> *nod*
19:19:54 * cjb appears
19:20:03 <nirik> ha.
19:20:15 <cjb> geode doesn't need PAE, AFAIK
19:20:16 <nirik> If nothing else will close out the meeting in a minute.
19:20:22 <cjb> we ship with max. 1GB RAM
19:20:37 <kylem> cjb, yeah, but does it support it?
19:20:39 <mjg59> cjb: But does it have it?
19:20:42 <mjg59> If we drop !PAE...
19:21:16 <kylem> not shipping PAE by default means we don't ship NX by default.
19:21:26 <kylem> anyway, we can discuss it later. :)
19:22:03 <nirik> ok, thanks for coming everyone!
19:22:08 <nirik> #endmeeting