Extras/SteeringCommittee/Meeting-20060720

2006 July, 20 FESCo Meeting

Meeting Summaries are posted on the wiki at: http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings

Attending

• thl (Chair)
• bpepple
• tibbs
• scop
• dgilmore
• spot
• rdieter
• abadger1999
• warren

Summary

• Mass Rebuild will start around FC'6T3.
• Minimal buildroots will be in place by then.
• check-rpaths (warning only) and check-buildroot will be additional checks incorporated into buildsystem.
• dgilmore put in charge of coordinating these changes.
• Future Election - deferred for a week. Discussion will start on extras-list.
• Ctrl-C problem. Still a problem. OTRS ticket updated and infrastructure people poked.
• Encourage Extras Reviews
• Starting to have a backlog of bugs blocking FE-NEEDSPONSORS.
• Most packagers there appear to only have one package and no reviews. So no one is willing to sponsor until they show more knowledge.
• Mentorship is a possible solution, where someone is sponsored with the idea that the mentor will help them learn rather than they know what to do right off the bat.
• Comaintainership: thl is preparing an email but it still needs someone to drive it forward.
• AWOL Maintainer Policy. Completed and available at http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers
• Comps updating. FC6's installer will allow additional repos but needs entries into comps otherwise a package won't be available.
• _wart_ volunteered to spearhead writing a cron script to regenerate comps from the comps.xml.in file.
• thl will contact c4chris about scripting a report that lists packages not in comps.
• IPv6 - deferred jwb on vacation
• Packaging Committee Report:
• perl module template was updated to indicate which items are not necessary for noarch packages.
• Approve KMods
• Vote to allow kernel modules are okay to be reviewed for Extras as per the KMod guidelines.
• Approve em8300 at https://bugzilla.redhat.com/189400
• Approve iscsitarget, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197867
• Others in Extras: None have a statement as to why it's not in the upstream kernel which is a minimum for voting to approve.
• Some discussion of the merits of the kabi standard http://www.kerneldrivers.org but no resolution.

Log

(09:06:30) The topic for #fedora-extras is: "This is the Fedora Extras channel, home of the FESCo meetings and general Extras discussion. | http://fedoraproject.org/wiki/Extras | Next FESCo Meeting: 2006-07-20 1700 UTC"
(10:00:16) thl has changed the topic to: FESCo meeting in progress
(10:00:23) thl: Hi everybody!
(10:00:28) bpepple: hey.
(10:00:30) thl: Who's around?
(10:00:36) tibbs: I'm here.
(10:00:37) ***bpepple is around.
(10:00:37) ***jima sits back and watches
(10:00:51) ***scop is here
(10:01:17) ***dgilmore is here
(10:01:37) thl: k, then let's start slowly
(10:01:43) thl has changed the topic to: FESCo meeting in progress --
(10:01:54) spot: i'm here now.
(10:01:58) thl has changed the topic to: FESCo meeting in progress -- M{ae}ss-Rebuild
(10:02:07) thl: just FYI
(10:02:27) thl: f13 told me taht we should start some time around the release of FC6T3
(10:02:34) ***rdieter is here
(10:02:37) thl: that leaved some weeks for dicussions and plaing
(10:02:40) thl: planing
(10:02:52) dgilmore: thl  and we will have the minimal buildroots in place before then  i hope
(10:02:56) thl: but we should hurry up to get everything sorted out in time
(10:03:14) thl: dgilmore, we IMHO must have them in place before then
(10:03:24) dgilmore: thl: i think we must
(10:03:27) scop: it would be really nice to have check-rpaths and especially check-buildroot deployed in the builders before that
(10:03:34) dgilmore: but it looks like we will need to rebuild the builders
(10:03:48) rdieter: rebuild as in re-install?
(10:03:48) thl: scop, check-buildroot ACK
(10:03:58) dgilmore: rdieter: yep
(10:04:00) ***abadger1999 shows up
(10:04:03) rdieter: fun.
(10:04:11) thl: scop, check-rpaths -> not sure
(10:04:17) ***cweyl is here (rabble)
(10:04:20) thl: scop, it will break a lot of x86_64 packages
(10:04:26) dgilmore: the hammers are currently running fc3,  ppc1 fc4 ppc2 rhel4
(10:04:34) thl: scop, that will probably a lot of work to fix...
(10:04:43) f13: thl: FWIW the gcc changes look pretty good.  The C++ visibility stuff is hitting things like KDE though, and code changes are necessary
(10:05:03) thl: f13, k, thx
(10:05:10) scop: thl, a stopgap could be to have QA_RPATHS=0x0001 set in the environment
(10:05:29) scop: so it would be just logged
(10:05:36) thl: scop, okay, that might be an idea
(10:06:12) thl: who wants to make sure the stuff gets used on the builders?
(10:06:19) thl: any volunteers?
(10:06:28) thl: or does anyone don't like taht idea?
(10:07:04) rdieter: stuff as in the "check-*" stuff?  imo, good idea.
(10:07:16) thl: rdieter, yes, stuff as in the "check-*" stuff?
(10:07:23) ***warren here
(10:07:30) scop: is anyone here knowledgeable enough about plague/mock to have a clue what would it take technically?
(10:07:32) dgilmore: thl: i can do that.  i am going to get things started for rebuilding the builder machines in the infrastructure meeting this arvo,  so i can make sure its something that gets done then
(10:07:43) scop: dgilmore, thanks
(10:07:46) thl: dgilmore, k, thx
(10:07:54) thl: btw, just FYI again
(10:08:07) tibbs: Can someone also supply documentation on getting those checks into our local mock configs?
(10:08:21) thl: when mock get's updated the minimal buildroots for FC{345} also change
(10:08:41) scop: I know how to do that in mach, but not mock...
(10:08:58) thl: so things there might break in stable distros due to missing BuildRequires
(10:09:51) tibbs: After all of the Dell guy's rebuilds, things deserve to break at this point if they haven't been fixed yet.
(10:09:57) jima: those ought to crop up the next time the maintainer tries to build, i imagine.
(10:09:59) tibbs: (sorry, I've forgotten his name(
(10:10:06) jima: mdomsch
(10:10:06) scop: Matt Domsch
(10:10:26) thl: jima, yes, normally
(10:10:42) thl: k, is there anything else we nned to discuss for the rebuild?
(10:10:51) thl: scop, what packages really need a rebuild?
(10:10:58) tibbs: Did we agree to use a "needs.rebuild" flag file?
(10:10:59) scop: dgilmore, let me know if you need any help with the check-* stuff
(10:11:11) scop: tibbs, I think so, yes
(10:11:18) abadger1999: I believe we voted yes on that.
(10:11:32) dgilmore: scop: will do,  ill most likely need some pointers
(10:11:33) scop: and I volunteered and will take care of it when it's time
(10:12:05) dgilmore: scop: Ill set it up in one of my local build systems first
(10:12:29) scop: dgilmore, ok, BTW don't pull in the whole (fedora-)rpmdevtools package
(10:12:47) scop: it might add something that is not specified to be there in minimal buildroots
(10:13:42) dgilmore: scop: :)  ok,  want to email me what  exactly we need to make sure is in the build roots  or chat latter on irc about it?
(10:13:59) thl: back to the "what needs rebuilding" question. All arch packages? what about noarch packages?
(10:14:19) scop: dgilmore, let's chat a bit after this meeting, ok?
(10:14:27) rdieter: imo, noarch can probably be left alone (by default)
(10:14:31) dgilmore: scop: sounds good
(10:14:35) f13: thl: only arch specific.  Stuff compiled by gcc
(10:14:48) thl: rdieter, well, they should get a "needs.rebuild", too
(10:14:54) tibbs: Are any of the scripting languages getting a bump for FC6?
(10:14:55) f13: thl: for Extras, you only need to rebuild stuff that is built by gcc to pick up gnu.hash tables.
(10:14:58) thl: so maintainers have to delete them
(10:15:02) scop: everything is going to get a "needs.rebuild" flag
(10:15:14) jima: you don't need to bump the release for this rebuild, right?
(10:15:19) f13: tibbs: I think a new python is out there, but no word yet of making it the default python
(10:15:34) f13: jima: I don't understand that question.
(10:15:52) tibbs: The release needs to change when you rebuild.
(10:16:07) thl: jima, you need to bumo the release
(10:16:40) thl: bump
(10:16:54) jima: ah, ok
(10:17:16) thl: seems we discussed everything for today
(10:17:22) thl: regarding that topic
(10:17:40) thl has changed the topic to: FESCo meeting in progress -- Next FESCo future/election
(10:17:54) thl: abadger1999, got my mail? was it helpful?
(10:18:49) abadger1999: thl: Yes it was.  But I haven't had time to think about it this week :-(
(10:19:02) abadger1999: I should have time over the weekend.
(10:19:10) thl: abadger1999, no need to hurry
(10:19:21) thl: I'll move that down in the schedule
(10:19:31) abadger1999: I'll start by sending an email out with some ideas and we can discuss next week.
(10:19:47) thl: abadger1999, target date: End of august ?
(10:19:57) abadger1999: Sounds good.
(10:20:07) abadger1999: I'll get the ball rolling this weekend.
(10:20:17) thl: abadger1999, k, thx
(10:20:19) thl: moving on
(10:20:23) abadger1999: FESCO list or extras list the better place to discuss this?
(10:20:37) thl: #topic FESCo meeting in progress -- CTRL-C problem
(10:20:43) thl: abadger1999, extras-list
(10:20:46) abadger1999: 'kay
(10:20:52) thl has changed the topic to: FESCo meeting in progress -- CTRL-C problem
(10:21:17) thl: scop, did you hear anything from Sopwith or the infrastructure group again?
(10:21:18) scop: yep, I tested it, and it's still a problem
(10:21:25) scop: no word from anyone
(10:22:07) thl: scop, maybe we should update the OTRS ticket and poke people directly
(10:22:44) thl: scop, ticket is here: https://admin.fedoraproject.org/tickets/customer.pl?Action=CustomerTicketZoom&TicketID=34
(10:22:46) ***mmcgrath looks in
(10:22:54) scop: unfortunately from where I live, poking folks more directly than personal mail would be a bit hard, or expensive :)
(10:22:56) mmcgrath: I thought someone worked on that already?
(10:23:09) thl: scop, can you add some more infos there?
(10:23:09) scop: mmcgrath, it was not fixed though
(10:23:17) thl: scop, then I'll poke people
(10:23:23) mmcgrath: k, I'll make sure to bring it up at the meeting today.
(10:23:30) thl: mmcgrath, thx
(10:23:55) scop: I get a red "No Permission!" when trying to look at that ticket
(10:24:12) ***rdieter nods, glad not to be the only one.
(10:24:28) thl: mmcgrath ?
(10:24:44) mmcgrath: thats on the list of todo too.
(10:24:49) rdieter: maybe otrs only lets you view your own tickets.
(10:24:58) thl: rdieter, seems so :-/
(10:25:11) mmcgrath: thats the default.  there's a "company tickets" section that we're working to enable.
(10:25:21) scop: the problem description is at https://www.redhat.com/mailman/private/fedora-extras-steering/2006-July/msg00019.html
(10:25:38) scop: (private archive though)
(10:25:40) thl: scop, k, I'll add that to the ticket
(10:25:44) thl: so let's move on
(10:25:58) thl has changed the topic to: FESCo meeting in progress -- Encourage Extras reviews
(10:26:11) tibbs: Pretty much the same as last week;
(10:26:17) thl: tibbs, that still on the schedule as "Priority 1 -- Look at it in every meeting"
(10:26:35) tibbs: I'm seeing some folks doing additional reviews, which is good, but there are a lot of things blocked on guidelines.
(10:26:36) thl: tibbs, shall I move it to "Priority 2"?
(10:26:55) tibbs: thl: I think that would be best.  I'm still paying attention to it constantly
(10:27:03) tibbs: but there's not all that much that I can do at this point.
(10:27:17) tibbs: We are starting to see things pile up on FE-NEEDSPONSOR
(10:27:25) tibbs: that's going to be the big bottleneck moving forward.
(10:27:41) thl: hmmmm
(10:27:51) thl: seems we need more or more active sponsors
(10:28:14) thl: but we can't make everyone a sponsor :-/
(10:28:24) tibbs: Or reduce the threshold for sponsorship.
(10:28:33) thl: tibbs, how?
(10:28:42) tibbs: thl: I don't know.
(10:28:52) tibbs: It's rare to see those folks doing reviews.
(10:29:09) bpepple: tibbs: Have we identified why there are so many FE-NEEDSPONSOR?  Last time I looked, it was mainly due to the submitters only having 1 package, which isn't a good indicator of knowledge.
(10:29:39) tibbs: bpepple: I could probably add up some stats by hand; c4chris might have something more automated he can do.
(10:29:51) tibbs: Most of it does seem to be only one package.
(10:29:56) bpepple: Adding more sponsors might not solve the problem.
(10:30:42) tibbs: I don't know what will.  Perhaps turning sponsorship into more of a mentoring thing,
(10:31:04) tibbs: where instead of demonstrating your knowledge up front, you work with someone who will eventually decide you're ready.
(10:31:32) abadger1999: tibbs: I like that idea.
(10:31:37) tibbs: That's sort of happening already,
(10:31:47) bpepple: And have the mentor be a co-maintainer.
(10:31:58) tibbs: some folks are saying "we'll look over your packages, and one of us will approve you when we agree that you're ready".
(10:32:20) cweyl: maybe a two-tier sponsorship system?  the "normal" process for people who intend to become regular, general contributors, and a "one-off" process where people who only have interest in getting one particular package in extras? (I know some @redhat seeking sponsorship for bits just like that right now)
(10:33:13) warren: Oh.  I intended on dealing with the @redhat people one-on-one myself.
(10:33:17) ***cweyl is just brainstorming
(10:34:03) thl: I like the idea with co-maintaining
(10:34:09) thl: but let's stop here
(10:34:10) tibbs: warren: You approved one guy I was intending to sponsor; we weren't sure if you were going to comment on his review ticket.
(10:34:25) thl: and move on, otherwise we'll run late again
(10:34:33) warren: tibbs, sorry about that confusion.
(10:34:36) tibbs: I'm fine with moving on; we can discuss forther on extras-list.
(10:34:41) thl: k
(10:34:43) bpepple: tibbs: Cool.
(10:34:53) thl has changed the topic to: FESCo meeting in progress -- Co-maintainership
(10:34:57) thl: just FYI
(10:35:05) tibbs: Nice segue there.
(10:35:05) thl: I'm preparing a mail on that
(10:35:24) thl: might still take some days to finish...
(10:35:32) thl: so let's ignore that for today
(10:36:00) jcollie[work]  [n=jcollie]  entered the room.
(10:36:08) thl has changed the topic to: FESCo meeting in progress --  AWOL Policy
(10:36:16) thl: this is in a proper place now
(10:36:19) tibbs: http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers?highlight=%28Extras%2FPolicy%29
(10:36:44) thl: anything else that needs work there?
(10:36:45) tibbs: Crap, just http://fedoraproject.org/wiki/Extras/Policy/AWOL_Maintainers
(10:36:53) thl: or can I remove it from the schedule for now?
(10:36:57) tibbs: I created the Extras/Policy hierarchy for things like this.
(10:37:00) thl: we can fine tune it later
(10:37:06) thl: tibbs, thx for that
(10:37:25) tibbs: I made the requested changes to point to the vacation page and process documents.
(10:37:42) tibbs: Anyone should feel free to fix my crap wiki formatting.
(10:37:49) f13: thl: ping
(10:37:54) abadger1999: tibbs: Thanks!
(10:37:59) thl: f13, pong
(10:38:00) f13: thl: subject that should be discussed:  Comps updating
(10:38:24) f13: FC6's installer now allows you to add repos at install time, such as Extras.  It uses comps in the repo to sort packages into groups.  If the package isn't in comps, its not available at install time.
(10:38:40) thl: hmmm
(10:38:40) f13: so as we get closer to release, the Extras comps should really be beat into shape and missing packages should be dealt with.
(10:38:54) thl has changed the topic to: FESCo meeting in progress --  Comps updating
(10:39:03) tibbs: Perhaps we need another report indicating packages not yet in comps.
(10:39:07) ***dgilmore needs to add my packages to comps
(10:39:17) thl: tibbs, that was my first though aswell
(10:39:25) spot: +1 to tibbs.
(10:39:27) thl: we probably should ask c4chris for help
(10:39:36) tibbs: I'm not sure how to add my packages to comps; I edited the files but the package never showed up.
(10:39:38) rdieter: tibbs++
(10:40:05) rdieter: stupid question: is this comps updating business documented anywhere?
(10:40:26) thl: anyone who is interested in driving this foward? e.g. ask c4chris for help or create a script?
(10:40:58) thl: rdieter, probably somewhere, but the wiki sometimes is a great mess..
(10:41:07) thl: rdieter, http://fedoraproject.org/wiki/Extras/Schedule/ExtrasCompsXml
(10:41:12) f13: rdieter: tibbs: so the comps.in file gets updated, but I think jeremy or somebody has to 'make' it to do the translations.
(10:41:19) f13: that happens irregularly
(10:41:42) tibbs: Perhaps our friend cron could help us?
(10:41:43) thl: scop, could that be integrated into the push scripts?
(10:41:56) tibbs: I recall that one problem was making sure the file was well-formed.
(10:42:00) thl: yeah, cron might be a good idea, too
(10:42:16) scop: cron++
(10:42:25) tibbs: Is a pass through xmlwf sufficient?
(10:42:34) scop: (and repoview should really be cron'd as well...)
(10:42:57) dgilmore: cron ++  with a check  so it only gets updated if changed
(10:43:15) dgilmore: repoview is part of the push scripts right?
(10:43:18) jima: dgilmore: yeah, else the mirrors are all going to be continually updating it.
(10:43:25) dgilmore:  thats where it should stay
(10:44:17) thl: well, one step at a time
(10:44:45) thl: who want's to look after a cron job for the comps updateing?
(10:45:14) thl: nor all at once please :)
(10:45:38) thl: k, so nobody today
(10:45:43) tibbs: I have no access to do anything like that.
(10:45:50) thl: abadger1999, be sure to mention it in the report
(10:45:58) green_ [n=green]  entered the room.
(10:45:59) thl: maybe someone outside of fesco is interested
(10:46:05) _wart_: thl:  I'll volunteer
(10:46:13) _wart_: I'd really like to see it fixed.
(10:46:23) jorge__ [n=jorge]  entered the room.
(10:46:26) thl: _wart_, k, thx
(10:46:42) thl: _wart_, do you have access to the servers?
(10:46:47) _wart_: Nope.
(10:46:50) thl: who has? scop?
(10:47:11) scop: if I have, all other signers do too
(10:47:23) scop: I don't even know where comps is hosted, never used it...
(10:47:39) thl: _wart_, seems it's a hard job :)
(10:47:55) dgilmore: _wart_: you can always  write a scipt to do it  and contact the infrastructure people  to implement
(10:47:59) thl: _wart_, please feel free to poke around and ask people how to get access (or who has access)
(10:47:59) _wart_: thl:  I'll still volunteer to do whatever I can to help fix it.
(10:48:25) thl: _wart_, I'll put it on the schedule
(10:48:37) thl: _wart_, if you get stuck or need help ping me
(10:48:40) _wart_: I'll start by contacting Jeremy, who has been managing it by hand so far.
(10:48:47) thl: _wart_, good plan
(10:48:51) thl: k, let's move on
(10:49:16) thl: ehh, no
(10:49:35) thl: I'll contact c4chris and ask him to enhance his scripts
(10:49:45) thl: so they check if all packages are listed in comps
(10:49:48) thl has changed the topic to: FESCo meeting in progress -- IPv6 Support in Extras
(10:49:59) thl: jwb not around
(10:50:03) thl: was his topic iitc
(10:50:04) thl: iirc
(10:50:11) bpepple: thl: On vacation.
(10:50:18) ***thl will skip it
(10:50:18) dgilmore: _wart_: if you need help to get a script  put in place ping me  and ill poke people
(10:50:26) _wart_: dgilmore:  Thx.
(10:50:27) f13: hrm
(10:50:31) thl has changed the topic to: FESCo meeting in progress -- spot, Packaging Committee Report
(10:50:32) f13: we talked about this in the packaging meeting
(10:50:42) scop: one thing from outside the agenda which was already forgotten last week: kmod approval(s?)
(10:50:47) scop: eg https://bugzilla.redhat.com/189400
(10:51:01) thl: scop, I added it to the schedule some minutes ago ;-)
(10:51:01) f13: and we thought (un voted) that in reviews we should ask if the software supports ipv6, and if it doesn't, the packager should contact upstream about it.
(10:51:09) f13: other than that, we'd be hands off on the subject
(10:51:21) scop: thl, sneaky :)
(10:51:27) spot: the only item to report from this weeks packaging meeting: Comments will be added to the perl template to more clearly indicate items in the template that are not necessary for noarch packages.
(10:51:49) scop: already done in rpmdevtools CVS, will be in 5.0
(10:52:01) thl: scop, spot, k, thx
(10:52:12) thl has changed the topic to: FESCo meeting in progress -- Weekly sponsorship nomination
(10:52:17) thl: any nominations?
(10:52:35) scop: btw dir ownership and Group tags were also discussed in the packaging committee meeting, with no resolution yet
(10:53:03) thl: BTW and FYI: you can always nominate new sponsors by mail, too; just send me the name, nich, e-mail adress and I'll forward it to fesco-list and/or sponsors-list
(10:53:20) ***spot goes afk, starving
(10:53:24) giallu left the room (quit: "Leaving").
(10:53:30) ***thl will move on in 15 seconds
(10:53:49) thl has changed the topic to: FESCo meeting in progress -- approve kmod's
(10:54:06) thl: k, there are two kmod maintainers asked for approval
(10:54:22) thl: scop, em8300 at https://bugzilla.redhat.com/189400
(10:54:47) thl: seems okay for me
(10:54:49) thl: so +1
(10:55:03) ***scop probably shouldn't vote :)
(10:55:28) thl: maybe we should lay down why this proceedure is needed to the new fesco members
(10:55:35) tibbs: As much as I understand the criteria, it seems fine to me.
(10:55:40) thl: actually, it's new to everyone
(10:55:52) thl: we didn#t run into the situation yet
(10:56:09) dgilmore: any patenet issues in regards to mpeg ?
(10:56:12) thl: but this "specific approval" mostly is to avoid conflicts
(10:56:32) thl: and to poke people and upstream to get their stuff into the vanilla kernel
(10:56:51) thl: and to avoid stupid kmod's in extras in general
(10:57:00) scop: the hollywood+/dxr3 is a hardware mpeg decoder
(10:57:18) scop: there is no mpeg stuff in the em8300* packages
(10:57:28) scop: it's really like what dvb modules are for dvb cards
(10:57:37) thl: dgilmore, there are probably other kmod in the vanilla kernel already (iirc)
(10:58:00) thl: (for similar devices)
(10:58:05) rdieter: looks good, +1
(10:58:07) thl: so it's probably okay
(10:58:13) dgilmore: thl: i realise that
(10:58:24) bpepple: I don't see any problems. +1
(10:58:40) thl: k, I consider it approved then
(10:58:41) tibbs: +1
(10:58:46) abadger1999: +1
(10:58:49) thl: the other module is
(10:59:08) dgilmore: +1
(10:59:20) thl: iscsitarget, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197867
(10:59:20) tibbs: Don't we need seven votes?
(10:59:49) scop: is there a vote count in effect in the first place in fesco?
(11:00:06) thl: scop, not that I'm aware off
(11:00:18) scop: I'm not aware of that either
(11:00:20) thl: scop, we just follow common sense mostly
(11:00:36) cweyl: thl: the "if no one screams" rule? :)
(11:00:51) rdieter: aaahhhh!!!
(11:00:52) thl: cweyl, yes, that probably describes it well ;-)
(11:01:15) thl: buuuuuu !!!
(11:01:41) thl: tibbs, do we want to get that stuff more formalized?
(11:01:46) rdieter: I'm ok with bz197867 too, +1
(11:02:04) thl: btw, O'm okay with #197867, so a +1 from me
(11:02:06) tibbs: thl: I don't want to make waves; I was just wondering what accepted criteria for approval are.
(11:02:20) tibbs: I'm concerned about the ISCSI target.
(11:02:32) tibbs: If it's not acceptable for upstream, are we sure we want it?
(11:02:48) thl: "at least seven votes" would mean that we can't run meetings without six members or less
(11:02:55) thl: and in the past we ofter were six or less
(11:03:05) f13: hrm, somebody was asking about that today
(11:03:12) thl: tibbs, your concers are valid imho
(11:03:17) f13: since we support iSCSI targets in anaconda now, to test we need some target software
(11:03:30) thl: tibbs, but from all I can see it seems they are working on something better to get upstream
(11:03:47) tibbs: If someone relies on it, though, and the upstream kernel does eventually get the "better" support, where does that leave us?
(11:03:53) thl: tibbs, but it seems some people are still interested in iscsitarget
(11:04:40) tibbs: I guess if everything is well-disclaimered it's OK.  The maintainer has indicated he'd do that.
(11:04:44) thl: f13, is the iSCSI stuff in RHEL?
(11:05:05) f13: thl: -EUNKNOWN
(11:05:31) f13: thl: I don't think so, since RHEL5 right now is mostly just FC6 bits.  I don't see an iscsi package for 5E
(11:05:50) scop: I'd be inclined accept it now, and when there's a distro version whose all kernels provide "better" things, drop it from that distro version onwards
(11:06:10) thl: scop, sound like a good plan
(11:06:12) f13: worksforme
(11:06:15) tibbs: I agree, as long as users know this.
(11:06:17) thl: so still a +1 from me
(11:06:20) tibbs: +1
(11:06:24) scop: +1
(11:06:24) bpepple: scop: sounds good.
(11:06:35) rdieter: +1 (still)
(11:06:39) bpepple: +1
(11:06:43) warren: +1 (doesn't hurt anyone except users)
(11:06:48) abadger1999: +1
(11:06:55) thl: k, accepted
(11:07:23) thl: does anyone want to discuss any Priority 2 or Priority 3 items?
(11:07:42) mdomsch [n=mdomsch]  entered the room.
(11:07:53) thl has changed the topic to: FESCo meeting in progress -- free discussion around Extras
(11:07:55) tibbs: We only talk about kernel modules after a reviewer has approved them, right?
(11:08:07) thl: tibbs, no, before the review starts
(11:08:25) thl: to avoid that people have work in the first place in case it's not accepted
(11:08:32) thl: em8300 was a sepcial case
(11:08:34) tibbs: Did the committee already discuss sysprof-kmod and the asterisk thing?
(11:08:41) tibbs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191745
(11:08:43) thl: tibbs, nope
(11:08:54) tibbs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177583
(11:09:04) thl: tibbs, is there a statement yet why the stuff is not upstream?
(11:09:11) tibbs: zaptel-kmod (the latter) is already being reviewed.
(11:09:25) thl: without such a statement I'm not going to approve kmod's
(11:09:36) rdieter: thl++
(11:09:49) scop: ack
(11:09:50) tibbs: I'll ping on those bugs and make sure they have the necessary info in them.
(11:09:56) scop: one more thing about kmods
(11:10:12) scop: what do people think about shipping them in devel?
(11:10:27) thl: tibbs, fyi, from http://www.fedoraproject.org/wiki/Packaging/KernelModules
(11:10:36) thl: "Besides rules around the packaging there is one additional *before* you start packaging a kernel module for Fedora Extras: Open a Review bug in [WWW]  http://bugzilla.redhat.com and ask FESCo via fedora<AT>leemhuis<DOT>info for permission if this module is allowed for Extras. This requires that you give at least the following informations:"
(11:10:49) thl: tibbs, point them there
(11:10:51) rdieter: why not in devel?  I'd say it's up to the maintainer.
(11:10:55) scop: following rawhide kernels there would be a non-trivial amount of work
(11:11:01) Sopwith [n=sopwith]  entered the room.
(11:11:16) scop: and I'm afraid that they'll end up as frequent visitors in the devel broken deps reports
(11:11:17) ***thl wonders if we need a FE-KMODNEEDSAPPROV blocker bug
(11:11:32) thl: scop, I think we don#t need them atm
(11:11:39) f13: the kmod stuff, I wouldn't want to see any of that get approved / voted on until the kabi stuff gets worked in.
(11:11:44) thl: scop, we should have them when plague supports automatic rebuilding
(11:11:46) tibbs: thl: I'll set it up if folks think so, but I don't think it's needed.
(11:11:47) cweyl: thl: +1 (rabble).  we block everything else to track them
(11:11:48) f13: that could really change the aspect of kernel module packaging.
(11:11:53) dgilmore: im 90% sure that the zaptel-kmod  submitter was asked for a reason its not upstream
(11:12:46) thl: f13, we mostly ignore the kabi stuff for extras atm afaics
(11:12:59) tibbs: dgilmore: You're correct.  He got a "read" on their intentions but no direct statement.
(11:12:59) thl: f13, the fedora-kernels don#t provide a stable abi in any case
(11:13:19) thl: f13, there was some discussion about that in earlier meetings and on the list
(11:13:47) scop: I think we already have enough barriers for kmods
(11:13:47) thl: f13, any if something changes we can follow that
(11:13:54) thl: scop, agreed
(11:14:04) thl: and we waited very long already
(11:14:07) tibbs: Any good reference for kabi?
(11:14:09) thl: we should start with them
(11:14:26) thl: tibbs, http://www.kerneldrivers.org/
(11:14:50) ***thl looks at his watch
(11:14:53) thl: quite late already
(11:15:03) scop: note also that kmods are already "sandboxed" within their respective kernel versions, so changing things shouldn't be much of a problem
(11:15:40) thl: anything else on this topic?
(11:15:44) thl: any other topics?
(11:15:52) thl: otherwise I'm going to close the meeting soon
(11:16:13) ***thl will close the meeting in 30 seconds
(11:16:35) ***thl will close the meeting in 10 seconds
(11:16:46) thl: -- MARK -- Meeting End
(11:16:52) thl: thx everybody
(11:16:54) tibbs: Who will move AWOL policy to the completed issues?
(11:17:03) thl: tibbs, I'll do that
(11:17:11) tibbs: Cool, actual progress!
(11:17:19) scop: :)
(11:17:54) 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-07-27 1700 UTC
(11:18:04) bpepple left the room.
(11:18:31) thl: btw, the list of priority 1 task is a bit shorter now
(11:18:43) thl: hopefully the next meetings are a bit less hectic
(11:19:12) f13: thl: the Fedora kernel is providing a KABI now
(11:19:24) thl: f13, I know
(11:19:25) f13: thl:  and rpm knows about it.
(11:19:41) thl: f13, but davej is not going to maintain a stable abi afaik
(11:19:48) f13: so, if we're going to approve any kernel packaging guidelines, it should be with that abi in mind.
(11:20:03) f13: thl: the ABI is at a subdir level.  SOme things change a lot less than others across updates
(11:20:38) f13: thl: while we're not going to make an effort to maintain a stable ABI, some stableness will be achieved anyway.  And there is no reason that we shouldn't try to use the kabi for what it is.
(11:20:55) f13: its not like we'd have to rebuild any more than doing it for each and every kernel spin.
(11:21:18) thl: f13, we probably should discuss this on the list again
(11:21:39) f13: thl: and wait for Jon Masters to get back from OLS so that he can participate
(11:21:51) thl: f13, but when this kabi stuff came up the people were not that glad about the idea for fedora afaics
(11:22:15) thl: f13, especially spot seemed to not like it that much
(11:22:27) thl: but if it works and we actually see how it works
(11:22:31) thl: it might be something different
(11:22:48) tibbs: I don't really see what the problem is.
(11:22:49) thl: f13, I simply had no real time or interest to look into it
(11:23:05) f13: I sat through a Lunch and Learn JCM did here in Westford, and now I understand it a lot better
(11:23:10) f13: it does make a lot of sense.
(11:23:19) f13: and jcm is very very motiviated to make it work.
(11:23:28) tibbs: We're seeing kernels come out with one-line fixes in them; it shouldn't hurt to say that the ABI doesn't change when that happens.
(11:23:34) thl: (and I'm not in the packaging comittee, so kmod decisions probably should now be handled by someone else)
(11:24:06) f13: tibbs: the abi is figured out automagically by looking at the ksysms table and checksumming at a directory level
(11:24:06) thl: f13, I think I understand the general direction
(11:24:13) tibbs: The kmod thing seems to be for Extras benefit, though.  Or are there plans to use it for Core?
(11:24:18) thl: f13, and I actually tend to like it
(11:24:35) thl: f13, but I had no time to really dig into it
(11:24:40) f13: tibbs: there aren't any more Core packages that are kernel modules, but it could hit RHEL
(11:25:04) thl: tibbs, yeah, an some hardware verndors might release driver updates this way