Extras/SteeringCommittee/Meeting-20070531

2007 May 31 FESCo Meeting

Members

Present

• Brian Pepple (bpepple)
• Jason Tibbitts (tibbs)
• Jesse Keating (f13)
• Toshio Kuratomi (abadger1999)
• Bill Nottingham (notting)
• Kevin Fenzi (nirik)
• Dennis Gilmore (dgilmore)
• Jeremy Katz (jeremy)
• Tom Callaway (spot)
• Rex Dieter (rdieter)
• Christian Iseli (c4chris)
• Josh Boyer (jwb)
• Warren Togami (warren)

Summary

Various Static Libs

• FESCo approved the proposal for a blanket exception for packages which link against flex's libfl.a
• FESCo voted against a proposal for linking ipsvd statically against dietlibc.
• FESCo voted against a proposal against statically link libgcrypt into gaim-otr.

ACL's

• Long discussion on how to solve some of our problems with the usage of acl's, which prevent people from fixing simple things like evr problems.
• For the interim, until a more permanent solution is implemented, tibbs & nirik have been given cvsadmin access, and if there are other Fedora contributors that commonly help out with such issue, and wish to also be given access please contact FESCo.

Log

[12:06]  <bpepple> FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
[12:06]  <cweyl|work> wwoods: enjoy your entirely coincidentally timed vacation ;)
[12:06]  * tibbs here
[12:06]  * notting is here
[12:06]  * c4chris here
[12:06]  * nirik is still here.
[12:06]  * jeremy is here
[12:06]  <rdieter> here mostly.
[12:06]  * abadger1999 here
[12:06]  * warren here
[12:06]  * cweyl|work grabs his usual rabble seat
[12:06]  * f13 hree
[12:06]  <f13> here even.
[12:06]  <f13> about to try pushing some F7 updates
[12:06]  <wwoods> fancy!
[12:06]  <bpepple> f13: cool.
[12:07]  <warren> f13, is it possible for me to use bodhi yet?  I need to add pidgin to F7 updates.
[12:07]  <notting> warren: you can add things
[12:07]  <warren> where is it currently?
[12:07]  <notting> warren: see mail to -maintainers.
[12:07]  <notting> we can push the button to push updates. *something* will happen. :)
[12:07]  <bpepple> Ok, we should probably get started.
[12:07]  *** bpepple sets the channel topic to "FESCO-Meeting -- blanket exception for packages which link against flex's libfl.a - tibbs".
[12:07]  <bpepple> tibbs: you want to start off?
[12:08]  <tibbs> OK.
[12:08]  <f13> warren: yes, add away
[12:08]  <tibbs> Flex includes a static library, libfl.a
[12:08]  <tibbs> It is considered standard practise for flex-using applications to link against this.
[12:08]  <c4chris> any good reason it's not dynamic?
[12:08]  <tibbs> Although plenty of software has their own implementation.
[12:08]  <tibbs> I think this dates back from ancient times.
[12:09]  <tibbs> It's simply the way it's always been done.
[12:09]  <notting> c4chris: i think flex is squarely in the 'we don't care about abi' camp
[12:09]  <bpepple> yuck.
[12:09]  * c4chris used it in ancient times, but don't remember what's in there...
[12:10]  <c4chris> oh well
[12:10]  <tibbs> The point is that either we have to allow this or someone has to go and recode all of those packages.
[12:10]  <tibbs> Any package with BR: flex potentially has an issue here.
[12:10]  <c4chris> did anyone grep BuildRequires: flex?
[12:10]  <bpepple> tibbs: do we know how widespread it's usage is in Fedora?
[12:10]  <tibbs> Well, flex is commonly used.
[12:11]  <tibbs> I did a grep over what I have checked out and found a pile of packages, but I don't have any firm stats.
[12:11]  <warren> How often does the flex ABI break?
[12:11]  <warren> Has flex ever had a security hole?
[12:11]  <bpepple> tibbs: that ok, I was just wondering.
[12:11]  <tibbs> Perhaps never in the past 20 years.
[12:11]  <notting> +1 on execption for me
[12:11]  <rdieter> +1 blanket exception
[12:12]  <notting> erm, *from* me
[12:12]  <warren> If there has never been a security implication, then I think we should just allow this.  We have more important problems to deal with elsewhere.
[12:12]  <warren> +1 blanket exception
[12:12]  <abadger1999> I'm for the exception.
[12:12]  <abadger1999> +1
[12:12]  <bpepple> +1 here also.
[12:12]  <tibbs> +1 from me.
[12:12]  * dgilmore is here
[12:12]  <jeremy> +1
[12:12]  <c4chris> +1
[12:12]  <nirik> +1
[12:12]  <tibbs> If there's an issue here, we can always go back and look at these packages later.
[12:13]  <bpepple> Ok, that's more than half of FESCo with '+1'.  tibbs, consider it approved.
[12:13]  <tibbs> But while I understand the issues against static linking, I just don't think there's any point in trying to "fix" flex-using packages.
[12:13]  <tibbs> This should be written down; perhaps in the packaging guidelines alongside the ocaml exception?
[12:13]  <abadger1999> tibbs: That seems like the correct place.
[12:13]  <f13> sure +1, I don't give a crap about flex... (:
[12:14]  <bpepple> tibbs: agreed.  do you want to handle documenting it?
[12:14]  <tibbs> I'll take care of the details.  Let's not waste any more time.
[12:14]  <bpepple> tibbs: cool.  moving on...
[12:14]  *** bpepple sets the channel topic to "FESCO-Meeting -- linking ipsvd statically against dietlibc -- requested by Patrice Dumas - https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00980.html".
[12:14]  <bpepple> Patrice wanted us to vote on this.
[12:15]  <tibbs> I would like to see some comment from the glibc and kernel maintainers regarding the implications of alternate libc implementations for the distro.
[12:15]  <abadger1999> I'm okay with the alternate libc implications but not so sure about static linking for efficiency.
[12:15]  <tibbs> For example, will we ever get into a state where we can't disable some kernel backwards-compatibility stuff because some other libc needs it?
[12:16]  <dgilmore> im kinda concerned due to Enrico being kinda slow lately with clamav
[12:16]  <nirik> dgilmore: he checked in 0.90.3 today... or last night.
[12:16]  <tibbs> dgilmore: I thought he was up to date with clamav.
[12:16]  <tibbs> I do wish he had documented the upgrade procedure for the release notes, though.
[12:16]  <abadger1999> Enrico is the dietlibc maintainer and has done his homework for ipsvd but -- what happens if someone who is not the dietlibc maintainer links statically against it for the same reasons.
[12:17]  <dgilmore> tibbs: he was not updaing FC-5 and FC-6
[12:17]  <notting> abadger1999: does diet even use dynamic linking?
[12:17]  <abadger1999> They're not going to be as in touch with changes in dietlibc that could open up security issues.
[12:17]  <nirik> dgilmore: yeah, but he said he didn't want to, because of config changes...
[12:17]  <tibbs> dgilmore: He can't update FC6 and older without breaking everyone's existing servers.
[12:17]  <tibbs> The configurations are not compatible.
[12:17]  <abadger1999> notting: I thought it had dynamic libs when I looked at it last week.
[12:18]  <dgilmore> tibbs: Thats what was said.  they would be some way to do it im sure
[12:18]  --> EvilBob has joined this channel (n=Robert@fedora/pdpc.sustaining.BobJensen).
[12:18]  <jeremy> experimental dynamic stuff was going in when we stopped using it for initrds
[12:18]  <dgilmore> ipsvd  is in RHEL5 right?
[12:19]  <notting> don't think so
[12:19]  <bpepple> doesn't upstream ipsvd advise against the use of dietlibc?
[12:19]  <tibbs> It doesn't seem to be in centos5
[12:20]  <tibbs> bpepple: I don't think they advise against it.
[12:20]  <dgilmore> hmm i was thinking of ipvsadm
[12:20]  <abadger1999> notting: /usr/lib/dietlibc/lib-i386/libc.so
[12:20]  <bpepple> tibbs: ok, I thought I saw that mentioned on the mailing list, but I could just be remembering wrong. :)
[12:21]  <tibbs> I don't see anything about it in the upstream web site.
[12:21]  * c4chris is not too thrilled with static dietlibc linking...
[12:21]  <dgilmore> upsream says here is how to link against dietlibc
[12:21]  * jeremy thinks linking (and statically no less) to alternate libcs is the path to madness
[12:22]  <abadger1999> bpepple: I think the argument was that ipsvd doesn't recommend the use of dietlibc explicitly in their docs... but enrico says some of the ipsvd maintainers have recommended it on mailing lists.
[12:23]  <bpepple> abadger1999: ah, that sounds right.
[12:23]  <dgilmore> jeremy: I agree with you
[12:23]  <bpepple> Are we at a point that we can vote on this, or should we wait another week?
[12:23]  <tibbs> I don't think a vote would pass at this point.
[12:23]  <rdieter> I trust Enrico knows what he's doing, esp since he's the maintainer of both pkgs in question, he's responsible for any consequences/fallout.
[12:23]  <warren> If you use dietlibc, don't you lose security features like FORTIFY_SOURCE?
[12:23]  <bpepple> ok, let's vote then.
[12:23]  <notting> warren: yes.
[12:23]  <abadger1999> What do we want to vote on?  Alternate libc or static link to diet?
[12:24]  <dgilmore> warren: if dietlibc does not have it and EXEC shield i would say so
[12:24]  <bpepple> how about static link to diet first?
[12:24]  <warren> exec shield should be unaffected here
[12:24]  <dgilmore> execshield being another maybe it wont have thing
[12:24]  <warren> FORTIFY_SOURCE would
[12:25]  <tibbs> I can't vote for any of this without some input from the kernel and glibc folks, so +0 from me.
[12:25]  <dgilmore> bpepple: whats the vote?
[12:25]  <warren> He wants dietlibc static entirely because it is "faster"?
[12:25]  <tibbs> faster and smaller.
[12:25]  <notting> warren: pretty much
[12:25]  <nirik> I think static linking for performance/memory reasons is bad. Why not let every package do that?
[12:25]  <bpepple> dgilmore: ipsvd statically linking against dietlibc.
[12:25]  <notting> -1
[12:25]  <c4chris> -1
[12:26]  <rdieter> +1
[12:26]  <jeremy> -1
[12:26]  <nirik> lets static link firefox! it will be faster! :(
[12:26]  <abadger1999> -0.5
[12:26]  <dgilmore> bpepple: im tending to say -1  but would like input from davej and jakab
[12:26]  <nirik> -1
[12:26]  <warren> +0
[12:26]  <bpepple> -1.
[12:26]  <tibbs> (and my +0 from before)
[12:26]  <dgilmore> jakub
[12:26]  <c4chris> they can build a Fedora static spin :-)
[12:27]  <warren> wait a second...
[12:27]  <warren> What exactly are we afraid of here?
[12:27]  <notting> setting a bad precedent.
[12:27]  <notting> (imo)
[12:27]  <dgilmore> i would probably be ok of a sub package that is ipsvd-static that links to dietlibc staticly
[12:27]  * bpepple agrees with notting.
[12:27]  * nirik also agrees with notting
[12:28]  <c4chris> notting: basically yes
[12:28]  <tibbs> BTW: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176579
[12:28]  <tibbs> comment #12 has rationale.
[12:29]  * bpepple waits for bugzilla to load.
[12:30]  <abadger1999> He posted the numbers to backup comment #12 on one of the mailing lists as well.
[12:30]  * c4chris thinks we stick with one kernel and one libc...
[12:30]  <warren> How does it make any sense that dietlibc static is smaller in binary and runtime than dynamic?
[12:30]  <nirik> thats for linking to dietlibc, right? why static?
[12:31]  <dgilmore> nirik: cause he says its faster
[12:31]  <warren> abadger1999, did he post anything about *why* it is faster than glibc?
[12:32]  <notting> the thing is, for *any* package <foo>, linking to dietlibc will yield something a) smaller b) less memory usage c) (possibly) faster,probably due to a)
[12:32]  <tibbs> Does dietlibc handle the VDSO and other fancy bits?
[12:33]  <c4chris> there must be a catch somewhere, otherwise why don't we replace glibc with dietlibc ?
[12:33]  <warren> If you're building something that is performance sensitive and want it in Fedora, you might want to do this?
[12:33]  <warren> notting, the benefits of this apply mainly to tiny programs?
[12:33]  <notting> c4chris: doesn't have all the same features
[12:33]  <warren> notting, larger programs have less benefit?
[12:33]  <notting> c4chris: or community,etc
[12:34]  <notting> warren: i suspect the larger program you have, the more likely it will rely on something that doesn't work (say, NSS)
[12:34]  <notting> but... i don't see how you could sanely write guidelines on what should and shouldn't be allowed to use it
[12:34]  <tibbs> Erm, no NSS?  For a network daemon?
[12:34]  <warren> I don't see why ipsvd needs to be so performance sensitive.
[12:35]  <tibbs> Because faster is always better, and all microoptimizations are good.
[12:35]  <warren> Gentoo!
[12:35]  <c4chris> I'm still at -1
[12:35]  <warren> We need to move on
[12:36]  <abadger1999> No objections to moving on.
[12:36]  <bpepple> warren: agreed.
[12:36]  <warren> Perhaps we need to re-explore the topic, when is it APPROPRIATE if at all to use an alternate libc.
[12:36]  <warren> but now now
[12:36]  <tibbs> I think there are only two "on the fence" votes; nothings going to be changing today.
[12:36]  <bpepple> tibbs: agreed.  moving on...
[12:36]  *** bpepple sets the channel topic to "FESCO-Meeting -- statically link libgcrypt into gaim-otr -- requested by Paul Wouters - http://www.redhat.com/archives/fedora-extras-list/2007-February/msg00425.html".
[12:37]  <tibbs> This is a real PITA.
[12:37]  <bpepple> Argggh! yet another static lib. ;)
[12:37]  <abadger1999> I say no if there's nothing broken yet.
[12:37]  <tibbs> libgcrypt is simply broken.
[12:37]  <notting> +0.25. fix your library!
[12:37]  <tibbs> Upstream doesn't seem to care.
[12:37]  <abadger1999> Between now and having something broken gcrypt might be fixed or the horse might sing.
[12:37]  <tibbs> debian has some patches which I don't understand.
[12:38]  <nirik> I say file a bug, don't static link for now... try and get upstream to fix.
[12:38]  <c4chris> nirik: +1
[12:38]  <bpepple> nirik: +1
[12:38]  <jeremy> nirik: +1
[12:38]  <abadger1999> nirik: +1
[12:38]  <tibbs> Isn't libgcrypt a "formerly core" package?
[12:38]  <nirik> yeah.
[12:39]  <tibbs> Looks like nalin's up.
[12:39]  <dgilmore> nirik: +1
[12:39]  <tibbs> I'd certainly want to see his opinion before doing anything here.
[12:39]  <tibbs> But upstream simply isn't going to fix this on anything other than a continental drift-style timeframe.
[12:39]  <warren> tibbs, +1
[12:40]  <nirik> weird. Theres someones public key in the cvs for that package. Perhaps it uses it during build.
[12:41]  <nirik> tibbs: you want to tell Paul what we think should be done? and shall we move on?
[12:41]  <abadger1999> Maybe as part of a test suite?
[12:41]  <jeremy> nirik: there's a detached gpg sig for the tarball; having the key makes it easy to verify
[12:41]  <tibbs> I can do that, but I don't remember his IRC nick.
[12:42]  <jeremy> uses the check-upstream-gpg-sig bits of Makefile.common
[12:42]  <bpepple> tibbs: I've got his nick in last week's meeting IRC log.  I get you the info.
[12:42]  <tibbs> Cool, I guess we're done here.
[12:43]  <nirik> jeremy: yep. Just saw that. all good.
[12:43]  <bpepple> Moving on....
[12:43]  *** bpepple sets the channel topic to "FESCO-Meeting -- MISC - F7".
[12:43]  <jeremy> it's out there!
[12:43]  <bpepple> Anything about F7 to discuss?
[12:43]  <f13> updates may be leaking out soon
[12:43]  <-- kital has left this channel ("Konversation terminated!").
[12:43]  <f13> I'm trying a bohdi push as soon as I'm done signing packages
[12:43]  <c4chris> time for a well deserved beer /me thinks :-)
[12:44]  <bpepple> c4chris: agreed.
[12:44]  <nirik> good work everyone on f7. ;)
[12:44]  <f13> Wake me up with it's time for F8
[12:44]  <bpepple> f13: Only got what 5 months?
[12:44]  <c4chris> f13: we start tomorrow :-p
[12:45]  * abadger1999 applauds the release team
[12:45]  <jeremy> c4chris: nah, waiting for monday ;)
[12:45]  <f13> c4chris: well, f8 content hit rawhide a few days ago so we've already started down that tunnel.
[12:45]  <cweyl|work> excellent.  I can start updating my packages again...  heh
[12:45]  --> warren_laptop has joined this channel (n=warren@c-24-218-124-99.hsd1.ma.comcast.net).
[12:45]  <warren_laptop> Lost connection...
[12:45]  <nirik> BTW, mock is in need of updating... f8, and epel4/epel5 that work. ;)
[12:45]  <bpepple> Anything else or should we move on?
[12:46]  <f13> yeah, going to get with clark on that maybe today
[12:46]  <warren_laptop> What was the resolution of libgcrypt?
[12:47]  <nirik> file a libgcrypt bug, don't static link the gaim-otr now since it doesn't break anything.
[12:47]  <warren_laptop> ok
[12:48]  *** bpepple sets the channel topic to "FESCO-Meeting -- MISC -- Package Database - abadger1999".
[12:48]  <bpepple> Anything to report on the package db front?
[12:49]  <f13> hopefully abadger1999 will have a LOT of time to work on it very soon
[12:49]  <warren_laptop> Now that I'm back from vacation and F7 is out, I should be able to focus on helping packagedb too.
[12:49]  <bpepple> warren_laptop: cool.
[12:50]  *** bpepple sets the channel topic to "FESCO-Meeting -- MISC -- Adding working groups to acl -- tibbs, nirik".
[12:50]  <bpepple> tibbs, nirik: you want to discuss this?
[12:50]  <tibbs> Yes.
[12:50]  <warren_laptop> this is pkg cvs ACL?
[12:50]  <nirik> it would be extra nice if there is a way for sponsors to touch sponsorees packages... wait for packagedb?
[12:50]  <jeremy> nirik: yeah, packagedb will make that a lot easier
[12:50]  <tibbs> I'm concerned that now packages are by default accessible to their owners only.
[12:50]  <jeremy> (and actually, say, doable)
[12:50]  <-- warren_laptop has left this channel ("Leaving").
[12:51]  <nirik> yeah, and the default is owner only... should we change that?
[12:51]  <warren> ah, reconnected to my proxy.
[12:51]  <notting> nirik: well, the owner can easily change that
[12:51]  <tibbs> The question is, how do we take of the kinds of cleanups and rebuilds that at least nirik and I used to do?
[12:51]  <jeremy> nirik: the problem is that the only "safe" default is owner only by default and then let them change
[12:51]  <jeremy> otherwise, there's a window in between creation and the acl being put in place
[12:51]  <dgilmore> nirik: its easy enough to contact a cvsadmin and get acl's removed if need be
[12:52]  <warren> owner + sponsor isn't safe?
[12:52]  <tibbs> So basically we have another big layer of process to go through before we can do through and so, say, rebuilds?
[12:52]  <dgilmore> warren: patches accepted
[12:52]  <jeremy> warren: there's no good way to get sponsor right now.  when we get the packagedb up, that becomes a lot easier
[12:52]  <bpepple> It would be nice to have something like a qa group that had blanket access to the packages.
[12:52]  <nirik> what would be bad about new packages being open and maintainer can add an acl if they want?
[12:52]  <f13> bpepple: some groups do have blanket access
[12:52]  <f13> nirik: non-owner could add an acl removing owner from having access
[12:53]  <warren> jeremy, doesn't the acl script already do a database query to find owner?
[12:53]  <nirik> f13: oh? I thought owner was always allowed.
[12:53]  <f13> it queries owners.list IIRC
[12:53]  <dgilmore> warren: no
[12:53]  <jeremy> warren: no, that's just owners.list parsing
[12:53]  <tibbs> So my question is then whether the project still wants folks like nirik and I to be able to fix the kind of issues we used to fix?
[12:53]  <f13> nirik: maybe... not sure
[12:53]  <dgilmore> warren: it gets a dump of owners
[12:53]  <warren> owners.list contains bugzilla addresses, it has to map to FAS name for ACL
[12:53]  <nirik> if it doesn't thats bad, someone could lock themselves out too.
[12:53]  <notting> tibbs: sure! short term, i suspect either adding to cvsadmin, or a new group is the simplest way
[12:54]  <notting> tibbs: the 'allow sponsor access' stuff isn't really practical to add to the current code
[12:54]  * nirik would prefer default to be open, and if people who know what they are doing want to lock down more, they can.
[12:54]  <warren> +1 default open
[12:54]  <tibbs> But I do understand that default open leads to a race for people who don't want it to be open.
[12:55]  <nirik> people who are new and don't know what they are doing and might need help should default to open.
[12:55]  <warren> "Adding working groups to acl -- tibbs, nirik" this isn't talking about having groups in ACL?
[12:55]  <abadger1999> Although they can checkin a pkg.acl before checking in code, correct?
[12:55]  <warren> "desktop" group, "kernel" group, etc?
[12:55]  <c4chris> maybe a new field in the fedora-cvs flag?
[12:55]  <nirik> yeah, I suppose. Perhapd add an acl note to the cvs request?
[12:55]  <notting> warren: that's being able to specify  a 'group' in the ACL file
[12:55]  <notting> warren: see the horrible acls for some of the desktop packages
[12:56]  <warren> notting, nod
[12:56]  <spot> we'll likely need this for secondary arches in the near future
[12:56]  <abadger1999> notting: I saw you reviewed c4chris's patch, should we apply that?
[12:56]  <dgilmore> notting: comaintainers get acl access from the onset
[12:56]  <notting> abadger1999: that's so long ago i can't remember :)
[12:56]  <abadger1999> :-)
[12:56]  <warren> c4chris, not sure what you mean
[12:56]  <warren> c4chris, but fedora-cvs can't have a "new field"
[12:56]  * c4chris wondered what happened to the patch :-)
[12:57]  <c4chris> warren: well, the requestor puts a comment in BZ along the flag request
[12:57]  <nirik> warren: in the template... say "ACL: me only"
[12:57]  <abadger1999> Not checked in yet but nobody yelled and it's in my mailbox.
[12:57]  <c4chris> he could add a group: thing
[12:57]  <notting> abadger1999: of course, we'd have to put all the groups in FAS, but i assume that scales
[12:57]  <warren> c4chris, nirik: that will be a lot easier and smoother to deal with when we have packagedb
[12:58]  <c4chris> sure
[12:58]  <-- sereinity has left this server ("Bye").
[12:58]  <nirik> yeah. ;(
[12:58]  <c4chris> but for the time being a simple all or me-alone wold be pretty simple
[12:59]  <abadger1999> notting: Should be doable.
[13:00]  <c4chris> I'd even default it to all, and honor 'me-alone' when actually requested
[13:00]  <nirik> thats what I would prefer to...
[13:00]  <c4chris> feels more open that way
[13:00]  <warren> wait
[13:01]  <warren> if default to all, then they could make it me-alone themself
[13:01]  <notting> the maintainer can 'fix' it, but it's sort of irritating to have to do
[13:01]  <nirik> sure, but there is the time between setup and them adding the acl file when it wouldn't be
[13:01]  <jeremy> warren: that leaves the window of attack
[13:02]  <warren> how serious is this "attack" really?
[13:02]  <nirik> I would prefer the burden be on maintainers who want that having to set it rather than new people who don't have a clue about it having to remove it to get help.
[13:02]  <notting> i would prefer easier ways to get more people able to help
[13:02]  <c4chris> nirik: yes
[13:02]  <warren> All by default is open, and the abuse potential really isn't that bad.
[13:02]  <f13> warren: it's enough that it concerns many people.
[13:03]  <f13> having it closed by default was a compromise after a long thread of doom
[13:03]  <nirik> well, we can discuss more on list I guess if we can't decide anything now.
[13:03]  <warren> 1) Open by defualt 2) Somebody else creates pkg.acl 3) Owner in owners.list can still override right?
[13:03]  <bpepple> In the short term, could we look at giving nirik & tibbs access?
[13:04]  <warren> bpepple, +1
[13:04]  <c4chris> bpepple: +1
[13:04]  <abadger1999> bpepple: +1
[13:04]  <dgilmore> +1
[13:04]  <notting> do we want to add them to cvsadmin, or have a new trusted cvs group?
[13:04]  <spot> +1
[13:04]  <abadger1999> Butthere are others like mschwendt that could also do with wide ranging access....
[13:04]  <dgilmore> notting: cvsadmin is ok
[13:04]  <tibbs> who is on cvsadmin currently?
[13:05]  <notting> ausil,jkeating,jwboyer,katzj,mikeb,mmcgrath,notting,petersen,wtogami
[13:05]  <dgilmore> notting: without some other group they cannot access cvs-int locally anyway
[13:05]  * jwb is here now
[13:05]  <spot> i should be on cvsadmin too...
[13:05]  <tibbs> Heh.
[13:05]  <dgilmore> notting: you added spot last week right
[13:05]  <notting> yeah, my checkout is stale
[13:06]  <notting> ok, will get people added in a few. website is slow for some bizarre reason :)
[13:06]  <nirik> so users in there can bypass the acls?
[13:06]  <notting> yes
[13:06]  <nirik> ok, makes sense.
[13:06]  <jwb> because we have uber ACL rights
[13:06]  <dgilmore> nirik: cvsadmin has full access to everything in cvs
[13:06]  <bpepple> with great power comes great responsibility.
[13:07]  <dgilmore> and with another group the permission to do branching :)
[13:07]  <warren> What timezone are nirik  and tibbs?
[13:07]  <-- amitphukan has left this server ("Leaving (আজিলৈ আহিলো)").
[13:07]  <nirik> MDT here.
[13:07]  <jwb> tibbs is central US
[13:07]  <tibbs> warren: US/Central
[13:07]  <dgilmore> warren: there US based
[13:07]  <warren> heh... that leaves only one non-US cvsadmin
[13:07]  <jwb> just like me and spot and dgilmore
[13:07]  <tibbs> So no additional coverage, unfortunately.
[13:08]  <spot> i'm only central US for a month or so.
[13:08]  <spot> then i'm eastern
[13:08]  <jwb> tibbs, no additional time coverage anyway.
[13:08]  <nirik> I'm often up evenings till pretty late tho.
[13:08]  <jwb> welcome to cvsadmin :)
[13:08]  <bpepple> Ok, should we move on?
[13:08]  <dgilmore> nirik, tibbs: do you want to help with branching?
[13:09]  <nirik> I'd be happy to as long as someone could explain the exact workflow.
[13:09]  <tibbs> I would be willing to assist since I'm in the review tickets anyway.
[13:09]  <jwb> nirik, tibbs: i'll send you a link
[13:09]  <jwb> it's relatively easy
[13:09]  <dgilmore> ok ill get you both added to the group with shell access to cvs-int
[13:09]  <tibbs> I've seen the wiki page.
[13:09]  <nirik> easy is good.
[13:09]  <jwb> tibbs, k
[13:10]  <rdieter> much else?  (I need food)
[13:10]  *** bpepple sets the channel topic to "FESCo meeting -- Free discussion around Fedora".
[13:10]  * dgilmore needs food also
[13:10]  <warren> lmacken, heh, the bodhi logo kind of looks like ICQ, but from another angle.
[13:10]  <bpepple> anything else before we start to wrap up for this week?
[13:10]  * c4chris has nothing more
[13:10]  <notting> we're already getting flamed about a prospective f8 schedule!
[13:10]  <nirik> so we are putting everyone up for election this cycle right?
[13:11]  <bpepple> nirik: yup.
[13:11]  <warren> FESCO election is a good topic.
[13:11]  <jeremy> gdk has already started some discussion about f8 schedule... long discussion to begin now ;)
[13:11]  <nirik> yeah, KDE people will not be happy.
[13:11]  <warren> nirik, will miss KDE4 or something?
[13:11]  <nirik> yeah, by 6 days
[13:11]  <dgilmore> F8 needs to have KDE4
[13:11]  <rdieter> nirik: it's not so bad (see my reply on ml).
[13:11]  <jwb> that's ridiculous
[13:12]  <dgilmore> anyways FESCo election times look good to me
[13:12]  <nirik> rdieter: yeah, at worst a rc could be shipped and a update could be pushed for final
[13:12]  <rdieter> exactly, no biggie.
[13:12]  <jwb> wait
[13:12]  <jwb> no
[13:12]  <jwb> if it's a matter of 6 days??
[13:12]  <jwb> just slip the damn schedule 6 days
[13:13]  <jwb> we'll likely slip anyway
[13:13]  <bpepple> jwb: what are the odds we won't be slipping anyhow?
[13:13]  <nirik> well, 6 days 5 months from now? we we slip? will they? will something else happen?
[13:13]  <rdieter> jwb: it's ok, really.  we'll likely have sources early anyway.
[13:13]  <jwb> rdieter, it's not about technical things
[13:13]  <warren> Don't pre-slip when slips may happen anyway.
[13:13]  <jwb> KDE 4 is important.  we should set our schedule to accomodate it
[13:13]  <nirik> so will we be blocking on merge reviews in f8?
[13:14]  * nirik ducks and runs
[13:14]  <jwb> i don't care if it's not a big deal from a technical perspective
[13:14]  <dgilmore> anyways Lets discuss this all later
[13:14]  <jwb> yeah
[13:14]  <bpepple> jwb: I really don't think it's gonna be an issue as rdieter has pointed out.
[13:14]  <rdieter> ok, imo, it's still much ado about nothing at this point, continue arguing if it makes you feel better. :)
[13:14]  <dgilmore> rdieter: :)
[13:14]  * rdieter runs to get food.
[13:14]  * warren needs to go
[13:14]  * jwb is grumpy today
[13:14]  <jwb> sorray
[13:14]  <jwb> er, sorry
[13:14]  * dgilmore needs food
[13:15]  <c4chris> :-)
[13:15]  <bpepple> anything about the election to discuss before calling quits for today?
[13:15]  <rdieter> jwb: np, busy day? :)
[13:15]  <jwb> rdieter, trying to catch up from being out for 2 weeks :)
[13:15]  <c4chris> bpepple: nah, just send the call out
[13:15]  <bpepple> c4chris: already sent it. ;)
[13:15]  <notting> vote early and vote often! oh wait.
[13:15]  <-- rwmjones has left this channel ("Left channel").
[13:15]  <warren> bpepple, who is officiating the election?
[13:16]  <c4chris> bpepple: oh... /me is a bit behind on emails
[13:16]  <warren> bpepple, and is it happening without locking out everyone from infrastructure like last time?
[13:16]  <warren> (That was horribly problematic.)
[13:16]  <bpepple> warren: I believe we decided back in april we weren't going to lock out infrastructure this time.
[13:17]  <c4chris> yea, no lockout
[13:17]  <warren> So is election being hosted somewhere outside of Fedora infrastructure?
[13:17]  <warren> perhaps by Sopwith?
[13:17]  * tibbs already self-nominated
[13:17]  <bpepple> warren: I'm fine with Sopwith doing it.
[13:17]  <tibbs> Is Sopwith still with Red Hat?
[13:17]  <jwb> no
[13:17]  <warren> has anyone asked him?
[13:17]  <bpepple> warren: not yet, but I can send him an e-mail.
[13:18]  <warren> Giving him the voting app and opening some IP access for the app to query the database only from his IP should be good enough.
[13:18]  <notting> warren: why host outside the infrastructure?
[13:18]  <jwb> yeah, confused on that
[13:18]  <warren> notting, last year Sopwith locked out everyone from infrastructure in order to guarantee that nobody will cheat the election.
[13:18]  <notting> trust! verify!
[13:19]  <bpepple> notting: I would hope we could trust our infrastructure team. ;)
[13:20]  <warren> I trust myself.
[13:20]  *** rdieter is now known as rdieter_away.
[13:20]  <tibbs> We seems to have a weird mix of trust and no trust that changes often.
[13:20]  <jwb> we should hire diebold
[13:20]  <jwb> oh ... wait
[13:20]  <cweyl|work> just because people want it to be open doesn't mean that we don't trust our teams.
[13:20]  <nirik> jwb: we would know we couldn't trust them. ;)
[13:21]  <warren> jwb, Diebold voting machines might be cheap off ebay now.
[13:21]  <cweyl|work> it just means that we're aware that appearances sometimes matter even more than actualities, so conducting our bits in the most transparent manner possible is the best way to ensure continued community faith and confidence.
[13:21]  <cweyl|work> </soapbox>
[13:21]  <warren> We might want to look into a 3rd party election host for the future, because we will have more elections for other things?
[13:22]  --> [splinux]  has joined this channel (n=splinux@fedora/splinux).
[13:22]  <nirik> we could have debian do our elections?
[13:22]  <warren> Fedora Board election will be even more important than this.
[13:22]  <nirik> and we could run theirs. ;)
[13:22]  <warren> OK we're getting silly, let's end this meeting.
[13:22]  <c4chris> wrap++
[13:23]  <bpepple> warren: agreed. we should probably continure this discussion on the mailing list.
[13:23]  * bpepple will end the meeting in 60
[13:23]  * bpepple will end the meeting in 30
[13:23]  * bpepple will end the meeting in 15
[13:23]  <bpepple> -- MARK -- Meeting End
[13:23]  <bpepple> Thanks, everyone!
[13:25]  <c4chris> bpepple: thanks
[13:25]  <c4chris> later folks
[13:26]  <nirik> thanks bpepple
[13:26]  *** couf is now known as couf_away.
[13:29]  <notting> thx