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