Extras/SteeringCommittee/Meeting-20070419

2007 April 19 FESCo Meeting

Members

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)

Summary

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

<bpepple> FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
* tibbs here
jeremy is here
c4chris here
jwb_gone is 1/2 here
<bpepple> Hi everybody; who's around?
<notting> yes?
* thl is on the rabble seats
jima too
nirik is here, although fixing a broken server too.
<bpepple> Ok, might as well get started.
--- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop
<tibbs> 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.
<bpepple> seems reasonable.
<c4chris> fine
<jwb_gone> +1
<nirik> +1
<jwb_gone> 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
<tibbs> 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.
<jwb_gone> yeah
"you" in the general sense
<tibbs> I'll report that back to Toshio; any other comments?
* bpepple listens to the crickets.
<tibbs> OK, the other thing is the trivial change of extras-list to devel-list in the guidelines.
<c4chris> sure
<bpepple> +1
<jeremy> +1
<nirik> tibbs: +1, just do it. ;)
<jwb_gone> +1
<tibbs> 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.
<notting> don't ask, just do :)
<tibbs> Which is really a topic that should be discussed at some point, although now might not be the best time.
<spot> sorry i'm late
had to rack mount some stuff. :)
<bpepple> 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.
<c4chris> rack mounting can be "fun"
<tibbs> Another note is that we've started to get into the topic of user/group creation and fedora-usermgmt and stuff.
<bpepple> tibbs: anything else?
<tibbs> This will get fun, so interested parties are as usual invited to the -packaging list and FPC meeting.
<jeremy> tibbs: ... and we won't ever hear from you again.  you'll be there forever :-P
<tibbs> So what's the final disposition on the ASCII change?
<spot> if by fun you mean "SOMETHING HORRIBLE HAS BURST FROM MY CHEST", then yes.
<notting> tibbs:i suggest you remove users and groups entirely, and replace everything with selinux roles and policy modules
<tibbs> It's so minor that I'd hate to come back with it next week.
<bpepple> tibbs: I don't see anyone complaining about it, so the change is fine IMO.
<tibbs> OK, thanks.
That's it from me.
<bpepple> ok, moving on.....
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Vote on rebuilding packages with old disttag - jwb
<bpepple> f13: -1
dgilmore: -1
from the mailing lists.
<jwb_gone> -1
<c4chris> -1
<notting> -1
<bpepple> -1 here also, since it's pretty much a cosmetic reason.
<jwb_gone> is anyone not familiar with the discussion?
<nirik> -1 (too late in the cycle). I would suggest we revist mass rebuilding per cycle after f7 is out.
<jeremy> -1
* bpepple agrees with nirik on having a discussion about future rebuilds.
<jwb_gone> that's a majority -1 already
<c4chris> nirik: yes
<tibbs> -1.  But the users may freak out so much that we'll have to reconsider.
<nirik> 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....
<jwb_gone> yep.  i agree
<bpepple> tibbs: maybe we should put something in the release notes regarding it?
* cweyl|work belatedly grabs a seat in the rabble section
<thl> nirik, we could try to get that into the vendor field
<jeremy> bpepple: sure
<thl> nirik, or some of the other fields in the rpm header maybe
<tibbs> The people who freak are probably the ones who will never read the release notes.
<jwb_gone> yeah, release notes would be a good idea
<LetoTo> yes: right now, to find out where a package is from, one looks at Buildhost
<bpepple> tibbs: true, but they only have themselves to blame for that.
<tibbs> But of course, it really needs to be documented.
<jwb_gone> tibbs, doesn't matter.  when they freak, we at least have it written down somewhere to point them at
<nirik> ie, have yum say: package clamav-0.90.2 (fedora) conflicts with clamav-0.90.2 (dag) or whatever...
* abadger1999 apologizes for being late
<bpepple> who do we need to poke to get that into the release notes?
<jwb_gone> nirik, can we have that discussion later?
<thl> nirik, sounds good, too
<nirik> yes, later is good. Just thought I would mention the idea.
<tibbs> Ideally the repo flavor could get into the RPM header somewhere.
<quaid> bpepple: write it into Docs/Beats/ directly is the best way
<bpepple> Ok, so FESCo is against the rebuild, and we'll add it to the release notes.
<quaid> alt find the beat writer on DocsProject/ReleaseNotes/Beats and ask that person to help
<bpepple> moving on, unless someone has something to add.
quaid: ok, thanks.
<tibbs> 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
<bpepple> Everyone read notting's proposal?
<jwb_gone> sounds fine to me
<c4chris> read it, and sounds sane to me
<jeremy> +1
<warren> +1
<bpepple> dgilmore: +1
<tibbs> Yes, seems fine as long as someone's willing to do all of the hacking.
<bpepple> f13: +1 with the basic idea.
<notting> we can fix it so the extras devel push doesn't need changing
<bpepple> +1 from me also.
<spot> +1
<abadger1999> +1
<notting> +1  from me (duh)
<nirik> +1
<bpepple> Ok, so I think we have enough '+1' to consider the proposal approved.
<jwb_gone> my 'sounds fine' was also a +1
:)
<c4chris> notting: you're going to implement it ?
<thl> btw, what is this about
was it discussed on public lists?
* thl wonders what he missed
<jwb_gone> thl, merging core and extras comps
<notting> c4chris: yeah, with some help from f13
<c4chris> cool
<bpepple> thl: oh, notting's e-mail might have been on the FESCo mailling list.
thl: sorry.
<thl> bpepple, things happen
<notting> thl: moving the f7 comps from internal RH CVS to the same place as extras comps, so there's only one file for f7
<thl> notting, sounds good;
* thl doesn't want to add anything
<nirik> so the untranslated extras stuff will just always appear in english? or not appear at all in other locales?
<jeremy> untranslated stuff appears in english
<notting> 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
<nirik> cool. moveon++
<bpepple> ok.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Upcoming FESCo election planning - bpepple
<c4chris> yea, I don't think there is much translation missing
<bpepple> We're getting close to the F7 release, and need to start planning for the next FESCo election.
<c4chris> right.  start a wiki candidates page again ?
<bpepple> c4chris: yes, but we also need to decide if we want to keep the same number of members.
<c4chris> ah, right
<bpepple> and if we want some assigned seats from other groups (like EPEL, FAB, packaging).
* warren maintains that we should not shrink the number of members.
<cweyl|work> bpepple: ex officio seats?
* bpepple tends to agree with warren.
<c4chris> currently 13, right ?
<bpepple> c4chris: correct.
<thl> bpepple, but there only 11 atm iirc
<abadger1999> I'm somewhat against assigned seats.
* c4chris is pretty happy with the current number
<thl> as andreas and I left
<bpepple> Here's what we decided last year in regard to elections: http://fedoraproject.org/wiki/Extras/Policy/FESCoElections
<abadger1999> Would rather see us delegate out to groups like releng and pc.
and epel.
<thl> or did f13 and notting take the places (/me is confused and shuts up)
<abadger1999> thl: Yes, f13 and notting came onboard at the same time.
<bpepple> thl: and when Andeas left I don't believe we filled his seat.
<thl> abadger1999, k
<c4chris> abadger1999: yes, I like delegates better (if needed)
<bpepple> So, my first question is do we want to keep the number of FESCo members at 13?
<warren> +1
<bpepple> +1
<c4chris> +1
<spot> +1
<warren> 13 is a lucky number.
<abadger1999> +1
<tibbs> +1
<notting> 0
<jwb_gone> 0
<jeremy> 0
<nirik> +1
* jwb_gone needs to grab some lunch before the cafeteria closes.  back ASAP
<bpepple> 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?
<nirik> I don't think we need assigned seats...
<bpepple> 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
<jeremy> I think the other way makes _more_ sense
there should be someone from fesco on fpc, epel, etc
<nirik> jeremy: +1
<abadger1999> jeremy: That makes sense to me.
<c4chris> jeremy: +1
* thl tends to agree with cweyl|work or nirik
<bpepple> jeremy: I'm fine with that, just throwing out ideas.
<jima> cweyl|work: that seems more sane to me (not that i have a vote anyway).
<nirik> then if there are items that need to be looked at happening in those places, they can bring it to fesco's attention...
<c4chris> I'd say all seats are up for ballot
<bpepple> So, the consensus is to not have any assigned seats.
<jeremy> anyone can attend, so ex officio members just mean that they're showing up
<bpepple> Do we want all the seats up for election then?
<c4chris> yes
<cweyl|work> jeremy: basically:)  but also that they're responsible to bring matters from the other groups to FESCo's attention
<nirik> do we still have all the voting system code?
<jima> s/ex officio members/rabble/ then?
<warren> cvsextras sponsored members eligible for voting?
<jeremy> jima: something like that :)
<bpepple> nirik: I believe so, though abadger1999 would know for sure.
<notting> warren: s/cvsextras/packagers/
<bpepple> warren: correct.
* cweyl|work annoints jima "lord imperium, rabble ex officio of FESCo"
<abadger1999> Yes we do.  It hasn't been enhanced like I was hoping but what is there still works.
<warren> notting, oops.
<warren> bpepple, we could ask Sopwith to officiate the voting again.
<nirik> the election wiki page looks fine to me... although /cvsextras/packagers/ needs to be done there too. ;)
<bpepple> 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.
<warren> nirik, I got caught up with freeze issues, working on the renaming next.
<nirik> warren: no worries.
* jima annoints cweyl "lord auctoritas"
<c4chris> election is two weeks after release, so maybe nominations at release time ?
<bpepple> 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.
<warren> 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.
<abadger1999> Can we vote on locking people out?
Because it is pretty darn silly.
<tibbs> I personally see no reason to lock people out.
* c4chris neither
<tibbs> It's going to be pretty tough to find a completely impartial vote-taker.
* bpepple doesn't see much reason to lock people out either.
<notting> do we have any fedora representatives from the UN?
<tibbs> Perhaps we could ask Debian to host our election  or something if it's really a concern.
<abadger1999> /e sees no reason naturally.
<nirik> or fsf. ;)
<abadger1999> che stallman?
<warren> well, that's why we ask Sopwith to host it.
* c4chris sees a business opportunity here :-)
<warren> I just mean, please don't lock out the candidates from infrastructure like the last election.
<bpepple> warren: agreed.
that's probably enough for today on this, I just wanted to start planning this since F7 is coming up pretty quick.
<jeremy> yes, yes it is
<bpepple> anything else, or should we move on?
<c4chris> move++
<bpepple> abadger1999: anything in regard to the packageDB?
<abadger1999> Nothing except I've missed my self imposed deadline :-(
<abadger1999> I'm going to work on it this weekend but if there's someone who wants to help that would be great.
<warren> BTW, is there any timetable for the proposed move of Extras from plague to koji?
<abadger1999> $DAYJOB has been killing me the past two weeks.
<bpepple> warren: I think f13 and dgilmore are both gone today.
<warren> oh
k, will ask later.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- FESCo Responsibilities
<nirik> is there any status update on bodhi? lmacken ?
* jwb_gone is back
<bpepple> nirik: not sure.
I added this to the schedule since a lot of the FAB meeting on Tuesday was about this.
<thl> bpepple, not sure if "FESCo Responsibilities" is worth discussing today
<thl> as we talked about it on tuesday
I'll write something up, and we can discuss it next week
<c4chris> thl: sounds good
<jeremy> thl: sounds good
<thl> but I'll of course take input if you guys want to give me input
<bpepple> 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
<bpepple> Anything else folks want to discuss now?
<tibbs> http://fedoraproject.org/wiki/Extras/Policy/KernelModules
Also has a reference to extras-list.
<LetoTo> ah yes. Can i nominate myself for sponsor :)
<tibbs> I'll change it now.
<nirik> anyone know what people should do about the i386 libperl in x86_64 broken deps?
<bpepple> LetoTo: Yes, send an e-mail to the maintainers-list.
<LetoTo> bpepple: ok thanks
<LetoTo> another topic
has anyone thought about dnssec and integration?
<jima> LetoTo: in what regard?
<LetoTo> We're working on abunch of dnssec related packages
<notting> nirik: so, the issue is i386 perl was removed from core
<LetoTo> well, there is the "who controls the keys in the OS" issue
<notting> nirik: which broke deps pulled in by -devel in extras?
<LetoTo> at first, i was thinking of perhaps a caching-nameserver-dnssec package.
<warren> 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
<bpepple> LetoTo: That might be a better topic to discuss on the devel mailling list.
<LetoTo> yes. will do.
sorry
<bpepple> LetoTo: No worries.
<warren> libpurple-devel.i386 pulls in libpurple.i386, libpurple.i386 is linked to libperl
<nirik> right. So we need all those packages to do a -libs split?
<warren> There is no good reason why x86_64 pulls in pidgin.i386 or libpurple.i386.
I wish I could add it to a blacklist.
<nirik> there is a blacklist...
<warren> oh?
<tibbs> They have -devel packages, so they're multilibbed.
* warren missed something.
<notting> warren: well, libpurple-devel.i386 does require libpurple.i386
<nirik> mschwent added gg2 just recently.
<tibbs> I'm beginning to think that we need a whitelist instead.
<warren> notting, but there is no reason at all to ship both archs.
<c4chris> there is a whitelist too
<nirik> I think we need to redo how multiarch works in f8... ;)
<notting> warren: you could move the perl bindings to perl-Purple
<warren> ugh
nobody actually *uses* those bindings
<cweyl|work> *cough* I do
<warren> really?!
<cweyl|work> yeah
<warren> upstream isn't even aware if they work or not =)
<cweyl|work> :)
<nirik> 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
* c4chris is confused why we need to put i386 stuff in an x86_64 repo
<warren> I rather blacklist pidgin.i386 from the x86-64 repo
it makes NO SENSE to ship it there
<jeremy> warren: why not?
<nirik> c4chris: in theory to allow i386 development on x86_64
<c4chris> nirik: but why can't the stuff com efrom the i386 repo directly ?
<warren> *NONE* of the x86-64 users use any of the pidgin.i386 stuff
<notting> c4chris: doesn't work right. needs yum changes
<jeremy> warren: maybe they don't today.  but why do you want to deny them the ability to do so?
<c4chris> oh
<warren> jeremy, what use can they possibly have for it?
<c4chris> can we change yum for F8 ?
<warren> jeremy, and this is the opposite of caillon's anti-user stance on firefox.
<thl> notting, we could open a special i386-devel-on-x86_64 repo and hardlink files from the i386 tree
<notting> c4chris: very possibly. there's a bug open
thl: messssssy
thl: and you still have the same problem
<nirik> so there are 8 packages affected here... we do need to get them fixed asap. ;)
<jeremy> thl: how is that better than what we have now?
<c4chris> notting: cool
<thl> the whole thing is messy
<jeremy> warren: I might be developing an application using libpidgin and want to test i386 and x86_64 on my x86_64 box
<warren> *can* I just add pidgin to the multilib blacklist?
<thl> jeremy, it could be a optional repo users can enable or disable
<jeremy> warren: and _yes_ I've done things like this
thl: users want things to _WORK_
<warren> jeremy, nothing stops you from installing the i386 rpms manually.  developing that is an extreme corner case.
users DO NOT NEED THIS
<thl> jeremy, how many users want to develop i386 stuff on x86_64?
<jeremy> 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
<notting> thl: but you have the same problem creating that repo
thl: it doesn't solve the problem, it just moves it somewhere else
<jeremy> thl: how else do you know what runtime libraries to provide?
<thl> I agree we need some i386 libs in the x86_64 tree
<warren> but not all
<thl> but the devel stuff there is really annoying imho
<jeremy> please.  enlighten me as to how you magically decide which ones are the "right" ones
<warren> case by case basis?
<jeremy> warren: which means that you're maintaining a list and that does not scale
<thl> jeremy, no idea; I'd say we maybe should revisit this early after F7
<jeremy> warren: it's what we used to do
<warren> It makes a whole lot of logical sense to ship only one arch of pidgin.
<jeremy> warren: and it fundamentally didn't work
<nirik> I think dwm has done some thinking on how to manage it better... he wanted to revisit after f7 too.
<jeremy> warren: the number of bugs from actual customers about it was far higher than you would believe
* bpepple agrees we should probably look at this after F7.
<jeremy> (we originally _did_ the whitelist because it seemed reasonable at the time)
<warren> 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.
<abadger1999> What is pidgin doing?  Is it embedding a perl interpreter or does it have perl bindings?
<warren> abadger1999, perl bindings
abadger1999, the libperl problem is almost independent from my question
* nirik thinks we should focus on fixing the 8^H6 affected packages now for f7 and revisit the big picture later.
<jeremy> warren: you're making broad sweeping assumptions about what people "need"
<thl> nirik, +1
<warren> jeremy, actually, perl.i386 being removed from x86-64 has the same logic.
<bpepple> nirik: agreed.
<warren> 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
<jeremy> warren: actually, there is a case where perl being multilib broke things
<warren> Perhaps this discussion doesn't belong in FESCO, I'll continue outside of this meeting.
<jeremy> (ppc64)
<notting> helllo ppc64
fix the packages for now, fix the repository generation later
<jeremy> 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
<warren> If -devel then multilib?  Is that truly a wise decision?
<abadger1999> nirik: Do the packages require libperl because they have perl bindings?  If so can we split the bindings into a subpackage?
<jeremy> we could (and perhaps should) split out libperl much like libpython
<nirik> abadger1999: not sure.
<jeremy> 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
<abadger1999> jeremy: Separate libperl package sounds sane.
<warren> would separate libperl solve our immediate problem?
<nirik> irssi, cyrus-imapd, fedora-ds-base, gg2, gnumeric, js, nagios, pidgin
<warren> separate libperl sounds like a cleaner solution no?
<f13> I'mhere
for the fedora release meeting
<bpepple> we should probably wrap this up....
<warren> jeremy, can we separate libperl for F7?
<jeremy> warren: sure!  just a simple matter of packaging :)
* warren done ranting.
<bpepple> Ok, since there folks waiting to start a meeting...
<thl> did anybody read https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00372.html ? Would FESCo like something in that direction?
* thl shuts up
<nirik> BTW, for dmw's multiuarch blocker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235752
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
<bpepple> -- MARK -- Meeting End