--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* jeremy is here
* jwb is here
* nirik is here.
abadger1999 sits in the bleachers
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
* tibbs here
jwb is here
bpepplehey, everybody.
* nirik is here still.
* spot is here
f13I'm here.
* poelcat here
bpeppleok, we can probably get started.
* notting is here
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Feature Proposal Approval - http://fedoraproject.org/wiki/Features/Dashboard - notting, poelcat
bpepplepoelcat: you want to lead this?
--- poelcat has changed the topic to: vote on feature: http://fedoraproject.org/wiki/FeatureEclipse33
* c4chris is here
bpepple+1 here also.
notting+1 with a 'whatever'. not sure this needs tracked as such.
jwbditto to notting
tibbsI have zero interest in eclipse or java; if they think thay can be ready with this, then +1.
nirik+1 here, might have a bugzilla tracker bug for all the affected packages (but thats a detail up to the maintainer I suppose)
bpeppleOk, that's seven '+1'.  any other comments before moving on?
* f13 looks
f13Eclipse is going to be IceTea ready?
nottingf13: it ran on proprietary jvms before...
*shrug* +1
jwbmove on
* bpepple wonders if poelcat is still here.
bpepplevote on feature: http://fedoraproject.org/wiki/Releases/FeatureGenericLogos
--- bpepple has changed the topic to: vote on feature: http://fedoraproject.org/wiki/Releases/FeatureGenericLogos
tibbsI think this is important.
jeremygiven that the contingency plan is the status-quo, I don't know that it's really committing to much :)
notting+1 from me, obviously
bpepplejeremy: agreed. +1
nirik+a lot... this is a good thing.
nottingjeremy: we should talk about anaconda theming, btw :)
nirikand it would be good to tout for f8 too.
daMaestro+1 ... i could work to help with this also
jeremynotting: yeah, it's in my "flagged mail to reply to" pile
poelcatbpepple: thanks... sucked into another meeting, back now
bpepplepoelcat: no worries.
ok, that's more than seven '+1'.
--- poelcat has changed the topic to: followup discussion on feature: http://fedoraproject.org/wiki/Features/IcedTea
poelcatapproval was deferred last week for further clarification
jwbi know nothing about java.  0
cailloni talked to the red hat eclipse team and they were jazzed about it
f13I don't know if we've gotten any clarification.  Has this page been changed at all?
bpepplef13: I don't see any change/
tibbsI still don't get it; we are now trying to get away from native code compilation?
caillonactually, let me see if i can pull someone in here
tibbsWhy would that possibly be a good thing?
jwbtibbs, i wonder that myself
f13I don't see how we can possibly do IceTea on i386/x86_64, but not ppc(64)
nottingf13: did we ask for a clarification on the page?
f13notting: hrm, probably failed that one :(
frozty_saHi...I'm new, but I've got a possible idea for the alternatives package, if I could tell it to whoever is the appropriate person later
caillonhm, i guess they're at lunch
jwbfrozty_sa, talk to someone in #fedora-devel
nottingfrozty_sa: that would probably be me, and -> #fedora-devel, or bz please
frozty_sathanks jwb
* jeremy is all for getting iced tea in and working well
jwbf13, yeah... i'm not overly thrilled about no ppc/ppc64 either
frozty_sanotting, I will speak to you in pm
jwbjeremy, does it drop native compiles?
jeremyf13: it's alternatives, so you get the "best" one
jwb: no, we'd still be doing native compiles for gcj
jwbjeremy, huh?
IcedTea is replacing gcj, yes?
jeremyjwb: gcj isn't going to go away, at least, not yet
jwbjeremy, that's not my question
jeremy, what is e.g. eclipse going to be built with?
jeremyjwb: just that the (already existing and managed by alternatives) /usr/bin/java will point to IcedTea on platforms where we've got it
jwbok, but if we're defaulting to IcedTea, does it compile to native code like gcj does?
jeremyno, you get the native code via gcj
* jeremy thinks he's not understanding the question
jwbbut the page says IcedTea would be the default
jeremyjwb: the native compilation is all done via explicit calls to gcj
jwbgr, hang on
nirikso IcedTea gets used for only non native packages/runtime stuff?
jwbok.  so today we have Eclipse native compiled with gcj, which is the default.  this page is asking to switch to IcedTea as the default.  are we then not going to compile eclipse anymore?
c4chrisnirik: that's what I think I'm understanding too
tibbsI have no problems with "we need a jvm; icedtea will do nicely".
jwbor is eclipse still built with gcj, and therefore gcj is required?
tibbsI have issues with "don't bother compiling any java we ship to native code; just run it all in the jvm".
jeremymy understanding (from talking with fitzsim before my vacation, hence, maybe fuzzy) is that eclipse is still _built_ with gcj.  but on platforms where icedtea is available, at runtime, you'll be using the jars via the jvm and not the native compiled bits
tibbsAnd why on earth would we want that?
jwbjeremy, why would we want that?
belegdoljeremy: wouldn't that be slower
jeremywe _already_ do all of this.  the only difference is what gets done by default
jwbtoday, default is eclipse runs native via gcj
jeremybelegdol: generally not.  the native code isn't necessarily the best in the world :/   try eclipse in the default setup, then try installing a jvm.  see which works faster/better
jwbdo we have numbers?
jeremyjwb: until you install the jdk.  at which point, it gets used instead because it's then /usr/bin/java
jwb: I don't have any recent ones -- I suspect the java guys have more
f13I'm willing to trust the java guys on this one though
so long as we're not screwing outselves on ppc I'm OK with this
(and that the building keeps happening as usual)
jwbi'm still leary
bpepplef13: +1
jwbbut then again, i vote 0
c4chrisso who is a java guy here?
* bpepple is definitely not.
jeremyc4chris: no one!   :-)
caillonwe're having the meeting during their lunch time
c4chriscan we get some advice from a real one?
tibbsIt's my lunch time too....
But aren't these feature requests supposed to come with a driver who will answer our questions?
c4chrisuntil then: 0
bpepplemaybe we should discuss this on the mailing list w/ the java guys?
tibbs tibbs|h
c4chrisbpepple: yea
poelcatcan someone summarize the issue to raise on the feature page or add it themselves?
c4chrisor have one here at the next meeting
bpepplejwb: could you add your concerns/questions to the feature page?
jwbyes.  tibbs, i'll ping you when i've done that to make sure yours are covered too
bpepplejwb: great.  thanks.
poelcatcaillon: are you ready to discuss http://fedoraproject.org/wiki/Releases/FeatureNetworkManager ?
jwb tibbs thanks
caillonpoelcat: one more week
poelcat: i need more clarification on something still
poelcatcaillon: fair enough... i'll raise next week
poelcatbpepple: no more features :)
bpepplepoelcat: cool.  Thanks.
moving on then.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Bugs blocking approved features -- notting
bpepplenotting: you wanted to discuss this.
nottingthis came up in regards to the 'disabling xfs' feature. it would be done, but it's blocking on changes to the font packages, some of which have been in bz for over a month w/o comment
and the question was - should there be some sort of step-in process? add people to ACLs? have an admin apply the changes? start AWOL maintainer?
jwbi thought people wanted xfs enabled?
oh, wrong xfs
nirikif there hasn't even been response I would say start awol procedure.
c4chrisnirik: agreed
tibbsYes, this is no different than any other non-response issue, I think.
* nirik is on cc for 3 font packages and hasn't seen any bugs on this. Is it all fonts?
nottingnot necessarily
caillonwhat packages are we blocking on:?
nottingcaillon: urw-fonts is the one that brought this up. i think jens was taking care of the asian ones
nirikThe danger of an admin stepping in is that then people then have an expectation that it's maintained, and if the maintainer is gone we want to know and have someone take it over.
nottingi suspect it is very much more 'maintainer slow/unresponsive' than 'gone'
jwbnotting, not even a single comment in the bug?
caillonhas a bug been filed?
nirikperhaps some public shaming then? post to maintainers or devel ?
nottingshould there be some sort of middle step between <no response> -> AWOL process?
jwbnotting, did someone try emailing them directly?
nottingi doesn't know
caillonand how long have we given them (trying to account for vacatoin, etc)
jwbthe AWOL process covers all that
nirikah, urw-fonts is than... ;) He's very busy
jwbjust follow it
tibbsWe know than isn't AWOL.
nottingcaillon: in this case, 6+ weeks
caillonclearly he's not awol though
bpeppleI'm inclined to have someone step-in, since this is holding up the feature.
jwbi would say AWOL in this case is package based
bpeppleand the maintainer clearly isn't awol.
nirikyeah, he may not be awol, but if he's too busy, someone else could take over the package.
abadger1999jwd: +1
jwb even.
c4chrisyea package based AWOL sounds reasonable
cailloni think i'd rather open up the acl.  he'd still own the package, but if he's blocking on fedora features, we need to step in.
nirikthere are 2 bugs about it filed, both priority "low"
bpepplecaillon: +1
nottingnirik: that's the default
nirikand no comments on the older one since 06-26.
jwbcaillon, that's fine with me
nirikI suppose for the feature we can have someone else do this change, but if than is too busy to maintain the package it would be best if someone take it over.
so, where are we here? vote on having an admin make the change and ask than if someone should take over the package?
cailloni'd really like than to reply though to confirm the change(s) are correct for his package
nirikis someone in the same office as than and can go over and ask him?
nottinghe's on this channel (but away)
caillonunlikely, but I can look up his phone number internally and call him tomorrow (I'm guessing he's gone home for the day already)
nirikI know he's often very busy with kde stuff...
bpepplecaillon: that sounds fine to me.
c4chriscaillon: +1
f13caillon: +1
bpepplenotting: was than's package the only one blocking this feature?
nottingbpepple: not sure. but it seems like a reasonable way to go. i think jens responsed on behalf of most of the others
bpepplenotting: ok.
anything else? or should we move on?
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- obsoleting kmod proposal - dwmw2, f13
bpepplef13: did dwmw2 get a chance to work on his proposal?
nirikFYI, there appears to be one more open kill xfs font bug... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=251026
f13bpepple: I haven't seen it.
bpepplef13: ok, we'll move on then, since he isn't here.
jwbno proposal from either dwmw2, f13, or |DrJef|
--- bpepple has changed the topic to: FESCO-Meeting -- Rebuilding Packages -- Needs to decide to always rebuild, or only when toolchain warrants it - all
bpepplethis was one of those topics we put off until after F7.
tibbsWe need to do it in any case for F8, so we could put it off again....
f13we do need it
we should do between test2 and 3
* nirik thinks "when releng says we need to" should be the rule...
tibbsFrankly I think it's something we'd need to decide on release-by-release.
f13need it for build-id, for ppc, and licensing.
guess we dont' need one for IceTea
c4chriswhat nirik said
nirikthat would mean we would need all the license changes done by then... so we should announce asap...
also if licenses aren't updated, do we have someone step in and do so? Or ?
f13Yeah, I want to give time for that to flesh out
belegdolit was announced
bpepplef13: Yeah, we definitely need to rebuild for F8, but some people want a policy that we rebuild regardless if there's a technical reason to warrant it.
f13and for build-id stuff to get working too
abadger1999mether really wants a vote on whether end-user confusion is reason enough to rebuild.
belegdolbut the "or later" stuff is driving me mad
abadger1999Whether or not there are any known technical reasons to rebuild.
nirikwell, the license changes were announced, but not when the mass rebuild would be...
belegdolah, ic
nirikwhich would be a deadline to make all the license changes.
jwbbpepple, agreed.  we need to vote in general
bpepplejwb: right.  this topic is for F8, it's about our future handling of rebuilds.
nirikok, I vote "only mass rebuilds when releng says they are needed" No required mass rebuild per cycle.
f13is the 'confusion' part the dist tag "mismatch" ?
caillonf13: yes
bpepplef13: partially.
f13bpepple: what else is it?
bpepplealso, some people this rebuilds also helps identify missing maintainers.
notting+1 to 'when releng says to' (have to step away for a moment)
nirikI think lack of response to bug reports is a better way to find awol maintainers...
f13bpepple: I'm not convinced that this is the best way to do it.
caillonbpepple: that might be one way, but its a crappy way IMO
f13where "it" == identify awol maintainers.
bpepplef13: I agree, but that's one of the arguments I've heard from people.
c4chris+1 to 'when releng says to'
abadger1999and axel likes to point out that we're always fallible (ie: brokenness that a rebuild would have fixed seems to occur.)
caillonbut we can also introduce brokenness because of a rebuild
jwbwould doing a mass rebuild benefit Secondary arches that are trying to come online?
i suspect so
f13yes and no
yes in that many things get built, no in that 'OMG THE WORLD JUST BUILT AND I CAN'T CATCH UP!'
jwbthey're going to have to cope with the latter anyway
f13to some extent yes.  But this is a massive amount of churn
jwband?  if we do a mass rebuild for technical reasons, they have to deal
jwbbelieve me, even if it's difficult for them it helps
belegdolwe will probably have gcc 4.2 for f9
jwbif nothing else, to highlight they don't have enough horsepower
bpeppleshould we do a vote, or does this need more discussion?
jwbi think it's been discussed to death already
the only "new" information is what i just brought up
bpeppleProposal: Only do rebuilds when it's warranted for technical reasons.
caillonbpepple: +1
jwbtibbs, jeremy?
spot, ?
er, 1
* bpepple wouldn't mind hearing abadger1999 opinion either, since he's here.
jwbthat's 7
jwbsure, abadger1999 ?
* nirik counts now 9 with nottings +1 from above.
jwbbpepple, please highlight that f8 will get a rebuild
abadger1999I think its six in one, half dozen the other.
jwbor whoever does meeting minutes
nirikI suspect most cycles we will end up having to do one (new gcc, etc)
bpepplejwb: I will.
nirik, i agree
nirikfor the f8 rebuild, can releng come up with a plan?
f13f8 will get a rebuild of the packages that need rebuilding
jwbf13, meaning?
f13noarch packages without a license change, no need to rebuild them.
jwboh, sure
nirikthats going to be a pretty small number of packages I suspect.
spotf13: the vast majority of packages needed license changes
c4chrisf13: even for the build-id thing?
bpepplespot: agreed.
f13c4chris: build-id only applies to packages with debuginfo
c4chrisf13: ah, right
jwbi have to step out for a sec
f13it's a targetted rebuild, just a very large target.
bpepplef13: the rel-eng team is planning to have rebuilds done between Test2 & Test3?
f13that's my thought yes.
we haven't proposed/voted on anything.
bpepplef13: cool. anything else? or should we move on?
f13that's probably good for now.
bpeppleok. moving on then.....
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleAnything folks wish to discuss?
in regard to Fedora. ;)
* bpepple listens to the crickets.
c4chrisnothing here
nirikwere we waiting for a proposal for security to ack security updates? Or was that approved already in the past?
abadger1999What should be the default commit acl for new packages?
f13we were waiting for a proposal.
I've kicked them again tomake one.
bpepplenirik: I think we were waiting for a proposal, but I'm not 100% sure.  I'll check the prior minutes.
nirikf13: ok, thanks.
abadger1999Default open to cvsextras or default open only to owner?
nottingabadger1999: imo, owner + sponsor, easily removed
caillonf13: how recently?
belegdoli think free access is better
f13abadger1999: If we can prevent somebody from taking over a new package, I'm all for wide open by default.
caillonshould we re-kick?  i talk to them nearly daily...
f13caillon: two days ago maybe?
caillonokay fair enough ;)
abadger1999f13: That should be doable.  The new package will be created with an owner.
nirikabadger1999: can you do 'sponsor automagically added' now? that would be a good thing.
abadger1999nirik: Needs some coding.
bpeppleanything else? or should we wrap up for this week?
tibbsI still think the default access should be to constrain new packagers.
But acls are on packages, not packagers....
nirikI'd like to see open to cvsextras by default...
abadger1999We have to ask FAS who the sponsor is and I'm afraid I didn't make that information public.
nirikabadger1999: yeah, would be very good down the road tho, so sponsors can fix things of sponsorees.
abadger1999So it sounds like cvsextras: +2    -1  0
tibbsIs it even possible to consider constraining new packagers?
abadger1999nirik: I'll open a ticket to explore that.
* nirik notes that currently new package requests can say if they want it or not...
tibbsIt would make the question of sponsorship so much easier.
abadger1999tibbs: that needs account system changes.
bpeppleabadger1999: I would prefer owners & sponsors, but I'm not strongly opposed to cvsextras.
abadger1999The levels that warren talks about but hasn't written a proposal for yet.
caillonif this is an issue, can we line it up for next week?  thursdays are really bad meeting days for me...
nirikabadger1999: yeah, perhaps if it could do: '@cvsextras-@probationary' and new people get in probationary, and get removed from it after a while.
bpepplecaillon: yeah, we're already past the hour.  we should end the meeting.
* nirik has nothing more today, and we are over time.
* bpepple will end the meeting in 60
abadger1999tibbs: But I agree, that would make me happy as well.
* bpepple will end the meeting in 30
cailloncool.  later guys
* bpepple will end the meeting in 15
bpepplelater, caillon.
bpepple-- MARK -- Meeting End

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