FESCo-20090116

jds2001 has changed the topic to: FESCo Meeting -- init
jds2001FESCo 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.
jds2001shall we get started or wait for a few more folks?
chacha_chaudhrychacha_chaudhry is here for Review O' Matic feature questions
rishichacha_chaudhry and I am here to represent Review-O-Matic, although I might have to run and grab dinner for a few minutes.
jds2001sharkcz is unable to be here this week.
we can do that first if you'd like
rishijds2001: Okay.
--- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets
jds2001.fesco 24
zodbotjds2001: #24 (Review O' Matic) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/24
jds2001so I'm sorta wondering if this is really a feature - being something that we want to get out on the soapbox and trumpet.
bpepplewas the features up for review sent to the list?  I didn't recall seeing any yesterday.
jds2001It really *is* cool though.
jds2001bpepple: I sent them about 1AM :(
bpeppleoh, that's why I didn't see it. ;)
nirikI'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.
jds2001right.
nottingmy issue with it as a feature is that it's not actually a feature *of the release*
jwbyeah
jds2001mine too, it's more of an infrastructure thing.
nirikalso, 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.
rishiYes, 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_chaudhrywell 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/
bpeppleI 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.
jds2001but i dont really think it should have been, imo, knowing what we do now.
not to say that both items aren't really cool.
nirikit's main advantage to end users might be higher quality packages... but thats really hard to measure.
f13transifex was really a service for beyond Fedora contributors
* rishi nods
bpeppleI don't think this meets our definition of being a feature. http://fedoraproject.org/wiki/Features/Policy/Definitions#Definition_of_a_Feature
nirikyeah... not that it's not important and useful. ;)
bpepplenirik: correct.
jds2001so 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
jds2001i 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_chaudhryThanks ... We just thought telling telling the world "We care more for our packages ..." is a feature. :) We will do it :)
zodbotjds2001: #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
jds2001i see 6 +1's, so lkundrak's request has been approved.  I'll take care of that after the meeting.
jds2001.fesco 14
zodbotjds2001: #14 (New Sponsor Request: Itamar Reis Peixoto) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/14
jds2001there 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
nirikyeah, do some reviews, then come back. -1.
j-rodnot yet
jds2001i 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:'(
jds2001itamarjp: dont give up, we just dont have any basis to form an opinion right now.
on to features...
jds2001.fesco 19
zodbotjds2001: #19 (CUPS PolicyKit Integration) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/19
j-rodjds2001: wasn't there a sponsor request for kevin koffler too? is that happening next week instead?
bpepplej-rod: next week.
jds2001j-rod: yeah, next week.
j-rodok, cool
* mclasen is here, can try to answer questions
jds2001so any questions on the CUPS-PK feature?
mclasen: cool :)
nottinglooks good to me. +1
* nirik notes docs has "FIXME: None, currently"
jwb+1
mclasennirik: well, there are no docs, currently
jds2001+1 here, fix the docs :)
j-rod+1, and what they said
bpepple+1
niriksounds 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.
mclasenif he does, he's encouraged to tell us...
jds2001I see six +1's, so FESCo has approved the CUPS PolicyKit integration feature
.fesco 20
zodbotjds2001: #20 (Debuginfo Revamp) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/20
* nirik nods. Just thought I would mention it.
nottingmclasen: 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
mclasenyes, that would be nice
I've mentioned that to the relevant parties repeatedly :-)
jds2001roland 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.
nirikalso, mass rebuild would be better sooner than later.
jds2001looks like some pretty big changes.
nottinggiven 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
nirikwell, knowing if there would be a mass rebuild I mean.
jwbis it backwards compatible?
jds2001would the new gdb (if we go that route) be able to take old debuginfo packages?
or what jwb said :)
nirikroland is not around right? (I don't think I have seen him on irc ever)
jwbhe's on irc
j-rodhe hangs out in #fedora-kernel
bpeppleI 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.'
jwbwhether he's available, i have no idea
* j-rod pings roland
jwbok, so to be honest, this is one of those features that is going to go into rawhide regardless of what we say
nirikjwb: probibly.
j-rodstill early-ish on the west coast
notting"DWARF tool + rpm deployment plan could include exploding in %post to current layout. "
that's just wrong.
bpepplenotting: that's what I was thinking also.
I'd like to hear from Roland on that, before approving this.
jds2001yeah, how do you remove it then? Are they planning to %ghost the stuff or what?
nottingi'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-rodyeah, I'd say defer this one for now, needs more questions answered
* jds2001 changes his early vote
nirik is fine deferring too.
bpepplejds2001: to late, your already committed. ;)
nirikis someone going to update the talk page there?
jds2001i 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
zodbotjds2001: #21 (ext4 default filesystem) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/21
jds2001no sandeen :(
jwbhe's coming
j-rodthere ya go
sandeenhey gang
jds2001sandeen: :)
j-rodso. just how scary is making ext4 the default for f11? :)
sandeenyou all have been helping test it, right?  :)
wwoodsooh are we going to play point/counterpoint?
sandeenthere is some scariness
j-rodyup. my laptop is running ext4 now
sandeenbut by and large it mostly seems to be working well for most people
* nirik is running it here on a server box... working fine.
sandeenthere are some known bugs; filesystem shrinking needs fixing
jwbdoes 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!
sandeenwwoods, 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
wwoodsI will summarize as: increased complexity and reduced stability on an unproven filesystem is not a good tradeoff for near-negligible gains in performance
sandeenbut 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
wwoodsext4 is not particularly useful for most users
as a personal anecdote I've had terrible luck with it
j-rodbut, but, but, moronix says its super-fast on ubuntu...
wwoodsI fully support it being available as an option in anaconda with no special boot args needed
nirikhttp://www.smolts.org/static/stats/stats.html
j-rodit was a bit fail in the f10 kernel and the first update kernel, but solid in -159 for me
sandeenwwoods, 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 ....)
drago01can't we just test it? reverting to ext3 as default before GA should be easy if needed
wwoodslet's take these one-by-one
sandeendrago01, there is some risk there of ext3 not getting good testing as a result
j-rodI'd definitely say make it chooseable in anaconda w/o a flag
jwbsandeen, 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-roddoes ext3 really need more testing?
nottingj-rod: it already is
sandeenjwb, yeah, if we focus on ext4, bail at the last minute, ext3 has been short-changed
j-rodnotting: ah, in rawhide?
wwoods"scales better" - useless for anyone with filesystems / files in the sub-terabyte range
drago01sandeen: wtf? it got more than enough testing already and still get some upstream
j-rodhaven't actually tried a rawhide installer recently
wwoods(i.e. almost everyone)
nottingwwoods: you've obviously  never run liferea (it's like firefox was. but worse.)
jwbsandeen, seriously?
sandeenjwb, drago01 I'm just being pedantic about qa
wwoodsnotting: okay, fair
sandeenodds are it's fine, but alpha fedora releases have uncovered ext3 bugs in the past
wwoodsbasically, here's the thing
drago01wwoods: and rpm calling fdatasync sucks too on ext3
wwoodsit's *dead simple* to convert an ext3 filesystem to ext4, right?
sandeenFSVO convert, yes
wwoodsFSVO?
j-rodyeah, you don't get the full benefit if it was ext3 to start
nirikdoesn't get all the features converting IIRC
j-rodfor some value of
sandeenyou can very easily tune2fs and mount with extents, new files are in ext4 format
niriks/ext3/ext4/ you mean
wwoodsso: 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
jds2001wwoods: somewhat upgrade.
wwoodsokay: "upgrade in place, with the caveat that they won't get some of the nice features thereof"
dwmw2_gonethey can upgrade in place to btrfs and get the features :)
sandeenTo be honest, yes, some of the motivation is to advance ext4's robustness by foisting it on the masses :)
jwbplease no
wwoodsd) once converted, ext4 filesystems can't be mounted as ext3 anymore
dwmw2_LHR(sorry I'm late)
sandeenwwoods, that's mostly true.  with a lot of hoop jumping you can go back.  it's not great
wwoodse) we lose some features of ext3 (fs shrink, for example)
sandeenwwoods, that will be fixed
it's just a bug
jwbby F11?
sandeensure
zlessi'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-rodhow many users actually shrink their fs?
wwoodsokay, fair, strike e)
jwbj-rod, i would say more than a few
dwmw2_LHRwhen will we have shrink working?
sandeenum, when is alpha released? :)
wwoodsI'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_LHRhow many users shrink their fs _immediately_ after installing it? :)
drago01wwoods: "d)" the feature is about new installs no converting
j-rodhuh. I think I've done it... never.
sandeenTBH I haven't looked into the bug yet, just got obvious when I used ext4 to make a livecd
wwoodsdrago01: either way. ext4 filesystems - created or converted - can no longer be mounted by ext3 tools/modules
sandeenthe fsck phase of the process found errors
jeremyj-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
drago01wwoods: ok
j-rodaha
nottingback in 2 min, sorry
sandeenjeremy, FWIW the fsck phase *seemed* to fix the errors :)
I haven't been able to make it boot yet (on ext3 either)
wwoodssandeen: 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-rodpeople w/other OSes could still pick ext3 if they must
sandeenwwoods, 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"
sandeenthe 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
wwoodsis really not a compelling argument to me
dwmw2_LHRwwoods: we have/had similar compatibility concerns with selinux labelling anyway, surely?
shared /home isn't _that_ feasible
jds2001at some point, we're going to have to bite the bullet and do it.
j-rodyeah
jwbjds2001, no we aren't
wwoodsI'm sorry, but that's baloney
unless "at some point" is "when btrfs is ready in a couple years"
dwmw2_LHRI don't think btrfs is that far out
j-rodso even when its rock-solid, performs better all over, we'd still not default to it?...
wwoodsI agree that sometime in the next couple of years we're going to need to mass-migrate our users to a new filesystem
jwbbtrfs as default is like an f13/f14 item
dwmw2_LHRalthough it _does_ need a lot more stabilisation. It's a lot newer than ext4
wwoodsI don't think now is the time
sandeendwmw2_LHR, more than just stabilisation
ENOSPC handling would be nice, for one :)
jwbwhich means, can we live with ext3 for f11, f12, f13?
f13damnit, I need to make it sot hat we don't ship F13
sandeenI'm impressed w/ the pace of development but don't underestimate the time it'll take
f13well, 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
wwoodsf13: right, that's what I'm saying
f13just to avoid default switching frequently
jeremyremoving 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)
f13but then again, it is Fedora, so meh.
dwmw2_LHRsandeen: true, but stabilisation is the major thing. ENOSPC is part of that
as is ENOMEM handling :)
f13: that makes sense to me
rwheelerext4's fsck time improvements alone will make a vast improvement for users - why the fear?
jds2001that sounds reasonable.
wwoodsrwheeler: vast improvement for *what* users
rwheelerany user with a disk larger than 200 GB (which is most of us)
j-rodusers that reboot their machines?
dwmw2_LHRfor 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
drago01non broken fsync
wwoodsI've never, *ever* seen *any* of my machines fsck at *all*
sandeenwwoods, you are a lucky man
wwoodsI'm really not seeing a lot of complaints about fsck being slow
except from people who manage a lot of storage
j-rodsure its not just hiding behind the boot splash?
wwoodsand those people can easily choose ext4
f13j-rod: no
j-rodwe still do an automatic fsck every x mounts
fsvo x
sandeenno, we tune that off in anaconda
f13j-rod: there are journal replays, but not full fscyncs
jwbj-rod, rwheeler: fsck does not run hardly ever
sandeenfscks.
rwheeleryou also will see a significant streaming write improvement
j-rodah
wwoodsj-rod: if that was the case my boot times would be unstable - they'd be long on the days I fsck and short others
f13j-rod: we stopped that insanity a while ago.
sandeenfscks happen when you get an error on your fs, or yo uhit the "fsck every BLAH mounts" misfeature
wwoodsright
j-rodmaybe its only when I keep crashing my boxes...
:)
wwoodsthat doesn't happen very often to anyone
jeremyj-rod: we turned off the auto fsck stuff when we first added ext3
sandeenf13, but mke2fs still defaults to having it on, so filesystems made outside anaconda get that treatment
rwheelerI 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
f13I 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-rodI 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.
rwheelerwwoods: not true at all, it is a routine thing in the real world
dwmw2_LHRit'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.
jwbrwheeler, then people that care can select ext4 as the fs
j-rodheh
mclasenf13: you can't really know how short the succession will be
sandeendwmw2_LHR, :)
f13rwheeler: does this real world contain people that just blindly accept defaults?
mclasen: it'll likely be shorter than ext2<->ext3 (:
jwbwhat bpepple +1
wwoodsseriously we can revisit this at F12
sandeenf13, fsck isn't about option choosing
rwheelerext4 is the evolved version of ext3 with a misnamed subdirectory
wwoodsand Fthirteen
jwbrwheeler, if that were true, then ext3 could mount ext4 filesystems
wwoodsI really don't see the value in doing it now
rwheelerI think that we should treat it just like the major upgrades we did to x11, etc
* notting is +1 for ext4 as default
f13well, lets think of this another way
one that is likely not popoular here
f13does anybody rightly think that btrfs will be viable for RHEL6?
dwmw2_LHRrwheeler: do you know if we can do in-place migration from ext4 to btrfs, or only from ext3/ext2 ?
no
f13if no, is the desire for RHEL6 to have ext4?
jwbpoor argument
f13if yes, that's one hell of an argument for ext4 by default in F11
rwheelerthere are plans to allow the in place migration from both
dwmw2_LHRRHEL6 is... 12 months out? We'd want it to be default in F11 for that :)
jwbf13, that's an argument for RH
f13yes, yes it is
I told you it wasn't going to be popular.
wwoodsThe Fedora side of my brain sez: that's RHT's problem, not Fedora's
rwheelerext4 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_LHRit's a relevant question, even if it isn't popular
f13of 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
jwbdwmw2_LHR, by that token, we should ask what CentOS and yellowdog want
wwoodsI'll offer this as a compromise: do ext4-by-default for Alpha and Beta
jwbthey are both eventual consumers of fedora...
wwoodsrevist at Feature Freeze or thereafter
jwbj-rod, hey, what does mythdora want?
j-rodI'm +1 for making it the default. and beat the hell out of it.
dwmw2_LHRnot really, because we don't expect them to bust a gut if we _try_ it and shit hits the fan.
wwoodsif we get a lot of nasty problems we revert
j-rodwith a contingency plan... what wwoods said
sandeenjwb, ext4 will delete big HDTV files faster ;)
drago01wwoods: thats what I proposed just test it and go back if it is too broken
j-rodjwb: *cough* xfs
sandeenhehe
dwmw2_LHRjffs2!
rwheelersandeen the faster deletion is an issue for people as well....
wwoodsbut I'm really, really not happy about foisting this on our theoretical millions of users
sandeenyeah, if alpha explodes all over reverting to ext3 is easy.  it'd be embarassing, but easy.
jeremydwmw2_LHR: I thought ubifs was what the cool kids used these days... ;)
wwoodswhen most of them don't need it and it's not really proven
dwmw2_LHRjeremy: true :)
sandeenwwoods, we foist new stuff on our users ALL THE TIME
dwmw2_LHRI'm happier doing it in Alpha than in the real release :)
j-rodthis *is* rawhide we're talking about... :D
dwmw2_LHRcan we try it just for the Alpha, then turn it off. Then make another decision before beta?
sandeendwmw2_LHR, hehe, so the plan is "add it to alpha and revert in beta?" :)
jeremysandeen: 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)
sandeenjeremy, I'll look into it.  probably.
dwmw2_LHRsandeen: well, add it for Alpha and reconsider for beta, once we have more information
rwheelerwe have enough fs developers working in rhel & fedora to support this very well (not to mention the IBM/SUN and others)
f13I 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
jeremyalthough I guess we probably need to ensure that anaconda copes for live installs with either case regardless of the default
jds2001ok, I've completely lost count. Who is +1 to this? Current proposal is "enable it, revert at feature freeze if it eats babies"?
f13but really, I don't care, that's a minor argument from my part.
wwoodsokay, 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)
wwoodsto include some *testable* metrics for speed and reliability
* sandeen wishes we had a filesystem people *were* begging for
dwmw2_LHRwwoods: to test it, we put it in Alpha :)
wwoodsrevisit at alpha, beta, etc.
dgilmoredid we start an hour early?
nottingmy argument is: fedora is about shipping the best of what's available today. that's ext4 right now, imo
jds2001dgilmore: we start at noon now :)
dwmw2_LHRI'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)
jds2001noon eastern, that is :)
wwoodsif it fails to meet the stated specifications, we revert to ext3-by-default
f13notting: that's a good argument.
dwmw2_LHRs'true
dgilmorejds2001: its noon now
sandeennotting, have you been using it?  good experience, problems, ?
nottingsandeen: no :)
j-rodyeah, what notting said. and then we just keep a *very* close eye on it
sandeenhehe
jwbso we're going round and round
need to vote
j-rodI've been using it quite a bit, very few issues, and those I have had, have been quickly fixed
+1
dgilmoreim +1 for ext4 as default unless we plan to switch to btrfs in F-12
wwoodsremoving 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_LHRI'd vote +1 to 'in Alpha, reconsider for beta', and vote 0 for 'in Alpha, reconsider if it _really_ goes tits-up'
jwbdgilmore, that is a silly way to vote
rwheelerbtw, we have pounded a lot of data through it with the rh performance guys and the HP big system guys
wwoodsdwmw2_LHR: we won't.
dwmw2_LHRrwheeler: yeah, that's no substitute for real users :)
phrofwiw, I've been using it on my development system for 6+ months, and it's not had any problems.
dgilmorejwb: perhaps.  i just dont think we should go switching the default file system 2 releases in a row
dwmw2_LHRwe're not switching to btrfs in F-12. Not as default
dgilmorejwb: so if we think we might want to switch to btrfs in F-12 id rather just wait till then
wwoodsbtrfs won't even be considered for defaulthood until F13 at the earliest
dwmw2_LHRI'd _like_ to be able to, but it ain't going to happen
nottingwwoods: i'll put a beer up that we'll be doing more OMG AAARGH kernel respins for modesetting than ext4 :)
jwbi vote 0
jds2001in F-thirteen we'll visit that.
dgilmorethen +1 for ext4
jds2001+1
dwmw2_LHR
rwheelerhard to get real users until we have more than one non-boot partition by default for new fs'es :-)
wwoodsfor F11 you'll need to put 'icantbelieveitsnotbtrfs' or something to enable it in anaconda
dwmw2_LHR:)
wwoodsnotting: I wouldn't bet against you on that one
* nirik got a phone call. Reading back up.
jds2001dwmw2_LHR: you have to vote in whole numbers :)
jds2001oh, you did.
nirik+1 from me, if it blows up, we fire contingency plan.
wwoodssandeen: 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_LHRI'm not too worried about the bugs aspect
jds2001i 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.
wwoodsesp. tests for things like rpmdb corruption that have been seen in the past
sandeenwwoods, we can try something like that.  it'll be weasily; I can pick a test I can pass :D
dwmw2_LHRI assume that if it breaks, sandeen won't sleep till it's fixed, with rwheeler standing over him with the whip
jds2001geez a lot left.
wwoodssandeen: 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
zodbotjds2001: #22 (Gnome 2.26) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/22
* mclasen still here, can try to answer questions
jwbwait
so did ext4 pass?
ah, yes
sorry
wwoodssandeen: 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
jwbproceed
rwheelerdwmw2_LHR we certainly have a focus on getting ext4 stable so we can get our fs people onto btrfs
wwoodsso 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.
jwbi'm +1 for Gnome 2.26
sandeen(sorry, carry on)
jds2001+1
nirik+1, no brainer, should trumpet.
notting+1
j-rod+1
mclasenbusiness as usual, really
jds2001i see six +1
McGiwer mclasen
bpepplemclasen: yeah.
nirikwhen is 2.26 scheduled to release?
jds2001so we've approved the gnome 2.26 feature
jwbmove on!
j-rodyeah, not much question here. next!
jwboh crap
i'm supposed to do minutes
nottingspeaking of, did we already approve the kde-4.2 feature?
dwmw2_LHR+1
hah
bpepplejwb: should be fun. ;)
mclasennotting: its on the approved list
jds2001jwb: i can send you the log if needed.
jwbbpepple, summaries are wonderful :)
jwbjds2001, nah, i think i have it.  if i don't, i'll ask you
jds2001.fesco 23
zodbotjds2001: #23 (Live System for the DVD Image) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/23
jds2001so this looks like more of a wishlist item to me.
jwbi added some comments on the discussion page here
jds2001and not a very likely one, either.
jwbit's not even technically possible for anything other than i386
-1
nottingis the submitter actually doing the patches for pungi?
jwbi dunno.  i asked about that
jds2001didnt see anything to that effect.
jwbthere's no patches, and no space on the x86_64 or ppc DVDs
jds2001only pungi patches ive seen recently are from notting
nottingjwb: 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...
f13yeah, I don't see this happening without somebody doing a lot of work
and I've already got too much work
nottingalso, it gives you a rather bizarre installation choice in that you'll be installing two different things depending on which boot option you choose
jwbyeah
dgilmore-1 as its really only feasable for i386
j-roddual-layer DVD image ftw!
jds2001-1 here too.
j-rod-1
bpepple-1
drago01jwb: "it's not even technically possible for anything other than i386" lets move to DL DVDs ;)
f13I 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)
dgilmorej-rod: dual layer dvd's are still not really an option
jwbdrago01, buy me a burner and media and we can talk
jds2001i see six -1
f13we could do live bluray with the full rpm set on it for choose your own adventure installs
dgilmoref13: sick puppy
j-roddgilmore: yeah, just being a jack-ass. :)
jds2001so we've declined the LiveCD on the install DVD
f13it'll take a week to mirror it, but...
* dwmw2_LHR wonders if we could manage tri-boot i386/x86_64/ppc install discs
dwmw2_LHRshouldn't be hard...
f13dwmw2_LHR: you get right on that (:
jwbhave fun
j-rodeven better: fat binaries w/all four arches in them.
jds2001ok, last feature :)
j-rodsingle disc image for everything
dgilmoredwmw2_LHR: it could be done.  but would have to be dual-layer dvd or blue-ray
jds2001.fesco 25
zodbotjds2001: #25 (Xfce 4.6) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/25
drago01jwb: 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:(
dgilmoredrago01: you have to have puchased a dvd burner in the last couple of years for dual layer support
jwbnirik999, so i asked a question about xfce since release is now set at feb 6
jds2001nirik999: we're on to xfce 4.6
nirik999great.
please re-ask, as my dircproxy hasn't reconnected yet.
drago01dgilmore: yeah
j-rodisn't this more or less the same sort of thing as new gnome and kde? or is there more to xfce 4.6
wwoodsnirik999: 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?
nirik999j-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
nirik999notting: yep. 4.5 was a devel cycle.
dwmw2_LHR+1
jds2001i see six +1's, so FESCo has passed the Xfce 4.6 feature
jwbi'll assume the answer to my question was "yes"
+1
nirik999upstream 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.
jds2001alrighty, on to other business.....
jds2001.fesco 10
nirik999for 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. ;)
zodbotjds2001: #10 (Review list of non-provenpackager committable packages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/10
jds2001nirik999: hehe :)
nirik999wwoods: no, should I be?
wwoodsonce again - XFCE46's Scope section should include more detail about what's changing, so we can write a test plan to test the changes
nirik999wwoods: agreed, I can try and improve it...
jds2001so I was thinking that we'd discuss what constitutes acceptable criteria for a package *not* to be provenpackager committable.
jds2001helps to have that prior to reviewing the list.
abadger1999jds2001: 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.
jwbpronto would be an exaggeration i think
jds2001abadger1999: i dont think pronto.
nirik999I'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?
dgilmorejds2001: i think packages that if patched incorrectly will break the world
f13nirik999: that isn't fixed, and might not be fixable with cvs itself.
dgilmorei.e. binutils gcc kernel glibc
f13those 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
dgilmoref13: sure they can always choose to open them up
jds2001what about security system packages, ala openssl, openssh, nss stuff?
f13we can then roll that into either acceptable criteria, or unacceptable.
bpepplef13: agreed.
jds2001s/system/sensitive
nirik999so, if thats not fixed, I do see a need to have closed packages. ;( Thats a reason to switch vcs's or setup IMHO.
f13this is one of those things where you can't envision every possible critera, and you have to roll with the requests as they come.
dgilmorejds2001: true,  we dont want a debian esque incident
dwmw2_LHRf13: true, although having guidelines doesn't hurt
nirik999I agree... lets email the maintainers who have closed and ask them?
f13nirik999: 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_LHRI think the plan stated before was that we'd let maintainers come to us and make their case
nirik999if it was fixed, I would see no real reason to close provenpackagers personally.
dwmw2_LHRand after a month or two, we'd open the packages we hadn't approved
we should call on the maintainers to do that
jds2001can do.
jds2001dwmw2_LHR: you saw the summary from our face-to-face meeting i guess?
jds2001about reseeding provenpackager w/sponsors?
bpepplejds2001: any reason why that turned from a proposal session into a decision?
jwbbpepple, majority vote was present
jds2001bpepple: i thought it was a decision :)
bpeppleIt would have been niced to have been given an option to way in on that.
jds2001and majority was at 6
jds2001bpepple: sorry :(
bpepples/way/weigh/
dwmw2_LHRjds2001: yes, I did. thanks.
bpeppleseemed like it was rammed through without any of the folks that might have dissented from being allowed to vote.
dwmw2_LHRwell, if they were quorate...
I have no particular objection to it, although I probably wouldn't have voted for it
bpepplebut 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.
f13I 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
jwbi 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. ;)
f13jwb: mail advertisement, non-fesco participation, etc...
* jds2001 too :)
bpepplef13: 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.
f13and well, the rahul effect
anything to avoid the rahul effect.
jwbsorry, but it was known from the last IRC meeting we were going to talk about this
jds2001bpepple: it was pitched as a barcamp session at paul's recommendation
and we did have non-fesco members present.
bpepplef13: 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.
f13bpepple: yeah, I agree with you.
jds2001do we want to re-vote now?
just for the record?
nirikbpepple: yeah, sorry.
bpepplejds2001: 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.
jds2001noted :)
anyhow, anymore on this?
* jds2001 takes that as a no, will follow up with individual maintainers.
jds2001.fesco 11
zodbotjds2001: #11 (Review FPC report) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/11
jds2001this is the FPC report that we missed last week.
and FPC has one other item as well.
jds2001.fesco 18
zodbotjds2001: #18 (FPC item for approval) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/18
* bpepple doesn't have any objections.
* jds2001 either, +1
j-rodno objections to anything here
nirikwell, 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...
f13The naming of fonts causes some pretty ... fun ... things to go in specs/macros
dgilmore+1
nirik+1
f13and some unexpected subpackage names
heavy use of -n going on, which is always a treat to debug
j-rodhm. 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-nimjds2001: world domination!
nirikfont 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.
jds2001seems worthy
nim-nimand cleaning up the huge pile of mispackaged fonts in the distro
f13the 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_LHRsounds good to me as nirik describes it
abadger1999There was no actual font naming guideline before.  nim-nim and FPC had several proposals and counter proposals before arriving at this naming convention.
nim-nimwe 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
jds2001jwb, notting?
jwb+1
nim-nimjwb: thanks
jds2001ok, 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
zodbotjds2001: #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-nimthank you
bpepple+1 to ovm, for pretty much the reasons that spot pointed out in the bug report.
nirikso it's a simulator where this is no free content.
(yet)
j-rod+1, it'll help enable development of a free sim
dwmw2_LHRwhat are the chances of free content?
dgilmorenirik: reverse
nirikah, ok.
dgilmoreits content with no free way to use it
* nirik reads the bug.
nirikbug 474980 for those following at home.
buggbotBug 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?
jds2001notting: there's hope for a free way to use it.
nottingah, ok
nirikwhy not just wait for those, package them and approve this after one of those is in?
why does adding it now help?
jds2001chitlesh is not around :/
* jds2001 wishes he could answer that, supposedly it will spur development or something
nirikthat seems strange to me... perhaps I am missing something
* jds2001 too
jds2001spot: do you have any insight on ovm other than what's in the bug?
dgilmorenirik: i dont get it either
nirikit 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.
dgilmorewould we allow something that can build without oracle,  but would only run with oracle as a db?
nottingspacewalk?
nirikdgilmore: we do already I think... there are some perl modules.
dgilmorenotting: it needs oracle to build
nirikbut they are mostly converters, not sure if they need oracle, or just data dumped from it.
dgilmorejust 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
abadger1999amazon s3 and flikr libraries.
dgilmoreabadger1999: they dont require non-free bits on your machine to be useful.
abadger1999Unless you count the js loaded by your browser :-)
nirikI guess it comes down to does this "enhance the users experence"
dgilmorei guess to me that it requires non-free bits on your local machine to be useful makes it a no go
nirikin the case where someone already have whatever commercial thing needs to run this, being able to yum install it would be nice.
dgilmorenirik: sure
nirikbut for anyone else it's a loose.
j-rodsomeone could want to install it to work on a free replacement, no?
jds2001j-rod: i think that's the goal.
dgilmorej-rod: they could
j-rodsure, there are probably very few people who actually want it...
nirikpopularity is not part of the criteria. ;)
j-rodbut 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
nirikhumm...so there are some free tools in alpha...
bpepplej-rod: correct.
j-rodso I'm still +1 for this
bpepplestill +1 to this also.
nirikI think I am ok with it as long as their are some free tools to use it...
jds2001+1 here as well
dgilmoreid like to see the alpha tools in, even if there not completely uesable
it would make me feel better about it
nirikyeah, 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
nirikso, where are we? ok, but add a note asking to package/review/approve the tools first?
jds2001i believe so.
dgilmoreid like the tools at the same time
so +1 from me with the proviso that the tools get added also
jds2001i see five +1's, so we'll allow this content provided that iverilog gets packaged at the same time.
jds2001that's the end of the agenda, anything else folks wanna bring up?
--- jds2001 has changed the topic to: FESCo meeting - open floor
bpeppledo we still want to have our irc logs here: http://bpepple.fedorapeople.org/fesco/, or somewhere else now that we are rotating meeting summaries?
nottingdo we just want to do the other open sponsor requests while we're here?
jds2001sure, we could do that.
bpeppleyeah, I'm fine with doing the other sponsor requests.
jds2001.fesco 15
zodbotjds2001: #15 (New Sponsor Request: Ian Weller) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/15
dgilmorebpepple: probably should look at putting them on fedorahosted
nirikbpepple: wiki?
jds2001so there were some objections here.
bpepplenirik: doesn't that screw up wiki searching still?
dgilmorejds2001: -1 for Ian,  id like to see more reviews and participation in the review/packaging process
jds2001bpepple: put them in teh Meeting: namespace
nirikbpepple: don't think so, as long as it's in Meeting:
bpepplejds2001: -1 to ian.  In my opinion he needs more package reviews.
nirikyeah, ianweller needs to do more reviews
j-rod-1, same concerns
jds2001-1 here, too - didnt realize the lack of package reviews.
nirikI'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 :)
dgilmorei count 4 -1
notting0 for now
nirik-1 for now... come back with reviews done. ;)
jds2001i 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
zodbotjds2001: #16 (New Sponsor Request: Kevin Kofler) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/16
nirik+1
jds2001+1, a no-brainer.
nottingi was confused, i thought he was one already. +1
bpepple+1 here also.
dgilmore+1 for kevin
he is doing amazing work
jds2001i see five +1's, so we have approved Kevin's request.
anything else?
mitrhttps://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)
nirikmitr: seems like a good thing to have. Lots of packages/interface with lots of groups.
mitrIs there a mass rebuild planned?
* j-rod has other work to tend to, needs to disappear or at least pay less attention
jds2001mitr: none at present, no.
bpepplemitr: As far as I'm aware I don't think one is planned at the moment.
nirikmitr: not that I know of yet.
gcc 4.4.0 just landed tho
f13it landed in a side collection
well not fully built either
nirikyeah, branch in cvs at least it looks like.
dgilmoref13: is there features in gcc-4.4.0  that would benefit from a mass rebuild?
dwmw2_LHRre StrongerHashes... looks like a sane plan
f13I think jakub has mumbled something about it
dgilmoref13: we should plan on doing one
f13there could also be rpm features to enable, like sha256 checksums
dgilmoreid like to see noarch packages included
nottingideally, schedule just one that handles sha256, gcc, debuginfo, etc.
f13dgilmore: that's what feature pages are for
nirikis the rpm lzma stuff ready this cycle?
f13notting: that's the idea
dgilmorei guess sha256 will require all package get rebuilt
nottingnirik: i thought lzma changed ABI, or format, or something
nirikwell, it was in alpha last time... but no idea if there has been progress... need to ask Panu.
tibbsHey, they finally named the gcc specfile properly!
niriktibbs: 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!