Extras/SteeringCommittee/Meeting-20060323

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

Important topics:

forward and help (hint: non-FESCo-Members are also invited) kernel modules now; no major problems showed up yet (I'm sure some problems will) summary; then discussing this topic probably is easier packages might have it; some of those bite us in the past already things like rpmlint checks some of what is probably needed there that area and use some existing tools are orphaned, obsoleted, whatever "dead.package" in it. Put a short explanation in it why it was removed. removed from Extras 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)
 * 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
 * Kernel module standardization
 * the repo-that-must-not-be-named uses the new scheme for several
 * 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
 * automatic checks for packages post-build
 * ensc has ideas how to check for hardcoded rpath's; a lot of x86_64
 * we could check for things like orphaned directories or extend it for
 * notting sent mail to fedora-buildsys list a few weeks ago describing
 * thl will send a mail to some rh folks; maybe we can work together in
 * Free Discussion related to Fedora Extras
 * old packages still in cvs but not in the repo anymore because they
 * remove all files from the devel repo and place a file
 * moving packages from Extras to Core and taking care that they are
 * Christians script now checks for it
 * the Core developer that imports the package into rawhide should open

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.