Extras/SteeringCommittee/Meeting-20060323

Summary

Present from FESCo: thl, thomasvs, ensc, jeremy, Sopwith

Important topics:

• Mass rebuild of Extras for FC5
• bugs for the remaining packages not yet rebuild were filed
• issue marked as done
• EOL Policy for FE
• thl did not find time for it; other are invited to bring that

forward and help (hint: non-FESCo-Members are also invited)

• Kernel module standardization
• the repo-that-must-not-be-named uses the new scheme for several

kernel modules now; no major problems showed up yet (I'm sure some problems will)

• Send email to pkg owners whenever someone else edits their pkg
• there seems to be a bit confusion what is needed
• thl> | Sopwith, let me look at the old discussions and write a

summary; then discussing this topic probably is easier

• automatic checks for packages post-build
• ensc has ideas how to check for hardcoded rpath's; a lot of x86_64

packages might have it; some of those bite us in the past already

• we could check for things like orphaned directories or extend it for

things like rpmlint checks

• notting sent mail to fedora-buildsys list a few weeks ago describing

some of what is probably needed there

• thl will send a mail to some rh folks; maybe we can work together in

that area and use some existing tools

• Free Discussion related to Fedora Extras
• old packages still in cvs but not in the repo anymore because they

are orphaned, obsoleted, whatever

• remove all files from the devel repo and place a file

"dead.package" in it. Put a short explanation in it why it was removed.

• moving packages from Extras to Core and taking care that they are

removed from Extras

• Christians script now checks for it
• the Core developer that imports the package into rawhide should open

a bug in bugzilla to inform the Extras maintainer; the developer also should remove the files in the devel branch of the Extras package (or find somebody that can do that for him if he has no access to extras cvs)

Full Log

19:00            --- | thl has changed the topic to: FESCo meeting in progress
19:00 <         thl> | hello everyone
19:00 <         thl> | who's around
19:00 <         thl> | ?
19:00              * | ensc
19:01              * | thomasvs is
19:01 <      giallu> | hi thl.. I'm here to syp what's a FESCO meeting is :)
19:01 <      giallu> | syp = spy :)
19:02 <         thl> | okay, let start with a free discussion until more fesco members turn up
19:02            <-- | daniel_hozac has quit ("reboot")
19:02            --- | thl has changed the topic to: FESCo meeting in progress -- Free discussion *related* to Fedora Extras
19:02 <         thl> | so guys, is there anything you want to discuss?
19:04 <         thl> | that is not much
19:04 <         thl> | ensc, what about the rpath stuff in the buildsys?
19:05            --> | daniel_hozac (Daniel Hokka Zakrisson)  has joined #fedora-extras
19:05 <        ensc> | dunno, whether it should be done there
19:05 <        ensc> | I would like a test-environment doing such tests
19:06 <         thl> | you mean after building?
19:06 <        ensc> | x86_64 is a big problem; almost every project whose maintainer does not use the Fedora libtool with generate /lib64 rpaths
19:06 <         thl> | or a scatch repo
19:06 <     jeremy> | thl: post-build would be best
19:06 <        ensc> | yes, after building
19:07 <        ensc> | there, you can check for things like orphaned directories too
19:07 <      jeremy> | notting sent mail to fedora-buildsys list a few weeks ago describing some of what is probably needed there
19:07 <         thl> | yeah, post-build sounds like a good idea to me, too
19:08 <         thl> | ensc, do we need to run it on the fedoraproject machines in that case?
19:08 <        ensc> | it should be run on an isolated machine
19:08 <         thl> | ensc, could you run it on your machine and post the results to fedora-extras-list?
19:09 <         thl> | ensc, why? (just out of curiosity)
19:09 <        ensc> | "it" does not exist yet ;)
19:10 <        ensc> | these packages will execute %scriptlets with root permissions
19:10 <         thl> | ahh, okay
19:10 <         thl> | ensc, could you try to create, test and run a script and show us the results?
19:10 <        ensc> | xen might be solution; vserver will not work due to things like the kernel %scriptlets
19:11 <        ensc> | there will be needed more than a script
19:11            --> | Sopwith (Elliot Lee)  has joined #fedora-extras
19:11 <        ensc> | you need some framework which starts the tests and evaluates the results
19:12 <     Sopwith> | Sorry I'm late...
19:12 <     Sopwith> | But it sounds like you're discussing a test harness for extras packages?
19:12            --> | bpepple (Brian Pepple)  has joined #fedora-extras
19:12            <-- | Eitch has quit ("Leaving")
19:12 <         thl> | Sopwith, yeah, checks for hardcoded rpath's
19:13 <         thl> | ensc, I don't think we have a machine for that atm
19:13 <        ensc> | (this was the entry point for the discussion; I want to extend it for things like rpmlint checks)
19:13 <         thl> | ensc, could you run it on one of yours for now?
19:13 <         thl> | ensc, to you have a x86_64 machine?
19:13 <        ensc> | no
19:14 <         thl> | I plan to setup xen on my router
19:14 <    Sopwith> | thl: We can get a machine for it, perhaps, but I'm interested in the software side of it because it bears on other stuff I've heard of. Would you send an e-mail to mspevack@redhat.com & timp@redhat.com letting them know what you're looking for?
19:14 <         thl> | that's a x86_64
19:14 <     Sopwith> | cc me if you like
19:14 <        ensc> | but as I said, there exist no "it" yet
19:14 <         thl> | ensc, Sopwith, I suggest we develop the "it" first and talk about the other details later
19:14 <        ensc> | ok
19:15 <    Sopwith> | thl: I'm asking you to send the e-mail because the "it" already may exist :)
19:16 <         thl> | Sopwith, okay, will do
19:16 <         thl> | might take some days
19:16              * | thl is still busy with some other stuff in another repo
19:16 <         thl> | okay, then let's go over to the schedule
19:16            --- | thl has changed the topic to: FESCo meeting in progress --  Mass rebuild of Extras for FC5
19:17 <         thl> | ensc, did you script file the bugs?
19:17 <        ensc> | yes
19:17 <         thl> | ensc, k, thx
19:17 <         thl> | well, is there anything else regading that topic
19:17 <         thl> | otherwise I'll mark it as "done"
19:18 <        ensc> | I wanted to use a seperate account for that but it seems the "blocks" field in initial reports is not available for everybody. So some bugs are not linked to the Tracker bug
19:18 <        ensc> | (perhaps 5-7 or so)
19:18 <         thl> | ensc, no big deal
19:18 <         thl> | k, moving on
19:19            --- | thl has changed the topic to: FESCo meeting in progress --   EOL Policy for FE
19:19 <         thl> | still no progress, sorry, didn't have time for it
19:19 <         thl> | maybe someone else is interested to driver this forward?
19:19 <         thl> | hint: non-FESCo-Members are also invited
19:20 <         thl> | well, okay, then it will have to wait
19:20            --- | thl has changed the topic to: FESCo meeting in progress -- Kernel module standardization
19:21 <         thl> | another well know repo uses the scheme developed in extras now
19:21 <         thl> | no real bugs have showed up until now
19:21 <         thl> | we'll see what happens in the next weeks
19:22 <     jeremy> | thl: good to hear
19:22 <         thl> | does anyone know if a update to plague 0.5 is planed for extras?
19:22 <         thl> | is that version capable to pass the kver and kvariants dynamicly?
19:23 <         thl> | okay, seem nobody knows that
19:23 <         thl> | moving on
19:24            --- | thl has changed the topic to: FESCo meeting in progress --  Encourage Extras reviews
19:24 <         thl> | I suppose we're still waiting for improved docs;
19:24 <         thl> | so I'll skip that
19:24            --- | thl has changed the topic to: FESCo meeting in progress --   Broken deps report
19:25 <         thl> | Sopwith, those should probably should run on a fedoraproject machine, too
19:25 <         thl> | Sopwith, I'll mention that in the mail we discussed earlier
19:25 <         thl> | mschwendt not here, so I'll skip this, too
19:25            --- | thl has changed the topic to: FESCo meeting in progress -- Weekly sponsorship nomination
19:25 <         thl> | anyone?
19:26            --- | thl has changed the topic to: FESCo meeting in progress -- Send email to pkg owners whenever someone else edits their pkg
19:27 <         thl> | Sopwith, your name is behind that topic on the schedule page
19:27 <     Sopwith> | hmm
19:27 <         thl> | We ignored it for a long time because we had more important things to do
19:27 <         thl> | but we should get this done sooner or later
19:27 <     Sopwith> | So compared to the baseline (having all maintainers subscribed to fedora-extras-commits), what needs to change?
19:28 <         thl> | the plan was this iirc:
19:28 <         thl> | If someone else changes one of my packages it get a additional mail directly to me
19:28            --- | mspevack_mtg is now known as mspevack
19:29 <         thl> | a lot of people probably don't read fedora-extras-commits
19:29 <     Sopwith> | nod... My main question is what is wrong with using fedora-extras-commits for this purpose? What is the fundamental problem that needs to be solved?
19:29 <      |Jef|> | thl: i have rules setup to flag it for references to my packages
19:29 <      |Jef|> | thl: but i certaintly dont "read" it
19:30 <         jwb> | |Jef|, would you read it if it came directly to your inbox?
19:30 <       |Jef|> | jwb: id find a way to filter it...
19:30 <         jwb> | yeah, exactly
19:30 <       |Jef|> | jwb: like i filter pretty much anything
19:30 <   thomasvs> | thl: probably just make it easy for someone to filter the ones that apply to you directly
19:31 <         thl> | Sopwith, the fundamental problem imho is: people should get a direct notice (e.g. not via mailinglist) if one of their pacakges is changed by someone else
19:31 <   thomasvs> | thl: ie, a simple description of the filter you need for this to work
19:31 <       |Jef|> | jwb: i look at commits folder about twice as ofter as i look in fedora-list
19:31 <    Sopwith> | thl: That's not a problem. :)
19:31 <         thl> | thomasvs, that would be an idea
19:31 <        jwb> | thl, that can be complicated though
19:31 <        jwb> | thl, what if you have "dual maintainers"
19:31 <         thl> | thomasvs, but people would need to set up filer manually
19:31 <     Sopwith> | That's something you want, but I guess I'm looking for justification of the want (so I can understand the various ways to meet it)
19:32 <         thl> | thomasvs, most of them won't do that
19:32 <       |Jef|> | jwb: lets face it.. i have nothing constructive to add to the initng discussion.. so reading over the commits for it would be...wasteful
19:32 <   thomasvs> | thl: ok, then mail people directly
19:32 <         thl> | Sopwith, let me look at the old discussions and write a summary
19:32 <     Sopwith> | One possible change would be having the package owner's e-mail address and account name listed in the header of all the commit message
19:32 <         thl> | then discussing this probably is easier
19:32 <         jwb> | |Jef|, yeah i do the same thing
19:32 <       |Jef|> | jwb: at worse.. id be compelled to make a smart ass comment about each commit
19:32 <    thomasvs> | (I have to admit that the reason *I* don't read that list is because it's too much traffic that does not pertain to me)
19:33 <     Sopwith> | That would make it easy for people to filter out commits to packages that they own, which they can't do right now (and /that/ is probably a problem)
19:33 <    thomasvs> | Sopwith: yep
19:33 <       |Jef|> | Sopwith: well not just "own"
19:34 <       |Jef|> | Sopwith: i sure as hell care about deps for the packages i "own"
19:34 <     Sopwith> | jef: Hmm, have you listed yourself on the Cc: list for those packages in owners.list?
19:34 <       |Jef|> | Sopwith: that would be silly
19:34 <       |Jef|> | Sopwith: because it makes too much sense
19:34 <     Sopwith> | hehe
19:35 <         thl> | Side note: There was also a discussion that sponsors should get mails if one of their packagers updates something in CVS
19:36 <         thl> | At least until the new packager has proven that he understoods packaging well
19:36 <         thl> | okay, let's move on
19:36 <       |Jef|> | Sopwith: as long as emails are generally applicable for a "watch list" having to add my address to CC in the ownerslist is a perfectly acceptable hurdle
19:36            --- | thl has changed the topic to: FESCo meeting in progress -- Free Discussion related to Fedora Extras
19:37 <         thl> | okay, is there something else that needs to be discussed?
19:37 <         thl> | what about the liboil story
19:38 <         thl> | e.g. package was moved to core
19:38 <         thl> | but the extras packager didn't notice that
19:38 <         thl> | how can we prevent that in the future?
19:38 <    thomasvs> | warren should have mailed matthias, no ?
19:38 <     Sopwith> | For starters, we need a tool that reports package overlaps between extras and core.
19:38 <         thl> | thomasvs, sure; maybe he did; we don't know
19:39 <         thl> | thomasvs, but mails get get lost of forgotten
19:39 <    bpepple> | thl: A bug should be opened for it?
19:39 <         thl> | thomasvs, we need something better
19:39 <   thomasvs> | thl: the mover to core could remove the CVS branches
19:39 <         thl> | Sopwith, we have such a tool since some days
19:39 <         thl> | thomasvs, yeah, I#d like something like that, too
19:39 <         thl> | jeremy, would that be possible?
19:39 <    thomasvs> | or better yet, remove the contents, and add a file like MOVED-TO-CORE
19:40 <         thl> | thomasvs, +1
19:40 <    Sopwith> | thl: Next step is to make sure that the right people get that report on a regular basis :)
19:40 <         thl> | Sopwith, we're working on that atm ;-)
19:40 <     jeremy> | thl: well, not all core packagers have access to extras cvs
19:40 <      jeremy> | adding it as a step to the new package process for core should be doable, though
19:41 <         thl> | jeremy, that would be great
19:41 <         thl> | something else regarding cvs:
19:42 <         thl> | we created FC5 branches in CVS for a lot of old packages that are orpahend or obsoleted
19:42 <         thl> | should they be deleted?
19:42 <         thl> | and the devel branch too?
19:43 <         thl> | jeremy, can the devel branch readded easily?
19:44 <     jeremy> | thl: probably.  and rather than delete the devel branch, possibly just a DEAD_PACKAGE marker
19:44 <      jeremy> | the problem with deleting it is that we lose history if it needs to come back
19:44 <         thl> | jeremy, k, sounds sane
19:44 <         thl> | jeremy, how could a DEAD_PACKAGE marker look like?
19:45 <         thl> | jeremy, just a file "dead.package"?
19:45 <         thl> | with a short explanation why it's dead in it?
19:45 <      jeremy> | works for me :-)
19:45 <         thl> | jeremy, the branch script would need to take care that no new branched are created later
19:45 <         thl> | but that's probably easy
19:46 <      jeremy> | well, allowing an older branch to be made is fine.  but not creating it when doing mass-branching is good
19:46 <         thl> | jeremy, exactly
19:46 <         thl> | k, that was all from my side
19:46 <      jeremy> | and the mass-branching is just a giant "for i in ..." script
19:46 <      jeremy> | if you get me a list of FC-5 branches which need to be killed, I can do that
19:47            <-- | dgregor has quit (Read error: 110 (Connection timed out))
19:47 <         thl> | jeremy, k, will try to find someone for that task ;-)
19:47 <         thl> | k, anything else?
19:47              * | thl will close the meeting in 60
19:48              * | thl will close the meeting in 30
19:48              * | thl will close the meeting in 15
19:48              * | thl will close the meeting in 5
19:48 <         thl> | MARK Meeting End
19:48 <         thl> | thx everyone
19:49            --- | thl has changed the topic to: This is the Fedora Extras channel, home of the FESCo meetings and general Extras discussion. | http://fedoraproject.org/wiki/Extras | Next FESCo Meeting: 2006-03-30 1800 UTC.