From Fedora Project Wiki
< Extras | SteeringCommittee
fp-wiki>ImportUser (Imported from MoinMoin) |
m (1 revision(s)) |
(No difference)
|
Latest revision as of 16:36, 24 May 2008
2006 August 10 FESCo
Meeting Summaries are posted on the wiki at:
http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings
Attending
- warren
- thl
- scop
- c4chris
- rdieter
- tibbs
- abadger1999
- bpepple
- dgilmore
Summary
Mass Rebuild
- Plan and questions are on the wiki at http://www.fedoraproject.org/wiki/Extras/Schedule/FC6MassRebuild
- Which packages need to be rebuilt
- sha256sum wasn't implemented in rpm so that isn't a factor
- Minimal buildroots have been implemented and will influence most packages
- Decided to go with the original plan: If a maintainer thinks a rebuild isn't required, they write a commit message that tells why not.
- Criteria that maintainers should apply is everything that isn't content should be rebuilt.
comps.xml
- The comps.xml script produced a big list:
http://www.fedoraproject.org/wiki/Extras/PackageStatus
- Commandline stuff should be included
- Packages should not be listed twice (confuses end users)
- nagmails will be sent so people know they have packages needing looking at
Legacy in buildroots
- Voted to activate legacy in buildroots and discuss maintainers responsibilities later
- tibbs will send out an email regarding maintainer responsibilities
- thl will document that FE branches in maintenance mode use Legacy packages
Ctrl-C Problem
- Async notification seems to be the only method to guarantee commit mail is sent
- Warren to take that up at the infrastructure meeting
Packaging Committee Report
- Python .pyos are to be included directly in packages instead of %ghosted
- c4chris is looking for a script to file bugzilla bugs for packages that need fixing
- scop has related changes to the python spec template prepared:
http://koti.welho.com/vskytta/pyspec.patch
Sponsorship Nominations
- rdieter was accepted
Misc
- FESCo members are now on both FAB and -maintainers
Future Elections
- Draft is at: http://www.fedoraproject.org/wiki/Extras/Schedule/ElectionDraft
- No objections to it yet. Wait one more week and then vote on acceptance
Package Database
- http://www.fedoraproject.org/wiki/Extras/Schedule/PackageDatabase
- http://www.fedoraproject.org/wiki/Infrastructure/PackageDatabase
- c4chris posted some brain dumps about this to extras-list
- c4chris joining infrastructure list so he can help coordinate between the extras community needs and infrastructure people doing the implementation
Free discussion
- zaptel-kmod and kmod policy in general
- Main question: Should kmods which have no intention of ever moving into the mainstream kernel be allowed in?
- If the package is well maintained and end-users accept the risk, why not?
- Fedora kernel developers have stated they will not debug kernel problems where users have kernel mods not from upstream installed
- thl to take the question to FAB
- http://fedoraproject.org/wiki/Extras/PackageEndOfLife documents how to remove a package from Extras (in case it is renamed upstream, moved to Core, etc)
After Meeting Discussion
- Too many items on the agenda per meeting? Items to discuss moving onto email instead of in the weekly IRC meetings
- Possibly move packaging committee report to email list
- To be able to discuss before the next packaging meeting, the FESCo meeting can't be directly after the packaging meeting. One would have to change times/dates
- Owners of a task update the status on the wiki before the meeting
- New sponsor discussion could happen entirely on list:
- Use two lists cvs-sponsors and fesco-list
Log
(09:55:13) ***warren here. (09:59:42) thl has changed the topic to: FESCo meeting in progress (09:59:46) thl: hi everyone (09:59:54) thl: who's around? (09:59:57) Rathann: o/ (10:00:01) Rathann: :> (10:00:07) ***c4chris__ is here (10:00:11) scop [n=scop] entered the room. (10:00:15) c4chris__ is now known as c4chris (10:00:18) drfickle left the room (quit: "Please do not reply to this burrito"). (10:00:24) rdieter: here. (10:00:36) tibbs: president. (10:00:41) warren: president? (10:00:56) tibbs: Used to say that in grade school. (10:00:59) c4chris: s/id// (10:01:07) c4chris: :) (10:01:24) thl: okay, then let's start slowly... (10:01:25) ***abadger1999 here (10:01:33) thl has changed the topic to: FESCo meeting in progress -- M{ae}ss-Rebuild (10:01:54) ***bpepple is here. (10:01:55) thl: scop, I assigned that job to you some days ago (10:02:06) scop: works4me (10:02:23) scop: but I've noticed a bunch of "fc6 respin" builds recently (10:02:29) thl: scop, there are some question still open; see http://www.fedoraproject.org/wiki/Extras/Schedule/FC6MassRebuild (10:03:02) thl: scop, can you work out the details that are still below "to be discussed" (10:03:17) thl: then we can discuss it in the next meeting (10:03:26) thl: (or now if someone prefers) (10:03:45) abadger1999: rpm signing w/ sha256sum seems to affect all packages (10:03:53) scop: I can do that, but I think those look pretty much like no-brainers (10:03:57) abadger1999: So the answer to which packages need rebuilding would be all. (10:04:04) scop: good point (10:04:13) thl: scop, probably, but someone need to work them out anyway ;-) (10:04:14) f13: abadger1999: that didn't make it in (10:04:22) f13: abadger1999: there is no sha256sum. (10:04:38) ***cweyl is here (rabble) (10:04:44) rdieter: is sha256sum signing in place now/yet (no?)? (10:04:48) f13: abadger1999: so the real answer is anything that is gcc compiled. (10:05:08) f13: rdieter: I don't think the patches even went into our rpm package yet. It was nacked to do such signing for FC6/RHEL5 (10:05:27) f13: the option may be patched into rpm, but it won't be enabled by default. (10:05:27) abadger1999: What about rebuilding with minimal buildroots? (10:05:45) ***dgilmore is kinda here (10:05:54) f13: abadger1999: certainly possible criteria (10:06:01) c4chris: And do we start on August 28 ? (10:06:17) f13: now that Extras has the minimal roots, you could add 'anything that hasn't built since <foo>' where foo is the date that the minimal buildroots went into place. (10:06:29) thl: c4chris, that's the plan currently, but I suggest we discuss this next week again (or the week after that) (10:06:37) c4chris: k (10:07:01) dgilmore: abadger1999: minimal buildroots are in place and the buildsys-build packages have been fixed (10:07:20) thl: well, a lot of people don't like a mass-rebuild were everything is rebuild (10:07:28) f13: abadger1999: for Core, the criteria was: Any binary compiled package (for gnu-hash support), any package that hasn't yet been built in brew (our minimal buildroot stuff), and any package that was still being pulled in from FC5. (10:07:49) thl: because it creates lot's of downloads that are unnesessary for people (10:08:07) thl: but if we want to rebuild everything to make sure that it stil builds -> okay for me (10:08:24) c4chris: thl, we are talking devel here (10:08:43) thl: c4chris, yes, but devel will become FC6 (10:08:45) c4chris: I think we need the mass rebuild (10:08:47) rdieter: c4chris++ right, better to be safe than sorry later. (10:08:59) thl: and people updateing from FC5 have the downloads then, too (10:09:11) c4chris: thl, become is the key word... (10:09:15) f13: rebuilding for gnu-hash is a big bonus (10:09:28) f13: I think people would like the performance increase it can give. (10:09:30) warren: FC3 and FC6 will be Extras releases that continue to be used long after FC4 and FC5 are retired for obvious reasons. Rebuilding FC6 Extras now is a good idea. (10:09:47) thl: okay, so a real mass rebuild (10:09:56) warren: I guarantee it will also find more bugs. (10:09:57) thl: we should post this to the list for discussion (10:10:00) scop: it's just plain silly to rebuild eg. huge game content packages that aren't anything else but stuff copied from the tarball to the file system (10:10:05) thl: who will manage that? (10:10:25) warren: scop, what if we setup an explicit exclusion list? owners can request packages to exclude. (10:11:17) scop: sure, if there's someone to review/maintain that list (10:11:36) scop: personally, I think the original plan would work well enough (10:11:45) warren: Are we proposing that we automatically rebuild everything, or first ask maintainers to do it themselves to see who is AWOL? (10:11:58) thl: warren, ask maintainers (10:11:59) c4chris: warren, ask maintainers (10:12:04) rdieter: scop, warren: isn't that what "needs.rebuild" on FC6MassRebuild? (10:12:08) warren: If that's the case, then they can deal with their own exclusions. (10:12:21) c4chris: warren, I think so too (10:12:35) warren: OK, this plan is good. (10:13:03) warren: > are there still 3 orphans in devel repo according to the package report: dxpc gtkglarea2 soundtracker. What do do? Remove them? (10:13:09) thl: does anyone want to annouce this plan to the list for discussion? (10:13:14) f13: ask people, give it a week or two, then step in and buildthe ones that haven't piped up? (10:13:18) thl: or do we simply mention it in the summary? (10:13:19) warren: One more warning on the mailing list asking for owners, with Aug 28th deadline to remove if nobody claims it. (10:13:36) rdieter: warren++ (10:13:47) thl: warren, +1 (10:13:47) c4chris: warren, yup (10:13:55) bpepple: warren: +1 (10:14:03) warren: I'll do that warning now... (10:14:23) scop: does anything else depend on any of those three? (10:14:30) thl: warren, let me check if those three are still around first (or if there are others still around) (10:14:33) warren: good question, I'll check (10:14:36) tibbs: dxpc was rebuilt fairly recently. (10:15:04) thl: warren, no, seems those three are the only ones according to the PackageStatus page (10:15:18) rdieter: I updated/built dxpc recently... so that it would be in good shape for any potential new maintainer. (10:15:23) ***f13 steps out (10:15:37) thl: okay, so again: does anyone want to annouce this new plan to the list for discussion? or do we simply mention it in the summary? (10:15:48) scop: one more item: what happens if a maintainer does not take care of his rebuilds? (10:15:52) warren: rdieter, without anybody responsible though, do we really want to keep it? (10:16:02) scop: thl, I thought warren said he'd announce it (10:16:06) rdieter: warren: no maintainer -> remove it. (10:16:23) warren: scop, I said I'd announce the orphan removal warning (10:16:26) thl: scop, I though warren want's to warn that those three might get removed? (10:16:52) scop: yep... so what's the new plan thl was talking about? (10:17:00) tibbs: BTW, I count 37 pachages belonging to extras-orphan@fedoraproject.org in the current owners.list. (10:17:02) scop: Extras/Schedule/FC6MassRebuild? (10:17:26) thl: scop, I thought we rebuild everything now (besides big data-only packages)? (10:17:38) thl: that's the impression I got (10:18:15) warren: How about rebuild everything *EXCEPT* maintainers can choose to explicitly skip it if they have a good reason? (10:18:16) c4chris: thl, right, but that's pretty much what FC6MassRebuild says, no? (10:18:31) warren: ooh... (10:18:34) scop: c4chris, exactly (10:18:38) thl: warren, we need to define "good reason" in that case (10:18:45) warren: How about rebuild everything *EXCEPT* maintainers can choose to explicitly skip it if they have a good reason? Except they MUST rebuild if it is demonstrated that a rebuild would fail. (10:19:05) warren: Binaries without GNU_HASH always rebuild? (10:19:13) warren: perl modules built against earlier perl versions? (10:19:15) warren: python? (10:19:16) thl: warren, Binaries without GNU_HASH always rebuild +1 (10:19:44) cweyl: warren: so basically everything that isn't content? (10:20:25) c4chris: cweyl, yes that's a good way to put it (10:21:23) abadger1999: cweyl: Sounds good. So everything goes through the minimal buildroot. (10:21:38) thl: "so basically everything that isn't content" -- +1, 0 or -1 please! (10:21:45) scop: as a general rule, works4me (10:21:45) warren: Content must be rebuilt *IF* it would fail to rebuild. (10:21:51) thl: "everything that isn't content" +0.66 (10:22:02) scop: warren, if it fails to rebuild, it can't be rebuilt (10:22:11) warren: Then it must be fixed? (10:22:25) scop: yes (10:22:27) warren: How about a separate exclude.list that contains (10:22:31) warren: packagename reason (10:22:51) warren: uqm-bigasscontent 1GB of game data that doesn't change. (10:23:02) rdieter: warren: do we really care about the reason? (10:23:13) Nodoid [n=paul] entered the room. (10:23:27) scop: I still think that the commit message to needs.rebuild is enough (10:23:38) c4chris: scop, +1 (10:23:42) thl: scop, +1 (10:23:42) abadger1999: scop: +1 (10:24:01) warren: hmm.. I guess (10:24:02) warren: ok (10:24:04) tibbs: !2 (10:24:04) c4chris: "everything that isn't content" +1 (10:24:08) tibbs: crap. (10:24:12) tibbs: +1 (10:24:28) bpepple: +1 (10:24:45) rdieter: I agree with scop, why isn't needs.rebuild sufficient? (or is this orthogonal to that?) (10:25:25) thl: guys we run late (10:25:38) warren: Let's move on (10:25:42) rdieter: ok (10:25:44) thl: afaics the current plan looks like this: (10:25:47) scop: we use needs.rebuild, but append something like "as a general rule, everything that is not pure content should be rebuilt" to FC6MassRebuild (10:25:53) thl: "everything that isn't content need a rebuild" (10:26:06) thl: "a needs.rebuild file will be placed into cvs" (10:26:31) thl: and if people don#t rebuild stuff they have to mention the reasons in the cvs delete commits message of needs.rebuild (10:26:37) thl: that okay for everybody? (10:26:40) ***warren looks at the 37 orphans... (10:26:42) c4chris: thl, scop: +1 (10:26:46) rdieter: +1 (10:26:55) scop: +1 (10:27:02) abadger1999: +1 (10:27:04) tibbs: +1 (10:27:05) bpepple: +1 (10:27:11) thl: okay, then let's move on (10:27:24) thl has changed the topic to: FESCO meeting -- Use comps.xml properly (10:27:26) thl: c4chris ? (10:27:31) warren: I suggested the exclude.list with reasons because it is easier to search than commit messages (10:27:35) warren: but that's fine (10:27:38) c4chris: Well I produced a big list... (10:27:54) c4chris: There was another idea to trim down soem more libs (10:28:17) thl: c4chris, do you want to work further on that idea and the stuff in general? (10:28:22) c4chris: So far, only Hans has added stuff to comps... (10:28:49) scop: warren, searching for needs.rebuild in a folder containing commit mails should work (10:28:49) c4chris: thl, a few things are not really clear: (10:28:56) thl: c4chris, we should send out mails directly to the maintainers when we now what needs to be in comps (and what not) (10:29:07) c4chris: do we also want cmdline stuff? (10:29:09) thl: then at least some maintainers will add stuff (10:29:19) thl: c4chris, cmdline stuff -> IMHO yes (10:29:38) c4chris: and do we allow packages listed twice? (10:29:42) thl: c4chris, or how does core handle cmdline stuff? (10:30:00) thl: c4chris, twiece? good question. Maybe you should ask jeremy or f13 (10:30:16) c4chris: thl, I think there are cmdline tools in Core too (10:30:17) scop: I'd suggest a SIG or a special group for taking care of comps (10:30:20) rdieter: c4chris: twice, as in more than one section/group? (10:30:25) jeremy: c4chris: packages being listed twice should be avoided (10:30:28) c4chris: rdieter, yes (10:30:34) jeremy: it leads to lots of user confusion (10:30:41) c4chris: jeremy, k, I thought so (10:30:54) rdieter: agreed, pick one(primary) group (and stick with it). (10:30:56) thl: scop, well, do you want to run the SIG? (10:31:10) warren: c4chris, twice is fine (10:31:17) warren: jeremy, eh? (10:31:24) thl: scop, I think we need a QA sig that looks after stuff like this (10:31:45) c4chris: thl, we sorta have a QA SIG... :-) (10:31:49) scop: thl, no, I'm not personally terribly interested in it (10:31:50) warren: Hmm, I might be thinking of the common practice of listing packages multiple times in the hidden language groups. (10:32:25) thl: c4chris, well, then it would be good if that sig could handle that ;-) (10:32:32) scop: which is actually why I'd prefer someone who is interested and can keep things consistent and useful would maintain comps (10:32:48) c4chris: thl, k (10:32:58) thl: c4chris, thx (10:33:08) thl: well, was this all regarding this topic for today? (10:33:29) c4chris: thl, yup. I'll see about sending some nagmails... (10:33:43) thl: c4chris, tia (10:33:45) thl has changed the topic to: FESCO meeting in progress currently -- Activate legacy in buildroots (10:33:54) thl: well, we had the discussion on the list (10:34:21) thl: my vote: activate legacy in buildroots now, discuss the maintainer responsibilities later (10:34:22) mspevack is now known as mspevack_afk (10:34:38) dgilmore: +1 (10:34:43) thl: building FE3 and FE4 without legacy is ridiculous (10:34:51) warren: +1 (10:35:00) tibbs: +1 (10:35:01) c4chris: +1 (10:35:09) rdieter: +1 (10:35:09) thl: abadger1999 ? (10:35:18) abadger1999: Yeah, why not? +1 (10:35:35) bpepple: +1 (10:35:38) thl: k, settled (10:35:43) dgilmore: Ill get the mock config changes done, and make sure we sync up the legacy tree (10:35:51) thl: dgilmore, tia (10:36:01) thl has changed the topic to: FESCO meeting in progress currently -- CTRL-C problem (10:36:05) thl: any news? (10:36:08) scop: hold on a bit (10:36:10) abadger1999: tibbs, Are you still going to send out a maintainer resp. email? (10:36:17) thl has changed the topic to: FESCO meeting in progress currently -- Activate legacy in buildroots (10:36:19) thl: scop, ? (10:36:38) scop: it should be also documented somewhere that use of "EOL" FE branches assumess FL is in use too (10:36:40) tibbs: I lost some work in the wiki crash, unfortunately. (10:37:03) thl: scop, agreed (10:37:04) tibbs: I've been trying to feel out where the community is on FE3-4 maintenance. (10:37:13) thl: dgilmore, can you look after that, too? (10:37:42) thl: http://www.fedoraproject.org/wiki/Extras/UsingExtras is the proper place afaics (10:38:05) scop: indeed (10:38:06) warren: What ever happened with the security SIG? The top priority of a security team would be to track issues and file tickets if new issues appear. Has that began? (10:38:18) abadger1999: tibbs: :-( (10:38:18) scop: yes (10:38:20) bpepple: warren: Yeah. (10:38:22) abadger1999: warren: Yes. (10:38:24) thl: warren, that's working afaics (10:38:26) warren: good =) (10:38:28) tibbs: That's been ongoing for some time. (10:38:55) thl: scop, well, I'll put in on http://www.fedoraproject.org/wiki/Extras/UsingExtras if no one else wants (10:39:00) thl: so, let's move on (10:39:04) thl has changed the topic to: FESCO meeting in progress currently -- CTRL-C problem (10:39:19) thl: any news? sopwith still traveling afaik (10:39:22) thl: so probably no (10:39:31) ***thl will skip this one in 20 seconds (10:39:34) warren: Same thought as last week (10:39:46) warren: only way to really fix this is to make CVS commit mail async (10:39:50) warren: do we want to do this? (10:40:12) thl: warren, are there ans disadvantages (10:40:30) thl: s/ans/any/ (10:40:50) scop: yes, someone has to do the work :) (10:41:11) warren: I'll bring it up at the infrastructure meeting today (10:41:21) warren: I don't know how easy it would be (10:41:28) thl: scop, hehe, the usual problem ;-) (10:41:35) thl: warren, tia (10:41:40) scop: and actually, it can be somewhat difficult (10:41:40) thl: k, moving on (10:41:41) warren: tia means? (10:41:46) scop: warren, TIA (10:41:50) warren: ? (10:41:55) scop: Thanks In Advance (10:41:58) warren: oh (10:41:59) thl: thx in advance (10:41:59) warren: ok (10:42:12) thl has changed the topic to: FESCO meeting in progress currently -- Packaging Committee Report (10:42:14) thl: ? (10:42:42) abadger1999: I think the only thing that passed today was changing how .pyos are handled. (10:42:56) abadger1999: They are to be included instead of ghosted. (10:43:16) thl: abadger1999, we probably should run a script over a devel checkout of extras and file bugs (10:43:24) thl: otherwise stuff will never get fixed... (10:43:34) thl: maybe another job for the QA sig? (10:43:37) abadger1999: That's a good idea. (10:43:47) bpepple: Yeah, there should be a lot of python packages this affects. (10:43:54) c4chris: thl, gotcha (10:43:56) thl: or any other volunteers (10:43:59) thl: ? (10:44:08) thl: c4chris, sorry ;-) (10:44:16) c4chris: np (10:44:27) scop: related python spec template changes: http://koti.welho.com/vskytta/pyspec.patch (10:44:54) thl: abadger1999, c4chris, can you look after such a script please? (10:45:02) rdieter: it was/is-going to be mentioned on fedora-maintainers too... (10:45:12) scop: grep -lF '%ghost' */devel/*.spec (10:45:23) c4chris: thl, yup, we'll cook something up (10:45:32) thl: scop, + "| file _bugs.sh" (10:45:36) thl: c4chris, tia (10:45:49) abadger1999: thl: Will do. (10:45:49) thl: k, moving on (10:45:58) thl has changed the topic to: FESCO meeting in progress currently -- Sponsorship nominations (10:46:04) thl: any new nominations? (10:46:29) c4chris: not that I know of (10:46:32) dgilmore: thl: yeah ill look after it also (10:46:33) ***bpepple listens to the crickets. (10:46:35) rdieter: Well, it feels dirty, but I'd like to nominate me. (10:46:56) c4chris: rdieter, self nominations are fine (10:46:57) rdieter: (wanted to sponsor someone the other day, and realized I couldn't... yet) (10:47:21) ***thl wonders why rdieter isn't a sponsor yet (10:47:26) warren: +1 rdieter (10:47:27) thl: well, that's probably easy (10:47:32) bpepple: +1 (10:47:33) abadger1999: +1 (10:47:34) c4chris: +1 (10:47:35) thl: I think we don#t need to discus this (10:47:36) scop: huh? -1 (10:47:39) thl: rdieter sponsor +1 (10:47:39) dgilmore: +1 for rdieter (10:47:41) scop: OOPS +1 (10:47:51) thl: k, rdieter accepted (10:48:03) thl has changed the topic to: FESCO meeting in progress currently -- approve kmod's (10:48:03) rdieter: thanks, no I have no excuse for more work.. (: (10:48:04) tibbs: +1 (10:48:08) tibbs: (slow) (10:48:16) ***warren upgrades rdieter (10:48:21) thl: no new kmods up for discussion, moving on (10:48:35) thl has changed the topic to: FESCO meeting in progress currently -- MISC (10:48:53) thl: dgilmore, FE3 and FE4 builders are working fine now (python and elf-utils?) (10:48:57) thl: ? (10:49:01) dgilmore: thl: yep all donr (10:49:02) c4chris: crap, the package database item has been eaten by the wiki crash... (10:49:04) dgilmore: done (10:49:19) thl: dgilmore, thx (10:49:24) warren: BTW, are all FESCO members on fedora-maintainers and fedora-advisory-board? (10:49:29) thl: c4chris, uhhps, yes, sorry (10:49:55) rdieter: -maintainers, probably, fab maybe not (but probably should) 9: (10:49:57) dgilmore: warren: should be though i know us new FESCO guys were only just added to fab (10:50:04) tibbs: warren: My mailbox is certainly bulging from the latter list, yes. (10:50:10) bpepple: warren: I'm on both. (10:50:13) c4chris: warren, I am (10:50:13) thl: all FESCo members should be on FAB now (10:50:16) tibbs: Someone went through and added us. (10:50:22) thl: I checked the subscribers last week (10:50:26) rdieter: good. (10:50:35) dgilmore: fab is high volume :) (10:50:42) warren: As developement leaders in Fedora, your opinions would be valued in many matters of importance discussed on fab. (10:50:55) thl has changed the topic to: FESCO meeting in progress currently -- Future FESCo elections (10:51:29) thl: abadger1999, we wait a bit more for replys to your mail before we proceed? (10:51:29) abadger1999: I posted the draft. Anyone want to propose changes? (10:51:34) dgilmore: warren: i gave a longish reply last night about how i went about doing aurora extras (10:51:52) ***warren reads that mail... (10:51:54) dgilmore: abadger1999: looked pretty sane to me (10:51:58) c4chris: abadger1999, I like the draft (10:52:01) warren: rdieter, upgraded (10:52:21) ***thl votes for "wait another week before we accept the proposal" (10:52:38) c4chris: thl, k (10:52:44) bpepple: thl: +1 (10:52:49) rdieter: thl: +1 (10:52:54) thl: k, so let's move on (10:52:55) abadger1999: thl: +1 (10:53:05) thl has changed the topic to: FESCO meeting in progress currently -- package database (10:53:46) thl: c4chris, warren ,do we want to discuss stuff regarding that topic today? (10:53:46) c4chris: I posted a couple brain-dumps kinda mails (10:54:10) c4chris: any word of advice at this time ? (10:54:23) warren: Keep dumping, next step is to collect and organize everything we want. (10:54:29) thl: c4chris, well, "simply do something until somebody yells" (10:54:44) c4chris: thl, k (10:54:57) thl: c4chris, sorry, but that#s often the only way to really get something done afaics (10:54:57) dgilmore: c4chris: Just that there is alot of things that it needs to support. We need to design it in a modular fashion so it can grow as we grow (10:55:17) mspevack_afk is now known as mspevack (10:55:25) c4chris: warren, k. I'll try to start the collect phase soon... (10:55:26) [splinux] left the room (quit: "Ex-Chat"). (10:55:33) warren: due to the large scope of package database, mailing lists and wiki are most appropriate and a best use of time. Only after we have the mess better organized into plans should we discuss it? (10:55:34) abadger1999: c4chris: Are you on infrastructure list? (10:55:43) thl: warren, +1 (10:55:59) dgilmore: warren: +1 (10:56:08) c4chris: abadger1999, not sure (10:56:11) abadger1999: warren: +1 (10:56:18) bpepple: warren: +1 (10:56:24) c4chris: abadger1999, is it open? (10:56:31) warren: c4chris, yes, to anyone (10:56:40) c4chris: I'll check (10:56:52) thl: k, so let's move on (10:56:57) c4chris: I think I'm on the buildsys list (or soemthing) (10:57:00) warren: https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list (10:57:03) thl has changed the topic to: FESCO meeting in progress currently -- free discussion around extras (10:57:10) thl: anything that we need to discuss? (10:57:11) j-rod: dgilmore: how are you setting -j32? (10:57:18) thl: or was that all for today? (10:57:34) dgilmore: j-rod: thats how many cpus are in the box so its being auto done (10:57:45) nirik: thl: any thoughts further on zaptel-kmod? (10:57:59) scop: this info should find a home somewhere: http://fedoraproject.org/wiki/PackagingDrafts/PackageEndOfLife (10:58:10) dgilmore: thl: I think thats all. Ive seen no further feedback on buildysys issues (10:58:43) thl: nirik, good idea (10:58:44) tibbs: scop: Yes, this is in FESCo's jurisdiction, it seems. (10:58:52) thl has changed the topic to: FESCO meeting in progress currently -- zaptel-kmod (10:58:58) scop: it's in the packaging namespace but is Extras only (at least for now) so that's not quite the correct place for it (10:59:16) thl: well, nirik started a discussion on fedora-devel (10:59:18) j-rod: dgilmore: ah, gotcha -- I was thinking it would be better to use slightly less, with the intention of filling the cpus with multiple simultaneous builds (10:59:25) cweyl: scop: maybe just move to Extras/PackageEndOfLife? (10:59:28) thl: but there was much that came out of it afaics (10:59:47) scop: cweyl, yeah, maybe (10:59:48) nirik: I guess I would say: should the kmod guidelines say "If the upstream has no plans to merge with the upstream kernel, the module is not acceptable for extras" ? (11:00:08) thl: nirik, well, IMHO yes (11:00:13) dgilmore: zaptel as much as i want it in. We need to do something to make sure that it gets upstream. So we should ask the community of someone is willing to do that (11:00:58) thl: dgilmore, sounds like a good idea, but I doubt we'll find someone (11:01:22) cweyl: wait, I've never really understood this. why should it matter if (for whatever, presumably legitimate reason) an upstream decides to not pursue having it merged into the kernel proper? (11:02:12) thl: c4chris, well, drivers belong in the kernel -- kmods are a solution to bridge the gap until they get merged into the kenrel, but no long term solution (11:02:26) thl: s/c4chris/cweyl/ (11:02:31) thl: cweyl, simply example: (11:02:46) thl: kmod-foo breaks after rebase to 2.6.18 (11:02:56) dgilmore: though dave jones comment that he wont provide support for kernels with any kind of external module means that we could have confused users if they file a bug and get in return WONTFIX becaue of the extras kmods (11:02:59) thl: but a new kmod-bar doesn#t build anymore on 2.6.17 (11:03:06) devrimgunduz left the room (quit: Remote closed the connection). (11:03:13) thl: people that need both kmod-foo and kmod-bar will have problems now (11:03:25) tibbs: I personally believe that the length of the solution is up to the maintainer of the Extras package. (11:03:47) cweyl: tibbs: +1 (11:03:49) tibbs: Any external module solution will have problems keeping in step with kernels. At that point it's up to the maintainer. (11:03:56) cweyl: thl: I think we're setting the bar too high (11:04:05) scop: cweyl++ (11:04:17) tibbs: I don't believe that acceptance into extras should be used as any kind of political leverage as I have seen some state before. (11:04:45) tibbs: The issue of bugs and their interaction with the main kernel is quite compelling, though. (11:04:46) thl: tibbs, that was the agreement we settled on before we worked on the kmod stuff at all (11:04:54) cweyl: it sounds like zaptel-kmod is well maintained, isn't going anywhere anytime soon, and isn't going into the mainstream kernel ever due to business reasons... why shouldn't we let a maintainer package it for people who want it? (11:05:04) thl: well (11:05:15) thl: I'll bring it up to fab for discussion (11:05:19) thl: that okay for everybody? (11:05:26) cweyl: wait -- why fap? (11:05:30) thl: FAB (11:05:33) tibbs: thl: I was not a party to that discussion. (11:05:33) abadger1999: To me we have to keep our kernel people happy. (11:05:34) cweyl: err, fab? isn't this just an extras? (11:05:34) thl: sorry, typo (11:05:46) thl: abadger1999, +1 (11:05:47) bpepple: abadger1999: +1 (11:05:47) cweyl: err, a FESCo decision? (11:06:05) tibbs: If the "agreement" is unchangeable then that would be unfortunate. (11:06:08) thl: cweyl, no, this IMHO is something that matter for fedora at a whole project (11:06:13) cweyl: hrm. (11:06:21) thl: tibbs, everything can be changed (11:06:25) ***dgilmore steps back, I want it in but i understand the reasons for not having it in (11:06:35) warren: thl, except Bush's mind. (11:06:45) tibbs: WTF? (11:06:45) thl: warren, :) (11:06:57) cweyl: well, think of it this way too: as a user, I choose to buy a nvidia card, knowing that I'll need a kmod for it. (11:07:07) cweyl: I know there are risks that go along with that, and I'm willing to take them. (11:07:21) c4chris: but when your kernel crash, you usually file a kernel bug... (11:07:30) warren: BTW, vaguely on this topic, there was interesting news yesterday. (11:07:34) cweyl: Same thing with people who want to use zaptek-kmod, or the iscsi module that was discussed a while back... (11:07:40) warren: AMD is planning on open sourcing some of the ATI driver stuff. (11:07:49) tibbs: warren: Link? (11:07:54) thl: warren, are they really planing it? (11:07:59) c4chris: cweyl, that's why we need to keep the kernel maintainers happy (11:08:00) ***warren finds URL (11:08:00) bpepple: warren: Yeah, that looks like it could be promising. (11:08:01) dgilmore: cweyl: not always. my company provides me a system (probably laptop) it needs a kmod and i dont support binary drivers. but i get no say in the purchasing decision (11:08:04) thl: I only heard rumors (11:08:30) ***nirik also only heard rumors. (11:08:31) cweyl: c4chris: I'm not saying we shouldn't :) (11:08:41) tibbs: I've only heard wishful thinking. (11:08:47) warren: http://www.infoworld.com/article/06/08/02/32OPcurve_1.html (11:08:49) nirik: warren: you talking about: http://www.infoworld.com/article/06/08/02/32OPcurve_1.html ? (11:08:58) nirik: yeah, I read that as a rumor. (11:08:59) thl: I consider that as rumors (11:09:12) c4chris: cweyl, that means we probably need FAB buying the idea too... (11:09:24) thl: I ascutally asked AMD and ATI guys for clarification already earlier today (11:09:27) warren: I think consulting FAB i sa good idea. (11:09:30) thl: no reply until now (11:09:38) warren: thl, not surprised (11:09:40) cweyl: dgilmore: right. but the point is I want to use h/w that requires a kmod, and my decision to do that doesn't impact anyone else (11:09:54) warren: Anyway, if this becomes true, it will put pressure on NVidia. (11:10:05) ***bpepple thinks it needs to go to FAB also. (11:10:07) cweyl: c4chris: it's not like kmods change their package, or globally affect all fedora users (11:10:09) thl: so, anything else that needs to be discussed? (11:10:18) ***thl will close the meeting in 60 seconds (11:10:24) dgilmore: cweyl: yes and no. its not always my decsion but yes i want my hareware to work (11:10:45) warren: I think we're actually slowly winning the proprietary kernel module war (11:10:55) warren: Intel is leading the way, and hopefully AMD comes next (11:11:00) ***thl will close the meeting in 30 seconds (11:11:11) abadger1999: Approving this? http://fedoraproject.org/wiki/PackagingDrafts/PackageEndOfLife (11:11:21) warren: Our only way to promote further growth is to maintain our hard line stance. (11:11:46) warren: SuSe and Ubuntu both switched away from proprietary modules to a hard line stance. (11:11:50) warren: we're doing the right thing (11:11:58) thl: abadger1999, well, if that something FESCo should approve (11:11:58) warren: it will be painful meanwhile though... (11:12:08) thl: why is it in the Packaging namespace then? (11:12:28) thl: abadger1999, but well, get's a +1 from me (11:12:32) c4chris: abadger1999, looks fine to me (11:12:52) scop: I suggested to put it in the packaging namespace, but others corrected me (11:13:07) abadger1999: thl: scop proposed it in packaging this morning but it seems much more like a FESCo thing. (11:13:17) thl: abadger1999, well, never mind (11:13:26) thl: abadger1999, it actually describes what we do already (11:13:29) thl: so +1 (11:13:35) c4chris: +1 (11:13:36) abadger1999: +1 (11:13:37) rdieter: +1 (11:13:38) bpepple: +1 (11:13:57) tibbs: +1 (11:14:00) thl: k, settled (11:14:16) thl: abadger1999, can you moe it over to a proper place in the wiki please? (11:14:23) ***thl will close the meeting in 30 (11:14:32) abadger1999: will do. (11:14:33) thl: s/moe/move/ (11:14:40) ***thl will close the meeting in 10 (11:14:50) thl: -- MARK -- Meeting end (11:14:55) thl: thx everybody! (11:15:05) tibbs: thl: Thanks. (11:15:11) c4chris: thl, thx (11:15:31) 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-08-17 1700 UTC (11:15:43) ***c4chris goes afk: time fer dinner :-) (11:16:10) thl: are you guys still satisfied with the way I run the meetings? (11:16:19) thl: or is there anything we should change? (11:16:33) tibbs: I'm not sure it could be done much better. (11:16:45) scop: thl, absolutely no problem with that (11:16:49) thl: I know I'm a bit hectic now and then (11:16:55) scop: I think the agenda is a bit swollen, though (11:17:01) dgilmore: thl: i think your doinga great job (11:17:21) thl: scop, you mean the wiki (11:17:28) dgilmore: thl: something you may need to step up and say hey were done on this now move on (11:17:40) thl: well, I wanted a better overview for those that missed a meeting or two (11:18:05) scop: thl, no, but I think there are maybe a bit too many things to process per meeting (11:18:39) thl: scop, yes (11:18:52) thl: maybe we should do more via mail (11:19:09) thl: e.g. the reports from the packaging committee maybe (11:19:33) scop: that would work for me (11:19:34) thl: maybe the owners of task should update the wiki pages with a status update *before* the meeting (11:19:51) abadger1999: thl: Both of those would be good ideas. (11:19:52) thl: we could avoid the "status update" questions then (11:20:05) scop: and sponsor stuff could be taken entirely to the list (11:20:09) Rathann: Nodoid: wow, you really did it, #202004 (11:21:08) thl: I'll think about it a bit more (11:21:37) thl: abadger1999, scop, but we need to make sure that we discuss important things from the packaging committee meetings here (11:21:50) scop: good point (11:21:51) thl: the less important things could be done on the list (11:22:11) abadger1999: If it needs to be discussed here then the report needs to be done here. (11:22:22) abadger1999: Or the wekly packaging meeting could be changed. (11:22:27) bpepple: scop: +1 (11:22:58) thl: abadger1999, changeing thepackaging meetings could help (11:23:51) thl: btw, regading sponsor discussions (11:23:59) thl: do we want to do that on cvs-sponsors (11:24:02) thl: or fesco only (11:24:11) ***thl votes for cvs-sponsors (11:24:38) ***bpepple votes for fesco. Could give more frank discussions. (11:24:48) abadger1999: I'll add meeting time to the packaging agenda. (11:25:44) thl: bpepple, but we are getting quite big, so it might more and more often happen that FESCo members don#t know those that were nominated for the sponsor job (11:26:23) bpepple: thl: It's pretty easy to query bugzilla for the reviews. (11:26:48) thl: well, let's discuss this on the list or in the next meeting (11:26:56) bpepple: no problem. (11:27:21) tibbs: c4chris did add bugzilla links to the "top reviewers" table in PackageStatus. (11:27:36) thl: bpepple, the past discussions we had on cvs-sponsors were quite frank iirc (11:27:45) tibbs: That list currently covers twelve reviews and up. (11:28:58) bpepple: yeah, but I'm afraid some of the discussions might discourage the participants enthusiasm, if there not comfortable with criticisms. (11:29:37) scop left the room ("Leaving"). (11:31:29) thl: bpepple, maybe we should do it on both lists? (11:32:00) bpepple: That might be a good idea. (11:34:20) cweyl: if there are criticisms, and they're discussed privately, might I suggest that it's a good idea to offer those criticisms, packaged constructively, to the nominee? That way they know what prevented them from being approved, and what they need to fix (11:34:20) thl: c4chris, /Extras/Schedule/PackageDatabase in place again (11:34:42) thl: cweyl, yeah, that's what I thought already, too (11:35:12) cweyl: and doing that publicly would give others guidance, establish precedent, etc, etc (11:35:30) cweyl: thl: I suspect I'm just stating the obvious here, but someone had to do it :) (11:35:45) dgilmore: thl: whats cvs-sponsers (11:36:26) bpepple: cweyl: Agreed, that was what I was thinking. (11:37:21) thl: dgilmore, a mailing-list where all sponsors are subscribed (it#s actually an alias or something else and no proper mailinglist) (11:38:00) dgilmore: thl: ok well i think its bad to discusss there because some fesco members are not in on that. (11:38:04) nirik: yeah, it's an alias... which unfortunately causes SPF issues. ;( (11:38:28) dgilmore: thl: namely me and im sure others (11:38:40) cweyl: nirik: cvs-sponsors causes skin cancer? (11:38:41) thl: dgilmore, well, we probably really should discuss on both lists (11:39:02) dgilmore: and I know i really dont have the time to dedicate to being a sponsor (11:39:37) nirik: cweyl: Sender Policy Framework... skin cancer might be easier to treat sometimes. ;( (11:40:00) cweyl: nirik: gotcha :) (11:40:36) dgilmore: nirik: people using SPF should add redhat /fedora mailservers to their dns (11:40:39) thl: dgilmore, np, I also don't find enough time to review and sponsor (11:40:49) thl: dgilmore, that's sad and I don#t like it (11:41:15) thl: but that's how it is ATM... :-/ (11:42:10) dgilmore: thl: yeaqh it is. Between Security and Infrastructure and my sparc port of extras, FESCO and maintaining my own packages I review when i can but I dont want to do a half assed job of something (11:42:50) thl: I actually even tried to get rid of a lot of packages in Extras (11:43:05) thl: to have more time for other stuff (11:43:13) dgilmore: I dont have a huge amount of packages. (11:43:36) dgilmore: I try to commit myself to things where i feel ill have a positive effect on something