Extras/SteeringCommittee/Meeting-20060413

Summary
Present from FESCo: thl, mschwendt, f13, scop, skvidal, thomasvs, warren


 * kernel module standarisation
 * some minor adjustments are needed -- thl will work further on them and post about it to the list
 * EOL Policy
 * Still undecided; we should continue to discuss this on the list; some people sill think that we should still allow new stuff in FC3; other say "maintenance mode now. No new packages, just fixes." Other ideas: Only new packages for FC3 if FESCo approves them. thl and warren want to avoid a "Fedora Legacy Team and the term in general.
 * Broken deps report
 * It can run on extras64 once it has been updated. Still undecided when to run ist -- after each push? In any case: The repo needs to be fully synced
 * No new sponsorship nominations
 * Build dependency exceptions (http://www.redhat.com/archives/fedora-extras-list/2006-March/msg01484.html)
 * A lot of opinions; See the full log for details
 * see the last sentence
 * let's go for the last sentence of http://www.redhat.com/archives/fedora-extras-list/2006-March/msg01484.html
 * Mailinglist for games SIG
 * warren created fedora-games-list

Full Log
18:59             * | thl looks around 19:00 <        thl> | Hi everyone; who's around for the FESCo Meeting? 19:00           --> | mschwendt (Michael Schwendt)  has joined #fedora-extras 19:00           --- | thl has changed the topic to: FESCO Meeting in progress 19:00           --> | f13 (http://svcs.affero.net/rm.php?r=jkeating)  has joined #fedora-extras 19:00             * | scop is after 3 minutes 19:01 <        thl> | okay, I'll start slowly 19:01           --- | thl has changed the topic to: FESCO Meeting in progress -- kernel module standarisation 19:01 <        thl> | the proposal is used by another repo 19:01 <        thl> | I notices some minor things there: 19:02 <        thl> | the kernel pacakges in core are named 19:02 <        thl> | kernel{,-variant}-foo 19:02 <        thl> | e.g. 19:02 <         thl> | kernel-smp-devel 19:02 <        thl> | but kmods are named 19:02 <        thl> | kmod-foo{,-variant} 19:02 <        thl> | e.g. 19:02 <         thl> | kmod-ndiswrapper-smp 19:03 <        thl> | did that happen accidently? 19:03 <        thl> | scop, ? 19:03 <       scop> | apples and oranges? 19:03 <        thl> | okay 19:03 <        thl> | good answer 19:03             * | skvidal is around 19:03 <        thl> | there is one other thing 19:04 <        thl> | the kmods imho should provide something like 19:04 <        thl> | kmod-foo-$(uname -r) 19:04 <        thl> | or "kmod-foo-kerneldep = $(uname -r)" 19:04 <       scop> | that needs to be arch-qualified too 19:04 <        thl> | to allow installation via 19:05 <        thl> | yum install 'kmod-foo-kerneldep = $(uname -r)' 19:05 <        thl> | or something like that 19:05 <       scop> | kmod-foo-%{__target_cpu} = $(uname -r) 19:05 <        thl> | multiple people asked me for that 19:05 <        thl> | scop, sounds okay for me 19:06 <         thl> | that okay for everybody? 19:06 <   thomasvs> | (I am here too) 19:06 <      scop> | thl, did the folks asking it say a specific reason for the need? 19:06 <    ignacio> | No variant in that? 19:06 <        thl> | ignacio, variant is in the uname 19:06 <       scop> | ignacio, good point, needs variant 19:07 <   thomasvs> | btw, I do feel they should be named like kernel, it's already very confusing 19:07 <       scop> | ....actually, it's in $(uname -r) 19:07             * | warren is here, but trying to do 2 meetings at once 19:07 <        thl> | scop, to install a older version via yum 19:07 <        thl> | peopel are still used to it from the old scheme 19:07 <        thl> | and I think we should provide it 19:08 <         thl> | anyway, let's proceed now 19:08 <       scop> | wait, the conclusion was? 19:08           --- | thl has changed the topic to: FESCo Meeting -- EOL Policy 19:08 <        thl> | f13, mschwendt ? 19:09 <        thl> | and of course everyone else :-) 19:09 <       scop> | thl, please hold on, what was the conclusion of the previous item? 19:09 <         thl> | scop, no one yet 19:09 <      warren> | I'm OK with this, except I still want to add stuff that I use in FC3 Extras. =( 19:09 <        thl> | I'll look into it closer and post for the list for opinion; sorry for being a bit hectic; but I think we have a lot todo today 19:10 <        thl> | warren, "want to add stuff" -> new stuff? 19:10 <        thl> | or updates to exisiting packages? 19:10 <     warren> | stuff that isn't in Extras yet but I use on my servers, it has only been a time issue 19:10 <     warren> | use on my servers for the forseeable future (forever), thus I have to maintain it 19:11 <         thl> | opinions? 19:11 <  mschwendt> | we should continue with this on the list -- why discuss this here? 19:11 <        f13> | ah I'm here. 19:11 <        thl> | We IMHO have to slow FC3 a bit down; no new packages would be a direct sign for everybody 19:12 <     warren> | actually the list would be better, we're trying to do a simultaneous in-person "how do we merge core and extras" meeting here. 19:12 <        thl> | mschwendt, can we move the discussion to a public list again? 19:12 <        f13> | yes, but we still need to get this resolved. 19:12 < mschwendt> | thl: sure 19:12 <        f13> | we go round arnd roun don teh list, never make a decision, chair it for a meeting, then at the meeting we just say discuss on list. 19:12 <        f13> | whats the point? 19:12 <    warren> | thl, if we had some way of saying "No new packages unless you can guarantee that you will maintain that package for 4 years." Would work for me personally, but enforcing that is the hard part. 19:12 <      |Jef|> | warren: good luck 19:13 <  mschwendt> | f13: what is your most recent proposal then? 19:13 <        f13> | I personally see FC3 as maintenance mode now. No new packages, just fixes. 19:13 <       scop> | f13++ 19:13 <        f13> | mschwendt: Extras follows core. 19:13 <    skvidal> | f13: +1 19:13 <        thl> | I tend to agree with f13 19:13 <        f13> | mschwendt: when core goes maint mode, as does extras. When Core gets dropped from Legacy, as it does from Extras. 19:14 <  mschwendt> | and who is the FE Legacy team? 19:14 <        f13> | mschwendt: there is none, that could be handled by the FE Security SIG 19:14 <     warren> | naming a team and calling them legacy is a wrong idea 19:14 <        f13> | indeed 19:14 <        thl> | no "FE Legacy" please 19:14 <  mschwendt> | and who does the FE Security SIG consist of? 19:14 <  mschwendt> | just Hans, or? 19:14 <        f13> | FE Security SIG would be committed to caring about security fixes as long as a release is at least in maint mode. After main tmode, boom. 19:15 <        f13> | mschwendt: I'm on it, there are others. 19:15 <  mschwendt> | so this will be a try-and-see thing -- okay 19:15 <        f13> | mschwendt: we don't really have an official one because we haven't gotten official blessing from FESCO for a security policy to begin with. 19:15 <        thl> | mschwendt, three people iirc 19:15 <        f13> | we're getting to the point of chicken / egg. 19:15 <     warren> | I'm OK with going ahead with this, but I don't want this to be 100% without flexibility. 19:15 <     warren> | I'm still actively using FE3 in production. 19:16 <     warren> | How about "No additions unless FESCO approves." ? 19:16 <  mschwendt> | f13: we should still discuss how to mark packages as "package owner doesn't do updates anymore", so the legacy people don't conflict with changes done the package owner 19:16 <       scop> | we don't need that on our TODO list 19:16 <     warren> | Just make the red tape and bureaucracy needed so large that people wont do it. 19:16 <        f13> | warren: yes, but you can't use your FESCO membership just to allow your package in. 19:16 <        f13> | we REALLY REALLY shouldn't be adding new things to a dead release. 19:16 <     warren> | f13, it isn't dead. 19:16 <        f13> | mschwendt: thats for a different discussion, but sure. 19:17 <      |Jef|> | f13: dead horses look brand new when you give them a new saddle 19:17 <        f13> | warren: right, and 7.2 and 6.2 aren't dead, blah blah blah 19:17 <      |Jef|> | f13: i think the term here is "undead" 19:18 <        thl> | I don't like the "No additions unless FESCO approves." idea very much 19:18             * | XulChris screams I'm not dead yet! 19:18 <    ignacio> | Just say it requires a majority vote from FESCO for adding new packages and be done with it. 19:18 <        thl> | but I can live with it if the other like it 19:18 <      |Jef|> | thl: afraid of fesco overload? 19:18 <        f13> | we have to turn it off at some time. 19:18 <  mschwendt> | time-killing discussion -- we should create a list of things we need to agree on and process that list item by item 19:19 <     warren> | Back to the list please 19:19             * | f13 is now somewhat AFK 19:19             * | warren in the other meeting now 19:19 <        thl> | okay, so who writes a summary and starts a discussion on extras-list? 19:19 <        thl> | f13, mschwendt ? 19:19 <  mschwendt> | I can do that 19:19 <        thl> | mschwendt, thx 19:20 <        thl> | okay, let's proceed then 19:20           --- | thl has changed the topic to: FESCo Meeting --  Broken deps report 19:20 <        thl> | mschwendt, your running the script more often now afaics 19:20 <  mschwendt> | most recent version here: http://home.arcor.de/ms2002sep/tmp/repoclosure-modified-20060408.tgz 19:20 <        thl> | what needs to be done to driver this forward? 19:21 <  mschwendt> | all I've done is execute "rc-run-all.py", and let it do everything alone 19:21 <        thl> | a fedoraproject machine to run it on? 19:21 <  mschwendt> | somebody to install it, probably edit the included yum.conf to point it to "local" mirrors 19:21 <  mschwendt> | and then we need a way to either run it periodically via cron or after a push 19:21 <       scop> | how long does a run take? 19:21 <        thl> | skvidal, do you have a machine for it? 19:22 <        thl> | skvidal, I can ask Sopwith for one that could do that, too 19:22 <  mschwendt> | scop: half an hour on a slow machine 19:23 <   skvidal> | thl: it can run on extras64 once it has been updated 19:23 <        thl> | could we run it after repo push? 19:23 <       scop> | mschwendt, probably too much to be included in the push scripts then 19:23 <        thl> | skvidal, k, great 19:23           <-- | warren has quit (Read error: 104 (Connection reset by peer)) 19:23 <  mschwendt> | scop: why? the push script could run it via atd 19:23 <       scop> | mschwendt, true 19:23 <  mschwendt> | the script uses a lockfile, so it doesn't run more than once 19:24 <       scop> | that'd work for me 19:24 <         thl> | do we want to run after each push or every day at a specific time? 19:24 < mschwendt> | thl: repo integrity is important 19:25 <        thl> | sure :-) 19:25 <         thl> | so every day at a specific time? 19:25 <   mschwendt> | I think you misunderstood me 19:25 <         thl> | ? 19:25 <        scop> | clearly after each push IMO 19:25 <   mschwendt> | the script needs a fully synced repository, so it doesn't fail downloading broken metadata 19:26 <        scop> | so add it as the last item of extras-push-all (after the rsync), running against the private buildsys repo copy, via atd? 19:26 <   mschwendt> | when running at an arbitrary time, it may be confronted with an incompletely sync repo 19:26 <   mschwendt> | s/sync/synced/ 19:27 <         thl> | okay; well let's handle the details via mail 19:27 <         thl> | skvidal, what's the status of extras64 update 19:27 <     skvidal> | two items outstanding 19:28 <     skvidal> | 1. coordinating with dcbw so we'll be around at the same time 19:28 <     skvidal> | 2. making sure the two bugs outstanding in mock are fixed before pushing out a new mock release 19:28 <    skvidal> | dcbw is out of the area, iirc, for this weekend so it won't happen then 19:28 <    skvidal> | and the mock stuff I hope to close out tomorrow 19:29 <        thl> | okay; then we'll revisit this item after the update is done 19:29 <    skvidal> | okie doke 19:29 <        thl> | okay for everybody 19:29           --- | thl has changed the topic to: FESCo Meeting -- Weekly sponsorship nomination 19:29 <        thl> | anyone? 19:30 <    skvidal> | doesn't sound like it 19:31            --- | thl has changed the topic to: FESCo Meeting -- Security Proposal 19:31 <        thl> | mschwendt, f13 ? 19:32 <  mschwendt> | not my item, sorry 19:33           <-- | M0ppi has quit ("Segmentation fault") 19:33 <        thl> | mschwendt, sorry, I got the impression that you were interested in it 19:33            --> | warren (Unknown)  has joined #fedora-extras 19:33 <        thl> | well, I'll try to start a discussion on fedora-extras-list for that 19:33 <        thl> | then we really should look at it at the next meeting 19:34           --- | thl has changed the topic to: FESCo Meeting --  Build dependency exceptions 19:34 <        thl> | spot's item 19:34 <        thl> | does anyone know the details? scop? 19:34 <    skvidal> | what's this about? 19:34 <  mschwendt> | it's about BuildRequires python perl gcc-c++ and so on 19:34 <        scop> | frequently reoccurring topic about "forbidden" build dependencies 19:34 <  mschwendt> | they should not block a package from being approved 19:35 <    skvidal> | 'forbidden'? 19:35 <  mschwendt> | the reviewing guidelines say they MUST NOT be put into a spec file 19:35 <       scop> | http://www.redhat.com/archives/fedora-extras-list/2006-March/msg01484.html 19:35 <       scop> | see the last paragraph 19:35 <  mschwendt> | that should become a SHOULD NOT -- with a bit of added common sense 19:35 <    skvidal> | ah 19:35 <     skvidal> | sorry 19:36 <  mschwendt> | packagers doing  BR gcc-c++  only make it complicated to build this package with a different gcc (e.g. gcc42-c++) 19:36           --> | Eitch (Hugo Cisneiros)  has joined #fedora-extras 19:36 <       scop> | shrug, those need to be parallel installable anyway 19:36           --> | Sopwith (Elliot Lee)  has joined #fedora-extras 19:36 <  mschwendt> | scop: why enforce a specific compiler package name? 19:36           <-- | Sopwith has quit (Read error: 104 (Connection reset by peer)) 19:37 <   thomasvs> | if libtool wasn't so silly to put in *hard requirements* on gcc-c++ and fortran we probably wouldn't be having this problem 19:37 <       scop> | mschwendt, to stop confused packagers bringing up the silly topic over and over again? 19:37           <-- | giallu has quit (Read error: 110 (Connection timed out)) 19:37 <  mschwendt> | scop: do you want to see BR make sed grep tar bzip2? 19:37 <  mschwendt> | BR rpm rpm-build? 19:37 <   thomasvs> | mschwendt: no, those are already required by rpmbuild 19:37 <       scop> | mschwendt, are you serious? 19:38 <   thomasvs> | mschwendt: the core of the argument is that there are some people that feel that you shouldn't automatically assume *any* programming language, except maybe C 19:38 <        scop> | you said "common sense", and "should not block" 19:38 <  mschwendt> | then why do we have a minimal build environment? 19:38 <   thomasvs> | gcc-c++ for one thing pulls in quite a bit more, and also has ABI problems between versions 19:39 <   thomasvs> | mschwendt: I have no idea why people feel gcc-c++ should be in that minimal env, and e.g. python shouldn't 19:39 <   mschwendt> | gcc-c++ _is_ in there 19:39 <   thomasvs> | mschwendt: yes, in what extras considers minimal. 19:39 <  mschwendt> | Core has even more stuff in there 19:39 <   thomasvs> | I have never heard a good reason why though, except that a lot of configure scripts break because libtool puts in a really stupid macro 19:40 <       scop> | also, the buildsys and the documented minimal env are not in sync 19:40 <   thomasvs> | given the relatively few number of c++ packages, I still don't see why it's part of minimal :) 19:40              * | thl still wonders why autofoo is installed by default in the buildsys 19:41 <    thomasvs> | but I'm looking forward to putting mono and java in as part of the minimal buildreqs! 19:41 <   thomasvs> | thl: I see no need for that either 19:41 <   mschwendt> | so, what do we discuss? that packagers should be permitted to add arbitrary BR? 19:41 <    thomasvs> | mschwendt: I think anything not pulled in by rpm-build should be ok to add 19:42 <    thomasvs> | I don't see where else to sensibly draw the line 19:42 <        scop> | rpm-build pulls in perl, for very questionable reasons 19:42 <        scop> | BR perl is what ignites these discussions most of the time 19:42 <    thomasvs> | scop: yep, that's too bad, but if that's the practical situation ... 19:42 <   thomasvs> | (can someone verify for me that the minimal env also pulls in a fortran compiler ?) 19:43 <   thomasvs> | (and can someone mention any fortran code we ship ?) 19:43 <       scop> | please stop the noise 19:43           <-- | jcollie has quit ("Leaving") 19:43 <  mschwendt> | thomasvs: do you refer to direct requirements of rpm-build or recursive dependencies? ;) 19:43 <        thl> | well, can somebody work out a proposal/solution for the problem? 19:43 <    thomasvs> | mschwendt: recursive.  "yum install rpm-build" -> everything available then is fine IMO 19:44 <   mschwendt> | thomasvs: then we need a new ExceptionList again 19:44 <        scop> | getting off topic.  do we have forbidden build dependencies or not? 19:45 <        scop> | whatever they are 19:45 <   mschwendt> | common sense should suffice -- where it doesn't, everything is lost anyway 19:45              * | thl repeats: can somebody work out a proposal/solution for the problem? 19:46 <         thl> | seems we are stucked atm 19:46              * | scop repeats: http://www.redhat.com/archives/fedora-extras-list/2006-March/msg01484.html 19:46 <        scop> | see the last sentence 19:46 <        scop> | (the "I'd have" part) 19:47 <         thl> | hmm; that would allow "BR: gcc" afaics 19:47 <   thomasvs> | scop: I agree with that, I guess what's in the list is a separate point 19:47 <        thl> | but yeah, it's okay 19:47 <        thl> | I can live with that 19:47 <       scop> | yes, and not scheduled for discussion today 19:47 <  mschwendt> | packagers should think twice before adding unneeded BR, easy as that 19:48 <        thl> | does anyone dislike the last sentence of http://www.redhat.com/archives/fedora-extras-list/2006-March/msg01484.html 19:48 <        thl> | otherwise I suggest we go for that one for now 19:48 <   thomasvs> | +1 19:48           <-- | Eitch has quit ("brb") 19:48 <  mschwendt> | I think some reviewers also try to make packagers eliminate redundant recursive BR, so this entire topic is a waste of time 19:49 <        thl> | well, seems some people wat to discuss it 19:50 <         thl> | so let's go for the last sentence of http://www.redhat.com/archives/fedora-extras-list/2006-March/msg01484.html 19:50 <        thl> | scop, can you change it in the wiki please? 19:50 <       scop> | will do 19:50 <         thl> | scop, thx 19:50 <   XulChris> | that was easy ;-) 19:50 <         thl> | okay, moving on 19:50 <         thl> | does anyone want to discuss and other items from the schedule? 19:51              * | thl needs to leave soon 19:51 <    XulChris> | any news on a games sig list? 19:51 <         thl> | XulChris, warren had planed to create it iirc 19:52 <         thl> | just fyi: the games SIG want's a separate mailinglist 19:52 <         thl> | that okay for everyone? 19:52 <      warren> | XulChris, list is created, will give it to you soon 19:52 <    XulChris> | what would it be called? 19:52 <      warren> | fedora-games-list 19:52 <    XulChris> | fedora-sig-games? 19:52 <      _wart_> | warren:  Woohoo!  thanks! 19:52 <    XulChris> | ok cool 19:52 <      warren> | it isn't setup yet 19:52 <      warren> | give me 30 minutes 19:52 <         thl> | k, anything else? 19:53              * | thl will close the meeting in 60 19:53 <        thl> | anyone interested to write the summary for the list? 19:53             * | thl will close the meeting in 30 19:53             * | thl will close the meeting in 15 19:53             * | thl will close the meeting in 10 19:54 <        thl> | MARK: Meeting end 19:54 <        thl> | thx everyone 19:54 <        thl> | cu next week