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