From Fedora Project Wiki

Revision as of 09:40, 27 February 2011 by Jjmartinez (talk | contribs) (update on the idea)

Other ideas that were incomplete or worth considering are found at Summer coding ideas for 2009.

Find an idea you like? Want to propose your own? See our Getting Started Guide:

http://groups.google.com/group/redhat-summer/web/gsoc-getting-started

Ideas for the JBoss community can be found here. We will be participating with JBoss this summer.

Turn smock into a real program

Status:

Summary of idea: smock is a hack that Dan and I wrote a few years ago that lets you build a chain of RPMs in mock. It works out all the dependencies and builds the packages in the right order, using the result from an earlier build to satisfy dependencies in a later build, and being almost completely automated. What really needs to happen is that mock is extended to support this as a native feature.

Contacts:

Mentor(s):

Notes:

Port Infrastructure TurboGears apps to TG2

Status: Proposed

Summary of idea: Several Fedora Infrastructure applications are written in TurboGears 1.0, and for longevity need to be ported to TG2. These include bodhi, mirrormanager, packagedb, elections, fas, smolt.

Contacts: Matt Domsch, Toshio Kuratomi

Mentor(s): mdomsch


MirrorManager enhancements

Status: Proposed

Summary of idea: MirrorManager provides the mirror lists to all Fedora systems. In addition to porting to TG2 (see above), several enhancements would be welcome:

  • Simplify creation of new MirrorManager instances (non-Fedora users, such as CentOS)
  • Simplify selection of mirrors within Cloud Providers on granularity other than netblocks and ASNs
  • Other items on the TODO list

Contacts: Matt Domsch

Mentor(s): mdomsch

mw enhancements

Status: Proposed

Summary of idea: [ mw] is a command-line program that pretends to be a version control system. It should eventually help people who are console nuts (like me) edit MediaWiki-based wikis without having to shout at their web browser.

Contacts: Ian Weller

Mentor(s): Ian Weller

Notes: This is also a proposed hackfest at FUDCon Tempe but I doubt we'll get as much as I'd like done there.

NIS support in SSSD

  • Status: Proposed
  • Summary of idea: Currently, the System Security Services Daemon supports only LDAP for network user identity. Support for NIS identities has been requested several times by end-users.
  • Contacts: Stephen Gallagher
  • Mentor(s): Stephen Gallagher

SUDO support in SSSD

  • Status: Proposed
  • Summary of idea: Sudo 1.8.0 will support a plugin interface for sudo authorization decisions. It would be excellent for SSSD to provide such a plugin to provide cached access to sudo information stored in the sudo LDAP schema. This would make it easier to maintain centralized sudo rules that also function while offline.
  • Contacts: Stephen Gallagher
  • Mentor(s): Stephen Gallagher
  • Notes: http://www.sudo.ws/sudo_plugin.man.html

Maven and PackageKit integration

Status: Proposed

Summary of idea: Currently when building with maven locally, all spec files need to specify build dependencies manually. Java libraries and maven plugins should have something like "Provide(groupId:artifactId:version:format)" so that "yum install org.apache.velocity:velocity" will correctly find and install velocity package. Second part of this project can be creating maven plugin asking you to install via PackageKit the package that provides the dependency.

Contacts: Stanislav Ochotnicky or Alexander Kurtakov

Mentor(s):

Notes: Basic knowledge of maven and rpm is required.

KDE Plasma and PackageKit integration

Status: Proposed

Summary of idea: Add automatically-generated rpm dependencies for kde/plasma related services (see also blog entry on the topic), and add packagekit hooks to use them (one concrete example would be for plasma dataengines (see also blog entry on the topic).

Contacts: Rex Dieter

Mentor(s):

Notes: Intermediate knowledge of rpm and/or kde plasma coding


Avahi yum repositories

Status: Proposed

Summary of idea: Add a yum plugin that will use avahi to find local mirrors of canonical repositories, and tools/scripts for local http/nfs servers to advertise what they have. It would also be nice to include proper nfs repository support in yum or a plugin, so the advertised repositories can be on NFS filesystems that are not already mounted locally on clients. The use on the clients should be transparent without any local yum repo config changes except perhaps for installing/enabling the plugin. Later anaconda could also be taught to use avahi to find repositories for installation.

Contacts: Roland McGrath

Mentor(s):

Notes: Divisible into various separate pieces that are worthwhile on their own.


Fill in some of the Missing nVidia and Radeon API pieces

Status: Proposed

Summary of idea: Add some of the missing 3d APIs for at least one of the major card types, considerably helping out the beleagured Radeon and Nvidia reverse-engineering efforts. There is enough currently (F14) missing that most 3d games do not function correctly, many of the underpinnings of FireFox 4 acceleration are blacklisted under Linux, and many other visual and other components cannot make correct use of the gpu(s) under Linux. Progress is abysmal for many reasons.

Contacts:

Mentor(s):

Notes: Requires good integration with the existing Radeon and nVidia teams and their testsuites


Fedora Medical

Status: In progress.

Summary of idea: Here, we are looking for a couple students who have some experience in RPM packaging, python, and bash. The idea can be found here: http://fedoraproject.org/wiki/SIGs/FedoraMedical We are looking forward to do mainly packaging and getting them published to fedora repo. Understanding fedora package maintainer guideline or having existing packages in fedora will be a plus. Also, the student should be interested in maintaining some of those packages after SOC.

Contacts: Susmit Shannigrahi <susmit at fedoraproject.org>

Mentor(s): Susmit Shannigrahi (for now)

Notes:

Improve critical dependency management in Yum

Status: Proposed (please review)

Summary of idea: The idea (roughly) is that Yum could be able to detect when a package update is going to break some important functionality of the system because is a dependency of another package that isn't being updated (Yum is not detecting that because when a kernel is updated, the previous one is not deleted, and the dependency isn't broken). This happens once in a while with kernel and third party packages that provide support for devices that doesn't work in Fedora official kernel because licensing restrictions: ie. Fedora updates the kernel, and RPM Fusion packages related to Broadcom wireless usually need 2-4 days to be updated, resulting in a non working wireless. I'm not sure if this is could be fixed changing some parameter in the RPM file provided by RPM Fusion, or if there are other cases in which "a smarter" Yum would beneficial.

Contacts:

Mentor(s):

Notes: I don't feel qualified to be mentor, but I guess Yum maintainer (Seth Vidal) could be a very good match.