bpeppleFESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod
* nirik is here.
sharkcz here
j-rod here
jwb is here
bpeppleanyone want to run the meeting?
* bpepple takes the silence as no else wants to.
bpeppleok, let's get started then.
FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets
* dwmw2 here
bpepple.fesco 38
zodbotbpepple: #38 (DebugInfoFS - https://fedoraproject.org/wiki/Features/DebuginfoFS) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/38
jwbwwoods, around?
bpepplewwoods just pinged me a couple of minutes ago that he couldn't make it.
bpeppleif we've got questions any questions regarding the feature we can push it to tomorrow.
nottingi'm all for it - +1. i don't speak for infrastructure, though :)
bpepple+1 here also.
dwmw2I'm slightly confused about versioning
does it cope if clients aren't completely up to date?
jwbgood question
pjones, ping?
nottingback in 2-3 minutes, sorry
dwmw2I'd also be a little happier just getting gdb to look up the debuginfo files with http directly or something, rather than having a mounted file system
jwbdwmw2, that sounds a bit more involved
considering you need debuginfos for multiple things, and the package names aren't exactly obvious at times
i think the fs is a nice approach, but your versioning question makes sense
nirikI wonder about loading issues, but I guess not too many people would debug things...
dwmw2I'm scared of internet-mounted file systems.
I expect processes poking around ih them to be stuck in D state while my poxy DSL line yoyos
* dgilmore is here
dwmw2I'd be _much_ happier if we just kept it in userspace.
jwbit is?
it's done via fuse and webdav
dwmw2it's still a mounted file system.
goes from userspace (gdb) to kernel (fs) and back again to fuse.
when gdb could have just used http for itself :)
dwmw2seems overly complex
bpepplehow about we add the versioning and file mounting question to the discussion page, and push this to tomorrow?
sharkczbpepple: yes
nirikbpepple: +1
bpeppleis there any other questions in regard to this? Or should we move on?
jwbmove on
bpepplemoving on....
.fesco 40
zodbotbpepple: #40 (OpenChange - https://fedoraproject.org/wiki/Features/OpenChange) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/40
bpeppleis mbarnes about?
this feature looks fairly straight forward.
niriksome of the reviews were stalled looking... let me see.
jwbyeah, my only question is the alpha snapshots of samba4
bpepplejwb: yeah, that's the only thing I'm a bit concerned about.
nirikthere is question in the review of how they want to package it, and no package yet for formal review...
nottingthere are 4 reviews listed in the feature
jwbsamba4 could be a feature in and of itself
but using alphas for it seems... spooky
nottingsamba4 isn't ready yet for a 'full' release - this is just using some of its libs
jwbwhat were the legal concerns with samba4 and how were they resolved?
nottingi don't know of any legal concerns other than it was gpl3?
jwblook at comments 36 and 37 in the review bug
spot, !
nottingen route to fosdem
ok, i guess it doesn't matter too horribly much if they are resolved
bpepplejwb: yeah, if the packages don't pass review obviously the feature will be dropped.
notting+1 from me
jwbare samba3 and samba4-alpha parallel installable?
sharkczit is the goal
jwbi'm +1 providing that turns out the be the case
nirik+1 from me, if it doesn't make it there is always f12 just around the bend. ;)
bpeppleok, I see five '+1', so we've approved the OpenChange feature.
anyone have anything else to add? Otherwise onto the next feature.
.fesco 39
zodbotbpepple: #39 (Firefox 3.1 - https://fedoraproject.org/wiki/Features/Firefox_3.1) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/39
jwb"There is no turning back"
i like the honesty
bpeppleyeah, that was nice.
notting'private' browsing mode. woo euphemisms!
jwbthough i wonder why the testsuite isn't run on ppc/ppc64
bpepplenot sure.
anyway, I see five '+1' so we've approved firefox-3.1 as a feature.
.fesco 43
zodbotbpepple: #43 (Repackaging of Fedora Fonts - http://tinyurl.com/cuorqt) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/43
bpepplenim-nim: ping.
jwbhow is this a feature?
bpepplejwb: I'm not sure that it is.
j-rodwtf? fonts again?
jwbso i'm of the opinion that this is something that just needs to get done
warrenThis doesn't seem like something worth mentioning as a bullet point in feature lists.
bpepplejwb: yeah, I'm of the same opinion.  I don't think it meets our definition of what a feature should be. https://fedoraproject.org/wiki/Features/Policy/Definitions#Definition_of_a_Feature
nottinghm. it's big enough that it probably needs tracked from a QA perspective
bpepplenotting: yeah, but I'm not sure if it's something we need to advertise.
jwbyes, but do we need to advertise that we renamed all our font packages?
* nirik999 votes -1000 to the intel video lockup feature that f10 currently has.
* bpepple sees that he's parroting jwb today.
abadger1999This is more than renaming...
nottingi'd poke wwoods as to if he's got a place to track these sorts of things, but he's not here
abadger1999nim-nim wants to do an audit of everything... pulling fonts into new packages, getting rid of things with no license, etc.
jwbabadger1999, and?
how is that any different from, you know, following the guidelines on a daily basis and addressing issues as they are found?
sharkczit is more an administrative work then a feature
abadger1999jwb: Is completion of the merge reviews going to be a feature?
This would be a similar task.
bpeppleabadger1999: I don't think merge reviews would be a feature.
nirik999well, this is more user visible tho isn't it?
new font names, more fonts, some normal scheme for naming font packages.
nottingnirik999: if we get the obsoletes right and the comps groups right... not really
jwband if we don't, it's a bug
abadger1999<shrug>.  nim-nim is the driver... you probably want to ask him for clarification.
abadger1999He might have filled out a Feature page and really just wants FESCo to say he has the authority to make these changes.
nirik999yeah, I suppose... is this something we want to tout tho?
nottingProposal: FESCo says this is not a feature, but is in favor of the initiative, and would like it to remain somewhere trackable for the purposes of QA.
bpeppleabadger1999: I think it definitely a worthy goal, but I don't really think it's something we should be trumpeting as a feature.
notting: +1
sharkcznotting: +1
j-rod+1 for notting's idea
* nirik999 looks at the feature definition again.
nirik999ok, +1 for nottings proposal
dgilmore+1 to notting
bpeppleok, I see six '+1' to notting's proposal.
jwbthat's enough, yes?
bpepplejwb: correct.
anyone have anything else to add? Other we can move on.
* nirik999 notes nim-nim has done a great deal of work, and it's appreciated by me at least... keep up the good work on fonts. ;)
bpepple.fesco 36
zodbotbpepple: #36 (Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/36
bpepple+1 nirik
warrenDid everyone read Jakub's recommendations on f-d-l?
Today Jakub reiterated his recommendation:
jwbcan we delay this one until the end of the meeting
i fear we wont get to some easier stuff
warrenprobably wise.
bpepplejwb: yeah, we can do that.
sharkczjwb: +1 :-)
nirik999jwb: +1
bpepple.fesco 44
zodbotbpepple: #44 (Update description guidelines - http://tinyurl.com/c7geap) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/44
bpeppleok, so this proposal looks to clarify a little better what update descriptions should include.
nirikwhy are they called guidelines if they are not binding?
nottingwhere in the grand scheme of docs would this end up?
mintos mbonnet_ m_stone mmcgrath mizmo marek McGiwer mbonnet mbacovsk_ mitr
sharkczthe "update descriptions" points 1+2+3 can be automated when doing updates via bodhi CLI
jwbnotting, maintainers section of the wiki?
f13nirik: because as a project we horribly misuse the term 'guideline'
nirik: in the real world, a 'guideline' is there to guide you or help you, whereas rules or laws bind you.
nirikyeah, perhaps. I would think 'best practices' or the like might be better
f13the Packaging Guidelines were first meant to be best practices, but then a lot of MUST things showed up vs SHOULD things
and now any "Guideline" in fedora is immediately seen as a binding law. :/
nirikyeah. We should fix that someday...
jwbwhich won't be today
i'm +1 for this proposal
dgilmore+1 better info for users is good. though im sure many will never read it
nirikI think we should also look at pushing more info into bodhi (ie, have it describe what should be in the text more, etc) also, perhaps it should have a link to whever this lands on the wiki for maintainers?
but yeah, +1
f13nirik: yeah, that can be done inclusive of this change.
f13I'm sure lmacken would love to see some patches (:
sharkcz+1, but needs some support to make it easier for packagers to fill the info
j-rod+1 too
jwbsharkcz, like what?
sharkczjwb: like moving bug numbers from spec file changelog into bodhi, etc
nirikwho is responsible for making this land in the main wiki and updating any wiki pages (and sending to fedora-announce)?
notting+1 for the proposal
bpeppleok, I see seven '+1', so we've approved the update description guideline proposal.
jwbnirik, i'll bug markmc about it
bpepplenirik: Usually the person that writes up the proposal.
nirikjwb: great.
nirikbpepple: yeah, not sure who that was in this case tho.
bpepplealright, moving on...........
.fesco 45
zodbotbpepple: #45 (provenpackager proposal - http://tinyurl.com/aozrfm) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/45
bpeppleboy, there is not much I like about this proposal.  abadger1999 summed up pretty well my thoughts about it.
nirikyeah, same here. -1 from me.
f13from the outside, I don't tlik eit
f13requires too much infrastructure we don't have in place, nor anybody to work on it
nirikI do welcome proposals on this... but I don't think this one is the right way to go.
f13I appreciate the concerns, I just don't like the suggested implementation.
bpepple-1 here also.
nottingi agree with the solution overview
i'm ambivalent on the implementation
dgilmoreit seems harsh and way too restrictive.  but there needs to be someway to do this
nirikAs an alternate: Should we just handle provenpackager upgrades like we do sponsors? ie, gather feedback from existing provenpackagers and then fesco votes?
nottingis the reseeding blocking on this?
jwbnotting, i don't think so
bpepplenirik: possibly, though I hate to have that much bureaucracy.  If we were to do that why even have the provenpackager group.
just have sponsors be the 'provenpackager'.
jwbbpepple, we have that much for sponsors...
warrenwhy does fesco need to approve it?  certainly if enough existing sponsors or provenpackagers all agree, that should be good enough?
jwbwarren, why do we have to approve sponsors?
nirikso where are we on the reseeding?
jwbabadger1999 made the FAS changes
we just need to announce and do it?
f13warren: how do "enough existing sponsors or proven packagers agree" ?
abadger1999jwb: I made the packagedb changes.
f13warren: what mechanism do we have in place to record that?
jwbabadger1999, yeah, sorry
nirikok, so abadger1999 will do it, then someone announces?
warrenf13: if a small number of individuals are put in charge of counting, recording and adding membership, that should be good enough?
jwbyou mean a small number like 9?
jwbwhich is how many are in FESCo...
f13warren: that's the point I was making.  We already have a group of people doing effectively the same thing for sponsor nominations.
f13it's not that far fetched to use the same people and proceedures to do the same thing for provenpackager nominations
nottingi think the idea behind rsc's proposal was that he didn't want it all done over e-mail threads?
jwbwhy is that a problem?
nirikwell, in his proposal there is a vote threshold. So someone/something has to keep track of it.
aside from procmail filtering for +1/-1 email isn't too good for that. Especially if there is discussion thats not even a vote.
abadger1999he didn't want email (not sure why) and he didn't want just one person to be responsible for sponsoring.
nim-nimnirik: To clarify https://fedorahosted.org/fesco/ticket/43
nim-nim1. I don't think the fonts stuff needs to be a feature to get authority to tell packagers to apply official guidelines
2. I do think it's a ton of work that needs support by QA groups, and to be traced in release notes
3. and lastly, I'm quite sure that if completed it will have high user visibility, even if it's not "software" work
* bpepple really thinks this whole provenpackager fiasco has been FUD-produced.
j-rodbpepple: I agree entirely
f13provenpackager itself was an attempt to mollify some of the FUD
it just wasn't enough for some individuals.
f13FESCo has to decide if those some individuals are enough to continue worrying about
dgilmoref13: i dont think there will ever be enough for some
f13our round of opt-outable acl opening was a pretty big success I thought, maybe enough of a success to call this mission accomplished
dgilmore: I think you're right.
bpepplef13: so is the reseeding still needed?
f13I'd like to see it reseeded yes
I still prefer to see it filled with folks who want it and would use it, as opposed to folks who wound up there because they happened to own a certain number of packages
bpeppleok, so really we just need to determine what method/criteria we should have for approving new folks to provenpackager.
f13: I'm fine with reseeding.
nottingbpepple: the bastard move would be delegating the method/criteria to the sponsors, but i don't know if we have conditions we want to lay on it
nirikthats what f13's doc would do...
f13I posted suggested conditions
* nirik would be fine with f13's proposal, or just making fesco do them.
nirikI guess that doesn't say who's doing the approving (fesco|sponsors), just guidelines
f13I think most of my proposal can be wrapped around any body that does the voting
the meat of my proposal was what to consider when voting.
nottingnirik: right, that was the thread that led to rsc's proposal
nirikrsc: I don't suppose you are around (or you would have spoken up sooner I bet)
nirikwell, I would be ok with fesco voting on them if it would take care of rsc's concerns.
bpeppleMy main concerns with having FESCo vote on requests is that I can see us being swamped with requests initially, and having folks that want to do the work waiting until our meetings before getting approved.
f13couldn't it be done out of band?
bpepplef13: yeah, though we've had bad track records of doing it in the past.
sharkczlike vote in FAS?
abadger1999No,  No vote in FAS.
trac maybe. FAS, no.
warrenBTW, how is this a feature for F-11?
nirikthe problem with out of band is that it lacks ability for feedback or public comment...
bpepplewarren: it's not.  It was pushed from last week's meeting.
sharkcznirik: announce, some time for comments, then vote
jwbwarren, it's not labeled as a feature either
nirikso you mean like: .. ticket -> announce to fedora-devel, mail sponsors -> wait -> vote in ticket
warrensorry, misunderstood
I thought this was a feature meeting.
sharkcznirik: yes
bpeppleI guess my whole problem with the way provenpackager has morphed has been that we merged extras+core in the hope of making it easier for folks to work on packages, and we've seemed to add a new fence.
f13bpepple: conversely we're keeping people outside the project because folks don't want to sponsor newbies if they get keys ot the castle.
bpepplef13: yeah. I guess my hope was that provenpackager would make it easier for newbies to get in, and allow current packagers the ability to work on the fedora colllection as a whole.
nottingdoes someone have a specific proposal/statement they want to call to vote?
bpepplenotting: other than rsc's proposal I'm not sure there is one.
abadger1999Are we ready to reseed?
f13could FESCo vote on my proposed text ?
f13its just criteria, nothing about how to apply that criteria
nottinghrm, ok
dgilmoref13: i liked your proposal
bpepple+1 to f13's provenpackager criteria proposal.
dwmw2+1 to f13's proposal at http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html
nottingProposal: FESCo agrees with Jesse's criteria, but feels the proposal sent to FESCo was too complex and bureacratic. We welcome another proposal for sponsorship.
bpepplenotting: +1
dwmw2for clarification, which proposal was this?
bpeppledwmw2: https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal
bpeppleok, I see six
'+1' to notting's proposal.
bpepplemake that seven. ;)
ok, with that approved it probably doesn't make sense to do the reseed until we decide how to apply f13's criteria.
is that right?
bpepplejust making sure.
ok, so is there anything else to add about this? Or should we move on to the architecture feature?
.fesco 36
zodbotbpepple: #36 (Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/36
warrenDid everyone read the thread on fedora-devel-list?
warrenJakub reiterated today his recommendation:
<jakub> warren: yes, -march=i586 -mtune=generic for Fedora, -march=i686 -mtune=generic for RHEL
-march=i586 vs -march=i686 Spec2k indicates an average 1.1% performance benefit for i686. There are however only 12 different tests, only some of which are core libraries that matter (gzip, bzip2). gzip shows a slight improvement, while bzip2 is flat. Some individual tests even became slower. This is a 1) a statistically insignificant difference 2) not enough tests to prove conclusively anything. 3) tests do not reflect real world code-
paths that people would run often.
f13we mostly care about the Fedora side of things here
nottingwarren: that second part was yours, not jakubs, correct?
warrennotting: yes
notting(because 1.1% *is* statistically significant, as far as compilers go)
warrennotting: did you look at what the 12 tests were?
nottingit's spec
warren: my openbench tests showed 1-2% as well. tests included (aaaugh) mp3
warrennotting: although not consistently across the board of all packages.
nottingregardless, i think the question boils down to more do we want to support i586-class *machines* in fedora
warrenThey are still plenty useful, just not in the ordinary way most Fedora users know.
nottingif we don't, there's no point in building -march=i586. if we do, there's no point in building -march=i686
* nirik999 gets his second video lockup of the day. Perhaps I should upgrade to rawhide?
drepperit's not i586-class machines
the i686 architecture was defined with options, one is cmov
gcc has no option to disable cmov when -march=i686 is selected
cjbnotting: I think you want to support the XO (or hope you do, 'cause we're planning on basing our next release on F11), and it's not clear whether building i686 will hurt us.
(the XO is an odd position because we *do* have cmov, but don't have undocumented stuff like "long nop")
dgilmorewhat are the chances that if we drop i586 the world will scream at us until we bring it back?
nottingcjb: a basic assumption would be that if you're already running i686 glibc and kernel, then things should remain working
cjbnotting: I'd a little worried by that assumption, but I tend to agree
for example, what would, say, mplayer do?
nottingdrepper: 'i586, and Via C3'
* dwmw2 just ordered a shiny new via machine
kylemcjb, hand write all the code in assembler, and call cpuid itself to test.
warrenProposal #1: Go with jakub's recommendations as the default.
Proposal #2: As a separate matter, consider allowing i686 builds of individual libraries or applications if benchmarks show conclusive gains.
dgilmoredwmw2: send it back
cjbnotting: Are there Fedora builds that have an i686 kernel and glibc that I might be able to boot on the XO?
nottingcjb: the live cd
dgilmorecjb: the livecds do
j-rodProposal #3: go i686. make i586 a secondary arch.
warren#1 is important to decide now since it blocks mass rebuilds.  #2 is unimportant. I don't really care if it happens or not.
cjbok.  that's what's not booting at the moment, but I don't think it's because of i686 :)
dgilmorecjb: my initial concern was 1. rpm ( we will have to make it lie) 2. that corner cases will sigill
cjbdgilmore: right
yes, both of those.
nottingProposal #4 (bastard): go i686 + sse2, drop p2/p3, athlon. just to be really draconian (not very serious)
dgilmorerpm can be made to do what we want
sharkcz#3 but for F-12
kylemjust fwiw, we can do ultra-slow cmov emulation in the kernel for machines that lack it if we go to i686. my patch works.
jwbi have a question
warrennotting: I'm not against #4, although what do the benchmarks say?
cjbkylem: that's interesting
jwbglibc is built today with -march=i686 or?
drepper, ^
kylemcjb, no, it's really not. but i wanted to shut people up.
nottingjwb: there's a i386 build and a i686 build
dwmw2glibc.i686 is, I believe. But we also have glibc.i386 which isn't
jwbi see
warrenjwb: we ship glibc.i386 and glibc.i686
drepperglibc.i386 is basically i486
dgilmorej-rod: id say do F-11 .i586  and F-12 .i686  and transition off .i586 as a secondary arch then
dreppersince there is no support for i386 at all
jwbright, nptl requires at least i486.  knew that
sharkczdgilmore: +1
j-roddgilmore: yeah, that might be a decent compromise
jwbdgilmore, necessitating mass rebuilds in back to back releases?
dwmw2I might rephrase that as 'transition i586 to a secondary arch when secondary arches are actually working'
f13jwb: not necessarily
warrenWhy not decide on F-12 when F-12 comes around?  Focus on the decision for F-11 to unblock this mass rebuild.
j-rodmeh. i586 could be the first working secondary arch. :)
jwbwarren, it'
f13jwb: for F12, you chang ethe default, and drop the i586 kernel.  As packages get rebuilt they'll fall out as .i686 istead of .i586
jwbit's not blocked.  gcc 4.4 hasn't even landed
dgilmorejwb: yes/no  having somethings .i586 would still work fine with everything else .i686
jwbf13, true
nottingmy concern about i586 is that i'm not sure at the core level (kernel, libc, etc.) anyone still has hardware, is testing this sort of hardware, can fix it if it breaks, etc. i don't like to imply support for things we aren't able to fix
warrennotting: I have been
f13so yeah, the real question here is, does Fedora wish to continue supporting i586 class machines as a primary arch.
j-rodkylem: how ultra-slow?... :)
rsc(why not building everything as .i686 and just the kernel in both flavors, i686 and i586 and kill i586 for F12 or so?)
f13notting: I had an i586 via on order, but was never in stock.
kylemj-rod, well, cmov is supposed to have a two or three cycle latency, this would be, well, ten thousand times or more.
dwmw2what did we say the performance improvement of -march=i686 was? On the _whole_ system rather than a cpu-intensive benchmark?
bpepplersc: mirrors will probably revolt. ;)
nottingdwmw2: we have whole-system benchmarks?
f13rsc: .i686 packages on an i586 kernel aren't likely to work.
skvidalb/c the arch doesn't support that way
rscf13: I thought, cmov is getting killed anyway?
skvidalan i586 box won't see an i686 pkg as installable
jwbwe're thrashing here
f13dwmw2: likely not much above the things we already make i686 versions of (eg glibc/openssl)
nottingrsc: the fact that i686 benchmarks faster than i586 implies that cmov is occasionally useful. as that's the main (only?) added insn
kylemcmov is a win on atom. it's probably not going anywhere.
dwmw2so what do we actually _gain_ by dropping i586 compatibility?
f13Fundamentally, does Fedora wish to continue supporting i586 as a primary arch.
warrennotting: not much faster
drepperusing -march=i586 can expose problems is "tuned" code where the authors tried to be clever and has i586 asm code.  The impact could be big.
f13dwmw2: less kernels, less complexity in installers
nottingdwmw2: more clear matrix of support and focus
jwbdrepper, do you agree with jakub's suggestions?
dwmw2if we drop the i586 kernel, people could still rebuild that and not have to rebuild the whole of fedora.
f13drepper: does not that risk exist with -march=i686 ?
jwbdrepper, or do you have different suggestions?
f13dwmw2: we'd also be able to drop the glibc and openssl builds.
dwmw2I'm inclined to leave userspace as it is, and revisit the question when we have proper support for atom in gcc
drepperf13: no risk for reasonable machines.  i586 is so different, only i586 code runs well on them
rscIf we go to drop i586 sooner or later, let's do it now :)
drepperI wouldn't bother with i586 and just bite the bullet and do i686 only
kylemdwmw2, i agree.
f13drepper: and we get around this now how?
warreni686 or i686 SSE2?
dgilmorewarren: i686 no sse
nottingwarren: realistically, if we drop p2/p3/athlon support (in fedora), we'll likely get lynched
f13drepper: if that's the case, why is jakub suggesting -march=i586 ?
nottingf13: it *is* faster
warrenI mean, if we're dropping machines, we might as well do it for clear performance gains, and make the secondary arch for everyone else.
dgilmorei686 sse2 means no XO support
drepperf13: read wrote I wrote (you never do).  selecting -march=i586 will cause this code to be used.  gcc defines i586 and __i586__ macros.  that can trigger different code to be used
abadger1999It really makes the ltsp work go out the window to drop i586 though...
dgilmorewarren: we do need to give the community to setup for i586 as a secondary arch
warrendgilmore: how about primary arch?
nottingdrepper: yes, but anyone doing hand-tuned assembly should either be building multiple packages or doing runtime-switching already
warrennotting: +1
kylemnotting, why must you assume people are competent?
drepperjakub suggested i586 AFAIK only to appease people using processors without cmoc
cmov even
kylemget davej to run one of his infamous greps.
dwmw2people do _weird_ shit with inline assembly
f13drepper: sorry if I seem a bit confused, it just seems that you and jakub were asking for different things.
warrendrepper: and he said cmov isn't worthwhile
f13drepper: or rather jakub was asking for one thing and you're warning us not to use it
dwmw2using autoshite doesn't help, either
they include sse2 in the Fedora packages just because they happened to build on a machine with sse2
cebbertso if we support i586 there's no real penalty for i686 machines?
j-rodI'd say go i686 w/no sse, include kylem's cmov emu as a stop-gap for cmov-less procs, make i586 a secondary arch
dwmw2or have done in the apst, at least.
f13j-rod: I'd only agree to that if we had a functional secondary arch setup.
nottingf13: well, using -march=i586 is predicated on the assumption that we're still supporting that class of machines - i don't think jakub was trying to make that call
dwmw2f13, j-rod: and if I had a clear idea of what we actually _gain_ by doing it
dgilmorej-rod: no enough time to egt i586 as a secondary arch up
j-rodf13: i586 can use the i686 w/cmov-emu until someone actually does the secondary thing
dreppercmov isn't worthwhile in all cases, correct.  and gcc should know about this.  but leave it up to gcc to make the decision.  there are some situations when cmov is OK (highly unpredictable conditions)
warrenkylem: in real world how much slower does cmov-emu make the entire system?
* dgilmore proposes that we do .i586 for F-11 i686 for F-12 and transition up
cebberti586 is already slow enough without trying to emulate cmov
warrenkylem: (does kernel and X have lots of cmov?)
kylemwarren, i don't know, i don't own anything this old.
j-rodif there really are enough people clamoring for i586, getting it up as a secondary shouldn't be that hard
warrenkylem: how big is the patch?  I have lots of this hardware.
j-rodsince any x86 hardware in the last 10 years can build it
kylemnot very, i can spin you an rpm today
warrenkylem: can you do it on a F-10 kernel?  F-11 is too broken
f13j-rod: it's having working code in koji to do the secondary arch thing
nottingkylem: for the dumb benchmark of the day, if you build gzip with -march=i686, you get 40 cmov instructions
dgilmoref13: its working.  but we need to get a realse with it out
abadger1999j-rod: We don't have anyone with a full secondary arch yet... it could be easy or it could be hard... Until the first one is working there's a lot of unknonw.
kylemthey're the same kernel now...
but yes.
j-rodbut i586 could *be* the first full secondary arch, probably much more easily than the more ... uncommon arches
sharkczlike s390x :-)
nottingkylem: and 60 in bzip2
kylememulating cmov is stupid and will be ridiculously slow. but then again, the machines you people seem to care about are worthless and ridiculously slow anyway.
nottingls -lart
warrenkylem: not really
j-rodsharkcz: exactly -- because I have at least a dozen machines in my own possession that could build i586 packages, vs. none that can build s390x (ignoring hercules)
warrenkylem: i586 machines make great thin clients
* nirik notes if there is a group/community that would want to do i586 as a secondary arch, changing now won't give them much time to get it working for f11.
kylemnotting, the instruction count is irrelevant, it could be one called on every iteration of a loop.
nottingkylem: right, but i can't grep that off the top of my head :P
dgilmorenirik: i think its too late to drop i586 support.  lets drop it for F-12
cjbyeah, 5 dn
yeah, I don't think any of this stuff should be aiming at F11
nirikdgilmore: yeah, I agree
jwbit was proposed to coincide with the gcc 4.4 rebuild
which does make sense from that angle
dgilmorefor F-11 lets build everything .i586  glibc, openssl, kernel .i586 and .i686
f13is there any value for shooting for -march i486 ?
dgilmorefor F-12 everything .i686
nottingf13: no
kylemwarren, their perf per watt is laughable.
warrens/i386/i586/ is uncontroversial.  Just do it.
f13dgilmore: I think drepper is saying that's dangerous.
if I'm reading him correctly
dgilmoref13: i guess we need to get jakub and drepper to agree
nottingf13: (paraphrasing) if a dump app does unconditional inline asm based on __i586___ being defined by the compiler, you'll get different code. and the app will get what it deserves
drepperI said it can expose problems which unnecessarily have to be handled
cebbertcould we ship a single glibc for i585 and up?
err i586
jwbyou said the same thing twice cebbert
f13drepper: so you'd rather us do nothing, or go straight to i686 ?
cebbertIOW if i586 is the minimum what do we gain with i686 also?
j-rodone thing I missed... what was the performance gain from i386 -> i586?
warrenj-rod: I asked that, I was told "not bother looking at, i386 < i586 < i686"
j-rod(didn't we argue against it for years, while mdk and suse were doing i586?)
drepperstraight to i686, ignore ancient machines
warrendrepper: we were told by tools team years ago that i386 with i686 optimized code was faster, but apparently that changed now?
nottingj-rod: i don't know, but look at it this way - if it's just -march, all you're doing is giving gcc more insns and availability to optimize. if gcc gets slower in that case, it's already buggy.
sharkczj-rod: IIRC you better sync primitives in glibc
j-rodWhat I'm getting at is if i386 -> i586 doesn't gain us squat, but we don't want to go i686 until F12, then why bother with i586 for one release?
drepperthe problem are atomic instructions
that's why a change from i386 is necessary
f13j-rod: that's my tought too
jwbdrepper, outside of glibc, is that really a problem?
drepperotherwise many programs individually have to select different archs
drepperatomic ops are available through headers and are frequently used
rscj-rod: you mean, skip i586 and straight-on to i686? The lack of time maybe existing for i586 secondary arch again.
j-rodI'm starting to think let f11 be, and shoot for i686 + sse2 for f12 and i586 as an f12 secondary arch
drepperyou cannot let F11 just "
it's a huge issue already
j-rod(okay, maybe just i686 w/o sse)
* lcafiero is Larry Cafiero, late as usual.
rscj-rod: sse is XO problem, so likely w/o sse ;)
j-roddrepper: so which is worse? sticking with i386 or going to i586 where we might be hitting previously untouched code?
* bpepple notes we've ran 2 hours, and it looks like there's another meeting about to start here.
* dgilmore again proposes that we do .i586 for F-11 i686 for F-12 and transition, giving time for those wanting i586 to get it happening
dreppersticking with i386 is the worst possible thing to do
warrenF-11 i586 to gain atomic ops, F-12 i686 SSE2 + secondary arch
themayorhey we are going to have the marketing meeting in #fedora-mktg since it seems busy in here
can you just send anyone who shows up there
bpepplethemayor: will do.  thanks.
drago01are there any cpus (other than older p4/atom) that support sse2 but aren't x86_64 ?
dgilmoreamd did not support SSE2 AFAIK
in 32 bit chipsets
warrennone of the 32bit Athlon supports SSE2
drago01yeah that started with the k8
themayorJonRob:  hey man
drago01so is it worth doing for only older p4?
themayorwe are in #mktg
dgilmoredoe the via i686 chips support sse2?
rscdrago01: yes. Xeon ones.
warrenF-11 i586 to gain atomic ops, F-12 i686 SSE2 + secondary arch?  This seems to create the least amount of stress?
nottingdgilmore: c7/nano yes. c3 no
rscdrago01: my local box has Xeon from 2003 or 2004, SSE2, but no x86_64.
drago01rsc: well this Xeons are P4 based
dgilmorelets agrue about sse2 support in F-12 time frame
rscdrago01: yes, but very widely in use - much more than i586 ones
dgilmoreright now we need to decide F-11
bpeppledgilmore: correct. so, we do we currently stand.
* dgilmore thinks F-11 can only be i586, its too late to drop so many arches.
sharkczdgilmore: +1
dgilmorefor F-12 we will be i686.  what variant of i686 yet to be decided
drago01well I did go for F11 i586 and move the marketing to x86_64 for people who do want perfomance (and have recent cpus)
warrendgilmore: if secondary arch is happening for F-12, might as well make the standard arch faster.
dgilmorewarren: maybe but lets arguee that at the start of F-12
jwb+1 to dgilmore
notting+0.5. would prefer i686, but this is better than nothing
jwbwhich is identical to jakub's suggestions
nirik+1 to dgilmore's proposal
jwbthat's enough to pass it
nottingaside: no disagreements to the rest of the feature?
* j-rod thinks everyone should just suck it up and get 64-bit hardware
nottingj-rod: send me a 64-bit atom and we'll talk
dgilmoreok so F-11 i586  F-12 i686(variant to be decided at the start of F-12 cycle)
bpepplejwb: correct. I see 5.5 '+1' votes for the dgilmore's proposal.
* nirik notes he was having problems finding a i386 host or guest here to look up something today. ;)
j-rodnotting: there would be that. And I have one myself...
sharkczyes,there is also the kernel part ...
rscj-rod: you want me to pay a new server? Perfect :)
nottingso, just to get out of here - votes on the rest of ArchitectureSupport?
warrenthe kernel part is unclear given this change
j-rodkernel-side... does there exist i686 + PAE - SSE2 ?
nottingj-rod: no, but kernel cares not at all about fp regs
erm, strike the 'no'. rest of the statement applies
dwmw2well, except that it has to save/restore them correctly.
warrencebbert wants to do the following to the F-11 kernel:
- Eliminate the current i686 kernel.
- i686 hardware would get i686 PAE by default.
- i586 kernel becomes i686, except without cmov. This is primarily so people don't complain when they realize they have the "i586" kernel.
warren(the last part is probably a bad idea)
jwbwait wait
we already did the x86 part
what about the rest
drago01notting: raid code uses sse afaik
warrenjwb: the kernel part is unclear after this change to i586 minimum
nottingdrago01: right, bt it's special
warren: how so?
kylemif the kernel is i586 minimum, then nothing changes.
jwbyeah, there is nothing to do...
dgilmore+1 to the rest of ArchitectureSupport
nottingwarren: eliminate bare i686 kernel. everyone gets what's most appropriate
jwbnotting, you omitted the ppc flags in your proposal
notting+1 (obvs from me)
nottingjwb: b/c there was no change?
dwmw2including installing x86_64 kernel with 32-bit userspace?
j-rod+1 to the rest
jwbnotting, there was
warrenkernel.i586.rpm and kernel-PAE.i686.rpm?
jwbnotting, we changed ppc64 to -mcpu=power4
dgilmorewarren: yes
nottingjwb: ok, there's an unwritten "do what jwb says" that goes there
warrenok, that's fine to me.
* davej wonders how arch changes on upgrades work
j-rodI thought it was kernel.i686 and kernel-PAE.i686
warrenj-rod: the current kernel.i686 goes away
dgilmorejwb: we changed sparc to -mcpu=ultrasparc
bpepplealright, I see five '+1' to the rest of the architecture feature, so it's been approved.
j-rodbut kernel.i686 was now w/o cmov (essentially, its what *was* kernel.i586)
jwbdgilmore, not a primary arch
* dgilmore doesnt think that ever needed realse notting
nirik is kinda confused by the page now, as we changed a bunch of what it was talking about with the i586
j-rodwarren: no, its just different
jwbdrepper, thanks for attending today
nirikI guess +1 based on it getting fixed up based on the i586 decision.
warrenj-rod: kernel.i586 or kernel.i686 without cmov are the same thing, the former is less problematic on our existing tools. The latter means fewer people complain for no good reason to cebbert.
nottingnirik: i'll fix it up
bpepplealright, so is there anything else in regard to the architecture feature folks want to say. Or should we start to wrap up for today?
dgilmorebpepple: lets wrap up
bpepple: and thanks for leading today
dwmw2we just approved instlaling x86_64 kernels with 32-bit userspace?
davejwarren: 586 is CONFIG_NOHIGHMEM, 686-nonpae is 4G_HIGHMEM
dgilmoredwmw2: yes
davejwarren: so it's not just cmov
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
dwmw232-64 bit compat is fairly well tested. Another thing we can thank ppc for :)
* bpepple will end the meeting in 15
dgilmoredwmw2: and sparc :)
warrendavej: I'm not in disagreement, I was talking about the theoretical i686, not the current i686
nottingdwmw2: you mean thank ppc for verifying the sparc work?
bpepple-- MARK -- Meeting End
rscWill we name kernel-PAE.i686 really so? Can't we just name it kernel.i686?
bpeppleThanks, everyone!
nirikcan someone who doesn't have an intel video card that locked up twice get me the full log?
warrennirik: intel driver has really sucked for me since F-10
bpepplenirik: yup, I'll upload here in a second.
nirikwarren: the lockups are really anoying.

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!