| jds2001 has changed the topic to: FESCo Meeting -- init | ||
| jds2001 | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod | |
|---|---|---|
| * notting is here | ||
| nirik is here. | ||
| j-rod here | ||
| jwb is here | ||
| * bpepple is here. | ||
| jds2001 | shall we get started or wait for a few more folks? | |
| chacha_chaudhry | chacha_chaudhry is here for Review O' Matic feature questions | |
| rishi | chacha_chaudhry and I am here to represent Review-O-Matic, although I might have to run and grab dinner for a few minutes. | |
| jds2001 | sharkcz is unable to be here this week. | |
| we can do that first if you'd like | ||
| rishi | jds2001: Okay. | |
| --- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets | ||
| jds2001 | .fesco 24 | |
| zodbot | jds2001: #24 (Review O' Matic) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/24 | |
| jds2001 | so I'm sorta wondering if this is really a feature - being something that we want to get out on the soapbox and trumpet. | |
| bpepple | was the features up for review sent to the list? I didn't recall seeing any yesterday. | |
| jds2001 | It really *is* cool though. | |
| jds2001 | bpepple: I sent them about 1AM :( | |
| bpepple | oh, that's why I didn't see it. ;) | |
| nirik | I'm a bit worried about the name and some of the text. This doesn't really review packages, it just helps reviewers by doing lots of the tests right? | |
| * bpepple goes to read the feature page. | ||
| jds2001 | right. | |
| notting | my issue with it as a feature is that it's not actually a feature *of the release* | |
| jwb | yeah | |
| jds2001 | mine too, it's more of an infrastructure thing. | |
| nirik | also, there could be a possiblity of false positives if run against existing packages... which should be avoided. :) Those are not anything that couldn't be overcome tho. | |
| rishi | Yes, it is more of an infrastructure and developer oriented thing, but ... | |
| notting | ... was transifex 'featured'? | |
| rishi | ... since Transifex went through the feature process, we thought we also needed to do the same. | |
| notting: Yes, we found a Transifex feature page on the Wiki. | ||
| chacha_chaudhry | well we are open for new name. And the history of name is bad. We never decided it. Project was proposed by some one else. | |
| s/Project/name/ | ||
| bpepple | I sorta fall into the camp that I'm not sure this should be a feature, since it's a back-end thing (similar to koji or bodhi). | |
| * jds2001 sees transifex in the F8 feature list. | ||
| jds2001 | but i dont really think it should have been, imo, knowing what we do now. | |
| not to say that both items aren't really cool. | ||
| nirik | it's main advantage to end users might be higher quality packages... but thats really hard to measure. | |
| f13 | transifex was really a service for beyond Fedora contributors | |
| * rishi nods | ||
| bpepple | I don't think this meets our definition of being a feature. http://fedoraproject.org/wiki/Features/Policy/Definitions#Definition_of_a_Feature | |
| nirik | yeah... not that it's not important and useful. ;) | |
| bpepple | nirik: correct. | |
| jds2001 | so I'm going to say -1, but that this is really cool and important at the same time :) | |
| jwb | -1 | |
| with the same comments | ||
| bpepple | -1 to as a feature. | |
| * nirik nods... same here. | ||
| notting | +1 to the idea (go forth and do it!), -1 to noting it as a feature | |
| jds2001 | i see five -1's, so FESCo has declined the Review O' Matic feature, however sees great value in it and urges rishi and chacha_chaudhry to go forth and do it! | |
| jds2001 | .fesco 12 | |
| chacha_chaudhry | Thanks ... We just thought telling telling the world "We care more for our packages ..." is a feature. :) We will do it :) | |
| zodbot | jds2001: #12 (New Sponsor Request: Lubomir Rintel (lkundrak)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/12 | |
| bpepple | +1 to lkundrak being made a sponsor. | |
| jds2001 | +1 here, no objections on the list. | |
| nirik | +1 here. He maintains a lot of packages and knows the guidelines. | |
| j-rod | +1 | |
| jwb | +1 | |
| notting | +1 | |
| jds2001 | i see 6 +1's, so lkundrak's request has been approved. I'll take care of that after the meeting. | |
| jds2001 | .fesco 14 | |
| zodbot | jds2001: #14 (New Sponsor Request: Itamar Reis Peixoto) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/14 | |
| jds2001 | there were objections to this on this list, as he has done *no* reviews. | |
| notting | -1 on that alone | |
| jds2001 | -1 here as well. | |
| bpepple | -1. He really needs to do some reviews. It's very hard to know how well he knows the guidelines. | |
| jwb | -1 | |
| nirik | yeah, do some reviews, then come back. -1. | |
| j-rod | not yet | |
| jds2001 | i see 6 -1's, so Itamar's request has been declined. He is however, free to re-apply after doing a number of reviews. | |
| itamarjp | :'( | |
| jds2001 | itamarjp: dont give up, we just dont have any basis to form an opinion right now. | |
| on to features... | ||
| jds2001 | .fesco 19 | |
| zodbot | jds2001: #19 (CUPS PolicyKit Integration) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/19 | |
| j-rod | jds2001: wasn't there a sponsor request for kevin koffler too? is that happening next week instead? | |
| bpepple | j-rod: next week. | |
| jds2001 | j-rod: yeah, next week. | |
| j-rod | ok, cool | |
| * mclasen is here, can try to answer questions | ||
| jds2001 | so any questions on the CUPS-PK feature? | |
| mclasen: cool :) | ||
| notting | looks good to me. +1 | |
| * nirik notes docs has "FIXME: None, currently" | ||
| jwb | +1 | |
| mclasen | nirik: well, there are no docs, currently | |
| jds2001 | +1 here, fix the docs :) | |
| j-rod | +1, and what they said | |
| bpepple | +1 | |
| nirik | sounds like a great idea. +1. Might be worth running the defaults past dwalsh, as he had some issues with some of the other policykit defaults a while back. | |
| mclasen | if he does, he's encouraged to tell us... | |
| jds2001 | I see six +1's, so FESCo has approved the CUPS PolicyKit integration feature | |
| .fesco 20 | ||
| zodbot | jds2001: #20 (Debuginfo Revamp) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/20 | |
| * nirik nods. Just thought I would mention it. | ||
| notting | mclasen: well, given what happened with dbus, and the PK flamewar, it might be nice to have a short 'writing DBUS and PK policies for dummies' doc | |
| mclasen | yes, that would be nice | |
| I've mentioned that to the relevant parties repeatedly :-) | ||
| jds2001 | roland not around for the debuginfo feature? | |
| nirik | +1 on this feature, but I see its only 1%, so I hope it's able to make it... | |
| jds2001 | +1, same here. | |
| nirik | also, mass rebuild would be better sooner than later. | |
| jds2001 | looks like some pretty big changes. | |
| notting | given the 1%, and what's involved, and when it would need to land for the mass rebuild (i'd prefer to only do one)... i'm skeptical | |
| nirik | well, knowing if there would be a mass rebuild I mean. | |
| jwb | is it backwards compatible? | |
| jds2001 | would the new gdb (if we go that route) be able to take old debuginfo packages? | |
| or what jwb said :) | ||
| nirik | roland is not around right? (I don't think I have seen him on irc ever) | |
| jwb | he's on irc | |
| j-rod | he hangs out in #fedora-kernel | |
| bpepple | I a little worried about this: 'Either gdb team has to adapt it to new conventions, or DWARF tool + rpm deployment plan could include exploding in %post to current layout.' | |
| jwb | whether he's available, i have no idea | |
| * j-rod pings roland | ||
| jwb | ok, so to be honest, this is one of those features that is going to go into rawhide regardless of what we say | |
| nirik | jwb: probibly. | |
| j-rod | still early-ish on the west coast | |
| notting | "DWARF tool + rpm deployment plan could include exploding in %post to current layout. " | |
| that's just wrong. | ||
| bpepple | notting: that's what I was thinking also. | |
| I'd like to hear from Roland on that, before approving this. | ||
| jds2001 | yeah, how do you remove it then? Are they planning to %ghost the stuff or what? | |
| notting | i'm -1 right now just because the scope, while described, includes a bit too much if/or/maybe/possibly | |
| bpepple | -1 for now here also. | |
| j-rod | yeah, I'd say defer this one for now, needs more questions answered | |
| * jds2001 changes his early vote | ||
| nirik is fine deferring too. | ||
| bpepple | jds2001: to late, your already committed. ;) | |
| nirik | is someone going to update the talk page there? | |
| jds2001 | i see three -1's, two +1's (me and nirik - though we are both fine deferring). | |
| * jds2001 calls this declined, pending further information | ||
| jds2001 | .fesco 21 | |
| zodbot | jds2001: #21 (ext4 default filesystem) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/21 | |
| jds2001 | no sandeen :( | |
| jwb | he's coming | |
| j-rod | there ya go | |
| sandeen | hey gang | |
| jds2001 | sandeen: :) | |
| j-rod | so. just how scary is making ext4 the default for f11? :) | |
| sandeen | you all have been helping test it, right? :) | |
| wwoods | ooh are we going to play point/counterpoint? | |
| sandeen | there is some scariness | |
| j-rod | yup. my laptop is running ext4 now | |
| sandeen | but by and large it mostly seems to be working well for most people | |
| * nirik is running it here on a server box... working fine. | ||
| sandeen | there are some known bugs; filesystem shrinking needs fixing | |
| jwb | does anyone have an overwhelming reason not to swithc? | |
| wwoods | "by and large it mostly seems to be working well for most people" is not a compelling argument for "so let's switch everyone to it" | |
| I have quite a few! | ||
| sandeen | wwoods, let's wait 'til ubuntu shakes it out for us, maybe? :) | |
| I have no doubt that it will uncover bugs if we switch new installs over to it | ||
| wwoods | I will summarize as: increased complexity and reduced stability on an unproven filesystem is not a good tradeoff for near-negligible gains in performance | |
| sandeen | but we've had it available in fedora since F9, and there are 1500 or so (last I checked) ext4 filesystems registered in smolt stats | |
| * jds2001 cnat claim to have really tested beyond trivially | ||
| wwoods | ext4 is not particularly useful for most users | |
| as a personal anecdote I've had terrible luck with it | ||
| j-rod | but, but, but, moronix says its super-fast on ubuntu... | |
| wwoods | I fully support it being available as an option in anaconda with no special boot args needed | |
| nirik | http://www.smolts.org/static/stats/stats.html | |
| j-rod | it was a bit fail in the f10 kernel and the first update kernel, but solid in -159 for me | |
| sandeen | wwoods, it performs better (streaming IO in particular, as well as fsck times, delete times, and better sync behavior), scales better (larger files, larger filesystems (someday)) and has a few nice features (persisitent preallocation, eventual defrag ....) | |
| drago01 | can't we just test it? reverting to ext3 as default before GA should be easy if needed | |
| wwoods | let's take these one-by-one | |
| sandeen | drago01, there is some risk there of ext3 not getting good testing as a result | |
| j-rod | I'd definitely say make it chooseable in anaconda w/o a flag | |
| jwb | sandeen, ext3? | |
| wwoods | "performs better" - fsck is negligible for normal user cases, and the most obvious fsync bug - the firefox/sqlite doom - is worked-around already | |
| j-rod | does ext3 really need more testing? | |
| notting | j-rod: it already is | |
| sandeen | jwb, yeah, if we focus on ext4, bail at the last minute, ext3 has been short-changed | |
| j-rod | notting: ah, in rawhide? | |
| wwoods | "scales better" - useless for anyone with filesystems / files in the sub-terabyte range | |
| drago01 | sandeen: wtf? it got more than enough testing already and still get some upstream | |
| j-rod | haven't actually tried a rawhide installer recently | |
| wwoods | (i.e. almost everyone) | |
| notting | wwoods: you've obviously never run liferea (it's like firefox was. but worse.) | |
| jwb | sandeen, seriously? | |
| sandeen | jwb, drago01 I'm just being pedantic about qa | |
| wwoods | notting: okay, fair | |
| sandeen | odds are it's fine, but alpha fedora releases have uncovered ext3 bugs in the past | |
| wwoods | basically, here's the thing | |
| drago01 | wwoods: and rpm calling fdatasync sucks too on ext3 | |
| wwoods | it's *dead simple* to convert an ext3 filesystem to ext4, right? | |
| sandeen | FSVO convert, yes | |
| wwoods | FSVO? | |
| j-rod | yeah, you don't get the full benefit if it was ext3 to start | |
| nirik | doesn't get all the features converting IIRC | |
| j-rod | for some value of | |
| sandeen | you can very easily tune2fs and mount with extents, new files are in ext4 format | |
| nirik | s/ext3/ext4/ you mean | |
| wwoods | so: a) most people don't *need* ext4, | |
| b) those that *want* it at install time can get it | ||
| c) those that want it later can easily upgrade in place | ||
| jds2001 | wwoods: somewhat upgrade. | |
| wwoods | okay: "upgrade in place, with the caveat that they won't get some of the nice features thereof" | |
| dwmw2_gone | they can upgrade in place to btrfs and get the features :) | |
| sandeen | To be honest, yes, some of the motivation is to advance ext4's robustness by foisting it on the masses :) | |
| jwb | please no | |
| wwoods | d) once converted, ext4 filesystems can't be mounted as ext3 anymore | |
| dwmw2_LHR | (sorry I'm late) | |
| sandeen | wwoods, that's mostly true. with a lot of hoop jumping you can go back. it's not great | |
| wwoods | e) we lose some features of ext3 (fs shrink, for example) | |
| sandeen | wwoods, that will be fixed | |
| it's just a bug | ||
| jwb | by F11? | |
| sandeen | sure | |
| zless | i've used ext4 in f9 and f10 for my root fs only. the only realworld change i noticed was vastly faster fsck times. (and a rpm db related bug) | |
| j-rod | how many users actually shrink their fs? | |
| wwoods | okay, fair, strike e) | |
| jwb | j-rod, i would say more than a few | |
| dwmw2_LHR | when will we have shrink working? | |
| sandeen | um, when is alpha released? :) | |
| wwoods | I've used ext4 in F9 and F10; every system has either suffered massive rpmdb corruption or the disk has died completely. but these are anecdotes. let's leave them out of the discussion for now. | |
| dwmw2_LHR | how many users shrink their fs _immediately_ after installing it? :) | |
| drago01 | wwoods: "d)" the feature is about new installs no converting | |
| j-rod | huh. I think I've done it... never. | |
| sandeen | TBH I haven't looked into the bug yet, just got obvious when I used ext4 to make a livecd | |
| wwoods | drago01: either way. ext4 filesystems - created or converted - can no longer be mounted by ext3 tools/modules | |
| sandeen | the fsck phase of the process found errors | |
| jeremy | j-rod: fs shrinking is required for the livecd to work. and if we're switching by default, the rootfs for the livecd needs to be ext4 also | |
| sandeen | "ext3 tools" are ext4 tools | |
| drago01 | wwoods: ok | |
| j-rod | aha | |
| notting | back in 2 min, sorry | |
| sandeen | jeremy, FWIW the fsck phase *seemed* to fix the errors :) | |
| I haven't been able to make it boot yet (on ext3 either) | ||
| wwoods | sandeen: I mean other tools; older rescue images, other distros, drivers in other OSes (think dual-boot machines), etc | |
| sandeen | "F9 rescue cd's won't rescue F11" doesn't seem compelling to me | |
| j-rod | people w/other OSes could still pick ext3 if they must | |
| sandeen | wwoods, and the windows ext3 driver corrupts ext3 anyway. I'll be glad to break that driver. | |
| wwoods | "slightly faster for certain uncommon cases at the expense of compatibility and stability" | |
| sandeen | the rpmdb corruption wwoods mentioned is the sort of thing that troubles me more; I've never reproduced it and we've not gotten a handle on it yet | |
| wwoods | is really not a compelling argument to me | |
| dwmw2_LHR | wwoods: we have/had similar compatibility concerns with selinux labelling anyway, surely? | |
| shared /home isn't _that_ feasible | ||
| jds2001 | at some point, we're going to have to bite the bullet and do it. | |
| j-rod | yeah | |
| jwb | jds2001, no we aren't | |
| wwoods | I'm sorry, but that's baloney | |
| unless "at some point" is "when btrfs is ready in a couple years" | ||
| dwmw2_LHR | I don't think btrfs is that far out | |
| j-rod | so even when its rock-solid, performs better all over, we'd still not default to it?... | |
| wwoods | I agree that sometime in the next couple of years we're going to need to mass-migrate our users to a new filesystem | |
| jwb | btrfs as default is like an f13/f14 item | |
| dwmw2_LHR | although it _does_ need a lot more stabilisation. It's a lot newer than ext4 | |
| wwoods | I don't think now is the time | |
| sandeen | dwmw2_LHR, more than just stabilisation | |
| ENOSPC handling would be nice, for one :) | ||
| jwb | which means, can we live with ext3 for f11, f12, f13? | |
| f13 | damnit, I need to make it sot hat we don't ship F13 | |
| sandeen | I'm impressed w/ the pace of development but don't underestimate the time it'll take | |
| f13 | well, my opinion would be to allow ext4 to be selected without magic cli args, but keep ext3 as the default. We eventually want to go to btrfs so make a default switch when that is ready | |
| wwoods | f13: right, that's what I'm saying | |
| f13 | just to avoid default switching frequently | |
| jeremy | removing the magic cli arg is fine (and really, probably nto a fesco decision; if kernel people are happy with it, then it's two seconds in anaconda) | |
| f13 | but then again, it is Fedora, so meh. | |
| dwmw2_LHR | sandeen: true, but stabilisation is the major thing. ENOSPC is part of that | |
| as is ENOMEM handling :) | ||
| f13: that makes sense to me | ||
| rwheeler | ext4's fsck time improvements alone will make a vast improvement for users - why the fear? | |
| jds2001 | that sounds reasonable. | |
| wwoods | rwheeler: vast improvement for *what* users | |
| rwheeler | any user with a disk larger than 200 GB (which is most of us) | |
| j-rod | users that reboot their machines? | |
| dwmw2_LHR | for users who _really_ ought to know what they're doing, and select ext4 for themselves | |
| * mclasen doesn't see big value in keeping the default fs type stable over multiple fedora releases | ||
| drago01 | non broken fsync | |
| wwoods | I've never, *ever* seen *any* of my machines fsck at *all* | |
| sandeen | wwoods, you are a lucky man | |
| wwoods | I'm really not seeing a lot of complaints about fsck being slow | |
| except from people who manage a lot of storage | ||
| j-rod | sure its not just hiding behind the boot splash? | |
| wwoods | and those people can easily choose ext4 | |
| f13 | j-rod: no | |
| j-rod | we still do an automatic fsck every x mounts | |
| fsvo x | ||
| sandeen | no, we tune that off in anaconda | |
| f13 | j-rod: there are journal replays, but not full fscyncs | |
| jwb | j-rod, rwheeler: fsck does not run hardly ever | |
| sandeen | fscks. | |
| rwheeler | you also will see a significant streaming write improvement | |
| j-rod | ah | |
| wwoods | j-rod: if that was the case my boot times would be unstable - they'd be long on the days I fsck and short others | |
| f13 | j-rod: we stopped that insanity a while ago. | |
| sandeen | fscks happen when you get an error on your fs, or yo uhit the "fsck every BLAH mounts" misfeature | |
| wwoods | right | |
| j-rod | maybe its only when I keep crashing my boxes... | |
| :) | ||
| wwoods | that doesn't happen very often to anyone | |
| jeremy | j-rod: we turned off the auto fsck stuff when we first added ext3 | |
| sandeen | f13, but mke2fs still defaults to having it on, so filesystems made outside anaconda get that treatment | |
| rwheeler | I really don't agree about fsck not running - you always need to run it when you really, really need to recover a drive with a failing disk | |
| wwoods | "faster fsck times" is an uncommon use case | |
| f13 | I don't think anybody is going to argue that ext4 is "better". I think the question is, if btrfs is our eventual goal, is it worth the work to change defaults twice in such short succession? | |
| * jeremy committed the bits to anaconda for it | ||
| j-rod | I think I've made more than an fs or two just using mkfs outside of anaconda, so mah bad | |
| bpepple | +1 to allowing ext4 to be selected without magic cli args, but keep ext3 as the default. | |
| rwheeler | wwoods: not true at all, it is a routine thing in the real world | |
| dwmw2_LHR | it's a special tuning -- we now do it only when you're on battery, or when you're about to try to give a presentation. | |
| jwb | rwheeler, then people that care can select ext4 as the fs | |
| j-rod | heh | |
| mclasen | f13: you can't really know how short the succession will be | |
| sandeen | dwmw2_LHR, :) | |
| f13 | rwheeler: does this real world contain people that just blindly accept defaults? | |
| mclasen: it'll likely be shorter than ext2<->ext3 (: | ||
| jwb | what bpepple +1 | |
| wwoods | seriously we can revisit this at F12 | |
| sandeen | f13, fsck isn't about option choosing | |
| rwheeler | ext4 is the evolved version of ext3 with a misnamed subdirectory | |
| wwoods | and Fthirteen | |
| jwb | rwheeler, if that were true, then ext3 could mount ext4 filesystems | |
| wwoods | I really don't see the value in doing it now | |
| rwheeler | I think that we should treat it just like the major upgrades we did to x11, etc | |
| * notting is +1 for ext4 as default | ||
| f13 | well, lets think of this another way | |
| one that is likely not popoular here | ||
| f13 | does anybody rightly think that btrfs will be viable for RHEL6? | |
| dwmw2_LHR | rwheeler: do you know if we can do in-place migration from ext4 to btrfs, or only from ext3/ext2 ? | |
| no | ||
| f13 | if no, is the desire for RHEL6 to have ext4? | |
| jwb | poor argument | |
| f13 | if yes, that's one hell of an argument for ext4 by default in F11 | |
| rwheeler | there are plans to allow the in place migration from both | |
| dwmw2_LHR | RHEL6 is... 12 months out? We'd want it to be default in F11 for that :) | |
| jwb | f13, that's an argument for RH | |
| f13 | yes, yes it is | |
| I told you it wasn't going to be popular. | ||
| wwoods | The Fedora side of my brain sez: that's RHT's problem, not Fedora's | |
| rwheeler | ext4 will definitely be in both rhel6 and 5.4 (and is tech preview in 5.3) | |
| * jwb points to his obligatory we are not RH sign | ||
| dwmw2_LHR | it's a relevant question, even if it isn't popular | |
| f13 | of course we're not red hat, but that doesn't mean we should immediately deny any thing that would /help/ Red Hat | |
| * dwmw2_LHR has one of those, but it's still a relevant question. It affects how much paid support we get if we choose it, for example | ||
| jwb | dwmw2_LHR, by that token, we should ask what CentOS and yellowdog want | |
| wwoods | I'll offer this as a compromise: do ext4-by-default for Alpha and Beta | |
| jwb | they are both eventual consumers of fedora... | |
| wwoods | revist at Feature Freeze or thereafter | |
| jwb | j-rod, hey, what does mythdora want? | |
| j-rod | I'm +1 for making it the default. and beat the hell out of it. | |
| dwmw2_LHR | not really, because we don't expect them to bust a gut if we _try_ it and shit hits the fan. | |
| wwoods | if we get a lot of nasty problems we revert | |
| j-rod | with a contingency plan... what wwoods said | |
| sandeen | jwb, ext4 will delete big HDTV files faster ;) | |
| drago01 | wwoods: thats what I proposed just test it and go back if it is too broken | |
| j-rod | jwb: *cough* xfs | |
| sandeen | hehe | |
| dwmw2_LHR | jffs2! | |
| rwheeler | sandeen the faster deletion is an issue for people as well.... | |
| wwoods | but I'm really, really not happy about foisting this on our theoretical millions of users | |
| sandeen | yeah, if alpha explodes all over reverting to ext3 is easy. it'd be embarassing, but easy. | |
| jeremy | dwmw2_LHR: I thought ubifs was what the cool kids used these days... ;) | |
| wwoods | when most of them don't need it and it's not really proven | |
| dwmw2_LHR | jeremy: true :) | |
| sandeen | wwoods, we foist new stuff on our users ALL THE TIME | |
| dwmw2_LHR | I'm happier doing it in Alpha than in the real release :) | |
| j-rod | this *is* rawhide we're talking about... :D | |
| dwmw2_LHR | can we try it just for the Alpha, then turn it off. Then make another decision before beta? | |
| sandeen | dwmw2_LHR, hehe, so the plan is "add it to alpha and revert in beta?" :) | |
| jeremy | sandeen: think we can get the shrinking bug fixed in time for the alpha? | |
| wwoods | (dude I know this - I'm playing the role of Curmudgeonly QA Guy here) | |
| sandeen | jeremy, I'll look into it. probably. | |
| dwmw2_LHR | sandeen: well, add it for Alpha and reconsider for beta, once we have more information | |
| rwheeler | we have enough fs developers working in rhel & fedora to support this very well (not to mention the IBM/SUN and others) | |
| f13 | I don't mind foisting ext4 on new users, I just would mind foisting something else as a default on them in the not distant future | |
| jeremy | although I guess we probably need to ensure that anaconda copes for live installs with either case regardless of the default | |
| jds2001 | ok, I've completely lost count. Who is +1 to this? Current proposal is "enable it, revert at feature freeze if it eats babies"? | |
| f13 | but really, I don't care, that's a minor argument from my part. | |
| wwoods | okay, here's what I want: flesh out the "Scope" section of https://fedoraproject.org/wiki/Features/Ext4DefaultFs | |
| f13 | (and I have no real FESCo vote) | |
| wwoods | to include some *testable* metrics for speed and reliability | |
| * sandeen wishes we had a filesystem people *were* begging for | ||
| dwmw2_LHR | wwoods: to test it, we put it in Alpha :) | |
| wwoods | revisit at alpha, beta, etc. | |
| dgilmore | did we start an hour early? | |
| notting | my argument is: fedora is about shipping the best of what's available today. that's ext4 right now, imo | |
| jds2001 | dgilmore: we start at noon now :) | |
| dwmw2_LHR | I'd be up for putting it in Alpha and keeping an open mind -- revisit the question before beta (which is slightly different to the 'pull it if everything breaks' proposal) | |
| jds2001 | noon eastern, that is :) | |
| wwoods | if it fails to meet the stated specifications, we revert to ext3-by-default | |
| f13 | notting: that's a good argument. | |
| dwmw2_LHR | s'true | |
| dgilmore | jds2001: its noon now | |
| sandeen | notting, have you been using it? good experience, problems, ? | |
| notting | sandeen: no :) | |
| j-rod | yeah, what notting said. and then we just keep a *very* close eye on it | |
| sandeen | hehe | |
| jwb | so we're going round and round | |
| need to vote | ||
| j-rod | I've been using it quite a bit, very few issues, and those I have had, have been quickly fixed | |
| +1 | ||
| dgilmore | im +1 for ext4 as default unless we plan to switch to btrfs in F-12 | |
| wwoods | removing my Curmudgeon hat: I want ext4-by-default, but I want it to not break my system, and when I wear that hat I'm not allowed to make tradeoffs so easily | |
| dwmw2_LHR | I'd vote +1 to 'in Alpha, reconsider for beta', and vote 0 for 'in Alpha, reconsider if it _really_ goes tits-up' | |
| jwb | dgilmore, that is a silly way to vote | |
| rwheeler | btw, we have pounded a lot of data through it with the rh performance guys and the HP big system guys | |
| wwoods | dwmw2_LHR: we won't. | |
| dwmw2_LHR | rwheeler: yeah, that's no substitute for real users :) | |
| phro | fwiw, I've been using it on my development system for 6+ months, and it's not had any problems. | |
| dgilmore | jwb: perhaps. i just dont think we should go switching the default file system 2 releases in a row | |
| dwmw2_LHR | we're not switching to btrfs in F-12. Not as default | |
| dgilmore | jwb: so if we think we might want to switch to btrfs in F-12 id rather just wait till then | |
| wwoods | btrfs won't even be considered for defaulthood until F13 at the earliest | |
| dwmw2_LHR | I'd _like_ to be able to, but it ain't going to happen | |
| notting | wwoods: i'll put a beer up that we'll be doing more OMG AAARGH kernel respins for modesetting than ext4 :) | |
| jwb | i vote 0 | |
| jds2001 | in F-thirteen we'll visit that. | |
| dgilmore | then +1 for ext4 | |
| jds2001 | +1 | |
| dwmw2_LHR | +½ | |
| rwheeler | hard to get real users until we have more than one non-boot partition by default for new fs'es :-) | |
| wwoods | for F11 you'll need to put 'icantbelieveitsnotbtrfs' or something to enable it in anaconda | |
| dwmw2_LHR | :) | |
| wwoods | notting: I wouldn't bet against you on that one | |
| * nirik got a phone call. Reading back up. | ||
| jds2001 | dwmw2_LHR: you have to vote in whole numbers :) | |
| jds2001 | oh, you did. | |
| nirik | +1 from me, if it blows up, we fire contingency plan. | |
| wwoods | sandeen: can you help craft a spec with testable metrics - things like "no data corruptor bugs open", "throughput on test 'foo' at least x.xx", etc. | |
| dwmw2_LHR | I'm not too worried about the bugs aspect | |
| jds2001 | i see around 5 +1's, so ext4 has been approved as the default filesystem in F11, with the understanding that we will revisit at Beta. | |
| wwoods | esp. tests for things like rpmdb corruption that have been seen in the past | |
| sandeen | wwoods, we can try something like that. it'll be weasily; I can pick a test I can pass :D | |
| dwmw2_LHR | I assume that if it breaks, sandeen won't sleep till it's fixed, with rwheeler standing over him with the whip | |
| jds2001 | geez a lot left. | |
| wwoods | sandeen: that's fine, I just want some things to point at to say "here are the specified goals of ext4, and everything passes, so we're good to go" | |
| jds2001 | .fesco 22 | |
| zodbot | jds2001: #22 (Gnome 2.26) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/22 | |
| * mclasen still here, can try to answer questions | ||
| jwb | wait | |
| so did ext4 pass? | ||
| ah, yes | ||
| sorry | ||
| wwoods | sandeen: I'm really trying to avoid something like the Empathy feature from F10, where we had an incomplete idea of what it was supposed to do, and then it turned out not to do what everyone wanted | |
| jwb | proceed | |
| rwheeler | dwmw2_LHR we certainly have a focus on getting ext4 stable so we can get our fs people onto btrfs | |
| wwoods | so even if you're writing a spec that ext4 currently meets, that's fine, I just want to be able to say: "no, everything is fine, we can prove it does everything it's supposed to" | |
| sandeen | (FWIW I think we should keep ext3->ext4 migration as an option, but with a boot flag; I Think that carries more risk (since it's existing data)) | |
| bpepple | +1 to gnome-2.26. | |
| jwb | i'm +1 for Gnome 2.26 | |
| sandeen | (sorry, carry on) | |
| jds2001 | +1 | |
| nirik | +1, no brainer, should trumpet. | |
| notting | +1 | |
| j-rod | +1 | |
| mclasen | business as usual, really | |
| jds2001 | i see six +1 | |
| McGiwer mclasen | ||
| bpepple | mclasen: yeah. | |
| nirik | when is 2.26 scheduled to release? | |
| jds2001 | so we've approved the gnome 2.26 feature | |
| jwb | move on! | |
| j-rod | yeah, not much question here. next! | |
| jwb | oh crap | |
| i'm supposed to do minutes | ||
| notting | speaking of, did we already approve the kde-4.2 feature? | |
| dwmw2_LHR | +1 | |
| hah | ||
| bpepple | jwb: should be fun. ;) | |
| mclasen | notting: its on the approved list | |
| jds2001 | jwb: i can send you the log if needed. | |
| jwb | bpepple, summaries are wonderful :) | |
| jwb | jds2001, nah, i think i have it. if i don't, i'll ask you | |
| jds2001 | .fesco 23 | |
| zodbot | jds2001: #23 (Live System for the DVD Image) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/23 | |
| jds2001 | so this looks like more of a wishlist item to me. | |
| jwb | i added some comments on the discussion page here | |
| jds2001 | and not a very likely one, either. | |
| jwb | it's not even technically possible for anything other than i386 | |
| -1 | ||
| notting | is the submitter actually doing the patches for pungi? | |
| jwb | i dunno. i asked about that | |
| jds2001 | didnt see anything to that effect. | |
| jwb | there's no patches, and no space on the x86_64 or ppc DVDs | |
| jds2001 | only pungi patches ive seen recently are from notting | |
| notting | jwb: well, we can cull stuff from the Fedora spin (puts on bastard hat). but if no one's working on the underlying compose/boot infrastructure for it... | |
| f13 | yeah, I don't see this happening without somebody doing a lot of work | |
| and I've already got too much work | ||
| notting | also, it gives you a rather bizarre installation choice in that you'll be installing two different things depending on which boot option you choose | |
| jwb | yeah | |
| dgilmore | -1 as its really only feasable for i386 | |
| j-rod | dual-layer DVD image ftw! | |
| jds2001 | -1 here too. | |
| j-rod | -1 | |
| bpepple | -1 | |
| drago01 | jwb: "it's not even technically possible for anything other than i386" lets move to DL DVDs ;) | |
| f13 | I do have a bluray burner here that I"ve been playing with | |
| dwmw2_LHR | -1 | |
| j-rod | (apologies to all the users w/only single-layer) | |
| dgilmore | j-rod: dual layer dvd's are still not really an option | |
| jwb | drago01, buy me a burner and media and we can talk | |
| jds2001 | i see six -1 | |
| f13 | we could do live bluray with the full rpm set on it for choose your own adventure installs | |
| dgilmore | f13: sick puppy | |
| j-rod | dgilmore: yeah, just being a jack-ass. :) | |
| jds2001 | so we've declined the LiveCD on the install DVD | |
| f13 | it'll take a week to mirror it, but... | |
| * dwmw2_LHR wonders if we could manage tri-boot i386/x86_64/ppc install discs | ||
| dwmw2_LHR | shouldn't be hard... | |
| f13 | dwmw2_LHR: you get right on that (: | |
| jwb | have fun | |
| j-rod | even better: fat binaries w/all four arches in them. | |
| jds2001 | ok, last feature :) | |
| j-rod | single disc image for everything | |
| dgilmore | dwmw2_LHR: it could be done. but would have to be dual-layer dvd or blue-ray | |
| jds2001 | .fesco 25 | |
| zodbot | jds2001: #25 (Xfce 4.6) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/25 | |
| drago01 | jwb: the burner ins't the problem you I can't find a non DL capable burner but the media is indead more expensive | |
| * nirik999 has his daily intel xorg crash. That bug is getting very very very anoying. | ||
| jds2001 | :( | |
| dgilmore | drago01: you have to have puchased a dvd burner in the last couple of years for dual layer support | |
| jwb | nirik999, so i asked a question about xfce since release is now set at feb 6 | |
| jds2001 | nirik999: we're on to xfce 4.6 | |
| nirik999 | great. | |
| please re-ask, as my dircproxy hasn't reconnected yet. | ||
| drago01 | dgilmore: yeah | |
| j-rod | isn't this more or less the same sort of thing as new gnome and kde? or is there more to xfce 4.6 | |
| wwoods | nirik999: are you using the 'noirqdebug' boot arg? | |
| * j-rod should read the feature page... | ||
| dgilmore | +1 for XFCE | |
| bpepple | +1 here also. | |
| notting | +1. do they do the same odd/even release scheme, which is why we don't have 4.5? | |
| nirik999 | j-rod: it's pretty much that... new release, new stuff. The big thing they redid is the configuration backend... | |
| jds2001 | +1 here | |
| j-rod | +1, that's what I figured | |
| nirik999 | notting: yep. 4.5 was a devel cycle. | |
| dwmw2_LHR | +1 | |
| jds2001 | i see six +1's, so FESCo has passed the Xfce 4.6 feature | |
| jwb | i'll assume the answer to my question was "yes" | |
| +1 | ||
| nirik999 | upstream is somewhat interesting when it comes to releases... I sure hope it's out in time, but the betas/rc's are looking pretty stable. | |
| jds2001 | alrighty, on to other business..... | |
| jds2001 | .fesco 10 | |
| nirik999 | for 4.4 they slipped a bunch, someone posted to the list "hey, when are we going to release" and they did the release the next day. ;) | |
| zodbot | jds2001: #10 (Review list of non-provenpackager committable packages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/10 | |
| jds2001 | nirik999: hehe :) | |
| nirik999 | wwoods: no, should I be? | |
| wwoods | once again - XFCE46's Scope section should include more detail about what's changing, so we can write a test plan to test the changes | |
| nirik999 | wwoods: agreed, I can try and improve it... | |
| jds2001 | so I was thinking that we'd discuss what constitutes acceptable criteria for a package *not* to be provenpackager committable. | |
| jds2001 | helps to have that prior to reviewing the list. | |
| abadger1999 | jds2001: On this one, note that I haven't locked down who can change that yet. it's very easy but I'm trying to get a few other changes into the same release. | |
| If locking it down is needed pronto, I can hotfix it this weekend. | ||
| jwb | pronto would be an exaggeration i think | |
| jds2001 | abadger1999: i dont think pronto. | |
| nirik999 | I'm wondering what the criteria should be too... do we really need any packages closed to this? I guess one issue is the cvs commit mail control-c thing. Was that fixed? | |
| dgilmore | jds2001: i think packages that if patched incorrectly will break the world | |
| f13 | nirik999: that isn't fixed, and might not be fixable with cvs itself. | |
| dgilmore | i.e. binutils gcc kernel glibc | |
| f13 | those would be acceptable, but still the maintainer could choose to open them up | |
| honestly, I think it's prudent to get feedback from the current closed packagers, to see why they feel they shoudl be closed | ||
| dgilmore | f13: sure they can always choose to open them up | |
| jds2001 | what about security system packages, ala openssl, openssh, nss stuff? | |
| f13 | we can then roll that into either acceptable criteria, or unacceptable. | |
| bpepple | f13: agreed. | |
| jds2001 | s/system/sensitive | |
| nirik999 | so, if thats not fixed, I do see a need to have closed packages. ;( Thats a reason to switch vcs's or setup IMHO. | |
| f13 | this is one of those things where you can't envision every possible critera, and you have to roll with the requests as they come. | |
| dgilmore | jds2001: true, we dont want a debian esque incident | |
| dwmw2_LHR | f13: true, although having guidelines doesn't hurt | |
| nirik999 | I agree... lets email the maintainers who have closed and ask them? | |
| f13 | nirik999: I have to look again at how much we can move fully serverside with the message bus, we /might/ be able to fix it | |
| dwmw2_LHR | I think the plan stated before was that we'd let maintainers come to us and make their case | |
| nirik999 | if it was fixed, I would see no real reason to close provenpackagers personally. | |
| dwmw2_LHR | and after a month or two, we'd open the packages we hadn't approved | |
| we should call on the maintainers to do that | ||
| jds2001 | can do. | |
| jds2001 | dwmw2_LHR: you saw the summary from our face-to-face meeting i guess? | |
| jds2001 | about reseeding provenpackager w/sponsors? | |
| bpepple | jds2001: any reason why that turned from a proposal session into a decision? | |
| jwb | bpepple, majority vote was present | |
| jds2001 | bpepple: i thought it was a decision :) | |
| bpepple | It would have been niced to have been given an option to way in on that. | |
| jds2001 | and majority was at 6 | |
| jds2001 | bpepple: sorry :( | |
| bpepple | s/way/weigh/ | |
| dwmw2_LHR | jds2001: yes, I did. thanks. | |
| bpepple | seemed like it was rammed through without any of the folks that might have dissented from being allowed to vote. | |
| dwmw2_LHR | well, if they were quorate... | |
| I have no particular objection to it, although I probably wouldn't have voted for it | ||
| bpepple | but in the grand scheme of things, I don't care that much, but I don't think it should become a habit in future fudcons. | |
| f13 | I wouldn't feel bad about putting that to another meeting vote | |
| we're a ways away from being able to /act/ upon that decision anyway | ||
| jwb | i fail to see how this is different from someone not making a meeting | |
| * nirik has no problem revisiting. I can +1 here as well as I did in person. ;) | ||
| f13 | jwb: mail advertisement, non-fesco participation, etc... | |
| * jds2001 too :) | ||
| bpepple | f13: I can live with the decision for the seeders I had more of a problem with having a vote without giving all of fesco an option to weigh-in. | |
| f13 | and well, the rahul effect | |
| anything to avoid the rahul effect. | ||
| jwb | sorry, but it was known from the last IRC meeting we were going to talk about this | |
| jds2001 | bpepple: it was pitched as a barcamp session at paul's recommendation | |
| and we did have non-fesco members present. | ||
| bpepple | f13: working on a proposal is fine, I'm just not thrilled with having a final decision being made without all the parties being able to weigh-in. but anyway we can get back to the topic. | |
| f13 | bpepple: yeah, I agree with you. | |
| jds2001 | do we want to re-vote now? | |
| just for the record? | ||
| nirik | bpepple: yeah, sorry. | |
| bpepple | jds2001: no, I'm fine with the decision, just not the process that was used. | |
| let's just try to avoid from doing that again in the future. | ||
| jds2001 | noted :) | |
| anyhow, anymore on this? | ||
| * jds2001 takes that as a no, will follow up with individual maintainers. | ||
| jds2001 | .fesco 11 | |
| zodbot | jds2001: #11 (Review FPC report) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/11 | |
| jds2001 | this is the FPC report that we missed last week. | |
| and FPC has one other item as well. | ||
| jds2001 | .fesco 18 | |
| zodbot | jds2001: #18 (FPC item for approval) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/18 | |
| * bpepple doesn't have any objections. | ||
| * jds2001 either, +1 | ||
| j-rod | no objections to anything here | |
| nirik | well, I'm not sure the font stuff is ideal... seems a lot of churn and macros. ;) However, I will trust that fpc knows what they are doing... | |
| f13 | The naming of fonts causes some pretty ... fun ... things to go in specs/macros | |
| dgilmore | +1 | |
| nirik | +1 | |
| f13 | and some unexpected subpackage names | |
| heavy use of -n going on, which is always a treat to debug | ||
| j-rod | hm. good point. wasn't thrilled at having to change a dependency *again* | |
| but if they'll finally settle on something and quit changing the names around on dejavu-*... | ||
| * jds2001 wonders what the end goal of all this is. | ||
| nim-nim | jds2001: world domination! | |
| nirik | font package names that make some sense, and are split out so you don't have to install a big package to get the one font you need. | |
| and font packages that are all using the same setup I guess. | ||
| jds2001 | seems worthy | |
| nim-nim | and cleaning up the huge pile of mispackaged fonts in the distro | |
| f13 | the end goal should be listed in teh proposal, is it not? | |
| * dwmw2_LHR wishes the damn page would load | ||
| nirik still needs to fix his font packages. Perhaps this weekend. | ||
| dwmw2_LHR | sounds good to me as nirik describes it | |
| abadger1999 | There was no actual font naming guideline before. nim-nim and FPC had several proposals and counter proposals before arriving at this naming convention. | |
| nim-nim | we settled with the minimal changes FPC would accept | |
| their first proposals were even more heavy on -n and renamings | ||
| * jds2001 only sees four +1's to this unless i'm missing something | ||
| jds2001 | jwb, notting? | |
| jwb | +1 | |
| nim-nim | jwb: thanks | |
| jds2001 | ok, the FPC proposals have been approved. | |
| notting | +1-ish. i don't like the churn, but as long as it's the last time :) | |
| dwmw2_LHR | +1 | |
| j-rod | +1, same caveat as notting | |
| jds2001 | .fesco 13 | |
| zodbot | jds2001: #13 (FESCo needs to determine whether ovm is acceptable content) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/13 | |
| * nirik nods. Hopefully this will be it and we can grow our font package collection from here. | ||
| nim-nim | thank you | |
| bpepple | +1 to ovm, for pretty much the reasons that spot pointed out in the bug report. | |
| nirik | so it's a simulator where this is no free content. | |
| (yet) | ||
| j-rod | +1, it'll help enable development of a free sim | |
| dwmw2_LHR | what are the chances of free content? | |
| dgilmore | nirik: reverse | |
| nirik | ah, ok. | |
| dgilmore | its content with no free way to use it | |
| * nirik reads the bug. | ||
| nirik | bug 474980 for those following at home. | |
| buggbot | Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=474980 medium, medium, ---, thibault.north@gmail.com, ASSIGNED, Review Request: ovm - Open Verification Methodology : IEEE 1800 SystemVerilog standard | |
| notting | 'content with no free way to use it'? so, along the lines of a CC-BY-SA mp3 file? | |
| jds2001 | notting: there's hope for a free way to use it. | |
| notting | ah, ok | |
| nirik | why not just wait for those, package them and approve this after one of those is in? | |
| why does adding it now help? | ||
| jds2001 | chitlesh is not around :/ | |
| * jds2001 wishes he could answer that, supposedly it will spur development or something | ||
| nirik | that seems strange to me... perhaps I am missing something | |
| * jds2001 too | ||
| jds2001 | spot: do you have any insight on ovm other than what's in the bug? | |
| dgilmore | nirik: i dont get it either | |
| nirik | it would be a bad experence for our users, IMHO. yum install ovm. Hey, I can't use this, I need to go buy this commercial app to use it. | |
| dgilmore | would we allow something that can build without oracle, but would only run with oracle as a db? | |
| notting | spacewalk? | |
| nirik | dgilmore: we do already I think... there are some perl modules. | |
| dgilmore | notting: it needs oracle to build | |
| nirik | but they are mostly converters, not sure if they need oracle, or just data dumped from it. | |
| dgilmore | just using that as an example. | |
| we allowed the games engine that would download closed game data. but there was free data that could be used | ||
| it wasnt the only function | ||
| abadger1999 | amazon s3 and flikr libraries. | |
| dgilmore | abadger1999: they dont require non-free bits on your machine to be useful. | |
| abadger1999 | Unless you count the js loaded by your browser :-) | |
| nirik | I guess it comes down to does this "enhance the users experence" | |
| dgilmore | i guess to me that it requires non-free bits on your local machine to be useful makes it a no go | |
| nirik | in the case where someone already have whatever commercial thing needs to run this, being able to yum install it would be nice. | |
| dgilmore | nirik: sure | |
| nirik | but for anyone else it's a loose. | |
| j-rod | someone could want to install it to work on a free replacement, no? | |
| jds2001 | j-rod: i think that's the goal. | |
| dgilmore | j-rod: they could | |
| j-rod | sure, there are probably very few people who actually want it... | |
| nirik | popularity is not part of the criteria. ;) | |
| j-rod | but I think there's a legitimate end-game and no blocker reason to keep it out | |
| this isn't being pimped as a feature, right? just want clearance to add the package | ||
| nirik | humm...so there are some free tools in alpha... | |
| bpepple | j-rod: correct. | |
| j-rod | so I'm still +1 for this | |
| bpepple | still +1 to this also. | |
| nirik | I think I am ok with it as long as their are some free tools to use it... | |
| jds2001 | +1 here as well | |
| dgilmore | id like to see the alpha tools in, even if there not completely uesable | |
| it would make me feel better about it | ||
| nirik | yeah, I am still not sure on the timing... it would make sense to me to add the tools at the same time or before. | |
| notting | +1 to add the tools at the same time, please | |
| nirik | so, where are we? ok, but add a note asking to package/review/approve the tools first? | |
| jds2001 | i believe so. | |
| dgilmore | id like the tools at the same time | |
| so +1 from me with the proviso that the tools get added also | ||
| jds2001 | i see five +1's, so we'll allow this content provided that iverilog gets packaged at the same time. | |
| jds2001 | that's the end of the agenda, anything else folks wanna bring up? | |
| --- jds2001 has changed the topic to: FESCo meeting - open floor | ||
| bpepple | do we still want to have our irc logs here: http://bpepple.fedorapeople.org/fesco/, or somewhere else now that we are rotating meeting summaries? | |
| notting | do we just want to do the other open sponsor requests while we're here? | |
| jds2001 | sure, we could do that. | |
| bpepple | yeah, I'm fine with doing the other sponsor requests. | |
| jds2001 | .fesco 15 | |
| zodbot | jds2001: #15 (New Sponsor Request: Ian Weller) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/15 | |
| dgilmore | bpepple: probably should look at putting them on fedorahosted | |
| nirik | bpepple: wiki? | |
| jds2001 | so there were some objections here. | |
| bpepple | nirik: doesn't that screw up wiki searching still? | |
| dgilmore | jds2001: -1 for Ian, id like to see more reviews and participation in the review/packaging process | |
| jds2001 | bpepple: put them in teh Meeting: namespace | |
| nirik | bpepple: don't think so, as long as it's in Meeting: | |
| bpepple | jds2001: -1 to ian. In my opinion he needs more package reviews. | |
| nirik | yeah, ianweller needs to do more reviews | |
| j-rod | -1, same concerns | |
| jds2001 | -1 here, too - didnt realize the lack of package reviews. | |
| nirik | I'm happy to note however, that there are lots of reviews on the queue. ;) | |
| * jds2001 encouraged him to apply, I feel sorta bad about that :/, but again, I didn't know the review situation | ||
| jds2001 will advise him accordingly, nirik :) | ||
| dgilmore | i count 4 -1 | |
| notting | 0 for now | |
| nirik | -1 for now... come back with reviews done. ;) | |
| jds2001 | i see five -1's, so we have declined ianweller's request, and request him to re-apply after doing further package reviews. | |
| jds2001 | .fesco 16 | |
| zodbot | jds2001: #16 (New Sponsor Request: Kevin Kofler) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/16 | |
| nirik | +1 | |
| jds2001 | +1, a no-brainer. | |
| notting | i was confused, i thought he was one already. +1 | |
| bpepple | +1 here also. | |
| dgilmore | +1 for kevin | |
| he is doing amazing work | ||
| jds2001 | i see five +1's, so we have approved Kevin's request. | |
| anything else? | ||
| mitr | https://fedoraproject.org/wiki/Features/StrongerHashes is not yet FeatureReadyForFESCO, but does anyone care to offer any comment now? | |
| j-rod | +1 for kevin | |
| sorry, was distracted | ||
| dwmw2_LHR | +1 | |
| (for kevin) | ||
| nirik | mitr: seems like a good thing to have. Lots of packages/interface with lots of groups. | |
| mitr | Is there a mass rebuild planned? | |
| * j-rod has other work to tend to, needs to disappear or at least pay less attention | ||
| jds2001 | mitr: none at present, no. | |
| bpepple | mitr: As far as I'm aware I don't think one is planned at the moment. | |
| nirik | mitr: not that I know of yet. | |
| gcc 4.4.0 just landed tho | ||
| f13 | it landed in a side collection | |
| well not fully built either | ||
| nirik | yeah, branch in cvs at least it looks like. | |
| dgilmore | f13: is there features in gcc-4.4.0 that would benefit from a mass rebuild? | |
| dwmw2_LHR | re StrongerHashes... looks like a sane plan | |
| f13 | I think jakub has mumbled something about it | |
| dgilmore | f13: we should plan on doing one | |
| f13 | there could also be rpm features to enable, like sha256 checksums | |
| dgilmore | id like to see noarch packages included | |
| notting | ideally, schedule just one that handles sha256, gcc, debuginfo, etc. | |
| f13 | dgilmore: that's what feature pages are for | |
| nirik | is the rpm lzma stuff ready this cycle? | |
| f13 | notting: that's the idea | |
| dgilmore | i guess sha256 will require all package get rebuilt | |
| notting | nirik: i thought lzma changed ABI, or format, or something | |
| nirik | well, it was in alpha last time... but no idea if there has been progress... need to ask Panu. | |
| tibbs | Hey, they finally named the gcc specfile properly! | |
| nirik | tibbs: yep | |
| * jds2001 has $DAYJOB stuff to tend to..... | ||
| nirik is good with closing meeting now. | ||
| dgilmore also | ||
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!