--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* jeremy is here
loupgaroublond is kibtzing
tibbsI'm here but it's very hectic today.
* poelcat here
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi, everyone.
jwbhowdy.  i'm here
poelcatcaillon: did you want me to put NetworkManager forward for approval?
caillonpoelcat: yes
and i can give a little status on that
when we're set for it
poelcatcaillon: cool
* bpepple waits another minute or so, while people show up.
* nirik is here via EVDO... the latest f7 testing kernel doesn't like his iwl3945. ;(
c4chris is here
c4chrishi all
bpeppleok, let's get started...
--- 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?
jeremy(notting's on vacation this week and next, fyi)
* bpepple thinks poelcat might have stepped away.
--- poelcat has changed the topic to: Please vote on feature: http://fedoraproject.org/wiki/Features/Transifex
* bpepple spoke too soon.
* poelcat does 2 meetings as once :)
glezos is here in case there are any Qs on transifex
poelcathopefully my speaking part is over
jeremythis is more of a meta-infrastructure-feature -- but I'm all for us touting it as an awesome thing :)
caillonglezos: is this what you mentioned to me at GUADEC?
glezoscaillon, yes
nirik+1 here... it's a cool thing and we should trumpet it. ;)
bpepple+1 here also.
jeremy+1 if mine wasn't clear
tibbsHopefully the infrastructure overhead isn't significant.
jwbone sec
bpepplejwb: np.
jwbah, the translation thing.  +1
glezostibbs, the pieces are there already at http://translate.fedoraproject.org/ -- we just added commit/push support with transifex
jeremythat looks like consensus to me...
jwb(sorry, was on the phone)
bpepplejeremy: yeah, I was hoping to get more than 50% of FESCo (7 +1).
c4chrisI count 7 now
--- poelcat has changed the topic to: Please vote on feature: http://fedoraproject.org/wiki/Features/FedoraElectronicLab
jeremythere's 7 :)
jwbthe ElectronicLab one is nice
bpepplec4chris: your right I missed one.
tibbsHey, +1 because it's already there and all.
* ChitleshGoorah is present for any Qs.
jeremyyeah -- as I said on fedora-devel, I'm up for helping chitlesh get a nice live image going with the bits
loupgaroublondare ambassadors trying to 'sell' this to school labs to use this with their electronics toolsets?
ChitleshGoorahthanks jeremy
loupgaroublond: I am
jeremymaybe it can also serve to help drive some of the trademark/branding questions if we have a concrete example case :-)
loupgaroublondawesome :)
c4chrisnice work, btw
bpeppleOk, I see six '+1'.
--- poelcat has changed the topic to: Please vote on feature: http://fedoraproject.org/wiki/Releases/FeatureNetworkManager
caillonbpepple: which is a vote for in case you missed it ;-)
f13here, sorry I'm late.
[splinux]hi guys
caillonpoelcat: well, +1 on NM obviously from me.
bpepplecaillon: I figured that. ;)
bpepple+1 to NM.
jwbdoes it do static IPs?
nirikso it will be on by default in F8? it's unclear from that page...
caillonwe just got the key configuration work done upstream, killed dhcdbd from it, and are going to start finishing up the key bits.
f13+1 for me.
caillonjwb: it has for a long time using the default /etc/sysconfig stuff
jeremycaillon: when are the bits going to land in rawhide.  since I suspect there's at least some coordination that needs to be done with, eg, anaconda
jwbcaillon, ok
caillonjwb: but the pieces we just added will allow for people to set it up with a GUI
jwbcaillon, nice!
caillonjeremy: hopefully next week.  going to talk to dcbw again to check on a few things but its close enough that i think its good to land
* jeremy is all for it, but just wants to see it landing soon and not the day before the test2 freeze
bpeppleOk, that's seven '+1', so NM has been approved.
caillonthe UI is going to be a bit of contention upstream, but that won't affect our translators since GNOME does translations
--- poelcat has changed the topic to: Followup discussion with fitzsim on http://fedoraproject.org/wiki/Features/IcedTea
nirik+1 here too, but it will need lots of testing for people's odd ball configs.
jeremydid we get answers to the questions from last week about IcedTea?
tibbsHow were we to expect answers to the questions added at the bottom of that page?
jwbum, crap
bpeppleI don't see any reply on the wiki page.
jwbthis is my fault
overholtfitzsim's here to answer them
poelcatfitzsim: can you respond to questions here?
jwboh wait...
fitzsimI read the questions on the wiki page
jwbsomeone added the questions for me.  thanks whoever did that
* bpepple thinks it might have been tibbs.
jwbthanks tibbs.  sorry, slipped my mind to do it
tibbsI added my questions; there might have been others.
fitzsimre: ppc support: we won't have IcedTea working on ppc before Fedora 8
caillonbtw, I'm already sold on IcedTea.  +1 for me.
tibbsAnd so the followup question is, what does PPC lose by not having this?
jwbor, does it cause a regression on PPC?
fitzsimtibbs: that follows into the second question: gcj/native compilation support
we plan to continue to support gcj + native compilation on Fedora 8
fitzsimbut we'd like to leave the decision of what to build against (gcj or IcedTea) to Java packagers
jwbfitzsim, in particular, will eclipse be built native with gcj?
fitzsim(knowing that some Java packagers may choose to only target IcedTea, i.e. x86, x86_64 only)
overholtsince everything we ship can build with gcj anyway, we'll probably stick with building with gcj and then just tell people to use IcedTea at runtime if they can
jwbfitzsim, and do you foresee IcedTea ever getting the ability to do native compiles, or are you always going to ship gcj too?
overholt, ok cool
c4chrisoverholt: I assume then there is a way for Java developer to indicate in his package that IcedTea should *not* kick in ?
overholtc4chris: I don't know what you mean
fitzsimjwb: I don't see IcedTea (OpenJDK) getting the ability to do native compilation, no
tibbsWe want native compilation, right?
jwbfitzsim, so gcj will continue on "forever"?
fitzsimjwb: but I don't see us necessarily always shipping gcj either
tibbsI've always been under the impression that we should always compile natively if possible.
c4chrisoverholt: AFAIU, IcedTea will kick in and overrule native compiled code when IcedTea is installed ?
overholtI'll step up and say that we don't care about native compilation
there, I said it :)
jwboverholt, why is that?
overholtc4chris: that depends on the alternative selected
jwbbecause it doesn't make sense to many of us
overholtjwb: the rest of the world doesn't care about it
jwb: it was the only way we could ship stuff in the past
loupgaroublondis there a practical difference? performance? integration?
c4chrisoverholt: which is a system wide thing ?  or a per-package thing ?
jwbdoesn't it gain you performance advantages?
overholtc4chris: system-wide
c4chris: it's the same now if you were using the Sun JVM
fitzsimjwb: tibbs: we GCJ developers pushed native compilation in the past because it was the only option for performant fully-free Java code
c4chrisoverholt: then I don't see how you leave things up to the Java developer choice ?
overholtc4chris: we don't now :)
c4chris: there's no way to
c4chris: unless we *only* shipped the gcj .sos
c4chris: but that's unnecessarily exclusive
fitzsimjwb: tibbs: in the past, if packagers didn't natively-compile then their packages would run on gcj/gij but very slowly
loupgaroublondthis sounds like you're asking wether python code should be compiled against the OS, or should it remain bytecompiled, only with java
fitzsimjwb: tibbs: which put gcj at a severe disadvantage to the proprietary JDKs
overholtbryce (gcj guy) used to give estimates of 100 times slower
performance of gcj vs. Sun has always been questionable
sometimes gcj would be faster for some things
other things, no
tibbsIn the end I have to abstain here.
bpepple+1 to IcedTea.
jeremy+1 from me still
jwbi don't care.  it seems like a performance regression, but +0
fitzsimjwb: it's not
overholtjwb: it's not
jwbso IcedTea runs just as fast as gcj?
fitzsimjwb: tibbs: maybe we should discuss this offline, but gcj native compilation vs IcedTea JIT is not a clear performance win
overholtor faster
jwbdo you have some numbers?
overholtanecdotal evidence, yup
overholtto be honest, the majority of people install our packages, install Sun's JDK, and move on
there's no reason to not move to IcedTea
jwbok, well i know nothing about java, so your pseudo evidence outweighs my paranoia
* bpepple agrees with overholt.
fitzsimjwb: we've been working to get IcedTea feature-complete, so we haven't done benchmarking yet
tibbsNobody really cares about the PPC issue, then?
fitzsimjwb: but I fully expect benchmarks will show comparable performance between IcedTea and Sun's JDK
caillontibbs: it'll just fall back to gcj there
jwbtibbs, i do, but gcj is there
tibbsAnd how complex does the packaging get if we packagers have to support both?
caillonit's alternatives based.
so that's not an issue
tibbsHow can it be?
overholtpeople already have workarounds for gcj or Classpath issues now
they can leave them in
tibbsThis is in the specfile.
overholtand just build for gcj still
jwbfitzsim, i didn't mean compared to Suns JDK, but ok
overholtthen it's a runtime choice
caillontibbs: ah whoops, misunderstood
fitzsimjwb: and benchmarks of GCJ vs Sun JDK have shown comparable performance, and in more recent years, better performance from the Sun JDK
jwbfitzsim, ah ok.  that i was not aware of
tibbsWell, this is why I'm abstaining; I simply don't understand Java sufficiently.
jwbso i change to +0.5
drago01jwb: http://www.linuxjournal.com/node/4860/print
jwbbtw, i appreciate fitzsim and overholt being here to answer questions.  thanks guys
fitzsimtibbs: it's a virtual provides: "java-devel" -- that will pull IcedTea on x86/x86_64 and java-1.5.0-gcj-devel on other architectures
caillontibbs: i doubt many of us here do, really.  but i trust the guys that do.
overholtif anyone's still on the fence, as an Eclipse guy, I *really* want this
spotcaillon: +1
drago01"Running the Kawa test suite using GCJ vs. JDK1.3.1, GCJ is about twice as fast, causes about half the page faults (according to the time command) and uses about 25% less memory (according to top)."
bpepplecaillon: +1
jwbdrago01, that article is from 2003
caillonwhich is why i have no problem voting +1
jwbi don't consider that recent
drago01overholt: noticed it now too
spotI say we support this feature. +1
overholtdrago01: :)
bpeppleCould we have a quick vote?  I'm not sure where we're at.
fitzsimdrago01: yes, Sun's JIT has improved since then
caillon(+0.5 rounds up to +1)
f13I have a question
jwbit does.  caillon is correct.  it's just my way of showing that i'd rather ppc be fully supported ;)
f13Right now our spec files have a lot of ugly %if stuff to decide if they're byte compiled or noarch with native java
how will that change with IceTea being in the distro, but wanting to still allow ppc to byte compile?
overholtf13: it won't
f13: they'll remain until we have one JDK on all arches
so then it really isnt a packagers choice.
fitzsimjwb: me too (+s390* and ia64) but those will come later
f13if it's in Fedora, it /has/ to support native compiling until such time as we drop gcj?
the native compilation only happens at build time with gcj
fitzsimf13: I'd say so, yes
jwbfitzsim, sure
f13if a java package is in Fedora, it has to support native compiling until we drop gcj I meant.
I don't know if I'd say "/has/", though
"/strongly/ preferred"
jwbi would
f13I would too
overholtI don't think we have 100% native compilation ATM
f13it's a bug if you ExcludeArch ppc, and the fix is to use native compile.
fitzsimf13: a weaker requirement is that it has to build on ppc
overholtwhich it can do with gij just fine
you just won't have the aot-compiled bits
* f13 is getting confused again (:
f13what is 'gij' ?
overholtsorry for muddying the waters.  I'll shut up now
the bytecode interpreter part of gcj
f13ok, that's runtime?
fitzsimf13: there's a difference between building a Java package bytecode-only on gcj on ppc, and natively-compiling with gcj on ppc
jwbbasically what we don't want is people excluding java packages on ppc for no good reason
f13so I'm ok with going with "it has to run on ppc"
f13and not require things outside of Fedora
bpepplef13: Is that a +1 then?
f13yeah, +1
bpeppleOk, that's seven '+1' then.  phewww.
fitzsimf13: ok, that's an even weaker requirement, which seems fine
* c4chris phewww's too :)
bpepplepoelcat: any other items that need to be looked at?
jwbbpepple, hey this is why it's important for the feature owners to show up :)
bpepplejwb: agreed.
fitzsimf13: (should we update the review/packaging guidelines with that requirement?)
tibbsThis discussion has only reinforced my desire to avoid Java.
But it would be nice at some point to actually have packaging guidelines for Java applications.
c4christibbs: agreed wholeheartedly :)
cailloni nominate tibbs to write them
f13fitzsim: I'd say note it in the Packaging/Java pages
bpepplecaillon: ;)
poelcatbpepple: that's all... the queue is empty :)
tibbscat "No @$@#$& Java" > Packaging/Java ?
bpepplepoelcat: thanks.
f13fitzsim: we already have guidelines that state if your package doesn't build on an arch that if you ExcludeArch you have to file a bug about it, and we can quickly point out where they went wrong in that bug.
ajax agoode abadger1999 AravindSeshadri
overholttibbs: har har
f13tibbs: hear hear!
bpepplefitzsim, overholt: thanks for answering out questions.
fitzsimtibbs: c4chris: Sun's licensing has caused Java packaging to be tricky in the past, admittedly
overholtbpepple: np
ok, moving on.....
f13it's crackjeremy!
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Default acl policy for new packages (open to cvsextras commits or open to owner only?) - abadger1999
bpeppleabadger1999 wanted us to discuss this.
fitzsimtibbs: c4chris: but now we're working on fixing the situation properly -- as more architectures become supported, packaging Java will become easier
spoti think open to all by default is the best idea.
abadger1999FWIW, I do as well.
tibbsAs much as I hate to say it, I think the default needs to be closed until we can constrain new packagers.
jwbtibbs, agreed
f13If we can prevent hostile take over of a new package, I'm +1 to open by default.
jwbor that
* spot isn't so worried about hypotheticals like that
abadger1999Well, new packages are created by a cvsadmin and have an owner.
spotanyone who goes through the process of getting sponsored is automatically far less likely to start screwing around with other packages
and even if they did, its trivial to undo
cailloncan we simply make it a requirement that a package review bug/request has to specify?
abadger1999So even with open acls, the owner would 1) get notification email and 2) can lock down the acl if they get such email.
c4chrisfitzsim: your work is much appreciated.  It's just that I don't appreciate Java so much... :)
f13abadger1999: my fear was somebody creating an ACL and locking out the owner, but I don't thik that's possible
jwbcaillon, huh?
i see
abadger1999f13: Right.  Not anymore.
f13what I /really/ want to see, is the ability for a cvs admin to just click an "Approved" button or something in packagedb, and the new packager could create the module from scratch with cvs-import
tibbsspot: The problem with relying on sponsorship is that I want to make the barrier for that lower.
But if it immediately means that they get instant access to every package in the repo then I can't.
spottibbs: even if that barrier is lowered, and someone goes on a spree, spewing garbage all over cvs
we... undo it.
tibbsSo if we have open by default then sponsorship must be difficult to achieve, which frustrates new packagers.
spotboot the individaul
bpeppletibbs: I think for that we would need acl to be based off the person, not the package.  sort of ties into warren's idea has having packager levels.
spotmy concern is that we're making life more difficult by default for the majority of well behaved packagers
just to cover the hypothetical corner case of a malicious or ignorantly dangerous one
c4chrisopen by default seems fine to me
tibbsWell, we wouldn't be if the only people we were constraining were new packagers.
spottibbs: i'm not opposed to having new packagers be on some sort of temporary access probation
bpeppletibbs: yeah, knurd expressed the same idea on the mailing list.
knurdspot, "and even if they did, its trivial to undo" -> what if a malicious package hits the repo
tibbsI guess a related question is who can start builds.
knurdthen quickly lots of systems might get infected
spotknurd: what happens if a bug causes disk corruption in the kernel?
f13seems we're talking about two different issues here.
abadger1999tibbs: That is valid.  Right now koji doesn't have build acls.
c4chrisabadger1999: how hard is it to implement tibbs' idea?
knurdspot, hehe, true, but just getting sponsered is to easy IMHO to give then full access imediately everywhere
tibbs, yeah, we discussed that in the past as well
abadger1999c4chris: Requires account system work and cvs work.  we can probably skip the pkgdb in the first round.
spoti just don't think we want to have walls up by default
abadger1999We've talked about the cvs work that would be required and haven't come up with a lot of ideas that have one drawback or another.
spothaving new packagers on a temporary probation period, ok, sure.
bpepplespot: I pretty much agree with you.  I'm fine with having the packages open, and having new packages being on a temp probation period where they can only modify their own packages.
loupgaroublondis there a way you can set it up so a new maintainer can commit, and the commits are marked 'pending for review' for the first few times
abadger1999it's something we do want to do in the future but we're still in the brainstorming stage
loupgaroublondthen give all maintainers a rating, the higher the rating, the more likely they commit will go through clean
bpeppleabadger1999: agreed.
loupgaroublond: warren worked on a proposal similar to that earlier this year.
loupgaroublondwhat happned to it?
f13this isn't something you ant in koji
well, maybe you do. Don't mind me. I'm not thinking well
bpeppleloupgaroublond: not many people were behind the idea, and then the F7 crunch came.
caillonf13: ant?  -ETOOMUCHJAVA ?
f13it was also very very complex.
caillon: SCARY
abadger1999Yeah.  I don't think we've really talked about what we would want or not want in koji yet.  I only recall cvs talks.
loupgaroublondgotcha, seems to me that this is a better canidate in the distributed source control world
f13loupgaroublond: it was an interesting concept, but no where near the KISS principle.
jwbit would utterly fail
f13abadger1999: it has to go into koji or else you could easily get around it by calling koji directly rather than 'make build'
c4chriswould the probation period simply be counted in weeks ?
loupgaroublondtrue, some patches for smolt come to me by mail or trac for someone to merge in anyways
abadger1999f13: That's the build acls, right?
f13(if we want any sort of 'who can build' ACLs)
c4chrisor number of commits ?
abadger1999f13: There commit acls and build acls are separate
jwbc4chris, that sort of defeats the purpose
f13I was speaking only of build ACLs
jwbc4chris, i would think a human would have to flip the bit if we're going to do a probation period
f13c4chris: that only puts a target for the usurper
c4chrisf13: right, so how do we define a probation period?
f13c4chris: nothing more than a speed bump.  Anybody who's intent on causing harm will simply just wait out the period or do whatever trial things are necessary to get the full access.
honestly? I don't think you can define it.
bpeppleabadger1999: is this decision holding up any of your work in the packagedb?
jwbf13, which is true regardless.  so a probation seems sort of pointless to me
c4chrisso I think the simplest is open
jwbif you're evil, you will be evil no matter what
abadger1999bpepple: No.  i just remember having this discussion multiple times without concluding.
c4chrisand we deal with the troublemakers in a harsh way
spotif we don't trust the packagers, we shouldn't sponsor them.
f13c4chris: I think a packager sponser has to determine for themselves at what time they turn their underling's access up to 11.
abadger1999We're currently implementing cvs closed by default.
knurdjwb, even if you have to wait one year or something like that to get wide access?
f13jwb: exactly.
bpeppleabadger1999: good.
jwbknurd, yes...
abadger1999and have had several requests to mass open acls for packages
and that brought it to the forefront of my brain again.
knurdjwb, sure, but most people don#t want to wait that loing and spend so much effort
tibbsAren't there other blocks to mass opening ACLs?
jwbknurd, which is why defaulting to open would be fine i guess
* spot points out that to end run this, you'd simply need to join a secondary arch team
abadger1999I'd like to see some plan like: yes default open OR yes default open when build acls are default closed OR yes default open when we have tier0 packagers.
jwbknurd, let them be evil immediately, and we can get rid of them that much quicker
abadger1999That way I have a goal to shoot for :-)
tibbsDidn't some mandate come from RH that said X, glibc and the kernel had to be closed?
jwbtibbs, this is for new packages
* nirik gets back from udev hell and tries to catch up on scrollback.
knurdjwb, but much more people might be intersted in doing evil stuff if itÄs easy to do evil stuff
bpeppleabadger1999: agreed.
tibbsjwb: Someone mentioned "mass opening of ACLs" above.
jwboh, no we don't want to do that
f13I'm simply +1 for open by default period.  Starting now.
jwbf13, +1
warrenf13, +1
c4chrisf13: +1
tibbsIf everyone's convinced that we have enough checkpoints in place to prevent malicious users from doing damage, then fine.
jwbknurd, yes, true.  but it's not that easy to get access to begin with :)
abadger1999tibbs (Sorry, that was me but I meant, for instance, the desktop team asked that all 300+ packages they own be opened)
knurdjwb, getting sponsered is easy if you're not a fool
* jeremy abstains
tibbsBut at this point I'm using "responds quickly to comments and works well with me" as the only real guideline for sponsorship.
* bpepple abstains also.
jwbtibbs, yeah.  that's a different issue
knurdtibbs, that's how most people act afaics
jwbso we have 5 +1's and two abstains
knurdand that#s what I meant with "getting sponsered is easy if you're not a fool"
nirik+1 for open by default from me.
jwb6.  tibbs, was your "that's fine" a +1 above?
tibbsCount me as a +1 then and we'll see what happens.
jwbok, that's 7
bpeppleok, that's been decided. ;)
jwbthe cool thing is, we can always change it if it doesn't work
bpepplejwb: agreed.
ok, we should start to wrap this up.
tibbsBTW, many folks I sponsor are shocked that they get access to anything other than their package.
bpeppleAnything else people need to discuss before calling it quits for today?
c4chrisuh ho, gotta run soon
caillonlets make sure that existing packages dont get changed
tibbsI'd like to point out the sad state of the review queue.
warrentibbs, eh?  as if they expect to change everything else?
bpepplecaillon: agreed.
it's only for new packages.
caillontibbs: i sorta wanted to bring that up actually
tibbswarren: They're shocked that they can change anything else.
caillontibbs: because i started doing package reviews again
tibbscaillon: Well, great.
caillonand the review process is rather uninviting
i'm annoyed at it already after 3 packages
jwbi don't think we have time for that today
bpepplejwb: agreed.
warrencaillon, could you please write an e-mail to the list about what you don't like about the review process?
abadger1999caillon: I'll make sure I only change the scripts that create new packages
f13caillon: that sounds like a good thread to start
bpeppleok, let's wrap it up......
* bpepple will end the meeting in 60
* tibbs AFK now.
* bpepple will end the meeting in 30
caillonabadger1999: thanks
* bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End

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