| --- jds2001 has changed the topic to: FESCo meeting -- init | ||
| jds2001 | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod | |
|---|---|---|
| * notting is here | ||
| nirik is here. | ||
| jwb_ is here | ||
| sharkcz is here | ||
| * bpepple is here. | ||
| jds2001 | dgilmore-oz said he'd try to make it, but it's 2AM down under :) | |
| * skvidal is here | ||
| notting | do we need to reschedule for him? or is he back at some point in the near future? | |
| * dwmw2 here | ||
| jds2001 | he's on vacation | |
| notting | (then again, scheduling for USA, sharkcz, dwmw2, and dgilmore-oz simultaneously....) | |
| jds2001 | it was like 3 weeks total. | |
| * j-rod here | ||
| sharkcz | notting: IIRC he is going back next week | |
| bpepple | at a minimum as long as the schedule goes out early enough, he can weigh-in on any topics that he has a strong opinion about. | |
| jds2001 | yeah, and i fail at that. :( | |
| anyhow, i think im going to toss the order on the agenda. | ||
| too much stuff, too little time | ||
| --- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - Tickets | ||
| jds2001 | .fesco 144 | |
| zodbot | jds2001: #144 (PPC as a secondary arch for Fedora 12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/144 | |
| jds2001 | so jwb_ wanted me to do this one first. | |
| jwb_ | yep | |
| jwb_ | most of us discussed this at the last FESCo meeting | |
| jwb_ | the proposal that was generally agreed on was: | |
| jds2001 | any changes from the strawman we did last week? | |
| jwb_ | Keep PPC as a primary architecture for Fedora 12, move to a secondary architecture for Fedora 13 | |
| sharkcz, i think you were missing last week. anything you wanted to add or discuss about this one? | ||
| dwmw2 | I'm happy with that as long as there are no infrastructure blockers preventing a successful F13 release | |
| jwb_ | (or anyone else for that matter) | |
| sharkcz | jwb_: no, I was there and I am fine with that setup | |
| jwb_ | dwmw2, 'infrastructure blockers'? | |
| * nirik is fine with that plan. +1 | ||
| jwb_ | sharkcz, ah, my apologies | |
| sharkcz | jwb_: np | |
| dwmw2 | jwb_: as long as it is technically possible for the interested folks to actually _do_ it | |
| jds2001 | +1 | |
| dwmw2 | which I _think_ it should be | |
| bpepple | I'm still +1 to the plan also. | |
| * notting is still +1 | ||
| sharkcz | +1 | |
| jwb_ | dwmw2, i think so too. it's technically possible today | |
| dwmw2 | judging by the feedback we got from the other teams on why they haven't released yet | |
| j-rod | +1 | |
| dwmw2 | +1 | |
| jwb_ | i'm going to vote -1 on this, for a few reasons and not solely because i happen to like ppc | |
| j-rod | spill | |
| jds2001 | care to elaborate? | |
| bpepple | jwb_: any particular reason? | |
| jwb_ | i'll try to be brief | |
| ppc/ppc64 has typically highlighted a number of issues in the code base that simply don't get caught on x86 for one reason or another | ||
| as dwmw2 points out, most of the 'ppc bugs' we find aren't really ppc bugs | ||
| also, it hits size limits for DVDs much sooner, so while it gets blamed, eventually you'll have the same problem on x86_64 | ||
| dwmw2 | if the main motivation for moving it to a secondary arch is the _release_ process, perhaps we should have it as a primary arch for building but let the PPC team handle release QA and ship the _releases_ as a 'secondary arch'? | |
| dwmw2 | you get the benefit that way in keeping Fedora portable, but don't put the burden on the releng folks | |
| j-rod | I kinda like that idea... | |
| jds2001 | <pie in the sky> | |
| jwb_ | except the infrastructure folks (including the mirrors) are impacted as well | |
| and they also would like to see it demoted | ||
| jds2001 | once AMQP messaging gets working, we can build all secondary arches simultaneously | |
| dwmw2 | jwb_: not if the _releases_ are shipped separately in the secondary/ tree | |
| jds2001 | </pe in the sky> | |
| f13 | not to mention the extra infra resources needed to build ppc/64 and to store ppc/64 builds | |
| jwb_ | dwmw2, they maintain the build systems and koji store | |
| notting | and it then gets weird with other arches | |
| f13 | jds2001: amqp won't necessarily help with that | |
| jds2001 | f13: maybe im stupid, but if you can tell multiple kojis "go do this", why not? | |
| jwb_ | honestly, if this were SPARC, or s390, or some other arch we were talking about, i'd have the same vote | |
| f13 | fwiw I agree on all the points jwb makes about ppc being useful to Fedora. However I feel that ppc can continue to be useful in these ways to Fedora if it is kept up at a functional secondary arch. | |
| jds2001 | of course the kojis have to be in shape to do that :) | |
| f13 | jds2001: because at the base level, koji isn't a "go do this" construct. It's a "is there anything for me to do" construct | |
| jwb_ | f13, that is true, yes. an unknown 'if', but fair | |
| dwmw2 | f13: arguably it's _better_ while a build breakage is killing the main build | |
| f13 | builders ask the hub every few minutes "is there anything for me to do" | |
| dwmw2: that's an argument. | ||
| dwmw2 | I think it would be really useful to have _some_ big-endian architecture where you can't re-use va-args killing main builds :) | |
| * nirik notes this has passed, right? shall we move on? or is there anything usefull to gain by further discussion? | ||
| f13 | and I think it would be really useful to use Fedora resources for arches that have significant user bases. | |
| jwb_ | nirik, i think we can move on. i just wanted to vote for the record this time and explain why | |
| * nirik nods. | ||
| jds2001 | .fesco 146 | |
| zodbot | jds2001: #146 (revoke rjones' sponsor and provenpackager status) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/146 | |
| jwb_ | oh, i will also note (as always) that I do not speak for my employer. my words and thoughts are my own | |
| jds2001 | jwb_: of course :) | |
| * rwmjones is here if you want to ask me questions | ||
| notting | -1. revocation should be for persistent, egregious, and/or willful breaking of the rules once explained | |
| dwmw2 | -1 | |
| jds2001 | -1 here too. | |
| sharkcz | -1 | |
| bpepple | -1, agrees with notting. | |
| dwmw2 | you can revoke mine too if you like -- I broke the repo this week too | |
| nirik | rwmjones: do you understand why broken deps are bad ? or do you think this was ok? | |
| rwmjones | nirik, yes, I see obviously almost no one agreed with my points in that thread ;-) | |
| nirik | rwmjones: also, in epel5, what functionality is lost by not having that dep? | |
| jwb_ | jds2001, the ticket says sponsor would need to be revoked as well as provenpackager. why? | |
| j-rod | -1 | |
| rwmjones | I would like to see it in the packaging guidelines though | |
| jds2001 | jwb_: because provenpackager is implied in sponsor. | |
| abadger1999 | jwb_: That's the way fesco has structured the hierarchy. If you are a sponsor you automatically have provenpackager. | |
| abadger1999 | (No technical tie) | |
| jwb_ | abadger1999, so is it technically possible? | |
| rwmjones | nirik, truthfully, much functionality is lost by not having that dep, but for EPEL-5 case I am actively working on fixing that problem | |
| jds2001 | jwb_: yes, it's technically possible, | |
| abadger1999 | jwb_: Yes. | |
| nirik | rwmjones: yeah, I saw the 5.4 bug... | |
| jwb_ | because, while i don't really care on the actual issue here, i do note that rwmjones never asked for it | |
| and has never used it | ||
| rwmjones | nim-nim, https://bugzilla.redhat.com/show_bug.cgi?id=497625 | |
| buggbot | Bug 497625: medium, low, rc, ehabkost, NEW, Add vmchannel support to qemu-kvm | |
| jds2001 | jwb_: the reasoning is that a sponsor can fix sponsoreees issues. | |
| rwmjones | TBH I just want to sponsor kalev | |
| he's a good packager, and I've followed his BZ's | ||
| nirik | rwmjones: providing packages with broken deps is very bad. Decreasing functionality with a runtime check is sad, but much more acceptable. | |
| rwmjones | if I lose sponsor status, I want to be sure that he is sponsored by sb else soon | |
| dwmw2 | if the sponsor goes away, does that revoke all sponsorships? | |
| jds2001 | rwmjones: we've already voted not to do that. | |
| dwmw2 | that seems... odd | |
| jwb_ | dwmw2, no | |
| nirik | jwb_: the other reasoning is that if you are a sponsor you should understand the guidelines well as well to explain them to sponsorees (IMHO) | |
| jwb_ | nirik, ok, fine. then it seems to me that sponsor and provenpackager really are the same thing | |
| so why are we calling them something different? | ||
| nirik | the other way is different. | |
| jwb_ | anyway, that's a larger item to discuss (again) | |
| dwmw2 | we digress... | |
| jwb_ | very much | |
| nirik | some people don't care to sponsor anyone, they just want to use provenpackager. | |
| so you can have just PP, but sponsor to me implies both. | ||
| jds2001 | so we have voted not to revoke sponsorship or provenpackager from rjones. | |
| nirik | yeah, sorry. | |
| rwmjones | nirik, I'm the opposite - i don't want to use my PP rights | |
| but do want to sponsor | ||
| jds2001 | can we move slightly on? :) | |
| * dwmw2 suspects that rjones is suitably educated now :) | ||
| drago01 | rwmjones: no one is forcing you to use them ;) | |
| jds2001 | .fesco 147 | |
| nirik | rwmjones: yeah, but the relationship to me means if you are a sponsor you should also meet the requirements of PP. | |
| zodbot | jds2001: #147 (Meeting agenda item: No broken dependencies should be a packaging guideline) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/147 | |
| rwmjones | ok so this is my ticket ... | |
| dwmw2 | er, packaging committee? | |
| rwmjones | well, there was a complex question of if this should be a fesco policy | |
| rwmjones | or something for FPC | |
| dwmw2 | proposals like that don't come directly to FESCo iirc | |
| jds2001 | yeah, i've already started a thread on f-packaging | |
| rwmjones | which tbh I don't really understand | |
| jwb_ | i think write a guideline we can't enforce at the moment seems a bit odd | |
| jds2001 | yeah | |
| jds2001 | it's really hard. | |
| dwmw2 | jwb_: on the contrary -- if we could enforce it, we wouldn't need the 'guideline' :) | |
| rwmjones | jwb_, well it could just outlaw deliberate dep breaking | |
| drago01 | jwb_: we can't enforce most of the guidelines (after the initial import) | |
| rwmjones | accidental would still be ok | |
| jwb_ | drago01, we could, if we tried | |
| abadger1999 | It's also not something that is easily provable at reviewtime. | |
| notting | well, deliberate dep breaking is already forbidden by the 'can not require things not in fedora' clause. although that's sort of a technicality | |
| jds2001 | and chain imports would then be prohibited. | |
| abadger1999 | And as written, I'd argue it's really a FESCo decision/assumption. | |
| drago01 | jwb_: new review bug after every change? | |
| -EDOESNOTSCALE | ||
| bpepple | abadger1999: I agree. | |
| jwb_ | notting, it doesn't say 'in this particular release of fedora' | |
| which is where this issue stems from | ||
| rwmjones | notting, that depends what you mean by 'fedora' ... it might have to be tighter like 'this release of fedora' | |
| jwb_ | drago01, we digress | |
| drago01 | jwb_: yeah | |
| abadger1999 | drago01: We tried that at fedora.us. Too much work to do managably. | |
| jds2001 | many years and many thousands of packages later..... | |
| nirik | I'm ok with us adding a written rule on this, but if it's a fesco policy and not a packaging thing, I doubt many reviewers will see/note it. | |
| nirik | so can we add it to fesco policy, and also update the review guidelines/packaging pages to mention it? | |
| abadger1999 | nirik: <nod> That's something that needs to be thought about long term. | |
| notting | i always thought it was common sense - a package with broken deps cannot be installed by our tools | |
| abadger1999 | How do we introduce packagers to all te things they need to know spread out over several areas of the wiki. | |
| nirik | frankly I think it's common sense, but it's easier IMHO to just write it down and drive on rather than discussing it forever. | |
| rwmjones | abadger1999 is right about that | |
| dwmw2 | Proposal: This should be referred to the packaging committee | |
| bpepple | isn't it mentioned in the maintainer responsibilities policy? | |
| skvidal | quick question | |
| * nirik finds the wiki slow to answer. ;( | ||
| skvidal | since everyone seems to be hellbent to treat things like a trial | |
| under what terms should provenpackager be revoked | ||
| dwmw2 | skvidal: when it becomes clear that it shouldn't have been granted in the first place | |
| skvidal | and what is the criteria | |
| jds2001 | skvidal: repeated, egregious offenses. | |
| * nirik thinks continued and willfull violations of policy. | ||
| skvidal | repeated AND egregious? | |
| or repeted OR egregious | ||
| wwoods | I think "willful" is an important term for this definition. | |
| jds2001 | wwoods: good point | |
| nirik | wwoods: yeah, bothersome to wills? :) | |
| jds2001 | as somneone pointed out to me in private, words on the wiki don't cost us anything. | |
| abadger1999 | So one thing I wonder in that definition -- does it matter if they're different offences? | |
| skvidal | y'all have all seemed to believe that rwmjones' was not egregious enough. | |
| skvidal | but it was obviously willfull | |
| jds2001 | sure, but it happened once. | |
| skvidal | and it was done on both el5 and f10 - so it was repeated | |
| nirik | rwmjones: would you do something like that again? | |
| rwmjones | nirik, no of course not | |
| kalev | Hello everybody, can I say a word about rwmjones? | |
| rwmjones | well, I'm not counting accidentally/through stupidity of course | |
| jds2001 | sure thing. | |
| kalev | I am interested in Fedora mingw32 packages and some time ago I wanted to contribute back to Fedora by packaging some libraries. | |
| abadger1999 | b/c provenpackager is meant to be given to people who have a high level of packaging knowledge. So if someone makes new mistakes it would seem to follow that. | |
| drago01 | skvidal: he did a mistake, learned from it .. lets go on | |
| jds2001 | rwmjones: everyone suffers form that a bit :) | |
| kalev | rwmjones is the person behind all Fedora MinGW related work, and he volunteered to sponsor me after I had filed a few review requests. | |
| I'd say he has been very helpful so far, being always around when I couldn't figure out something on my own and pointing me to right directions. | ||
| I can't say anything about his 'provenpackager' work, but I am certainly glad to have him as my sponsor, and I think he might be a good spon | ||
| skvidal | drago01: I don't believe the second clause at all, actually | |
| kalev | sponsor to someone else in the future | |
| skvidal | drago01: given the vehement "if it is not in the rules then it can't be an offense" defense he gave | |
| skvidal | drago01: but let's not worry about him for the moment | |
| dwmw2 | I think all requests to revoke access need to be considered on their own merit | |
| skvidal | if we're going to treat this like a law court | |
| (since it is clear everyone here seems to think that's how it is) | ||
| dwmw2 | I don't think it makes sense to make up a formula in advance | |
| skvidal | then lay down the rules | |
| dwmw2 | no, I disagree -- I don't think it's like a court at all. | |
| we didn't have rules and blindly apply them. We made a judgement. | ||
| skvidal | dwmw2: I don't either. but there seems to be this misguided idea that rules need to be established | |
| dwmw2 | yeah, I disagree with that | |
| policy is just a euphemism for not having to think | ||
| jds2001 | skvidal: i dont think that nay of us voted that way we did because something wasnt written down. | |
| markmc | kalev, welcome to fedora, and please try and ignore all this arguing :) | |
| jds2001 | skvidal: after having a bit to think about it (really hard), I decided that a single transgression just didn't rise to that level. | |
| dwmw2 | I think skvidal is right to resist the 'must have rules' mentality. | |
| now, can we get back to the point? :) | ||
| jds2001 | now if the transgression had been putting 'rm -rf /' in %post of the kernel, that'd be different. | |
| skvidal | jds2001: okay - then under what assumptions/reasoning is provenpackager granted? | |
| jds2001 | there's no rule against that either. | |
| rwmjones | jds2001, there's probably a (real) law against it | |
| * nirik notes that the f10 and el-5 builds were imported with that dep, and it was removed in el5 after the discussion about devel. As far as I can see it was corrected and there was not a repeated offense. | ||
| dwmw2 | skvidal: we assume that it would be good for Fedora as a whole if the person is able to contribute to all packages | |
| skvidal | why do we have provenpackager, again, then? | |
| dwmw2 | to allow people to contribute to all packages? | |
| skvidal | but not to sponsor | |
| dwmw2 | or, to pander to the tinfoil hat brigade who didn't want _everyone_ to be able to do that? | |
| skvidal: I believe that sponsor is a higher bar | ||
| skvidal | apparently it is not | |
| given the circumstances just discussed | ||
| jds2001 | skvidal: er? | |
| * dwmw2 confused | ||
| jds2001 too | ||
| skvidal | is sponsor ever given without pp? and vice-versa? | |
| jwb_ | skvidal, sponsor implies pp. pp does not imply sponsor | |
| which is confusing as hell, but ok | ||
| skvidal | are there any cases of pp w/o sponsor? | |
| dwmw2 | thus, revoking pp implies revoking sponsor | |
| jds2001 | skvidal: yes | |
| skvidal | ah, who? | |
| nirik | many of the desktop team folks | |
| skvidal | ok | |
| then I'll retract tat | ||
| err that | ||
| rwmjones | why is there a hierarchy between the two? why not just separate things | |
| nirik | rwmjones: we could. | |
| bpepple | skvidal: there's plenty of other folks besides the desktop team that we approved for pp a month or so back. Should be in the meeting minutes. | |
| dwmw2 | meeting over in 20 minutes? | |
| jwb_ | dwmw2, we're scheduled for 2 hours i think | |
| dwmw2 | joy :) | |
| bpepple | dwmw2: wishful thinking. | |
| markmc | rwmjones, jwb_ gave the rationale earlier - "a sponsor should be able to commit fixes for sponsoree's mistakes" | |
| nirik | rwmjones: would it help in your case? if you only wanted sponsor to sponsor one person I would be happy to sponsor them for you, and you could move on... | |
| jwb_ | markmc, that wasn't me, but yeah | |
| dwmw2 | I don't see a good reason to change it | |
| rwmjones | nirik, as I said before I don't mind, so long as kalev is sponsored and we don't lose him in non-sponsored limbo | |
| nirik | rwmjones: but don't you use provenpackager to commit to some of the mingw packages? or you own all those? | |
| jds2001 | rwmjones: nothing is happening to your sponsor status, we already voted on that :) | |
| rwmjones | nirik, I co-maint many of them, but by no means all of them | |
| dwmw2 | can someone remind me what agenda item we _are_ on now... ? | |
| skvidal | dwmw2: the guidelines | |
| jwb_ | 'make a policy about broken deps' | |
| jds2001 | we're supposedly talking about the guidelines. | |
| skvidal | dwmw2: which is why I wanted to know what the guidelines were for removing status/access from a packager | |
| jwb_ | 'broken deps are bad. don't do that' | |
| dwmw2 | Proposal: Packaging guidelines are for FPC to handle. | |
| jwb_ | dwmw2, not a packaging issue | |
| dwmw2 | https://fedorahosted.org/fesco/ticket/147 ? | |
| jwb_ | broken deps can happen for a variety of reasons | |
| jwb_ | well, not solely a packaging issue anyway | |
| dwmw2 | the ticket we're discussing explicitly says 'added as a new section to the Fedora packaging guidelines' ... | |
| ok, +1 to the guideline then | ||
| jds2001 | right, and that FPC would have to handle. But FPC doesn't believe it's the right place. | |
| abadger1999 | jds2001: Note: FPC could debate a different version of this for Guidelines. | |
| FPC would be more implementation. | ||
| abadger1999 | OTOH, this is really common sense. | |
| It might not pass FPC. | ||
| rwmjones | I'm more than happy to take on the responsibility of taking this to FPC | |
| rwmjones | just raised here because there was the question of whether it should be a fesco policy | |
| nirik | Proposal: "Packagers should strive to avoid broken dependencies on their packages. Packages with broken dependencies for the version(s) of fedora they are targeting should be blocked in review until those dependencies are fixed" | |
| jds2001 | nirik: where does that go? | |
| nirik: review guidelines? | ||
| nirik | yeah, I would ask FPC to consider adding that to review guidelines. First as a SHOULD and second as a MUST? Of course releases are ever changing, so a clean package today could have a broken dep tomorrow. | |
| jwb_ | or if you fudge an update | |
| nirik | or if someone else does. | |
| jwb_ | exactly | |
| nirik | or if rpm has a bug | |
| or ... | ||
| jwb_ | hence my 'enforce' comment earlier | |
| nirik | well, if we could enforce it, we could just say "no packages with broken deps will be released" | |
| jds2001 | that's unenforceable :( | |
| jwb_ | today | |
| nirik | currently, sure. | |
| abadger1999 | nirik: That would be better, imho. | |
| nirik | rwmjones / abadger1999: could you guys take that to FPC? I think it really makes more sense to be somewhere in guidelines than on a fesco policy page | |
| rwmjones | sure | |
| nirik | (or feel free to enhance it to something that will pass, I don't care :) | |
| abadger1999 | I can help with wording... but I'm not sure that I'm for it so rwmjones, you'll need to be the main proponent :-) | |
| rwmjones | sure | |
| nirik | cool. Shall we move on? | |
| jds2001 | sounds good. | |
| jds2001 | .fesco 142 | |
| zodbot | jds2001: #142 (Make x86_64 more visible or even the default choice) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/142 | |
| jds2001 | i guess unless someone has other ideas on what we should cover next :) | |
| jds2001 | so i missed this last week | |
| nirik | do we have any data here? what % is 32/64? what % is 32 but could be 64? | |
| jds2001 | but when i first saw it, i thought this was more a websites thing than fesco | |
| jds2001 | nirik: no data :( | |
| im trying to get mizmo real quick | ||
| nirik | add websites to cc, ask for data, punt to next week? :) | |
| dwmw2 | nirik: +1 | |
| nirik | in general I think it's a good idea to get folks with 64bit hardware running 64bit os... | |
| mizmo | hi | |
| jds2001 | hey mizmo thanks for coming on such short notice :) | |
| jds2001 | so there's a fesco ticket to make x86_64 more visible or the default | |
| jds2001 | i know that you did a huge redesign of get-fedora. | |
| mizmo | it seems pretty simple to fix, just add a banner on the side above the ppc banner to link directly to x86_64 | |
| abadger1999 | drago01: Is that what you were envisioning? | |
| mizmo | the problem here is that it used to be, clicky clicky get live x86 32-bit, everything else go to the full blown page | |
| nirik | well, I think the reporter wanted the main desktop one to go to x86_64 | |
| mizmo | but then ppl kept saying 'what about MY spin' | |
| so we started adding those banners | ||
| mizmo | that's why x86_64 is not as obvious as it used to be. because originally we didn't call out kde and ppc | |
| drago01 | abadger1999: its better as the current situation (completly hidden) but still not optimal | |
| mizmo | its not completely hidden | |
| why would the main desktop one go to x86_64 | ||
| drago01 | let me rephrase "hidden from the main screen" | |
| mizmo | thats a terrible idea | |
| it's not hidden from the main screen. you click view all and it's on the view all screen | ||
| drago01 | thats the point why should a user click view all rather than just download? | |
| mizmo | the one download that will work for 90%+ of users is the one on the main screen. | |
| drago01 | unless he knows that there is something he is searching for | |
| mizmo | drago01, are you asking me why should 100% of users get a screenful of links, or why should 90% of users get one simple click and 10% have to click once more? | |
| nirik | well, we can't know what arch someone is... and many people won't know either. | |
| mizmo | because the screenful of links made no one happy | |
| which is why 32-bit is the default you get. even if you have x86_64 and don't know it, it will work fine on your machine | ||
| if you care enough to download a 64-bit OS you are probably (1) a minority (2) smart enough to click once more | ||
| the tradeoff here is simplicity for most and an extra click for a few. | ||
| vs a very complex screen for all | ||
| nirik | mizmo: yeah, but then lots of people with 64bit hardware get a 32bit os... | |
| mizmo | nirik, but it works does it not? | |
| nirik | sure, but it's not ideal. Not sure how we could detect that tho. ;( | |
| jds2001 | yeah, but there are advantages to the 64bit os | |
| mizmo | the problem is the 90% of people who are fine with the default link are happy and say nothing, while that 10% or less that actually care about having 64bit OS are very loud and argumentative | |
| i know there are advantages, but i do not think anyone but power users are aware of them and care about them | ||
| dwmw2 | the 32-bit installer should detect a 64-bit OS and offer the choice of installing 64-bit (even if it has to use the network to do so) | |
| mizmo | thats a really cool idea dwmw2 | |
| dwmw2 | that would be more useful than web site tweaks | |
| nirik | dwmw2: won't help with live tho. | |
| jwb_ | and require changes that would make clumens weep | |
| dwmw2 | :) | |
| jds2001 | nirik: i know that on fedora at least ff passes the arch in user-agent | |
| nirik | jds2001: yeah, perhaps we could use that (for f12...) | |
| jds2001 | wouldnt do anything if i were running 32bit os though :) | |
| drago01 | mizmo: I don't see why we should spend effort on moving from i386 to i5/686 while we already have an arch that does use the newer instruction set and it gains more than 1-2% | |
| dwmw2 | this works nicely for ppc32/ppc64 :) | |
| mizmo | what i do not want, is my little brother deciding to try out fedora, going to get.fpo, and getting a 64-bit iso on his slow uplink downloading that for hours, taking the time and truoble to figure out how to burn an iso to a disc in windows, and then trying to install it and it fails on his 32-bit machine | |
| drago01 | we should make this more visible to the user | |
| mizmo | drago01, which user? | |
| nirik | mizmo: sure, agreed. | |
| mizmo | which users care? | |
| do the users who are smart enough to figure it out only care? that's what i think. the users who can't figure it out on their own certainly would rather one click. | ||
| that works for them. | ||
| nirik | mizmo: will adding more banners to the right side be a problem? or make it too busy? | |
| mizmo | nirik, im not a big fan of them but it seems the best solution | |
| nirik, i would put the 64-bit one right under the kde one and above the ppc one | ||
| nirik | they are kinda distracting and could confuse people... KDE? do I want that? | |
| mizmo | right | |
| nirik | what is it? :) | |
| mizmo | but thats the problem when special interest groups demand a banner | |
| and are appeased | ||
| drago01 | mizmo: ok if we can agree on the banner it would be an improvement | |
| mizmo | and id rather ad a banner for KDE then get into the tarpit of arguing gnome vs kde | |
| nirik | how about a Xfce banner? :) | |
| mizmo | since getting into that argument is like buying a ticket for the titanic | |
| jds2001 | nirik: i was waiting for that :) | |
| mizmo | heh | |
| drago01 | what about this: | |
| mizmo | i hope you are kidding about xcfe | |
| er xfce | ||
| smooge | I want my TVTWM banner, nirik | |
| mizmo | if not, let me clear some space on my desk for my forehead | |
| dwmw2 | mizmo: on EEE? probably not... | |
| jwb_ | WARNING WARNING DERAILMENT POSSIBLE | |
| nirik | mizmo: mostly. :) It would be nice to have something, but I don't care that much... ;) | |
| drago01 | "Download 32bit Version" "Download 64 Bit Version" ("I don't know which one to download") (link to a page with explaination) | |
| mizmo | drago01, no | |
| no way | ||
| nirik | how about we add a '64bit' to the right side for now. | |
| mizmo | once you force a decision like that on the 90% of users who dont know and dont give a crap about 32 bit vs 64 bit, you've lost them. | |
| jds2001 | drago01: and what is this "explanation" | |
| mizmo | banner on the right is fine. no 32 vs 64 bit choice in the main download area. | |
| bpepple | alright, does anyone on fesco have an objection to the banner solution proposed by mizmo? | |
| jwb_ | no | |
| mizmo | it was a very explicit design decision agreed upon by many people that users should have *one* button to click | |
| * ricky mentions that any proposed changes would have to happen after the F11 release, since we're in a string freeze right now. | ||
| nirik | and then we ask people who care about this to be involved in a more long term solution for f12. (checking browser? redoing out setup so it works better on 64bit, etc) | |
| smooge | +1 mizmo. Plus the fact that it seems people choose 64 bit because its bigger than 32 bit | |
| bpepple | ricky: agreed. | |
| mizmo | again, the people who care are the vast minority so i would prefer the screen not be designed for and by a minority | |
| smooge | or at least the people I have had to deal with "why isn't this DVD working?" have been that way | |
| mizmo | smooge, that is exactly what happened to my little bro when he tried fedora out | |
| smooge, and he doesn't have 64 bit | ||
| nirik | +1 to banner. Too bad about f11... oh well. :( | |
| ricky | As a side note, we'd rather avoid depending on javascript/browser detection on get-fedora. The example that always gets brought up is somebody downloading Fedora on somebody else's computer. | |
| jwb_ | nirik, it's only 6 months ;) | |
| jds2001 | +1 to banner | |
| mizmo | im sorry to be a royal PITA about this, but the entire design falls apart when you keep adding these options. | |
| drago01 | well ok lets agree on the banner if this is possible | |
| notting | i am not a interaction designer. +1 to mizmo doing what she feels is best | |
| jwb_ | mizmo, i don't think you're being a PITA | |
| mizmo | you add back a 64 bit button then the kde people will want a button | |
| * dwmw2 defers to mizmo | ||
| ricky | I'm not crazy about the banner though. | |
| mizmo | jwb_, well i could be less grumpy maybe lol | |
| ricky, me neither :( | ||
| bpepple | +1 to mizmo doing what she feels is best. | |
| ricky | Because then we'll need to have a KDE Live x86_64 page, which is a pain. | |
| nirik | mizmo: I don't disagree either. It's not a easy problem to solve. | |
| drago01 | mizmo: I do understand that providing a lot of options to the user is not a good idea .. but hidding the 64 bit version in some subpage is wrong either | |
| mizmo | drago01, handling kde in a subpage is wrong then too. as is handling ppc in a subpage. | |
| ricky | The thought I had was having a 64 bit link next to the 32 bit one, if that's not too potentially confusing. | |
| mizmo | drago01, thats a slippery slope argument | |
| * nirik thinks this also ties very heavily into the "who is our end user" discussion. | ||
| drago01 | mizmo: well ppc is not consumer hardware | |
| mizmo | ricky, i think thats a bad idea because again, you're now presenting a choice to the 90% of users who will be paralyzed when they don't know the answer and flee to ubuntu.com | |
| drago01 | kde is a different story | |
| mizmo | drago01, there are plenty of old macs out there. | |
| ricky | That's true. How do you think we should handle the KDE Live CD then? Just give up and make yet another page for it? | |
| drago01 | hmm ubuntu seems to just add radio buttons | |
| to choose between the two | ||
| but thats even worse | ||
| mizmo | ricky, here's how i would handle it - | |
| drago01, im not by any means trying to refer to ubuntu as a model to follow in anything | ||
| ricky, my assumption is that if yo uclick on the x86_64 link, you probably know what you're doing. | ||
| ricky, so the page you get can be a bit more cluttered than the front page since we'd have advanced users going there | ||
| ricky, so i would split out the x86_64 bit page to have the desktop spin in a block, the kde spin in a block, and then link out to the full links page | ||
| ricky, oh and it should have tehe install dvd for 64-bit too | ||
| ricky | That doesn't feel all that morally different from telling x86_64 users to just go to the all page | |
| drago01 | btw I disagree that using x86_64 is an advanced usecase | |
| mizmo | ricky, so the x86_64 page should have (in this order) desktop live 64bit, kde live 64bit, install 64-bit | |
| jwb_ | so we're going in circles | |
| drago01 | its using what is best suited for the hardware | |
| ricky | But I guess halfway simple is better than not simple. | |
| jwb_ | and it FESCo already deferred to mizmo | |
| mizmo | ricky, it is different, because they get one button for the major three choices for x86_^4 | |
| jwb_ | er | |
| s/and it/and i think | ||
| dwmw2 | anyone with 1GiB or more of RAM in their PC wants x86_64.... | |
| mizmo | ricky, but you're right on another level too, the original idea was one simple link for 90% of people, advanced users click once more to the all page. we didn't plan on having banners initially. | |
| jwb_ | dwmw2, except when i have 2 in my 32-bit laptop? | |
| mizmo | dwmw2, that isn't true. | |
| jwb_ | :) | |
| nirik | I vote we defer this and revisit if/when the board says "here is who fedora is for". :) | |
| ricky | Are the situations where x86_64 is beneficial documented in the install guide? | |
| mizmo | dwmw2, half the machines i own, i have no idea what their ram is or if they are 32-bit or 64-bit. i doubt my parents know what their arch is | |
| dwmw2, the point of the redesign was to be friendlier to more than just techies. | ||
| ricky | Because that's the first step, and we link to the install guide if people aren't sure which to download. | |
| drago01 | ricky: the situation is "when the hardware supports it" | |
| mizmo | ricky, but which is better? a page with one simple link that works for 90%, or a page with a scary question and a link to a 100-page manual for you to download and read to answer that scary question? | |
| dont you think people would want to pass on taking an exam to try out linux | ||
| bpepple | mizmo: ;) | |
| mizmo | the assumption here, that is not shared by all | |
| is that 32 bit os on 64-bit hardware is a tragedy and a big problem that must be solved. | ||
| jds2001 | ok, so we've already deferred to mizmo. Is there anything more productive here we can do? | |
| nirik | we may also be able to get smolt to tell us % that are in that situation. | |
| jds2001 | we do have other agenda items :) | |
| ricky | If there were some way to say: "If you care, read this" | |
| drago01 | mizmo: it is as ram prices are decrasing and people will not use there old machines for ever | |
| mizmo | ricky, where would that go? | |
| drago01, ram prices may be falling, but how many people these days seriously buy and install ram upgrades on their own? | ||
| jwb_ | so can we move this to the websites list or channel? | |
| mizmo | drago01, seriously? | |
| ricky | No idea, just throwing that idea out there. | |
| mizmo | ricky, maybe under resources | |
| drago01 | mizmo: no not ram upgrades but new pcs will have more ram as a conseqence | |
| mizmo | okay im done, sorry | |
| i hope this all helped | ||
| ricky | Heh, sorry for taking up the meeting, let's continue this on fedora-websites-list, for those that are interested | |
| notting | we shold probably move on in the agenda | |
| jwb_ | thanks | |
| thanks for the input mizmo and ricky | ||
| and drago01 | ||
| jds2001 | alright, FPC has a few drafts. One of them requires a Ph.D. or two to understand :) | |
| jds2001 | .fesco 148 | |
| zodbot | jds2001: #148 (FPC report - 2009-05-12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/148 | |
| * nirik suggests we do them one at a time. | ||
| jds2001 | yeah | |
| drago01 | ricky: that what I tried to do from the beginning but it seems that nobody really cared and rahul pushed me to get this to fesco | |
| drago01 | but ok lets move this to the list | |
| jds2001 | GConf scriptlets. | |
| nirik | abadger1999: so what does this improve? | |
| bpepple | nirik: less verbose for starters. ;) | |
| abadger1999 | nirik: This should improve the speed of updates some. | |
| nirik: It's shorter and simpler for what you write in the spec files. | ||
| nirik | ok, so how are existing packages to be changed? | |
| abadger1999 | And it hides implementation details that might be changing i nthe future. | |
| nirik | (in mass? bugs filed and maintainers do it (with tracker)? something else)? | |
| notting | what's the /var/lib/rpm-state bits for? | |
| abadger1999 | There's no need to switch over old packages. But switching will give us a speed improvement. | |
| I'd ask mclasen if he wants us to do a switch or just let people make changes on their own. | ||
| nirik | ok. It would be good to change for consistency at least, never mind the speed changes... | |
| abadger1999 | notting: /var/lib/rpm-state is needed to hold temporary files between the %pre and %post stages of the package install. | |
| notting | %dconf_will_save_us | |
| * jds2001 votes for GConf2 to own /var/lib/rpm-state/gconf - it just Makes Sense(TM) | ||
| jwb_ | +1 | |
| dwmw2 | +1 | |
| jwb_ | er, to that and the guideline | |
| nirik | +1 here... | |
| bpepple | +1 | |
| sharkcz | +1 | |
| jds2001 | +1 | |
| notting | +1. if someone wants to mass-fix packages, that would be swell | |
| jds2001 | i see 7 +1's, so we've approved the GConf scriptlets guideline | |
| nirik | or mass file/tracker bug it. | |
| jds2001 | Globus? | |
| * nirik notes many globus packages are already in... does this change them any? | ||
| jds2001 tried reading through this, I think that's why I overslept this morning :) | ||
| abadger1999 | nirik: Nope. The globus packager wrote this and hasbeen updating hisspec files | |
| nirik | excellent. +1 here then. | |
| dwmw2 | +1 | |
| jds2001 | +1, not that i entirely understand it, but there's nothing insane in it. | |
| notting | +1 on the 'seems reasonable'. not a globus expert, not sure i want to be one | |
| bpepple | +1 | |
| jwb_ | +1 | |
| sharkcz | +1 | |
| jds2001 | i see six +1's, so we've approved the Globus guidelines | |
| er make that seven :) | ||
| Pre-review? | ||
| dwmw2 | this seems sane | |
| jds2001 | +1, seems to be what we were looking for. | |
| jwb_ | i like this quite a bit actually | |
| +1 | ||
| notting | +1 | |
| sharkcz | +1 | |
| bpepple | +1 | |
| dwmw2 | +1 | |
| nirik | +1 | |
| jds2001 | i see seven +1's, so we've approved the pre-review guidelines. | |
| nirik | oh. one thing on this... | |
| jds2001 | next, for the local IPv6 nut in the house :) | |
| jds2001 | .fesco 149 | |
| zodbot | jds2001: #149 (NetworkManager IPv6 - https://fedoraproject.org/wiki/Features/NetworkManagerIPv6) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/149 | |
| * jds2001 is getting slap-happy, sorry :) | ||
| nirik | should we make it clear that want fesco to approve uses of prereview moving forward? | |
| bpepple | nirik: yeah, that sounds like a good idea. | |
| jds2001 | nirik: good point | |
| nirik | otherwise it could just get used for anything at all, which I think is not the intent. | |
| jds2001 | nirik: not really | |
| abadger1999 | nirik: Along those lines, note that there was a feeling in fpc that they didn't like pre-review at all. | |
| jds2001 | since it says it will be imported into some sort of special tag only | |
| abadger1999 | nirik: If it comes up again, might want to have some discussion on fedora-devel list first. | |
| jds2001 | and of course such a thing needs to exist :) | |
| nirik | I personally thought it was ok as a one-off to help java guys, but not as a long term policy for new packages or anything. | |
| bpepple | abadger1999: sounds like a reasonable request. | |
| nirik | abadger1999: can you add a 'rel-eng/fesco must review and approve package groups that intend to use this guideline' ? or something like that. | |
| abadger1999 | nirik: Sure. Can I also add, "this was a one-off and needs to be discussed ahead of time before being used again" ? | |
| nirik | yes, that sounds good to me at least. | |
| jds2001 | abadger1999: sure | |
| abadger1999 | Excellent. Making the change now | |
| jds2001 | alright, on to the NM IPv6? | |
| notting | +1 to NMv6 | |
| dwmw2 | +1 to this | |
| bpepple | +1 NM feature. | |
| sharkcz | +1 | |
| nirik | +1 | |
| jds2001 | +1 | |
| i see six +1's, no we've approved NM IPv6 feature | ||
| jds2001 | .fesco 150 | |
| zodbot | jds2001: #150 (NetworkManager System connections - http://tinyurl.com/o2pzay) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/150 | |
| jds2001 | +1 | |
| dwmw2 | +1 | |
| sharkcz | +1 | |
| notting | +1 | |
| nirik | +1 | |
| bpepple | +1 | |
| nirik | (I guess still using network for bonding and other exotic cases) | |
| jds2001 | yeah, i wouldnt expect this to grok bonding | |
| i see six +1's, so we've approved the NM System Connections feature | ||
| jds2001 | .fesco 151 | |
| zodbot | jds2001: #151 (PolicyKitOne - https://fedoraproject.org/wiki/Features/PolicyKitOne) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/151 | |
| bpepple | +1 to PolicyKitOne | |
| jds2001 | having an actively developed PK is a Good Thing(TM) | |
| +1 | ||
| nirik | I vote yes on PolicyKitOne (just for pjones and his hatred of +1). ;) | |
| jds2001 | nirik: :) | |
| sharkcz | +1 | |
| notting | pk1+1 | |
| jds2001 | notting: is that pk2? :) | |
| jwb_ | yay | |
| dwmw2 | +1 | |
| jds2001 | i see seven affirmative votes, so we've approved PolicyKitOne :) | |
| jds2001 | so i have one other item on the agenda that i dont think belongs there anymore | |
| jds2001 | .fesco 108 | |
| zodbot | jds2001: #108 (Would be good if there was an acl for "let all packagers edit this package" in pkgdb) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/108 | |
| jwb_ | why doesn't that belong? | |
| jds2001 | we discussed it last week? | |
| bpepple | didn't we discuss this last week? | |
| * bpepple see jds2001 beat him to the question. | ||
| jwb_ | oh, yes | |
| man... i think i'm getting old | ||
| bpepple | jwb_: hmm, that doesn't bode well for me since I've got a few years on you. | |
| jds2001 | jwb_: im older than you and therefore more senile :) | |
| abadger1999 | jwb_: It's the kids' fault. | |
| jwb_ | agreed with all that | |
| :) | ||
| * jds2001 has nothing more | ||
| jds2001 | i didnt think we'd get through everything today, but we did. | |
| Yay! | ||
| --- jds2001 has changed the topic to: FESCo meeting -- Open Floor | ||
| nirik | I have one item to mention: | |
| jds2001 | oh, i have one more too. | |
| nirik | elections. | |
| jds2001 | nirik: we're thinking the same :) | |
| nirik | yeah. | |
| https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations | ||
| open today it seems | ||
| jwb_ | so is anyone whose seat is _not_ up going to step down? | |
| nirik | https://fedoraproject.org/wiki/Elections | |
| jwb_ | that would be me, j-rod, sharkcz, and jds2001. i'm staying. | |
| * jds2001 plans on staying | ||
| bpepple | my seat is also up. I'm still debating if I'm going to run. | |
| j-rod | no plans to leave | |
| jwb_ | want to make sure we are telling people we have the right number of seats open | |
| sharkcz | I am also staying | |
| * nirik is also debating. Fresh blood might be a good thing. | ||
| jwb_ | bpepple, i was asking about the people who don't have terms up | |
| jwb_ | ok, seems all of those people are staying. proceed :) | |
| bpepple | jwb_: ah, wasn't paying that close attention. ;) | |
| jwb_ | notting, dwmw2, are you running again? | |
| dwmw2 | yeha | |
| although if the meetings keep running for 2 hours (till 8pm on a Friday night) I might reconsider :) | ||
| jwb_ | just think of it as a way to get a 2 hour jump on beer drinking | |
| bpepple | dwmw2: yeah, that does sorta suck. | |
| jwb_ | oops, did i say that out loud? ;) | |
| notting | jwb_: was planning on it | |
| bpepple | jwb_: hey, some weeks that's the only way to get through the meetings. ;) | |
| jwb_ | heh :) | |
| dwmw2 | I thought the idea of having a 2-hour slot was that we wouldn't screw over the unfortunate people who booked the meeting room after us, when we occasionally ran over by 5-10 minutes | |
| not that we'd actually _use_ it :) | ||
| bpepple | dwmw2: yeah, that was the original thought. | |
| jds2001 | dwmw2: work expands to fill the time available for it's completion :) | |
| * dwmw2 heads off to find food | ||
| jds2001 | surely you have read parkinsons law | |
| jwb_ | whose doing minutes? | |
| jds2001 | you are :) | |
| jwb_ | ok | |
| jds2001 | wow, i was joking, but if you would I'd love it :) | |
| jwb_ | i wil | |
| i'll start right now | ||
| jwb_ | before i forget :) | |
| jds2001 | :) | |
| bpepple | I'll upload the log in the usual spot. | |
| jwb_ | bpepple, which is where? | |
| jwb_ | i was planning on doing that too, but that will help me greatly | |
| bpepple | http://bpepple.fedorapeople.org/fesco/ | |
| jwb_ | bpepple, cool | |
| bpepple | Give me a minute, and I'll get it there. | |
| jwb_ | ok | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!