--- jds2001 has changed the topic to: FESCo meeting -- init
jds2001FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod
* notting is here
nirik is here.
jwb_ is here
sharkcz is here
* bpepple is here.
jds2001dgilmore-oz said he'd try to make it, but it's 2AM down under :)
* skvidal is here
nottingdo we need to reschedule for him? or is he back at some point in the near future?
* dwmw2 here
jds2001he's on vacation
notting(then again, scheduling for USA, sharkcz, dwmw2, and dgilmore-oz simultaneously....)
jds2001it was like 3 weeks total.
* j-rod here
sharkcznotting: IIRC he is going back next week
bpeppleat 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.
jds2001yeah, 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
zodbotjds2001: #144 (PPC as a secondary arch for Fedora 12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/144
jds2001so jwb_ wanted me to do this one first.
jwb_most of us discussed this at the last FESCo meeting
jwb_the proposal that was generally agreed on was:
jds2001any 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?
dwmw2I'm happy with that as long as there are no infrastructure blockers preventing a successful F13 release
jwb_(or anyone else for that matter)
sharkczjwb_: 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
sharkczjwb_: np
dwmw2jwb_: as long as it is technically possible for the interested folks to actually _do_ it
dwmw2which I _think_ it should be
bpeppleI'm still +1 to the plan also.
* notting is still +1
jwb_dwmw2, i think so too.  it's technically possible today
dwmw2judging by the feedback we got from the other teams on why they haven't released yet
jwb_i'm going to vote -1 on this, for a few reasons and not solely because i happen to like ppc
jds2001care to elaborate?
bpepplejwb_: 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
dwmw2if 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'?
dwmw2you get the benefit that way in keeping Fedora portable, but don't put the burden on the releng folks
j-rodI 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
jds2001once AMQP messaging gets working, we can build all secondary arches simultaneously
dwmw2jwb_: not if the _releases_ are shipped separately in the secondary/ tree
jds2001</pe in the sky>
f13not 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
nottingand it then gets weird with other arches
f13jds2001: amqp won't necessarily help with that
jds2001f13: 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
f13fwiw 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.
jds2001of course the kojis have to be in shape to do that :)
f13jds2001: 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
dwmw2f13: arguably it's _better_ while a build breakage is killing the main build
f13builders ask the hub every few minutes "is there anything for me to do"
dwmw2: that's an argument.
dwmw2I 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?
f13and 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
zodbotjds2001: #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
jds2001jwb_: 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
jds2001-1 here too.
bpepple-1, agrees with notting.
dwmw2you can revoke mine too if you like -- I broke the repo this week too
nirikrwmjones: do you understand why broken deps are bad ? or do you think this was ok?
rwmjonesnirik, yes, I see obviously almost no one agreed with my points in that thread ;-)
nirikrwmjones: 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?
rwmjonesI would like to see it in the packaging guidelines though
jds2001jwb_: because provenpackager is implied in sponsor.
abadger1999jwb_: 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?
rwmjonesnirik, truthfully, much functionality is lost by not having that dep, but for EPEL-5 case I am actively working on fixing that problem
jds2001jwb_: yes, it's technically possible,
abadger1999jwb_: Yes.
nirikrwmjones: 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
rwmjonesnim-nim, https://bugzilla.redhat.com/show_bug.cgi?id=497625
buggbotBug 497625: medium, low, rc, ehabkost, NEW, Add vmchannel support to qemu-kvm
jds2001jwb_: the reasoning is that a sponsor can fix sponsoreees issues.
rwmjonesTBH I just want to sponsor kalev
he's a good packager, and I've followed his BZ's
nirikrwmjones: providing packages with broken deps is very bad. Decreasing functionality with a runtime check is sad, but much more acceptable.
rwmjonesif I lose sponsor status, I want to be sure that he is sponsored by sb else soon
dwmw2if the sponsor goes away, does that revoke all sponsorships?
jds2001rwmjones: we've already voted not to do that.
dwmw2that seems... odd
jwb_dwmw2, no
nirikjwb_: 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?
nirikthe other way is different.
jwb_anyway, that's a larger item to discuss (again)
dwmw2we digress...
jwb_very much
niriksome 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.
jds2001so we have voted not to revoke sponsorship or provenpackager from rjones.
nirikyeah, sorry.
rwmjonesnirik, I'm the opposite - i don't want to use my PP rights
but do want to sponsor
jds2001can we move slightly on? :)
* dwmw2 suspects that rjones is suitably educated now :)
drago01rwmjones: no one is forcing you to use them ;)
jds2001.fesco 147
nirikrwmjones: yeah, but the relationship to me means if you are a sponsor you should also meet the requirements of PP.
zodbotjds2001: #147 (Meeting agenda item: No broken dependencies should be a packaging guideline) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/147
rwmjonesok so this is my ticket ...
dwmw2er, packaging committee?
rwmjoneswell, there was a complex question of if this should be a fesco policy
rwmjonesor something for FPC
dwmw2proposals like that don't come directly to FESCo iirc
jds2001yeah, i've already started a thread on f-packaging
rwmjoneswhich tbh I don't really understand
jwb_i think write a guideline we can't enforce at the moment seems a bit odd
jds2001it's really hard.
dwmw2jwb_: on the contrary -- if we could enforce it, we wouldn't need the 'guideline' :)
rwmjonesjwb_, well it could just outlaw deliberate dep breaking
drago01jwb_: we can't enforce most of the guidelines (after the initial import)
rwmjonesaccidental would still be ok
jwb_drago01, we could, if we tried
abadger1999It's also not something that is easily provable at reviewtime.
nottingwell, deliberate dep breaking is already forbidden by the 'can not require things not in fedora' clause. although that's sort of a technicality
jds2001and chain imports would then be prohibited.
abadger1999And as written, I'd argue it's really a FESCo decision/assumption.
drago01jwb_: new review bug after every change?
bpeppleabadger1999: I agree.
jwb_notting, it doesn't say 'in this particular release of fedora'
which is where this issue stems from
rwmjonesnotting, that depends what you mean by 'fedora' ... it might have to be tighter like 'this release of fedora'
jwb_drago01, we digress
drago01jwb_: yeah
abadger1999drago01: We tried that at fedora.us.  Too much work to do managably.
jds2001many years and many thousands of packages later.....
nirikI'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.
nirikso can we add it to fesco policy, and also update the review guidelines/packaging pages to mention it?
abadger1999nirik: <nod>  That's something that needs to be thought about long term.
nottingi always thought it was common sense - a package with broken deps cannot be installed by our tools
abadger1999How do we introduce packagers to all te things they need to know spread out over several areas of the wiki.
nirikfrankly I think it's common sense, but it's easier IMHO to just write it down and drive on rather than discussing it forever.
rwmjonesabadger1999 is right about that
dwmw2Proposal: This should be referred to the packaging committee
bpeppleisn't it mentioned in the maintainer responsibilities policy?
skvidalquick question
* nirik finds the wiki slow to answer. ;(
skvidalsince everyone seems to be hellbent to treat things like a trial
under what terms should provenpackager be revoked
dwmw2skvidal: when it becomes clear that it shouldn't have been granted in the first place
skvidaland what is the criteria
jds2001skvidal: repeated, egregious offenses.
* nirik thinks continued and willfull violations of policy.
skvidalrepeated AND egregious?
or repeted OR egregious
wwoodsI think "willful" is an important term for this definition.
jds2001wwoods: good point
nirikwwoods: yeah, bothersome to wills? :)
jds2001as somneone pointed out to me in private, words on the wiki don't cost us anything.
abadger1999So one thing I wonder in that definition -- does it matter if they're different offences?
skvidaly'all have all seemed to believe that rwmjones' was not egregious enough.
skvidalbut it was obviously willfull
jds2001sure, but it happened once.
skvidaland it was done on both el5 and f10 - so it was repeated
nirikrwmjones: would you do something like that again?
rwmjonesnirik, no of course not
kalevHello everybody, can I say a word about rwmjones?
rwmjoneswell, I'm not counting accidentally/through stupidity of course
jds2001sure thing.
kalevI am interested in Fedora mingw32 packages and some time ago I wanted to contribute back to Fedora by packaging some libraries.
abadger1999b/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.
drago01skvidal: he did a mistake, learned from it .. lets go on
jds2001rwmjones: everyone suffers form that a bit :)
kalevrwmjones 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
skvidaldrago01: I don't believe the second clause at all, actually
kalevsponsor to someone else in the future
skvidaldrago01: given the vehement "if it is not in the rules then it can't be an offense" defense he gave
skvidaldrago01: but let's not worry about him for the moment
dwmw2I think all requests to revoke access need to be considered on their own merit
skvidalif we're going to treat this like a law court
(since it is clear everyone here seems to think that's how it is)
dwmw2I don't think it makes sense to make up a formula in advance
skvidalthen lay down the rules
dwmw2no, 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.
skvidaldwmw2: I don't either. but there seems to be this misguided idea that rules need to be established
dwmw2yeah, I disagree with that
policy is just a euphemism for not having to think
jds2001skvidal: i dont think that nay of us voted that way we did because something wasnt written down.
markmckalev, welcome to fedora, and please try and ignore all this arguing :)
jds2001skvidal: after having a bit to think about it (really hard), I decided that a single transgression just didn't rise to that level.
dwmw2I think skvidal is right to resist the 'must have rules' mentality.
now, can we get back to the point? :)
jds2001now if the transgression had been putting 'rm -rf /' in %post of the kernel, that'd be different.
skvidaljds2001: okay - then under what assumptions/reasoning is provenpackager granted?
jds2001there's no rule against that either.
rwmjonesjds2001, 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.
dwmw2skvidal: we assume that it would be good for Fedora as a whole if the person is able to contribute to all packages
skvidalwhy do we have provenpackager, again, then?
dwmw2to allow people to contribute to all packages?
skvidalbut not to sponsor
dwmw2or, 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
skvidalapparently it is not
given the circumstances just discussed
jds2001skvidal: er?
* dwmw2 confused
jds2001 too
skvidalis 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
skvidalare there any cases of pp w/o sponsor?
dwmw2thus, revoking pp implies revoking sponsor
jds2001skvidal: yes
skvidalah, who?
nirikmany of the desktop team folks
then I'll retract tat
err that
rwmjoneswhy is there a hierarchy between the two?  why not just separate things
nirikrwmjones: we could.
bpeppleskvidal: 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.
dwmw2meeting over in 20 minutes?
jwb_dwmw2, we're scheduled for 2 hours i think
dwmw2joy :)
bpeppledwmw2: wishful thinking.
markmcrwmjones, jwb_ gave the rationale earlier - "a sponsor should be able to commit fixes for sponsoree's mistakes"
nirikrwmjones: 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
dwmw2I don't see a good reason to change it
rwmjonesnirik, as I said before I don't mind, so long as kalev is sponsored and we don't lose him in non-sponsored limbo
nirikrwmjones: but don't you use provenpackager to commit to some of the mingw packages? or you own all those?
jds2001rwmjones: nothing is happening to your sponsor status, we already voted on that :)
rwmjonesnirik, I co-maint many of them, but by no means all of them
dwmw2can someone remind me what agenda item we _are_ on now... ?
skvidaldwmw2: the guidelines
jwb_'make a policy about broken deps'
jds2001we're supposedly talking about the guidelines.
skvidaldwmw2: 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'
dwmw2Proposal: Packaging guidelines are for FPC to handle.
jwb_dwmw2, not a packaging issue
dwmw2https://fedorahosted.org/fesco/ticket/147 ?
jwb_broken deps can happen for a variety of reasons
jwb_well, not solely a packaging issue anyway
dwmw2the ticket we're discussing explicitly says 'added as a new section to the Fedora packaging guidelines' ...
ok, +1 to the guideline then
jds2001right, and that FPC would have to handle.  But FPC doesn't believe it's the right place.
abadger1999jds2001: Note: FPC could debate a different version of this for Guidelines.
FPC would be more implementation.
abadger1999OTOH, this is really common sense.
It might not pass FPC.
rwmjonesI'm more than happy to take on the responsibility of taking this to FPC
rwmjonesjust raised here because there was the question of whether it should be a fesco policy
nirikProposal: "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"
jds2001nirik: where does that go?
nirik: review guidelines?
nirikyeah, 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
nirikor if someone else does.
nirikor if rpm has a bug
or ...
jwb_hence my 'enforce' comment earlier
nirikwell, if we could enforce it, we could just say "no packages with broken deps will be released"
jds2001that's unenforceable :(
nirikcurrently, sure.
abadger1999nirik: That would be better, imho.
nirikrwmjones / 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
nirik(or feel free to enhance it to something that will pass, I don't care :)
abadger1999I can help with wording... but I'm not sure that I'm for it so rwmjones, you'll need to be the main proponent :-)
nirikcool. Shall we move on?
jds2001sounds good.
jds2001.fesco 142
zodbotjds2001: #142 (Make x86_64 more visible or even the default choice) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/142
jds2001i guess unless someone has other ideas on what we should cover next :)
jds2001so i missed this last week
nirikdo we have any data here? what % is 32/64? what % is 32 but could be 64?
jds2001but when i first saw it, i thought this was more a websites thing than fesco
jds2001nirik: no data :(
im trying to get mizmo real quick
nirikadd websites to cc, ask for data, punt to next week? :)
dwmw2nirik: +1
nirikin general I think it's a good idea to get folks with 64bit hardware running 64bit os...
jds2001hey mizmo thanks for coming on such short notice :)
jds2001so there's a fesco ticket to make x86_64 more visible or the default
jds2001i know that you did a huge redesign of get-fedora.
mizmoit seems pretty simple to fix, just add a banner on the side above the ppc banner to link directly to x86_64
abadger1999drago01: Is that what you were envisioning?
mizmothe problem here is that it used to be, clicky clicky get live x86 32-bit, everything else go to the full blown page
nirikwell, I think the reporter wanted the main desktop one to go to x86_64
mizmobut then ppl kept saying 'what about MY spin'
so we started adding those banners
mizmothat's why x86_64 is not as obvious as it used to be. because originally we didn't call out kde and ppc
drago01abadger1999: its better as the current situation (completly hidden) but still not optimal
mizmoits not completely hidden
why would the main desktop one go to x86_64
drago01let me rephrase "hidden from the main screen"
mizmothats a terrible idea
it's not hidden from the main screen. you click view all and it's on the view all screen
drago01thats the point why should a user click view all rather than just download?
mizmothe one download that will work for 90%+ of users is the one on the main screen.
drago01unless he knows that there is something he is searching for
mizmodrago01, 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?
nirikwell, we can't know what arch someone is... and many people won't know either.
mizmobecause 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
nirikmizmo: yeah, but then lots of people with 64bit hardware get a 32bit os...
mizmonirik, but it works does it not?
niriksure, but it's not ideal. Not sure how we could detect that tho. ;(
jds2001yeah, but there are advantages to the 64bit os
mizmothe 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
dwmw2the 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)
mizmothats a really cool idea dwmw2
dwmw2that would be more useful than web site tweaks
nirikdwmw2: won't help with live tho.
jwb_and require changes that would make clumens weep
jds2001nirik: i know that on fedora at least ff passes the arch in user-agent
nirikjds2001: yeah, perhaps we could use that (for f12...)
jds2001wouldnt do anything if i were running 32bit os though :)
drago01mizmo: 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%
dwmw2this works nicely for ppc32/ppc64 :)
mizmowhat 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
drago01we should make this more visible to the user
mizmodrago01, which user?
nirikmizmo: sure, agreed.
mizmowhich 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.
nirikmizmo: will adding more banners to the right side be a problem? or make it too busy?
mizmonirik, 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
nirikthey are kinda distracting and could confuse people... KDE? do I want that?
nirikwhat is it? :)
mizmobut thats the problem when special interest groups demand a banner
and are appeased
drago01mizmo: ok if we can agree on the banner it would be an improvement
mizmoand id rather ad a banner for KDE then get into the tarpit of arguing gnome vs kde
nirikhow about a Xfce banner? :)
mizmosince getting into that argument is like buying a ticket for the titanic
jds2001nirik: i was waiting for that :)
drago01what about this:
mizmoi hope you are kidding about xcfe
er xfce
smoogeI want my TVTWM banner, nirik
mizmoif not, let me clear some space on my desk for my forehead
dwmw2mizmo: on EEE? probably not...
nirikmizmo: 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)
mizmodrago01, no
no way
nirikhow about we add a '64bit' to the right side for now.
mizmoonce 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.
jds2001drago01: and what is this "explanation"
mizmobanner on the right is fine. no 32 vs 64 bit choice in the main download area.
bpepplealright, does anyone on fesco have an objection to the banner solution proposed by mizmo?
mizmoit 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.
nirikand 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
bpepplericky: agreed.
mizmoagain, the people who care are the vast minority so i would prefer the screen not be designed for and by a minority
smoogeor at least the people I have had to deal with "why isn't this DVD working?" have been that way
mizmosmooge, 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. :(
rickyAs 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
mizmoim sorry to be a royal PITA about this, but the entire design falls apart when you keep adding these options.
drago01well ok lets agree on the banner if this is possible
nottingi 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
mizmoyou add back a 64 bit button then the kde people will want a button
* dwmw2 defers to mizmo
rickyI'm not crazy about the banner though.
mizmojwb_, well i could be less grumpy maybe lol
ricky, me neither :(
bpepple+1 to mizmo doing what she feels is best.
rickyBecause then we'll need to have a KDE Live x86_64 page, which is a pain.
nirikmizmo: I don't disagree either. It's not a easy problem to solve.
drago01mizmo: 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
mizmodrago01, handling kde in a subpage is wrong then too. as is handling ppc in a subpage.
rickyThe thought I had was having a 64 bit link next to the 32 bit one, if that's not too potentially confusing.
mizmodrago01, thats a slippery slope argument
* nirik thinks this also ties very heavily into the "who is our end user" discussion.
drago01mizmo: well ppc is not consumer hardware
mizmoricky, 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
drago01kde is a different story
mizmodrago01, there are plenty of old macs out there.
rickyThat's true.  How do you think we should handle the KDE Live CD then?  Just give up and make yet another page for it?
drago01hmm ubuntu seems to just add radio buttons
to choose between the two
but thats even worse
mizmoricky, 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
rickyThat doesn't feel all that morally different from telling x86_64 users to just go to the all page
drago01btw I disagree that using x86_64 is an advanced usecase
mizmoricky, 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
drago01its using what is best suited for the hardware
rickyBut I guess halfway simple is better than not simple.
jwb_and it FESCo already deferred to mizmo
mizmoricky, it is different, because they get one button for the major three choices for x86_^4
s/and it/and i think
dwmw2anyone with 1GiB or more of RAM in their PC wants x86_64....
mizmoricky, 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?
mizmodwmw2, that isn't true.
nirikI vote we defer this and revisit if/when the board says "here is who fedora is for". :)
rickyAre the situations where x86_64 is beneficial documented in the install guide?
mizmodwmw2, 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.
rickyBecause that's the first step, and we link to the install guide if people aren't sure which to download.
drago01ricky: the situation is "when the hardware supports it"
mizmoricky, 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
bpepplemizmo: ;)
mizmothe 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.
jds2001ok, so we've already deferred to mizmo.  Is there anything more productive here we can do?
nirikwe may also be able to get smolt to tell us % that are in that situation.
jds2001we do have other agenda items :)
rickyIf there were some way to say: "If you care, read this"
drago01mizmo: it is as ram prices are decrasing and people will not use there old machines for ever
mizmoricky, 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?
mizmodrago01, seriously?
rickyNo idea, just throwing that idea out there.
mizmoricky, maybe under resources
drago01mizmo: no not ram upgrades but new pcs will have more ram as a conseqence
mizmookay im done, sorry
i hope this all helped
rickyHeh, sorry for taking up the meeting, let's continue this on fedora-websites-list, for those that are interested
nottingwe shold probably move on in the agenda
thanks for the input mizmo and ricky
and drago01
jds2001alright, FPC has a few drafts.  One of them requires a Ph.D. or two to understand :)
jds2001.fesco 148
zodbotjds2001: #148 (FPC report - 2009-05-12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/148
* nirik suggests we do them one at a time.
drago01ricky: 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
drago01but ok lets move this to the list
jds2001GConf scriptlets.
nirikabadger1999: so what does this improve?
bpepplenirik: less verbose for starters. ;)
abadger1999nirik: This should improve the speed of updates some.
nirik: It's shorter and simpler for what you write in the spec files.
nirikok, so how are existing packages to be changed?
abadger1999And it hides implementation details that might be changing i nthe future.
nirik(in mass? bugs filed and maintainers do it (with tracker)? something else)?
nottingwhat's the /var/lib/rpm-state bits for?
abadger1999There'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.
nirikok. It would be good to change for consistency at least, never mind the speed changes...
abadger1999notting: /var/lib/rpm-state is needed to hold temporary files between the %pre and %post stages of the package install.
* jds2001 votes for GConf2 to own /var/lib/rpm-state/gconf - it just Makes Sense(TM)
jwb_er, to that and the guideline
nirik+1 here...
notting+1. if someone wants to mass-fix packages, that would be swell
jds2001i see 7 +1's, so we've approved the GConf scriptlets guideline
nirikor mass file/tracker bug it.
* 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 :)
abadger1999nirik: Nope.  The globus packager wrote this and hasbeen updating hisspec files
nirikexcellent. +1 here then.
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
jds2001i see six +1's, so we've approved the Globus guidelines
er make that seven :)
dwmw2this seems sane
jds2001+1, seems to be what we were looking for.
jwb_i like this quite a bit actually
jds2001i see seven +1's, so we've approved the pre-review guidelines.
nirikoh. one thing on this...
jds2001next, for the local IPv6 nut in the house :)
jds2001.fesco 149
zodbotjds2001: #149 (NetworkManager IPv6 - https://fedoraproject.org/wiki/Features/NetworkManagerIPv6) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/149
* jds2001 is getting slap-happy, sorry :)
nirikshould we make it clear that want fesco to approve uses of prereview moving forward?
bpepplenirik: yeah, that sounds like a good idea.
jds2001nirik: good point
nirikotherwise it could just get used for anything at all, which I think is not the intent.
jds2001nirik: not really
abadger1999nirik: Along those lines, note that there was a feeling in fpc that they didn't like pre-review at all.
jds2001since it says it will be imported into some sort of special tag only
abadger1999nirik: If it comes up again, might want to have some discussion on fedora-devel list first.
jds2001and of course such a thing needs to exist :)
nirikI 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.
bpeppleabadger1999: sounds like a reasonable request.
nirikabadger1999: can you add a 'rel-eng/fesco must review and approve package groups that intend to use this guideline' ? or something like that.
abadger1999nirik: Sure.  Can I also add, "this was a one-off and needs to be discussed ahead of time before being used again" ?
nirikyes, that sounds good to me at least.
jds2001abadger1999: sure
abadger1999Excellent.  Making the change now
jds2001alright, on to the NM IPv6?
notting+1 to NMv6
dwmw2+1 to this
bpepple+1 NM feature.
i see six +1's, no we've approved NM IPv6 feature
jds2001.fesco 150
zodbotjds2001: #150 (NetworkManager System connections - http://tinyurl.com/o2pzay) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/150
nirik(I guess still using network for bonding and other exotic cases)
jds2001yeah, i wouldnt expect this to grok bonding
i see six +1's, so we've approved the NM System Connections feature
jds2001.fesco 151
zodbotjds2001: #151 (PolicyKitOne - https://fedoraproject.org/wiki/Features/PolicyKitOne) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/151
bpepple+1 to PolicyKitOne
jds2001having an actively developed PK is a Good Thing(TM)
nirikI vote yes on PolicyKitOne (just for pjones and his hatred of +1). ;)
jds2001nirik: :)
jds2001notting: is that pk2? :)
jds2001i see seven affirmative votes, so we've approved PolicyKitOne :)
jds2001so i have one other item on the agenda that i dont think belongs there anymore
jds2001.fesco 108
zodbotjds2001: #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?
jds2001we discussed it last week?
bpeppledidn't we discuss this last week?
* bpepple see jds2001 beat him to the question.
jwb_oh, yes
man... i think i'm getting old
bpepplejwb_: hmm, that doesn't bode well for me since I've got a few years on you.
jds2001jwb_: im older than you and therefore more senile :)
abadger1999jwb_: It's the kids' fault.
jwb_agreed with all that
* jds2001 has nothing more
jds2001i didnt think we'd get through everything today, but we did.
--- jds2001 has changed the topic to: FESCo meeting -- Open Floor
nirikI have one item to mention:
jds2001oh, i have one more too.
jds2001nirik: we're thinking the same :)
open today it seems
jwb_so is anyone whose seat is _not_ up going to step down?
jwb_that would be me, j-rod, sharkcz, and jds2001.  i'm staying.
* jds2001 plans on staying
bpepplemy seat is also up.  I'm still debating if I'm going to run.
j-rodno plans to leave
jwb_want to make sure we are telling people we have the right number of seats open
sharkczI 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 :)
bpepplejwb_: ah, wasn't paying that close attention. ;)
jwb_notting, dwmw2, are you running again?
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
bpeppledwmw2: yeah, that does sorta suck.
jwb_oops, did i say that out loud? ;)
nottingjwb_:  was planning on it
bpepplejwb_: hey, some weeks that's the only way to get through the meetings. ;)
jwb_heh :)
dwmw2I 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 :)
bpeppledwmw2: yeah, that was the original thought.
jds2001dwmw2: work expands to fill the time available for it's completion :)
* dwmw2 heads off to find food
jds2001surely you have read parkinsons law
jwb_whose doing minutes?
jds2001you are :)
jds2001wow, i was joking, but if you would I'd love it :)
jwb_i wil
i'll start right now
jwb_before i forget :)
bpeppleI'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
jwb_bpepple, cool
bpeppleGive me a minute, and I'll get it there.

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