| --- 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 | ||
| tibbs | I'm here but it's very hectic today. | |
|---|---|---|
| * poelcat here | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
| Hi, everyone. | ||
| jwb | howdy. i'm here | |
| caillon | ! | |
| poelcat | caillon: did you want me to put NetworkManager forward for approval? | |
| caillon | poelcat: yes | |
| and i can give a little status on that | ||
| when we're set for it | ||
| poelcat | caillon: 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 | ||
| c4chris | hi all | |
| bpepple | ok, let's get started... | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Feature Proposal Approval - http://fedoraproject.org/wiki/Features/Dashboard - notting, poelcat | ||
| bpepple | poelcat: 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 | ||
| poelcat | hopefully my speaking part is over | |
| jeremy | this is more of a meta-infrastructure-feature -- but I'm all for us touting it as an awesome thing :) | |
| caillon | glezos: is this what you mentioned to me at GUADEC? | |
| glezos | caillon, yes | |
| caillon | cool | |
| nirik | +1 here... it's a cool thing and we should trumpet it. ;) | |
| caillon | +1 | |
| bpepple | +1 here also. | |
| jeremy | +1 if mine wasn't clear | |
| c4chris | +1 | |
| tibbs | +1 | |
| bpepple | jwb? | |
| tibbs | Hopefully the infrastructure overhead isn't significant. | |
| jwb | one sec | |
| bpepple | jwb: np. | |
| jwb | ah, the translation thing. +1 | |
| glezos | tibbs, the pieces are there already at http://translate.fedoraproject.org/ -- we just added commit/push support with transifex | |
| jeremy | that looks like consensus to me... | |
| jwb | (sorry, was on the phone) | |
| bpepple | jeremy: yeah, I was hoping to get more than 50% of FESCo (7 +1). | |
| c4chris | I count 7 now | |
| --- poelcat has changed the topic to: Please vote on feature: http://fedoraproject.org/wiki/Features/FedoraElectronicLab | ||
| jeremy | there's 7 :) | |
| jwb | the ElectronicLab one is nice | |
| bpepple | c4chris: your right I missed one. | |
| tibbs | Hey, +1 because it's already there and all. | |
| jwb | +1 | |
| * ChitleshGoorah is present for any Qs. | ||
| c4chris | +1 | |
| jeremy | yeah -- as I said on fedora-devel, I'm up for helping chitlesh get a nice live image going with the bits | |
| nirik | +1 | |
| loupgaroublond | are ambassadors trying to 'sell' this to school labs to use this with their electronics toolsets? | |
| bpepple | +1 | |
| ChitleshGoorah | thanks jeremy | |
| loupgaroublond: I am | ||
| jeremy | maybe it can also serve to help drive some of the trademark/branding questions if we have a concrete example case :-) | |
| +1 | ||
| loupgaroublond | awesome :) | |
| c4chris | nice work, btw | |
| bpepple | Ok, I see six '+1'. | |
| caillon | seven | |
| --- poelcat has changed the topic to: Please vote on feature: http://fedoraproject.org/wiki/Releases/FeatureNetworkManager | ||
| caillon | bpepple: which is a vote for in case you missed it ;-) | |
| f13 | here, sorry I'm late. | |
| [splinux] | hi guys | |
| caillon | poelcat: well, +1 on NM obviously from me. | |
| bpepple | caillon: I figured that. ;) | |
| spot | +1 | |
| bpepple | +1 to NM. | |
| jwb | does it do static IPs? | |
| nirik | so it will be on by default in F8? it's unclear from that page... | |
| caillon | we 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. | |
| caillon | jwb: it has for a long time using the default /etc/sysconfig stuff | |
| jeremy | caillon: 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 | |
| jwb | caillon, ok | |
| caillon | jwb: but the pieces we just added will allow for people to set it up with a GUI | |
| jwb | caillon, nice! | |
| tibbs | +1 | |
| c4chris | +1 | |
| jwb | +1 | |
| caillon | jeremy: 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 | ||
| bpepple | Ok, that's seven '+1', so NM has been approved. | |
| caillon | the 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. | |
| jeremy | did we get answers to the questions from last week about IcedTea? | |
| tibbs | How were we to expect answers to the questions added at the bottom of that page? | |
| jwb | um, crap | |
| bpepple | I don't see any reply on the wiki page. | |
| jwb | this is my fault | |
| overholt | fitzsim's here to answer them | |
| poelcat | fitzsim: can you respond to questions here? | |
| fitzsim | sure | |
| jwb | oh wait... | |
| fitzsim | I read the questions on the wiki page | |
| jwb | someone added the questions for me. thanks whoever did that | |
| * bpepple thinks it might have been tibbs. | ||
| jwb | thanks tibbs. sorry, slipped my mind to do it | |
| tibbs | I added my questions; there might have been others. | |
| fitzsim | re: ppc support: we won't have IcedTea working on ppc before Fedora 8 | |
| caillon | btw, I'm already sold on IcedTea. +1 for me. | |
| tibbs | And so the followup question is, what does PPC lose by not having this? | |
| jwb | or, does it cause a regression on PPC? | |
| fitzsim | tibbs: that follows into the second question: gcj/native compilation support | |
| we plan to continue to support gcj + native compilation on Fedora 8 | ||
| fitzsim | but we'd like to leave the decision of what to build against (gcj or IcedTea) to Java packagers | |
| jwb | fitzsim, 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) | |
| overholt | since 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 | |
| jwb | fitzsim, 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 | ||
| c4chris | overholt: I assume then there is a way for Java developer to indicate in his package that IcedTea should *not* kick in ? | |
| overholt | c4chris: I don't know what you mean | |
| fitzsim | jwb: I don't see IcedTea (OpenJDK) getting the ability to do native compilation, no | |
| tibbs | We want native compilation, right? | |
| jwb | fitzsim, so gcj will continue on "forever"? | |
| fitzsim | jwb: but I don't see us necessarily always shipping gcj either | |
| tibbs | I've always been under the impression that we should always compile natively if possible. | |
| c4chris | overholt: AFAIU, IcedTea will kick in and overrule native compiled code when IcedTea is installed ? | |
| overholt | I'll step up and say that we don't care about native compilation | |
| there, I said it :) | ||
| jwb | overholt, why is that? | |
| overholt | c4chris: that depends on the alternative selected | |
| jwb | because it doesn't make sense to many of us | |
| overholt | jwb: the rest of the world doesn't care about it | |
| jwb: it was the only way we could ship stuff in the past | ||
| loupgaroublond | is there a practical difference? performance? integration? | |
| c4chris | overholt: which is a system wide thing ? or a per-package thing ? | |
| jwb | doesn't it gain you performance advantages? | |
| overholt | c4chris: system-wide | |
| c4chris: it's the same now if you were using the Sun JVM | ||
| fitzsim | jwb: tibbs: we GCJ developers pushed native compilation in the past because it was the only option for performant fully-free Java code | |
| c4chris | overholt: then I don't see how you leave things up to the Java developer choice ? | |
| overholt | c4chris: we don't now :) | |
| c4chris: there's no way to | ||
| c4chris: unless we *only* shipped the gcj .sos | ||
| c4chris: but that's unnecessarily exclusive | ||
| fitzsim | jwb: tibbs: in the past, if packagers didn't natively-compile then their packages would run on gcj/gij but very slowly | |
| loupgaroublond | this sounds like you're asking wether python code should be compiled against the OS, or should it remain bytecompiled, only with java | |
| fitzsim | jwb: tibbs: which put gcj at a severe disadvantage to the proprietary JDKs | |
| overholt | bryce (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 | ||
| tibbs | In the end I have to abstain here. | |
| bpepple | +1 to IcedTea. | |
| jeremy | +1 from me still | |
| c4chris | +1 | |
| jwb | i don't care. it seems like a performance regression, but +0 | |
| fitzsim | jwb: it's not | |
| overholt | jwb: it's not | |
| jwb | so IcedTea runs just as fast as gcj? | |
| fitzsim | jwb: tibbs: maybe we should discuss this offline, but gcj native compilation vs IcedTea JIT is not a clear performance win | |
| overholt | or faster | |
| jwb | do you have some numbers? | |
| overholt | nope | |
| jwb | :) | |
| overholt | anecdotal evidence, yup | |
| overholt | to 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 | ||
| jwb | ok, well i know nothing about java, so your pseudo evidence outweighs my paranoia | |
| overholt | :) | |
| * bpepple agrees with overholt. | ||
| fitzsim | jwb: we've been working to get IcedTea feature-complete, so we haven't done benchmarking yet | |
| tibbs | Nobody really cares about the PPC issue, then? | |
| fitzsim | jwb: but I fully expect benchmarks will show comparable performance between IcedTea and Sun's JDK | |
| caillon | tibbs: it'll just fall back to gcj there | |
| jwb | tibbs, i do, but gcj is there | |
| tibbs | And how complex does the packaging get if we packagers have to support both? | |
| caillon | it's alternatives based. | |
| so that's not an issue | ||
| tibbs | How can it be? | |
| overholt | people already have workarounds for gcj or Classpath issues now | |
| they can leave them in | ||
| tibbs | This is in the specfile. | |
| overholt | and just build for gcj still | |
| jwb | fitzsim, i didn't mean compared to Suns JDK, but ok | |
| overholt | then it's a runtime choice | |
| caillon | tibbs: ah whoops, misunderstood | |
| fitzsim | jwb: and benchmarks of GCJ vs Sun JDK have shown comparable performance, and in more recent years, better performance from the Sun JDK | |
| jwb | fitzsim, ah ok. that i was not aware of | |
| tibbs | Well, this is why I'm abstaining; I simply don't understand Java sufficiently. | |
| jwb | so i change to +0.5 | |
| overholt | :) | |
| jwb | :) | |
| drago01 | jwb: http://www.linuxjournal.com/node/4860/print | |
| jwb | btw, i appreciate fitzsim and overholt being here to answer questions. thanks guys | |
| fitzsim | tibbs: 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 | |
| caillon | tibbs: i doubt many of us here do, really. but i trust the guys that do. | |
| overholt | if anyone's still on the fence, as an Eclipse guy, I *really* want this | |
| spot | caillon: +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)." | |
| bpepple | caillon: +1 | |
| overholt | 1.3.1 | |
| ha | ||
| jwb | drago01, that article is from 2003 | |
| caillon | which is why i have no problem voting +1 | |
| jwb | i don't consider that recent | |
| drago01 | overholt: noticed it now too | |
| spot | I say we support this feature. +1 | |
| overholt | drago01: :) | |
| bpepple | Could we have a quick vote? I'm not sure where we're at. | |
| +1 | ||
| spot | +1 | |
| caillon | +1 | |
| fitzsim | drago01: yes, Sun's JIT has improved since then | |
| c4chris | +1 | |
| jeremy | +1 | |
| jwb | +0.5 | |
| caillon | (+0.5 rounds up to +1) | |
| jwb | yes | |
| fitzsim | ha! | |
| f13 | I have a question | |
| jwb | it does. caillon is correct. it's just my way of showing that i'd rather ppc be fully supported ;) | |
| f13 | Right 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? | ||
| overholt | f13: it won't | |
| f13: they'll remain until we have one JDK on all arches | ||
| f13 | ok. | |
| so then it really isnt a packagers choice. | ||
| overholt | nope | |
| fitzsim | jwb: me too (+s390* and ia64) but those will come later | |
| f13 | if it's in Fedora, it /has/ to support native compiling until such time as we drop gcj? | |
| overholt | huh? | |
| the native compilation only happens at build time with gcj | ||
| fitzsim | f13: I'd say so, yes | |
| jwb | fitzsim, sure | |
| f13 | if a java package is in Fedora, it has to support native compiling until we drop gcj I meant. | |
| overholt | oh | |
| yes | ||
| I don't know if I'd say "/has/", though | ||
| "/strongly/ preferred" | ||
| jwb | i would | |
| f13 | I would too | |
| overholt | I don't think we have 100% native compilation ATM | |
| f13 | it's a bug if you ExcludeArch ppc, and the fix is to use native compile. | |
| fitzsim | f13: a weaker requirement is that it has to build on ppc | |
| overholt | which it can do with gij just fine | |
| you just won't have the aot-compiled bits | ||
| * f13 is getting confused again (: | ||
| f13 | what is 'gij' ? | |
| overholt | sorry for muddying the waters. I'll shut up now | |
| the bytecode interpreter part of gcj | ||
| f13 | ok, that's runtime? | |
| fitzsim | f13: there's a difference between building a Java package bytecode-only on gcj on ppc, and natively-compiling with gcj on ppc | |
| f13 | ok. | |
| jwb | basically what we don't want is people excluding java packages on ppc for no good reason | |
| f13 | so I'm ok with going with "it has to run on ppc" | |
| overholt | cool | |
| f13 | and not require things outside of Fedora | |
| bpepple | f13: Is that a +1 then? | |
| f13 | yeah, +1 | |
| bpepple | Ok, that's seven '+1' then. phewww. | |
| fitzsim | f13: ok, that's an even weaker requirement, which seems fine | |
| * c4chris phewww's too :) | ||
| bpepple | poelcat: any other items that need to be looked at? | |
| jwb | bpepple, hey this is why it's important for the feature owners to show up :) | |
| bpepple | jwb: agreed. | |
| fitzsim | f13: (should we update the review/packaging guidelines with that requirement?) | |
| tibbs | This 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. | ||
| c4chris | tibbs: agreed wholeheartedly :) | |
| caillon | i nominate tibbs to write them | |
| f13 | fitzsim: I'd say note it in the Packaging/Java pages | |
| bpepple | caillon: ;) | |
| poelcat | bpepple: that's all... the queue is empty :) | |
| tibbs | cat "No @$@#$& Java" > Packaging/Java ? | |
| bpepple | poelcat: thanks. | |
| f13 | fitzsim: 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 | ||
| overholt | tibbs: har har | |
| f13 | tibbs: hear hear! | |
| bpepple | fitzsim, overholt: thanks for answering out questions. | |
| fitzsim | tibbs: c4chris: Sun's licensing has caused Java packaging to be tricky in the past, admittedly | |
| overholt | bpepple: np | |
| bpepple | s/out/our/ | |
| ok, moving on..... | ||
| f13 | it'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 | ||
| bpepple | abadger1999 wanted us to discuss this. | |
| fitzsim | tibbs: c4chris: but now we're working on fixing the situation properly -- as more architectures become supported, packaging Java will become easier | |
| spot | i think open to all by default is the best idea. | |
| abadger1999 | FWIW, I do as well. | |
| tibbs | As much as I hate to say it, I think the default needs to be closed until we can constrain new packagers. | |
| jwb | tibbs, agreed | |
| f13 | If we can prevent hostile take over of a new package, I'm +1 to open by default. | |
| jwb | or that | |
| * spot isn't so worried about hypotheticals like that | ||
| abadger1999 | Well, new packages are created by a cvsadmin and have an owner. | |
| spot | anyone 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 | ||
| caillon | can we simply make it a requirement that a package review bug/request has to specify? | |
| abadger1999 | So even with open acls, the owner would 1) get notification email and 2) can lock down the acl if they get such email. | |
| c4chris | fitzsim: your work is much appreciated. It's just that I don't appreciate Java so much... :) | |
| f13 | abadger1999: my fear was somebody creating an ACL and locking out the owner, but I don't thik that's possible | |
| jwb | caillon, huh? | |
| oh | ||
| i see | ||
| abadger1999 | f13: Right. Not anymore. | |
| f13 | what 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 | |
| tibbs | spot: 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. | ||
| spot | tibbs: even if that barrier is lowered, and someone goes on a spree, spewing garbage all over cvs | |
| we... undo it. | ||
| tibbs | So if we have open by default then sponsorship must be difficult to achieve, which frustrates new packagers. | |
| spot | boot the individaul | |
| bpepple | tibbs: 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. | |
| spot | my 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 | ||
| c4chris | open by default seems fine to me | |
| tibbs | Well, we wouldn't be if the only people we were constraining were new packagers. | |
| spot | tibbs: i'm not opposed to having new packagers be on some sort of temporary access probation | |
| bpepple | tibbs: yeah, knurd expressed the same idea on the mailing list. | |
| knurd | spot, "and even if they did, its trivial to undo" -> what if a malicious package hits the repo | |
| tibbs | I guess a related question is who can start builds. | |
| knurd | then quickly lots of systems might get infected | |
| spot | knurd: what happens if a bug causes disk corruption in the kernel? | |
| f13 | seems we're talking about two different issues here. | |
| abadger1999 | tibbs: That is valid. Right now koji doesn't have build acls. | |
| c4chris | abadger1999: how hard is it to implement tibbs' idea? | |
| knurd | spot, 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 | ||
| abadger1999 | c4chris: Requires account system work and cvs work. we can probably skip the pkgdb in the first round. | |
| spot | i just don't think we want to have walls up by default | |
| abadger1999 | We'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. | |
| spot | having new packagers on a temporary probation period, ok, sure. | |
| abadger1999 | s/haven't/have/ | |
| bpepple | spot: 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. | |
| loupgaroublond | is 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 | |
| abadger1999 | it's something we do want to do in the future but we're still in the brainstorming stage | |
| loupgaroublond | then give all maintainers a rating, the higher the rating, the more likely they commit will go through clean | |
| bpepple | abadger1999: agreed. | |
| loupgaroublond: warren worked on a proposal similar to that earlier this year. | ||
| loupgaroublond | what happned to it? | |
| f13 | this isn't something you ant in koji | |
| well, maybe you do. Don't mind me. I'm not thinking well | ||
| bpepple | loupgaroublond: not many people were behind the idea, and then the F7 crunch came. | |
| caillon | f13: ant? -ETOOMUCHJAVA ? | |
| f13 | it was also very very complex. | |
| caillon: SCARY | ||
| caillon | :) | |
| abadger1999 | Yeah. I don't think we've really talked about what we would want or not want in koji yet. I only recall cvs talks. | |
| loupgaroublond | gotcha, seems to me that this is a better canidate in the distributed source control world | |
| f13 | loupgaroublond: it was an interesting concept, but no where near the KISS principle. | |
| jwb | it would utterly fail | |
| f13 | abadger1999: it has to go into koji or else you could easily get around it by calling koji directly rather than 'make build' | |
| c4chris | would the probation period simply be counted in weeks ? | |
| loupgaroublond | true, some patches for smolt come to me by mail or trac for someone to merge in anyways | |
| abadger1999 | f13: That's the build acls, right? | |
| f13 | (if we want any sort of 'who can build' ACLs) | |
| c4chris | or number of commits ? | |
| abadger1999 | f13: There commit acls and build acls are separate | |
| f13 | yeah | |
| jwb | c4chris, that sort of defeats the purpose | |
| f13 | I was speaking only of build ACLs | |
| jwb | c4chris, i would think a human would have to flip the bit if we're going to do a probation period | |
| f13 | c4chris: that only puts a target for the usurper | |
| c4chris | f13: right, so how do we define a probation period? | |
| f13 | c4chris: 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. | ||
| bpepple | abadger1999: is this decision holding up any of your work in the packagedb? | |
| c4chris | exactly | |
| jwb | f13, which is true regardless. so a probation seems sort of pointless to me | |
| c4chris | so I think the simplest is open | |
| jwb | if you're evil, you will be evil no matter what | |
| abadger1999 | bpepple: No. i just remember having this discussion multiple times without concluding. | |
| c4chris | and we deal with the troublemakers in a harsh way | |
| spot | if we don't trust the packagers, we shouldn't sponsor them. | |
| f13 | c4chris: I think a packager sponser has to determine for themselves at what time they turn their underling's access up to 11. | |
| abadger1999 | We're currently implementing cvs closed by default. | |
| knurd | jwb, even if you have to wait one year or something like that to get wide access? | |
| f13 | jwb: exactly. | |
| bpepple | abadger1999: good. | |
| jwb | knurd, yes... | |
| abadger1999 | and have had several requests to mass open acls for packages | |
| and that brought it to the forefront of my brain again. | ||
| knurd | jwb, sure, but most people don#t want to wait that loing and spend so much effort | |
| tibbs | Aren't there other blocks to mass opening ACLs? | |
| jwb | knurd, 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 | ||
| abadger1999 | I'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. | |
| jwb | knurd, let them be evil immediately, and we can get rid of them that much quicker | |
| abadger1999 | That way I have a goal to shoot for :-) | |
| tibbs | Didn't some mandate come from RH that said X, glibc and the kernel had to be closed? | |
| jwb | tibbs, this is for new packages | |
| * nirik gets back from udev hell and tries to catch up on scrollback. | ||
| knurd | jwb, but much more people might be intersted in doing evil stuff if itÄs easy to do evil stuff | |
| bpepple | abadger1999: agreed. | |
| tibbs | jwb: Someone mentioned "mass opening of ACLs" above. | |
| jwb | oh, no we don't want to do that | |
| f13 | I'm simply +1 for open by default period. Starting now. | |
| jwb | f13, +1 | |
| warren | f13, +1 | |
| spot | +1 | |
| c4chris | f13: +1 | |
| tibbs | If everyone's convinced that we have enough checkpoints in place to prevent malicious users from doing damage, then fine. | |
| jwb | knurd, yes, true. but it's not that easy to get access to begin with :) | |
| abadger1999 | tibbs (Sorry, that was me but I meant, for instance, the desktop team asked that all 300+ packages they own be opened) | |
| knurd | jwb, getting sponsered is easy if you're not a fool | |
| * jeremy abstains | ||
| tibbs | But 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. | ||
| jwb | tibbs, yeah. that's a different issue | |
| knurd | tibbs, that's how most people act afaics | |
| jwb | so we have 5 +1's and two abstains | |
| knurd | and that#s what I meant with "getting sponsered is easy if you're not a fool" | |
| nirik | +1 for open by default from me. | |
| jwb | 6. tibbs, was your "that's fine" a +1 above? | |
| tibbs | Count me as a +1 then and we'll see what happens. | |
| jwb | ok, that's 7 | |
| caillon | +-0 | |
| bpepple | ok, that's been decided. ;) | |
| jwb | the cool thing is, we can always change it if it doesn't work | |
| :) | ||
| bpepple | jwb: agreed. | |
| ok, we should start to wrap this up. | ||
| tibbs | BTW, many folks I sponsor are shocked that they get access to anything other than their package. | |
| bpepple | Anything else people need to discuss before calling it quits for today? | |
| c4chris | uh ho, gotta run soon | |
| caillon | lets make sure that existing packages dont get changed | |
| c4chris | wrap++ | |
| tibbs | I'd like to point out the sad state of the review queue. | |
| warren | tibbs, eh? as if they expect to change everything else? | |
| bpepple | caillon: agreed. | |
| it's only for new packages. | ||
| caillon | tibbs: i sorta wanted to bring that up actually | |
| tibbs | warren: They're shocked that they can change anything else. | |
| warren | oh | |
| caillon | tibbs: because i started doing package reviews again | |
| tibbs | caillon: Well, great. | |
| caillon | and the review process is rather uninviting | |
| i'm annoyed at it already after 3 packages | ||
| jwb | i don't think we have time for that today | |
| bpepple | jwb: agreed. | |
| warren | caillon, could you please write an e-mail to the list about what you don't like about the review process? | |
| abadger1999 | caillon: I'll make sure I only change the scripts that create new packages | |
| f13 | caillon: that sounds like a good thread to start | |
| bpepple | ok, let's wrap it up...... | |
| * bpepple will end the meeting in 60 | ||
| * tibbs AFK now. | ||
| * bpepple will end the meeting in 30 | ||
| caillon | abadger1999: 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!