Extras/SteeringCommittee/Meeting-20051021

Fedora Extras Steering Committee Meeting

21 October 2005

Present

• Warren Togami
• Adrian Reber
• Jeremy Katz
• Thorsten Leemhuis
• Ville Skytta
• Dams Nade
• Colin Charles
• Enrico Scholz
• Michael Schwendt
• Seth Vidal
• Greg DeKoenigsberg
• Jesse Keating

Agenda

• Old package pruning - remove all but the latest 2 of any package. Make this automatic everytime the repository metadata is rebuilt for Extras. Doing this prunes 800-1000 packages from Extras, and will save between 4-5GB on mirrors. For packages pending release (packages in the needsign queue), we move them to a temporary space, then prune, to avoide the possible race of getting old and new. Seth will add this goodness to the scripts soon.

• Office hours - Posted times that guarantee to be someone qualified to be at #fedora-extras. We currently have this on some of our personal wiki pages. Formalizing this isn't necessary, as there's always someone knowledgable at #fedora-extras
• Account expiration - is disabling access of people who have done something, but have stopped for an extended period of time. Perform further research on this, looking at the ASF (Warren) as an example even. Colin will summarise for next week, to push research on list.
• Sponsorship nominations don't exist this week
• Contributor aliases on fedoraproject.org will happen. Park of the marketing project, and both Colin and Seth have access to this.
• Kernel module packaging - Thorsten provided a good summary in e-mail. We'll traverse by point basis.
• "Provides: kernel-module, kernel-module = %{kver}, kernel-modules or ...". yum prefers kernel-modules, as it follows up2date behaviour; it looks for Provides: kernel-module.
• "Target directory for the module: follow upstream, updates/ extras/ ..." - Ville suggests "extra", i.e. for /lib/modules/uname -r/extra/ (extra and not extra_s_ to follow upstream kernel documentation)
• We still stick to NO Extras package/module updating a Core module. Our standard should include the "updates" directory, so Independent Hardware Vendors (IHVs) can follow a similar standard. So we agree on extra/ and updates/. But we should revisit this when we can talk to Spot.
• kernel-module-foo-kver is a poor choice (and yum can be changed to adapt this). Jeremy suggests foo, and foo-kmod if there's userspace. Thorsthen and Jesse (along w/Anvil, Seth, Warren, etc.) suggest kernel-mod-foo, to avoid confusion with userland. Jeremy says prefixes are horrible for UIs. We have decided on kmod-foo, as the %{name}.
• We agree on Requires: kernel-%{_target_cpu} = %{kver. Enrico suggests that a yum plugin be written, and its agreed upon that it gets installed upon with Core
• A yum provides kernel-module should search thru all available kernel modules.
• Split userspace and kernel SRPMS.
• How is the buildsystem going to handle passing the kernel version and arch to the build? Arch should be ok, kernel version is tricky - just build for current kernel? But that requires users updating. For a start, lets build against the current kernel and see how much trouble it creates for users. We can revisit the issue then.