From Fedora Project Wiki

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

Package Database

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
Retrieved from "https://fedoraproject.org/w/index.php?title=Extras/SteeringCommittee/Meeting-20060810&oldid=18391"