| bpepple | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod | |
|---|---|---|
| * nirik is here. | ||
| sharkcz here | ||
| j-rod here | ||
| jwb is here | ||
| bpepple | anyone want to run the meeting? | |
| * bpepple takes the silence as no else wants to. | ||
| bpepple | ok, let's get started then. | |
| FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets | ||
| * dwmw2 here | ||
| bpepple | .fesco 38 | |
| zodbot | bpepple: #38 (DebugInfoFS - https://fedoraproject.org/wiki/Features/DebuginfoFS) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/38 | |
| jwb | wwoods, around? | |
| bpepple | wwoods just pinged me a couple of minutes ago that he couldn't make it. | |
| bpepple | if we've got questions any questions regarding the feature we can push it to tomorrow. | |
| notting | i'm all for it - +1. i don't speak for infrastructure, though :) | |
| bpepple | +1 here also. | |
| dwmw2 | I'm slightly confused about versioning | |
| does it cope if clients aren't completely up to date? | ||
| jwb | good question | |
| pjones, ping? | ||
| notting | back in 2-3 minutes, sorry | |
| dwmw2 | I'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 | |
| jwb | dwmw2, 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 | ||
| nirik | I wonder about loading issues, but I guess not too many people would debug things... | |
| dwmw2 | I'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 | ||
| dwmw2 | I'd be _much_ happier if we just kept it in userspace. | |
| jwb | it is? | |
| it's done via fuse and webdav | ||
| dwmw2 | it'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 :) | ||
| dwmw2 | seems overly complex | |
| bpepple | how about we add the versioning and file mounting question to the discussion page, and push this to tomorrow? | |
| sharkcz | bpepple: yes | |
| nirik | bpepple: +1 | |
| bpepple | is there any other questions in regard to this? Or should we move on? | |
| jwb | move on | |
| bpepple | moving on.... | |
| .fesco 40 | ||
| zodbot | bpepple: #40 (OpenChange - https://fedoraproject.org/wiki/Features/OpenChange) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/40 | |
| bpepple | is mbarnes about? | |
| this feature looks fairly straight forward. | ||
| nirik | some of the reviews were stalled looking... let me see. | |
| jwb | yeah, my only question is the alpha snapshots of samba4 | |
| bpepple | jwb: yeah, that's the only thing I'm a bit concerned about. | |
| nirik | there is question in the review of how they want to package it, and no package yet for formal review... | |
| notting | there are 4 reviews listed in the feature | |
| jwb | samba4 could be a feature in and of itself | |
| but using alphas for it seems... spooky | ||
| notting | samba4 isn't ready yet for a 'full' release - this is just using some of its libs | |
| jwb | what were the legal concerns with samba4 and how were they resolved? | |
| notting | i don't know of any legal concerns other than it was gpl3? | |
| jwb | look at comments 36 and 37 in the review bug | |
| spot, ! | ||
| notting | en route to fosdem | |
| jwb | bah | |
| ok, i guess it doesn't matter too horribly much if they are resolved | ||
| bpepple | jwb: yeah, if the packages don't pass review obviously the feature will be dropped. | |
| notting | +1 from me | |
| bpepple | +1 | |
| jwb | are samba3 and samba4-alpha parallel installable? | |
| sharkcz | it is the goal | |
| jwb | i'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. ;) | |
| sharkcz | +1 | |
| bpepple | ok, I see five '+1', so we've approved the OpenChange feature. | |
| anyone have anything else to add? Otherwise onto the next feature. | ||
| .fesco 39 | ||
| zodbot | bpepple: #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 | ||
| bpepple | yeah, that was nice. | |
| +1 | ||
| sharkcz | +1 | |
| jwb | +1 | |
| nirik | +1 | |
| notting | 'private' browsing mode. woo euphemisms! | |
| +1 | ||
| jwb | though i wonder why the testsuite isn't run on ppc/ppc64 | |
| bpepple | not sure. | |
| anyway, I see five '+1' so we've approved firefox-3.1 as a feature. | ||
| .fesco 43 | ||
| zodbot | bpepple: #43 (Repackaging of Fedora Fonts - http://tinyurl.com/cuorqt) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/43 | |
| bpepple | nim-nim: ping. | |
| jwb | how is this a feature? | |
| bpepple | jwb: I'm not sure that it is. | |
| j-rod | wtf? fonts again? | |
| jwb | so i'm of the opinion that this is something that just needs to get done | |
| warren | This doesn't seem like something worth mentioning as a bullet point in feature lists. | |
| bpepple | jwb: 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 | |
| notting | hm. it's big enough that it probably needs tracked from a QA perspective | |
| bpepple | notting: yeah, but I'm not sure if it's something we need to advertise. | |
| jwb | yes, 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. | ||
| abadger1999 | This is more than renaming... | |
| notting | i'd poke wwoods as to if he's got a place to track these sorts of things, but he's not here | |
| abadger1999 | nim-nim wants to do an audit of everything... pulling fonts into new packages, getting rid of things with no license, etc. | |
| jwb | abadger1999, and? | |
| how is that any different from, you know, following the guidelines on a daily basis and addressing issues as they are found? | ||
| sharkcz | it is more an administrative work then a feature | |
| abadger1999 | jwb: Is completion of the merge reviews going to be a feature? | |
| This would be a similar task. | ||
| jwb | no? | |
| bpepple | abadger1999: I don't think merge reviews would be a feature. | |
| nirik999 | well, this is more user visible tho isn't it? | |
| new font names, more fonts, some normal scheme for naming font packages. | ||
| notting | nirik999: if we get the obsoletes right and the comps groups right... not really | |
| jwb | and if we don't, it's a bug | |
| abadger1999 | <shrug>. nim-nim is the driver... you probably want to ask him for clarification. | |
| abadger1999 | He might have filled out a Feature page and really just wants FESCo to say he has the authority to make these changes. | |
| nirik999 | yeah, I suppose... is this something we want to tout tho? | |
| notting | Proposal: 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. | |
| bpepple | abadger1999: 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 | ||
| sharkcz | notting: +1 | |
| j-rod | +1 for notting's idea | |
| jwb | +1 | |
| * nirik999 looks at the feature definition again. | ||
| nirik999 | ok, +1 for nottings proposal | |
| dgilmore | +1 to notting | |
| bpepple | ok, I see six '+1' to notting's proposal. | |
| jwb | that's enough, yes? | |
| bpepple | jwb: 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 | |
| zodbot | bpepple: #36 (Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/36 | |
| bpepple | +1 nirik | |
| warren | Did everyone read Jakub's recommendations on f-d-l? | |
| Today Jakub reiterated his recommendation: | ||
| jwb | can we delay this one until the end of the meeting | |
| i fear we wont get to some easier stuff | ||
| warren | probably wise. | |
| bpepple | jwb: yeah, we can do that. | |
| sharkcz | jwb: +1 :-) | |
| nirik999 | jwb: +1 | |
| bpepple | .fesco 44 | |
| zodbot | bpepple: #44 (Update description guidelines - http://tinyurl.com/c7geap) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/44 | |
| bpepple | ok, so this proposal looks to clarify a little better what update descriptions should include. | |
| nirik | why are they called guidelines if they are not binding? | |
| notting | where in the grand scheme of docs would this end up? | |
| mintos mbonnet_ m_stone mmcgrath mizmo marek McGiwer mbonnet mbacovsk_ mitr | ||
| sharkcz | the "update descriptions" points 1+2+3 can be automated when doing updates via bodhi CLI | |
| jwb | notting, maintainers section of the wiki? | |
| f13 | nirik: 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. | ||
| nirik | yeah, perhaps. I would think 'best practices' or the like might be better | |
| f13 | the 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. :/ | ||
| nirik | yeah. We should fix that someday... | |
| jwb | which 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 | |
| bpepple | +1 | |
| nirik | I 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 | ||
| f13 | nirik: yeah, that can be done inclusive of this change. | |
| nirik | agreed. | |
| f13 | I'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 | |
| jwb | sharkcz, like what? | |
| sharkcz | jwb: like moving bug numbers from spec file changelog into bodhi, etc | |
| nirik | who 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 | |
| bpepple | ok, I see seven '+1', so we've approved the update description guideline proposal. | |
| jwb | nirik, i'll bug markmc about it | |
| bpepple | nirik: Usually the person that writes up the proposal. | |
| nirik | jwb: great. | |
| nirik | bpepple: yeah, not sure who that was in this case tho. | |
| bpepple | alright, moving on........... | |
| .fesco 45 | ||
| zodbot | bpepple: #45 (provenpackager proposal - http://tinyurl.com/aozrfm) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/45 | |
| bpepple | boy, there is not much I like about this proposal. abadger1999 summed up pretty well my thoughts about it. | |
| nirik | yeah, same here. -1 from me. | |
| f13 | from the outside, I don't tlik eit | |
| f13 | requires too much infrastructure we don't have in place, nor anybody to work on it | |
| nirik | I do welcome proposals on this... but I don't think this one is the right way to go. | |
| f13 | I appreciate the concerns, I just don't like the suggested implementation. | |
| dgilmore | -1 | |
| bpepple | -1 here also. | |
| sharkcz | -1 | |
| notting | i agree with the solution overview | |
| i'm ambivalent on the implementation | ||
| dgilmore | it seems harsh and way too restrictive. but there needs to be someway to do this | |
| nirik | As an alternate: Should we just handle provenpackager upgrades like we do sponsors? ie, gather feedback from existing provenpackagers and then fesco votes? | |
| notting | is the reseeding blocking on this? | |
| jwb | notting, i don't think so | |
| bpepple | nirik: 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'. | ||
| jwb | bpepple, we have that much for sponsors... | |
| warren | why does fesco need to approve it? certainly if enough existing sponsors or provenpackagers all agree, that should be good enough? | |
| jwb | warren, why do we have to approve sponsors? | |
| nirik | so where are we on the reseeding? | |
| jwb | abadger1999 made the FAS changes | |
| we just need to announce and do it? | ||
| f13 | warren: how do "enough existing sponsors or proven packagers agree" ? | |
| abadger1999 | jwb: I made the packagedb changes. | |
| f13 | warren: what mechanism do we have in place to record that? | |
| jwb | abadger1999, yeah, sorry | |
| abadger1999 | <nod> | |
| nirik | ok, so abadger1999 will do it, then someone announces? | |
| warren | f13: if a small number of individuals are put in charge of counting, recording and adding membership, that should be good enough? | |
| jwb | you mean a small number like 9? | |
| jwb | which is how many are in FESCo... | |
| warren | nevermind | |
| f13 | warren: that's the point I was making. We already have a group of people doing effectively the same thing for sponsor nominations. | |
| f13 | it's not that far fetched to use the same people and proceedures to do the same thing for provenpackager nominations | |
| notting | i think the idea behind rsc's proposal was that he didn't want it all done over e-mail threads? | |
| jwb | why is that a problem? | |
| nirik | well, 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. | ||
| abadger1999 | he didn't want email (not sure why) and he didn't want just one person to be responsible for sponsoring. | |
| nim-nim | nirik: To clarify https://fedorahosted.org/fesco/ticket/43 | |
| nim-nim | 1. 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-rod | bpepple: I agree entirely | |
| f13 | provenpackager itself was an attempt to mollify some of the FUD | |
| it just wasn't enough for some individuals. | ||
| f13 | FESCo has to decide if those some individuals are enough to continue worrying about | |
| dgilmore | f13: i dont think there will ever be enough for some | |
| f13 | our 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. | ||
| bpepple | f13: so is the reseeding still needed? | |
| f13 | I'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 | ||
| bpepple | ok, 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. | ||
| notting | bpepple: 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 | |
| nirik | thats what f13's doc would do... | |
| f13 | I posted suggested conditions | |
| * nirik would be fine with f13's proposal, or just making fesco do them. | ||
| nirik | http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html | |
| nirik | I guess that doesn't say who's doing the approving (fesco|sponsors), just guidelines | |
| f13 | I 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. | ||
| notting | nirik: right, that was the thread that led to rsc's proposal | |
| nirik | rsc: I don't suppose you are around (or you would have spoken up sooner I bet) | |
| nirik | well, I would be ok with fesco voting on them if it would take care of rsc's concerns. | |
| bpepple | My 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. | |
| f13 | couldn't it be done out of band? | |
| bpepple | f13: yeah, though we've had bad track records of doing it in the past. | |
| sharkcz | like vote in FAS? | |
| abadger1999 | No, No vote in FAS. | |
| trac maybe. FAS, no. | ||
| warren | BTW, how is this a feature for F-11? | |
| abadger1999 | :-) | |
| nirik | the problem with out of band is that it lacks ability for feedback or public comment... | |
| bpepple | warren: it's not. It was pushed from last week's meeting. | |
| sharkcz | nirik: announce, some time for comments, then vote | |
| jwb | warren, it's not labeled as a feature either | |
| nirik | so you mean like: .. ticket -> announce to fedora-devel, mail sponsors -> wait -> vote in ticket | |
| warren | sorry, misunderstood | |
| I thought this was a feature meeting. | ||
| sharkcz | nirik: yes | |
| bpepple | I 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. | |
| f13 | bpepple: conversely we're keeping people outside the project because folks don't want to sponsor newbies if they get keys ot the castle. | |
| bpepple | f13: 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. | |
| notting | does someone have a specific proposal/statement they want to call to vote? | |
| bpepple | notting: other than rsc's proposal I'm not sure there is one. | |
| abadger1999 | Are we ready to reseed? | |
| f13 | well | |
| f13 | could FESCo vote on my proposed text ? | |
| f13 | its just criteria, nothing about how to apply that criteria | |
| notting | hrm, ok | |
| so: | ||
| dgilmore | f13: 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 | |
| notting | Proposal: FESCo agrees with Jesse's criteria, but feels the proposal sent to FESCo was too complex and bureacratic. We welcome another proposal for sponsorship. | |
| bpepple | notting: +1 | |
| jwb | +1 | |
| nirik | +1 | |
| sharkcz | +1 | |
| dgilmore | +1 | |
| dwmw2 | for clarification, which proposal was this? | |
| jwb | rsc's | |
| bpepple | dwmw2: https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal | |
| notting | +1 | |
| bpepple | ok, I see six | |
| '+1' to notting's proposal. | ||
| dwmw2 | +1 | |
| bpepple | make 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? | ||
| dgilmore | correct | |
| bpepple | just making sure. | |
| ok, so is there anything else to add about this? Or should we move on to the architecture feature? | ||
| .fesco 36 | ||
| zodbot | bpepple: #36 (Architecture Support - https://fedoraproject.org/wiki/Features/ArchitectureSupport) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/36 | |
| warren | Did everyone read the thread on fedora-devel-list? | |
| f13 | mostly | |
| warren | Jakub reiterated today his recommendation: | |
| <jakub> warren: yes, -march=i586 -mtune=generic for Fedora, -march=i686 -mtune=generic for RHEL | ||
| http://fpaste.org/paste/2949 | ||
| -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. | ||
| f13 | we mostly care about the Fedora side of things here | |
| notting | warren: that second part was yours, not jakubs, correct? | |
| warren | notting: yes | |
| notting | (because 1.1% *is* statistically significant, as far as compilers go) | |
| warren | notting: did you look at what the 12 tests were? | |
| notting | it's spec | |
| warren: my openbench tests showed 1-2% as well. tests included (aaaugh) mp3 | ||
| warren | notting: although not consistently across the board of all packages. | |
| notting | regardless, i think the question boils down to more do we want to support i586-class *machines* in fedora | |
| warren | They are still plenty useful, just not in the ordinary way most Fedora users know. | |
| notting | if 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? | ||
| drepper | it'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 | ||
| cjb | notting: 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") | ||
| dgilmore | what are the chances that if we drop i586 the world will scream at us until we bring it back? | |
| notting | cjb: a basic assumption would be that if you're already running i686 glibc and kernel, then things should remain working | |
| cjb | notting: I'd a little worried by that assumption, but I tend to agree | |
| s/I'd/I'm | ||
| for example, what would, say, mplayer do? | ||
| notting | drepper: 'i586, and Via C3' | |
| * dwmw2 just ordered a shiny new via machine | ||
| kylem | cjb, hand write all the code in assembler, and call cpuid itself to test. | |
| warren | Proposal #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. | ||
| dgilmore | dwmw2: send it back | |
| cjb | notting: Are there Fedora builds that have an i686 kernel and glibc that I might be able to boot on the XO? | |
| notting | cjb: the live cd | |
| dgilmore | cjb: the livecds do | |
| j-rod | Proposal #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. | |
| cjb | ok. that's what's not booting at the moment, but I don't think it's because of i686 :) | |
| dgilmore | cjb: my initial concern was 1. rpm ( we will have to make it lie) 2. that corner cases will sigill | |
| cjb | dgilmore: right | |
| yes, both of those. | ||
| notting | Proposal #4 (bastard): go i686 + sse2, drop p2/p3, athlon. just to be really draconian (not very serious) | |
| dgilmore | rpm can be made to do what we want | |
| sharkcz | #3 but for F-12 | |
| kylem | just fwiw, we can do ultra-slow cmov emulation in the kernel for machines that lack it if we go to i686. my patch works. | |
| jwb | i have a question | |
| warren | notting: I'm not against #4, although what do the benchmarks say? | |
| cjb | kylem: that's interesting | |
| jwb | glibc is built today with -march=i686 or? | |
| drepper, ^ | ||
| kylem | cjb, no, it's really not. but i wanted to shut people up. | |
| notting | jwb: there's a i386 build and a i686 build | |
| dwmw2 | glibc.i686 is, I believe. But we also have glibc.i386 which isn't | |
| jwb | i see | |
| warren | jwb: we ship glibc.i386 and glibc.i686 | |
| drepper | glibc.i386 is basically i486 | |
| dgilmore | j-rod: id say do F-11 .i586 and F-12 .i686 and transition off .i586 as a secondary arch then | |
| drepper | since there is no support for i386 at all | |
| jwb | right, nptl requires at least i486. knew that | |
| sharkcz | dgilmore: +1 | |
| j-rod | dgilmore: yeah, that might be a decent compromise | |
| jwb | dgilmore, necessitating mass rebuilds in back to back releases? | |
| dwmw2 | I might rephrase that as 'transition i586 to a secondary arch when secondary arches are actually working' | |
| f13 | jwb: not necessarily | |
| warren | Why not decide on F-12 when F-12 comes around? Focus on the decision for F-11 to unblock this mass rebuild. | |
| j-rod | meh. i586 could be the first working secondary arch. :) | |
| jwb | warren, it' | |
| f13 | jwb: for F12, you chang ethe default, and drop the i586 kernel. As packages get rebuilt they'll fall out as .i686 istead of .i586 | |
| jwb | it's not blocked. gcc 4.4 hasn't even landed | |
| dgilmore | jwb: yes/no having somethings .i586 would still work fine with everything else .i686 | |
| jwb | f13, true | |
| notting | my 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 | |
| warren | notting: I have been | |
| f13 | so yeah, the real question here is, does Fedora wish to continue supporting i586 class machines as a primary arch. | |
| j-rod | kylem: 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?) | |
| f13 | notting: I had an i586 via on order, but was never in stock. | |
| kylem | j-rod, well, cmov is supposed to have a two or three cycle latency, this would be, well, ten thousand times or more. | |
| j-rod | oy | |
| dwmw2 | what did we say the performance improvement of -march=i686 was? On the _whole_ system rather than a cpu-intensive benchmark? | |
| bpepple | rsc: mirrors will probably revolt. ;) | |
| notting | dwmw2: we have whole-system benchmarks? | |
| f13 | rsc: .i686 packages on an i586 kernel aren't likely to work. | |
| skvidal | b/c the arch doesn't support that way | |
| rsc | f13: I thought, cmov is getting killed anyway? | |
| skvidal | an i586 box won't see an i686 pkg as installable | |
| jwb | we're thrashing here | |
| f13 | dwmw2: likely not much above the things we already make i686 versions of (eg glibc/openssl) | |
| notting | rsc: the fact that i686 benchmarks faster than i586 implies that cmov is occasionally useful. as that's the main (only?) added insn | |
| kylem | cmov is a win on atom. it's probably not going anywhere. | |
| dwmw2 | so what do we actually _gain_ by dropping i586 compatibility? | |
| f13 | Fundamentally, does Fedora wish to continue supporting i586 as a primary arch. | |
| warren | notting: not much faster | |
| drepper | using -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. | |
| f13 | dwmw2: less kernels, less complexity in installers | |
| notting | dwmw2: more clear matrix of support and focus | |
| jwb | drepper, do you agree with jakub's suggestions? | |
| dwmw2 | if we drop the i586 kernel, people could still rebuild that and not have to rebuild the whole of fedora. | |
| f13 | drepper: does not that risk exist with -march=i686 ? | |
| jwb | drepper, or do you have different suggestions? | |
| f13 | dwmw2: we'd also be able to drop the glibc and openssl builds. | |
| dwmw2 | I'm inclined to leave userspace as it is, and revisit the question when we have proper support for atom in gcc | |
| drepper | f13: no risk for reasonable machines. i586 is so different, only i586 code runs well on them | |
| rsc | If we go to drop i586 sooner or later, let's do it now :) | |
| drepper | I wouldn't bother with i586 and just bite the bullet and do i686 only | |
| kylem | dwmw2, i agree. | |
| f13 | drepper: and we get around this now how? | |
| gotcha. | ||
| warren | i686 or i686 SSE2? | |
| dgilmore | warren: i686 no sse | |
| notting | warren: realistically, if we drop p2/p3/athlon support (in fedora), we'll likely get lynched | |
| f13 | drepper: if that's the case, why is jakub suggesting -march=i586 ? | |
| notting | f13: it *is* faster | |
| warren | I mean, if we're dropping machines, we might as well do it for clear performance gains, and make the secondary arch for everyone else. | |
| dgilmore | i686 sse2 means no XO support | |
| drepper | f13: 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 | |
| abadger1999 | It really makes the ltsp work go out the window to drop i586 though... | |
| dgilmore | warren: we do need to give the community to setup for i586 as a secondary arch | |
| warren | dgilmore: how about primary arch? | |
| notting | drepper: yes, but anyone doing hand-tuned assembly should either be building multiple packages or doing runtime-switching already | |
| warren | notting: +1 | |
| kylem | notting, why must you assume people are competent? | |
| j-rod | heh | |
| drepper | jakub suggested i586 AFAIK only to appease people using processors without cmoc | |
| cmov even | ||
| kylem | get davej to run one of his infamous greps. | |
| dwmw2 | people do _weird_ shit with inline assembly | |
| f13 | drepper: sorry if I seem a bit confused, it just seems that you and jakub were asking for different things. | |
| warren | drepper: and he said cmov isn't worthwhile | |
| f13 | drepper: or rather jakub was asking for one thing and you're warning us not to use it | |
| dwmw2 | using autoshite doesn't help, either | |
| they include sse2 in the Fedora packages just because they happened to build on a machine with sse2 | ||
| cebbert | so if we support i586 there's no real penalty for i686 machines? | |
| j-rod | I'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 | |
| dwmw2 | or have done in the apst, at least. | |
| f13 | j-rod: I'd only agree to that if we had a functional secondary arch setup. | |
| notting | f13: 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 | |
| dwmw2 | f13, j-rod: and if I had a clear idea of what we actually _gain_ by doing it | |
| dgilmore | j-rod: no enough time to egt i586 as a secondary arch up | |
| j-rod | f13: i586 can use the i686 w/cmov-emu until someone actually does the secondary thing | |
| drepper | cmov 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) | |
| warren | kylem: 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 | ||
| cebbert | i586 is already slow enough without trying to emulate cmov | |
| warren | kylem: (does kernel and X have lots of cmov?) | |
| kylem | warren, i don't know, i don't own anything this old. | |
| j-rod | if there really are enough people clamoring for i586, getting it up as a secondary shouldn't be that hard | |
| warren | kylem: how big is the patch? I have lots of this hardware. | |
| j-rod | since any x86 hardware in the last 10 years can build it | |
| kylem | not very, i can spin you an rpm today | |
| warren | kylem: can you do it on a F-10 kernel? F-11 is too broken | |
| f13 | j-rod: it's having working code in koji to do the secondary arch thing | |
| notting | kylem: for the dumb benchmark of the day, if you build gzip with -march=i686, you get 40 cmov instructions | |
| dgilmore | f13: its working. but we need to get a realse with it out | |
| abadger1999 | j-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. | |
| kylem | they're the same kernel now... | |
| but yes. | ||
| j-rod | but i586 could *be* the first full secondary arch, probably much more easily than the more ... uncommon arches | |
| sharkcz | like s390x :-) | |
| notting | kylem: and 60 in bzip2 | |
| kylem | emulating 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. | |
| notting | ls -lart | |
| warren | kylem: not really | |
| j-rod | sharkcz: 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) | |
| warren | kylem: 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. | ||
| kylem | notting, the instruction count is irrelevant, it could be one called on every iteration of a loop. | |
| notting | kylem: right, but i can't grep that off the top of my head :P | |
| dgilmore | nirik: i think its too late to drop i586 support. lets drop it for F-12 | |
| cjb | yeah, 5 dn | |
| oops | ||
| yeah, I don't think any of this stuff should be aiming at F11 | ||
| nirik | dgilmore: yeah, I agree | |
| jwb | it was proposed to coincide with the gcc 4.4 rebuild | |
| which does make sense from that angle | ||
| dgilmore | for F-11 lets build everything .i586 glibc, openssl, kernel .i586 and .i686 | |
| f13 | is there any value for shooting for -march i486 ? | |
| dgilmore | for F-12 everything .i686 | |
| notting | f13: no | |
| kylem | warren, their perf per watt is laughable. | |
| warren | s/i386/i586/ is uncontroversial. Just do it. | |
| f13 | dgilmore: I think drepper is saying that's dangerous. | |
| if I'm reading him correctly | ||
| dgilmore | f13: i guess we need to get jakub and drepper to agree | |
| notting | f13: (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 | |
| drepper | I said it can expose problems which unnecessarily have to be handled | |
| cebbert | could we ship a single glibc for i585 and up? | |
| err i586 | ||
| jwb | you said the same thing twice cebbert | |
| f13 | drepper: so you'd rather us do nothing, or go straight to i686 ? | |
| cebbert | IOW if i586 is the minimum what do we gain with i686 also? | |
| j-rod | one thing I missed... what was the performance gain from i386 -> i586? | |
| warren | j-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?) | |
| drepper | straight to i686, ignore ancient machines | |
| warren | drepper: we were told by tools team years ago that i386 with i686 optimized code was faster, but apparently that changed now? | |
| notting | j-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. | |
| sharkcz | j-rod: IIRC you better sync primitives in glibc | |
| j-rod | What 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? | |
| drepper | the problem are atomic instructions | |
| that's why a change from i386 is necessary | ||
| f13 | j-rod: that's my tought too | |
| thought | ||
| jwb | drepper, outside of glibc, is that really a problem? | |
| drepper | otherwise many programs individually have to select different archs | |
| jwb | many? | |
| drepper | atomic ops are available through headers and are frequently used | |
| rsc | j-rod: you mean, skip i586 and straight-on to i686? The lack of time maybe existing for i586 secondary arch again. | |
| j-rod | I'm starting to think let f11 be, and shoot for i686 + sse2 for f12 and i586 as an f12 secondary arch | |
| drepper | you cannot let F11 just " | |
| be" | ||
| it's a huge issue already | ||
| j-rod | (okay, maybe just i686 w/o sse) | |
| * lcafiero is Larry Cafiero, late as usual. | ||
| rsc | j-rod: sse is XO problem, so likely w/o sse ;) | |
| j-rod | drepper: 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 | ||
| drepper | sticking with i386 is the worst possible thing to do | |
| warren | F-11 i586 to gain atomic ops, F-12 i686 SSE2 + secondary arch | |
| themayor | hey 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 | ||
| bpepple | themayor: will do. thanks. | |
| drago01 | are there any cpus (other than older p4/atom) that support sse2 but aren't x86_64 ? | |
| dgilmore | amd did not support SSE2 AFAIK | |
| in 32 bit chipsets | ||
| warren | none of the 32bit Athlon supports SSE2 | |
| drago01 | yeah that started with the k8 | |
| themayor | JonRob: hey man | |
| drago01 | so is it worth doing for only older p4? | |
| themayor | we are in #mktg | |
| dgilmore | doe the via i686 chips support sse2? | |
| rsc | drago01: yes. Xeon ones. | |
| warren | F-11 i586 to gain atomic ops, F-12 i686 SSE2 + secondary arch? This seems to create the least amount of stress? | |
| notting | dgilmore: c7/nano yes. c3 no | |
| rsc | drago01: my local box has Xeon from 2003 or 2004, SSE2, but no x86_64. | |
| drago01 | rsc: well this Xeons are P4 based | |
| dgilmore | lets agrue about sse2 support in F-12 time frame | |
| rsc | drago01: yes, but very widely in use - much more than i586 ones | |
| dgilmore | right now we need to decide F-11 | |
| bpepple | dgilmore: correct. so, we do we currently stand. | |
| * dgilmore thinks F-11 can only be i586, its too late to drop so many arches. | ||
| sharkcz | dgilmore: +1 | |
| dgilmore | for F-12 we will be i686. what variant of i686 yet to be decided | |
| j-rod | +1 | |
| sharkcz | +1 | |
| drago01 | well I did go for F11 i586 and move the marketing to x86_64 for people who do want perfomance (and have recent cpus) | |
| warren | dgilmore: if secondary arch is happening for F-12, might as well make the standard arch faster. | |
| dgilmore | warren: maybe but lets arguee that at the start of F-12 | |
| warren | sure | |
| jwb | +1 to dgilmore | |
| notting | +0.5. would prefer i686, but this is better than nothing | |
| jwb | which is identical to jakub's suggestions | |
| nirik | +1 to dgilmore's proposal | |
| jwb | that's enough to pass it | |
| bpepple | +1 | |
| notting | aside: no disagreements to the rest of the feature? | |
| * j-rod thinks everyone should just suck it up and get 64-bit hardware | ||
| notting | j-rod: send me a 64-bit atom and we'll talk | |
| dgilmore | ok so F-11 i586 F-12 i686(variant to be decided at the start of F-12 cycle) | |
| j-rod | (kidding) | |
| bpepple | jwb: 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-rod | notting: there would be that. And I have one myself... | |
| sharkcz | yes,there is also the kernel part ... | |
| rsc | j-rod: you want me to pay a new server? Perfect :) | |
| j-rod | heh | |
| notting | so, just to get out of here - votes on the rest of ArchitectureSupport? | |
| warren | the kernel part is unclear given this change | |
| j-rod | kernel-side... does there exist i686 + PAE - SSE2 ? | |
| notting | j-rod: no, but kernel cares not at all about fp regs | |
| erm, strike the 'no'. rest of the statement applies | ||
| dwmw2 | well, except that it has to save/restore them correctly. | |
| warren | cebbert 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. | ||
| jwb | wait | |
| warren | (the last part is probably a bad idea) | |
| jwb | wait wait | |
| https://fedoraproject.org/wiki/Features/ArchitectureSupport | ||
| vote | ||
| we already did the x86 part | ||
| what about the rest | ||
| +1 | ||
| drago01 | notting: raid code uses sse afaik | |
| warren | jwb: the kernel part is unclear after this change to i586 minimum | |
| notting | drago01: right, bt it's special | |
| warren: how so? | ||
| kylem | if the kernel is i586 minimum, then nothing changes. | |
| jwb | yeah, there is nothing to do... | |
| dgilmore | +1 to the rest of ArchitectureSupport | |
| notting | warren: eliminate bare i686 kernel. everyone gets what's most appropriate | |
| jwb | notting, you omitted the ppc flags in your proposal | |
| notting | +1 (obvs from me) | |
| bpepple | +1 | |
| notting | jwb: b/c there was no change? | |
| dwmw2 | including installing x86_64 kernel with 32-bit userspace? | |
| j-rod | +1 to the rest | |
| jwb | notting, there was | |
| sharkcz | +1 | |
| warren | kernel.i586.rpm and kernel-PAE.i686.rpm? | |
| jwb | notting, we changed ppc64 to -mcpu=power4 | |
| dgilmore | warren: yes | |
| notting | jwb: ok, there's an unwritten "do what jwb says" that goes there | |
| warren | ok, that's fine to me. | |
| * davej wonders how arch changes on upgrades work | ||
| j-rod | I thought it was kernel.i686 and kernel-PAE.i686 | |
| warren | j-rod: the current kernel.i686 goes away | |
| dgilmore | jwb: we changed sparc to -mcpu=ultrasparc | |
| bpepple | alright, I see five '+1' to the rest of the architecture feature, so it's been approved. | |
| j-rod | but kernel.i686 was now w/o cmov (essentially, its what *was* kernel.i586) | |
| jwb | dgilmore, 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-rod | warren: no, its just different | |
| jwb | drepper, thanks for attending today | |
| nirik | I guess +1 based on it getting fixed up based on the i586 decision. | |
| warren | j-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. | |
| notting | nirik: i'll fix it up | |
| bpepple | alright, so is there anything else in regard to the architecture feature folks want to say. Or should we start to wrap up for today? | |
| dgilmore | bpepple: lets wrap up | |
| bpepple: and thanks for leading today | ||
| dwmw2 | we just approved instlaling x86_64 kernels with 32-bit userspace? | |
| davej | warren: 586 is CONFIG_NOHIGHMEM, 686-nonpae is 4G_HIGHMEM | |
| dgilmore | dwmw2: yes | |
| dwmw2 | ok | |
| davej | warren: so it's not just cmov | |
| * bpepple will end the meeting in 60 | ||
| bpepple will end the meeting in 30 | ||
| dwmw2 | 32-64 bit compat is fairly well tested. Another thing we can thank ppc for :) | |
| * bpepple will end the meeting in 15 | ||
| dgilmore | dwmw2: and sparc :) | |
| warren | davej: I'm not in disagreement, I was talking about the theoretical i686, not the current i686 | |
| notting | dwmw2: you mean thank ppc for verifying the sparc work? | |
| bpepple | -- MARK -- Meeting End | |
| rsc | Will we name kernel-PAE.i686 really so? Can't we just name it kernel.i686? | |
| bpepple | Thanks, everyone! | |
| nirik | can someone who doesn't have an intel video card that locked up twice get me the full log? | |
| warren | nirik: intel driver has really sucked for me since F-10 | |
| bpepple | nirik: yup, I'll upload here in a second. | |
| nirik | warren: the lockups are really anoying. | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!