Extras/SteeringCommittee/Meeting-20070419

= 2007 April 19 FESCo Meeting =

Present

 * Brian Pepple 	(bpepple)
 * Jason Tibbitts	(tibbs)
 * Christian Iseli	(c4chris)
 * Toshio Kuratomi	(abadger1999)
 * Kevin Fenzi 		(nirik)
 * Josh Boyer		(jwb)
 * Jeremy Katz		(jeremy)
 * Bill Nottingham	(notting)
 * Tom Callaway		(spot)
 * Warren Togami	(warren)

Absent

 * Dennis Gilmore	(dgilmore)
 * Jesse Keating	(f13)
 * Rex Dieter  	(rdieter)

Packaging Committee Report

 * FESCo approved the Packaging Committee's guidelines regarding:
 * Minor clarifications to the filename encoding guidelines

Vote on rebuilding packages with old disttag

 * FESCo voted against a proposal to rebuild packages with old disttag's. This was decision was based on the fact that there has not been any major changes in the toolchain for Fedora 7, and this would avoid making end users download the packages for only a release tag change.

Comps process

 * FESCo approved notting's proposal to move the f7 comps from internal RH CVS to the same place as extras comps, so there's only one file for f7.

Misc

 * Discussed upcoming FESCo election.
 * Discussed i386 libperl in x86_64 broken deps.

Log
FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren jeremy is here c4chris here jwb_gone is 1/2 here Hi everybody; who's around? yes? jima too nirik is here, although fixing a broken server too. Ok, might as well get started. --- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop A couple of things this week. Minor clarifications to the filename encoding guidelines: https://www.redhat.com/archives/fedora-packaging/2007-April/msg00156.html After some discussion on -maintainers regarding the meaning of ASCII we ended up with that. seems reasonable. fine  +1 +1  tibbs, minor technical point tibbs, you might want to just attach that png to the wiki page itself rather than link to it so it doesn't disappear on you I'll take "you" to be the committee, since I personally think the original was fine and this is all a waste of time. abadger1999 was driving this but he doesn't seem to be around.  yeah "you" in the general sense I'll report that back to Toshio; any other comments? OK, the other thing is the trivial change of extras-list to devel-list in the guidelines. sure +1 +1 tibbs: +1, just do it. ;)  +1 I know it's trivial, but I don't think it's appropriate to let FPC decide what should and shouldn't be submittted to FESCO. don't ask, just do :) Which is really a topic that should be discussed at some point, although now might not be the best time. sorry i'm late had to rack mount some stuff. :) I'm of the opinion that minor things don't need to go to FESCo, but we can talk about that later if we've got the time. rack mounting can be "fun" Another note is that we've started to get into the topic of user/group creation and fedora-usermgmt and stuff. tibbs: anything else? This will get fun, so interested parties are as usual invited to the -packaging list and FPC meeting. tibbs: ... and we won't ever hear from you again. you'll be there forever :-P So what's the final disposition on the ASCII change? if by fun you mean "SOMETHING HORRIBLE HAS BURST FROM MY CHEST", then yes. tibbs:i suggest you remove users and groups entirely, and replace everything with selinux roles and policy modules It's so minor that I'd hate to come back with it next week. tibbs: I don't see anyone complaining about it, so the change is fine IMO. OK, thanks. That's it from me. ok, moving on..... --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Vote on rebuilding packages with old disttag - jwb f13: -1 dgilmore: -1 from the mailing lists.  -1 -1 -1 -1 here also, since it's pretty much a cosmetic reason.  is anyone not familiar with the discussion? -1 (too late in the cycle). I would suggest we revist mass rebuilding per cycle after f7 is out. -1  that's a majority -1 already nirik: yes -1. But the users may freak out so much that we'll have to reconsider. all the dist tag/repotag mess... I think we should push for tools to be better about saying what repo/dist a package is from....  yep. i agree tibbs: maybe we should put something in the release notes regarding it? nirik, we could try to get that into the vendor field bpepple: sure nirik, or some of the other fields in the rpm header maybe The people who freak are probably the ones who will never read the release notes.  yeah, release notes would be a good idea  yes: right now, to find out where a package is from, one looks at Buildhost tibbs: true, but they only have themselves to blame for that. But of course, it really needs to be documented.  tibbs, doesn't matter. when they freak, we at least have it written down somewhere to point them at ie, have yum say: package clamav-0.90.2 (fedora) conflicts with clamav-0.90.2 (dag) or whatever... who do we need to poke to get that into the release notes?  nirik, can we have that discussion later? nirik, sounds good, too yes, later is good. Just thought I would mention the idea. Ideally the repo flavor could get into the RPM header somewhere. bpepple: write it into Docs/Beats/ directly is the best way Ok, so FESCo is against the rebuild, and we'll add it to the release notes. alt find the beat writer on DocsProject/ReleaseNotes/Beats and ask that person to help moving on, unless someone has something to add. quaid: ok, thanks. Some note about how Fedora moves quickly and not all packages change, and how upgrades go faster when we aren't needlessly replacing packages might placate a few folks, I guess. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- comps process - notting Everyone read notting's proposal?  sounds fine to me read it, and sounds sane to me +1 +1 dgilmore: +1 Yes, seems fine as long as someone's willing to do all of the hacking. f13: +1 with the basic idea. we can fix it so the extras devel push doesn't need changing +1 from me also. +1 +1 +1 from me (duh) +1 Ok, so I think we have enough '+1' to consider the proposal approved.  my 'sounds fine' was also a +1
 * tibbs here
 * thl is on the rabble seats
 * bpepple listens to the crickets.
 * bpepple agrees with nirik on having a discussion about future rebuilds.
 * cweyl|work belatedly grabs a seat in the rabble section
 * abadger1999 apologizes for being late

notting: you're going to implement it ? btw, what is this about was it discussed on public lists?  thl, merging core and extras comps c4chris: yeah, with some help from f13 cool thl: oh, notting's e-mail might have been on the FESCo mailling list. thl: sorry. bpepple, things happen thl: moving the f7 comps from internal RH CVS to the same place as extras comps, so there's only one file for f7 notting, sounds good; so the untranslated extras stuff will just always appear in english? or not appear at all in other locales? untranslated stuff appears in english nirik: the only group in extras comps not in core comps is 'window managers', and i think that got added to the pot files to get translated anyway cool. moveon++ ok. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Upcoming FESCo election planning - bpepple yea, I don't think there is much translation missing We're getting close to the F7 release, and need to start planning for the next FESCo election. right. start a wiki candidates page again ? c4chris: yes, but we also need to decide if we want to keep the same number of members. ah, right and if we want some assigned seats from other groups (like EPEL, FAB, packaging).  bpepple: ex officio seats? currently 13, right ? c4chris: correct. bpepple, but there only 11 atm iirc I'm somewhat against assigned seats. as andreas and I left Here's what we decided last year in regard to elections: http://fedoraproject.org/wiki/Extras/Policy/FESCoElections Would rather see us delegate out to groups like releng and pc. and epel. or did f13 and notting take the places (/me is confused and shuts up) thl: Yes, f13 and notting came onboard at the same time. thl: and when Andeas left I don't believe we filled his seat. abadger1999, k abadger1999: yes, I like delegates better (if needed) So, my first question is do we want to keep the number of FESCo members at 13? +1 +1 +1 +1 13 is a lucky number. +1 +1 0 <jwb_gone> 0 0 +1 Ok, I think we have a majority on this, so FESCo will remain a 13 member committee. Now do want some of the subgroups to have a seat on FESCo? I don't think we need assigned seats... Or to word it differently, how many seats are up for election? <cweyl|work> bpepple: if they do, IMHO they should be ex officio seats. members, but no vote, as they hold that position by virtue of holding a different position, and weren't elected I think the other way makes _more_ sense there should be someone from fesco on fpc, epel, etc jeremy: +1 jeremy: That makes sense to me. jeremy: +1 jeremy: I'm fine with that, just throwing out ideas. cweyl|work: that seems more sane to me (not that i have a vote anyway). then if there are items that need to be looked at happening in those places, they can bring it to fesco's attention... I'd say all seats are up for ballot So, the consensus is to not have any assigned seats. anyone can attend, so ex officio members just mean that they're showing up Do we want all the seats up for election then? yes <cweyl|work> jeremy: basically:) but also that they're responsible to bring matters from the other groups to FESCo's attention do we still have all the voting system code? s/ex officio members/rabble/ then? cvsextras sponsored members eligible for voting? jima: something like that :) nirik: I believe so, though abadger1999 would know for sure. warren: s/cvsextras/packagers/ warren: correct. Yes we do. It hasn't been enhanced like I was hoping but what is there still works. notting, oops. bpepple, we could ask Sopwith to officiate the voting again. the election wiki page looks fine to me... although /cvsextras/packagers/ needs to be done there too. ;) Ok, so we want all 13 seats up for election? And when do we start accepting nominations on the wiki? warren: that sounds fine with me. nirik, I got caught up with freeze issues, working on the renaming next. warren: no worries. election is two weeks after release, so maybe nominations at release time ? I believe according to our guideline we are to start the election 2 weeks after F7, and the election period last between 10-14 days. can we *PLEASE* make the new election software so we don't have lock out all members from infrastructure like last time? That was disruptive. Can we vote on locking people out? Because it is pretty darn silly. I personally see no reason to lock people out. It's going to be pretty tough to find a completely impartial vote-taker. do we have any fedora representatives from the UN? Perhaps we could ask Debian to host our election or something if it's really a concern. /e sees no reason naturally. or fsf. ;) che stallman? well, that's why we ask Sopwith to host it. I just mean, please don't lock out the candidates from infrastructure like the last election. warren: agreed. that's probably enough for today on this, I just wanted to start planning this since F7 is coming up pretty quick. yes, yes it is anything else, or should we move on? move++ abadger1999: anything in regard to the packageDB? Nothing except I've missed my self imposed deadline :-( I'm going to work on it this weekend but if there's someone who wants to help that would be great. BTW, is there any timetable for the proposed move of Extras from plague to koji? $DAYJOB has been killing me the past two weeks. warren: I think f13 and dgilmore are both gone today. oh k, will ask later. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- FESCo Responsibilities is there any status update on bodhi? lmacken ? nirik: not sure. I added this to the schedule since a lot of the FAB meeting on Tuesday was about this. bpepple, not sure if "FESCo Responsibilities" is worth discussing today as we talked about it on tuesday I'll write something up, and we can discuss it next week thl: sounds good thl: sounds good but I'll of course take input if you guys want to give me input thl: that's what I was wondering also, though not all of FESCo was there. I'm fine with waiting for your write-up. --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Anything else folks want to discuss now? http://fedoraproject.org/wiki/Extras/Policy/KernelModules Also has a reference to extras-list. <LetoTo> ah yes. Can i nominate myself for sponsor :) I'll change it now. anyone know what people should do about the i386 libperl in x86_64 broken deps? LetoTo: Yes, send an e-mail to the maintainers-list. <LetoTo> bpepple: ok thanks <LetoTo> another topic has anyone thought about dnssec and integration? LetoTo: in what regard? <LetoTo> We're working on abunch of dnssec related packages nirik: so, the issue is i386 perl was removed from core <LetoTo> well, there is the "who controls the keys in the OS" issue nirik: which broke deps pulled in by -devel in extras? <LetoTo> at first, i was thinking of perhaps a caching-nameserver-dnssec package. nirik, 1) somebody built something that has a -devel sub-package 2) perl.i386 was removed from x86_64 3) the i386 package pulled in no longer resolves deps LetoTo: That might be a better topic to discuss on the devel mailling list. <LetoTo> yes. will do. sorry LetoTo: No worries. libpurple-devel.i386 pulls in libpurple.i386, libpurple.i386 is linked to libperl right. So we need all those packages to do a -libs split? There is no good reason why x86_64 pulls in pidgin.i386 or libpurple.i386. I wish I could add it to a blacklist. there is a blacklist... oh? They have -devel packages, so they're multilibbed. warren: well, libpurple-devel.i386 does require libpurple.i386 mschwent added gg2 just recently. I'm beginning to think that we need a whitelist instead. notting, but there is no reason at all to ship both archs. there is a whitelist too I think we need to redo how multiarch works in f8... ;) warren: you could move the perl bindings to perl-Purple ugh nobody actually *uses* those bindings <cweyl|work> *cough* I do really?! <cweyl|work> yeah upstream isn't even aware if they work or not =) <cweyl|work> :) so there isn't any kind of "do this to fix it" for maintainers in this position? I guess we should take it back to the list. <cweyl|work> I've even sent them XS patches improving them, but haven't had much luck getting them in I rather blacklist pidgin.i386 from the x86-64 repo it makes NO SENSE to ship it there warren: why not? c4chris: in theory to allow i386 development on x86_64 nirik: but why can't the stuff com efrom the i386 repo directly ? *NONE* of the x86-64 users use any of the pidgin.i386 stuff c4chris: doesn't work right. needs yum changes warren: maybe they don't today. but why do you want to deny them the ability to do so? oh jeremy, what use can they possibly have for it? can we change yum for F8 ? jeremy, and this is the opposite of caillon's anti-user stance on firefox. notting, we could open a special i386-devel-on-x86_64 repo and hardlink files from the i386 tree c4chris: very possibly. there's a bug open thl: messssssy thl: and you still have the same problem so there are 8 packages affected here... we do need to get them fixed asap. ;) thl: how is that better than what we have now? notting: cool the whole thing is messy warren: I might be developing an application using libpidgin and want to test i386 and x86_64 on my x86_64 box *can* I just add pidgin to the multilib blacklist? jeremy, it could be a optional repo users can enable or disable warren: and _yes_ I've done things like this thl: users want things to _WORK_ jeremy, nothing stops you from installing the i386 rpms manually. developing that is an extreme corner case. users DO NOT NEED THIS jeremy, how many users want to develop i386 stuff on x86_64? thl: they don't want to have to understand vagueries of what arch something is or anything else.  they want the software they're running/developing to work thl: but you have the same problem creating that repo thl: it doesn't solve the problem, it just moves it somewhere else thl: how else do you know what runtime libraries to provide? I agree we need some i386 libs in the x86_64 tree but not all but the devel stuff there is really annoying imho please. enlighten me as to how you magically decide which ones are the "right" ones case by case basis? warren: which means that you're maintaining a list and that does not scale jeremy, no idea; I'd say we maybe should revisit this early after F7 warren: it's what we used to do It makes a whole lot of logical sense to ship only one arch of pidgin. warren: and it fundamentally didn't work I think dwm has done some thinking on how to manage it better... he wanted to revisit after f7 too. warren: the number of bugs from actual customers about it was far higher than you would believe (we originally _did_ the whitelist because it seemed reasonable at the time) How much sense does it make that x86_64 users have both archs of pidgin, needing to download updates for both archs every time there is a security hole, when they absolutely NEVER need the i386? We should be optimizing for the common case, not extreme corner cases. What is pidgin doing? Is it embedding a perl interpreter or does it have perl bindings? abadger1999, perl bindings abadger1999, the libperl problem is almost independent from my question warren: you're making broad sweeping assumptions about what people "need" nirik, +1 jeremy, actually, perl.i386 being removed from x86-64 has the same logic. nirik: agreed. jeremy, perl.i386 didn't work, but it didn't harm either, but we decided to remove it. You *could* build stuff against libperl.i386 just like your pidgin.i386 logic warren: actually, there is a case where perl being multilib broke things Perhaps this discussion doesn't belong in FESCO, I'll continue outside of this meeting. (ppc64) helllo ppc64 fix the packages for now, fix the repository generation later and the only reason perl started being multilib (and thus, that we're probably having this discussion) is that perl grew a -devel package when it previously didn't have one If -devel then multilib? Is that truly a wise decision? nirik: Do the packages require libperl because they have perl bindings? If so can we split the bindings into a subpackage? we could (and perhaps should) split out libperl much like libpython abadger1999: not sure. warren: -devel means you have a library that someone could develop against. if I can develop against it, I can be distributing an i386 binary of it that you might want to run on your x86_64 box jeremy: Separate libperl package sounds sane. would separate libperl solve our immediate problem? irssi, cyrus-imapd, fedora-ds-base, gg2, gnumeric, js, nagios, pidgin separate libperl sounds like a cleaner solution no? I'mhere for the fedora release meeting we should probably wrap this up.... jeremy, can we separate libperl for F7? warren: sure! just a simple matter of packaging :) Ok, since there folks waiting to start a meeting... did anybody read https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00372.html ? Would FESCo like something in that direction? BTW, for dmw's multiuarch blocker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235752 bpepple will end the meeting in 30 bpepple will end the meeting in 15 -- MARK -- Meeting End
 * thl wonders what he missed
 * thl doesn't want to add anything
 * warren maintains that we should not shrink the number of members.
 * bpepple tends to agree with warren.
 * c4chris is pretty happy with the current number
 * jwb_gone needs to grab some lunch before the cafeteria closes. back ASAP
 * thl tends to agree with cweyl|work or nirik
 * cweyl|work annoints jima "lord imperium, rabble ex officio of FESCo"
 * jima annoints cweyl "lord auctoritas"
 * c4chris neither
 * bpepple doesn't see much reason to lock people out either.
 * c4chris sees a business opportunity here :-)
 * jwb_gone is back
 * warren missed something.
 * c4chris is confused why we need to put i386 stuff in an x86_64 repo
 * bpepple agrees we should probably look at this after F7.
 * nirik thinks we should focus on fixing the 8^H6 affected packages now for f7 and revisit the big picture later.
 * warren done ranting.
 * thl shuts up
 * bpepple will end the meeting in 60