Find an idea you like? Want to propose your own? See the Getting Started Guide with GSoC:
You may be interested in ideas from 2014 2013, 2012, 2011, 2010, 2009 and 2008.
Further, last year accepted ideas from the Fedora Project can be found at GSoC 2014 web site
Students Welcome
If you are a student looking forward to participate the GSoC 2014 with Fedora, please feel free to browse the idea list which is still growing. Do not hesitate to contact the mentors/ contributors as indicated in this page for any related clarification. If you are new to The Fedora project, following material would help you to get started. Further please sign-up with the Fedora Account System(FAS) if you are willing to continue with the Fedora project. #fedora-devel, IRC channel can be used to get instant support.
- The Foundation
- Fedora Documentation (Users/ Contributors)
- How to work with IRC?
- Fedora Account System
- Development
Supporting Mentors
Following contributors are also willing to support the GSoC 2015 program. (please feel free to add your self, attach the user page). Sometimes there should be some backing up mentors to mentor if the original mentor get busy with something for a short time period. In such case we need help.
Draft of an idea
Please add your idea as follows.
Project name
Status:
Summary of idea:
Knowledge prerequisite:
Skill level:
Contacts:
Mentor(s):
Notes:
!!!The draft was changed slightly, please add required field as required!!!
Idea list for GSoC 2015
Implement Tinykdump
Status: Proposed - draft
Summary of idea: Tinykdump is a minimal daemon to capture kernel-based crash dumping (kdump) memory image to usb storage. Compared to the traditional kdump solution, it is,
* more reliable and scalable * has smaller memory foot-print * more friendly to kernel developers
More information here: https://fedorahosted.org/tinykdump/
Knowledge prerequisite: Python, kernel programming (desired)
Skill level: intermediate (programming)
Contacts: CAI Qian
Mentor(s): CAI Qian
Notes: Rough roadmap:
- Implement tinykdump daemon to be included in Fedora.
- Submit kernel patches for reserving kdump memory at run-time for community review and inclusion.
- Currently, pstore only log kernel messages for panic and Oops. Patches are needed to support logging of kdump kernel and initramfs console output.
Port Fedora helper scripts to Python3
Status: Proposed - draft
Summary of idea: Fedora is swithing to using Python 3 as default soon, therefore several tools used to build Fedora should to be ported to python 3 as well.
Knowledge prerequisite: Python 2&3 programming skills
Skill level: intermediate (programming)
Contacts: Till Maas, Dennis Gilmore, #fedora-releng[?]
Mentor(s):Till Maas, Dennis Gilmore
Notes: Rough roadmap:
- Become familiar with Fedora packaging to know how to use the affected tools, maybe package something
- Make select releng scripts PEP8 compliant
- Add python3 support to the following packages, also make the packages PEP8 compliant if applicable:
- rpkg
- packagedb-cli
- fedpkg
- mash
- Fedora Review
- Add python3 support to more packages depending on how much time is left
Enhance Fedora build setup
Status: Proposed - draft
Summary of idea: Fedora uses the Koji build system with GIT as a source. Plugings/scripts are needed to allow package maintainer to be able to use own branches without accidently deleting the source of published RPMs.
Knowledge prerequisite: Python programming skills, ideally some packaging knowledge
Skill level: intermediate (programming), high (understanding/analysing code, GNU/Linux)
Contacts: Till Maas, Dennis Gilmore, #fedora-releng[?]
Mentor(s):Till Maas, Dennis Gilmore
Notes: Rough roadmap:
- Become familiar with the Fedora packaging workflow, maybe by packaging some software
- Learn how to interface koji and write a script to get a mapping of git commit ID to package build (name, version, release)
- Write a koji plugin to enforce that pkgs can be only built from the right GIT branch for each build target (might need improvements to koji's plugin interface as well): https://fedorahosted.org/rel-eng/ticket/5843
- Write a fedmsg service/cronjob to regularly tag sucessful builds in GIT: https://fedorahosted.org/rel-eng/ticket/5856
- Help with koji2
Improve Sigul Signing Server
Status: Proposed - draft
Summary of idea: The Sigul signing server is used by release engineering to sign Fedora RPMs. There are two major problems that make it hard to release updated packages in a timely manner: It crashes and it cannot be used simulateneously.
Knowledge prerequisite: Python programming skills, ideally some background knowledge about GPG, security and networking
Skill level: intermediate (programming), high (understanding/analysing code, GNU/Linux)
Contacts: Till Maas, Dennis Gilmore, #fedora-releng[?]
Mentor(s): Till Maas, Dennis Gilmore
Notes: Rough roadmap:
- Setup a sigul test instance, maybe a staging system in Fedora Infra
- Debug why sigul hangs and patch it
- Enable sigul to process multiple tasks at once
- Fix other bugs/issues such as problems with logging or secure GPG defaults
AskFedora UX/UI & Functionality Overhaul
Status: Proposed - draft
Summary of idea:
AskFedora is a community knowledge base and support forum and designed to be the primary place for community support in Fedora. It is powered by Askbot, Django based web application. The UI and the UX for AskFedora needs overhaul to give it some uniformity with the current Fedora websites. There may also be changes to be done in Askbot itself and have possibility of being integrated upstream. We aim to achieve results similar to what Ask Ubuntu has achieved, however Ask Ubuntu is not based on Askbot and similar theming techniques can't be applied. Discussions are open for this.
But why?: Over the years of its existence, AskFedora's popularity has increased and there are 11,000+ questions that have been asked on the website and has 12,500+ contributors as of today (out of which quite a few are active). We think, it really needs to 'look good' and 'provide a better user experience' now.
Status right now: Mockups during the last Design Fedora Activity Day (FAD) 2015 were done. Checkout this and this blogpost for latest updates on mockups. An openshift instance has also been created and source for testing repository is available for setting up your own staging instance.
Knowledge prerequisites: Front-end (HTML/CSS/JS) development, UI/UX design experience, some knowledge of Django/Python
Skill level: Beginner/Intermediate
Contacts: suchakra at fedoraproject dot org
Mentor(s):
TD;LR The infra and some ideas for testing is all ready, we need someone to improve AskFedora's UI/UX.
Glitter Gallery Improvements
Status: Proposed - draft
Summary of idea:
GlitterGallery is GitHub for designers - being developed by and for the Fedora design team, but hoping to be useful to all designers. It's a web app that allows designers and artists to create, share, and collaborate, backed by Git for version control, and intended to be part of a FLOSS design suite that includes
- Sparkleshare - a git-backed, Dropbox like system that will automatically check in and push files in project directly to a shared git repo
- Magic Mockup - a javascript library you can insert into an SVG of mockups to enable interactive, click-through mockups (see a demo here
- Inkscape is our preferred design tool of choice
Last year, two GSoC students worked on a number of critical improvements to GlitterGallery, but there is still plenty of work to be done.
- Public gallery of works; currently the app requires a user to login and to follow other users before they can see work other than their own. They can also view direct links to works. A public gallery can be used to browse and explore works without having to be logged in.
- Better design suite integration, which could mean better support for local editing with SparkleShare; Inkscape integration through an extension; and/or support for creating and sharing interactive SVGs with Magic Mockup
- Better commenting - the current commenting system is basic, and there's lots of ways it could be improved, including thread support, pingback support, the ability to reference a specific region of a design in a comment
- External issue tracking - Glitter Gallery has an integrated issue tracker, but it would be useful to also be able to integrate with external bug/issue trackers such as GitHub and Bugzilla.
- Enhanced history view - (see https://github.com/glittergallery/GlitterGallery/issues/187)
- Your own ideas
Knowledge prerequisites: git, Ruby on Rails, front-end (HTML/CSS/JS) development, design experience would be great but optional
Skill level: Intermediate
Contacts: emichan at fedoraproject dot org, sarupbanskota at fedoraproject dot org
Mentor(s): Emily Dirsh, Sarup Banskota
Notes: The GlitterGallery repository is hosted on GitHub.
Open Ideas From GSoC 2014
FedmsgSobumper
Status: Proposed (as a maturity level in RFC6410)
Summary of idea: Automatically rebuild the whole dependency subtree in rawhide if any ABI-backwards-incompatible so-bump occures.
Knowledge prerequisite: Python, shell
Skill level: Low-Medium
Contacts: jpacner @ @ redhat @ @ com
Mentor(s): jpacner @ @ redhat @ @ com
Notes: The script will be hooked to Fedmsg bus and should be as small as possible (for details, please contact the mentor). This will save rawhide contributors much time.
Bugspad
Status: Proposed
Summary of idea: Bugspad is a bug tracking system designed keeping performance in mind. The target is to keep same level of features like Bugzilla but people should be able to host it in a standard vm. It should also require less configuration and maintainence. For a test evaluation goal we want to have all Fedora bugs and but better performance from current Bugzilla.
Project details can be found at http://bugspad.readthedocs.org/en/latest/
Minimal required TODO
- Fully working frontend, primary idea is to go fully selfhosted. All bugs should be filed in that instance against Bugspad.
Knowledge prerequisite:
* Good idea on web applications and frontend design. * The person should know about API(s) in general and how to design them well. * Python, Javascript, HTML, CSS will be the primary languages to deal with.
Skill level: Medium-High
Contacts: kushal AT fedoraproject DOT org
Mentor(s): Kushal Das
Notes: The backend is written in golang. Before you start talking have at least one instance up somewhere (hints: your laptop).
Waartaa
Status: Proposed
Summary of idea: Waartaa is an open source communication tool for teams and groups. It is built on top of IRC. Currently, Waartaa is an IRC client as a service and it supports centralized logging, 24x7 idling, notifications and unique identity to a user on IRC. You can visit the project’s homepage: https://www.waartaa.com for more details. A demo instance of Waartaa is hosted at https://try.waartaa.com.
Roadmap:
- Build a central hub for searching/reading channel logs for Open Source communities and projects.
- Build a faster and scalable backend.
- Freedom of choice: Expose an API so that users can use their existing IRC clients with waartaa.
- Find a secure way to authenticate with IRC services without storing RAW passwords.
- Respect user privacy: user personal messages should be stored in an encrypted format in the server.
- Allow users to download chat logs in various formats compatible with popular IRC clients.
- HTML5 mobile app
- VCS, Bugzilla and other task management tools integration.
- Video/audio conference facility on top of HTML5 and JS technologies.
Knowledge prerequisite: Python, Javascript, HTML, CSS.
Skill level: Medium
Contacts:
- rtnpro at fedoraproject dot org
- sayanchowdhury at fedoraproject dot org
Mentor(s): Ratnadeep Debnath, Kushal Das, Sayan Chowdhury
Notes:
Afterthought
Status: Proposed
Summary of idea: Afterthought will be the tool to run (not predefined) jobs on *nix systems. At very high level, it will take an URI as argument, fetch the data of the URI, strip/parse the formatted data (with instruction sets) & execute the commands/jobs. This makes automating tasks, server/application deployments so much easy.
By operation, one can simply consider it as a dynamic, lazy-loaded shell-script. When running a script it follows the routines put in it at the creation time (which may have been obsoleted at the time of execution); whereas, afterthought fetches the latest routines, which would be the latest route-to-follow for the operation - without the user needing to worry about it (or get the 'latest' script).
Other possibilities include, configuring a base procedure customized to particular needs, profiles and/or credentials. And the endpoint doesn't need to reply the same on 2020 for a Fedora Machine with Clang, as it did on 2015 for a CentOS rig with GCC - if you know get what I mean. Other such possibilities are:
$ afterthought http://zomg.app/install $ afterthought https://le-wild-github.app/username/pushes/to/ci $ afterthought https://thoughtpolice.tld/openshift/deploy?user=id&code=github.com/foo/bar $ afterthought https://thoughtpolice.tld/user/?profile=setup-irc-bouncer-on-my-raspberry-pidora $ afterthought https://thoughtpolice.tld/user/?profile=run-httpd-server-on-a-docker-image-of-fedora
OR maybe, in a Dockerfile
CMD ["afterthought", "http://thoughthacker.tld/rule-the-world#plan-TBD-but-this-image-ships-today"]
So, all in all - less RTFM, less maintenance (or chasing ghost of the past routines/scripts), more automation - wherever applies (hint: applies in way too many places).
Knowledge prerequisite: *nix && (Rust || C/C++ || Go) && (Node.js::FlatIron/Express || Python::Flask/Pyramids || Ruby::Rails/Camping)
Skill level: Intermediate
Contacts: Soumya Deb (Debloper)
Mentor(s): Soumya Deb (Debloper)
Notes:
Web hosting control panel
Status: Proposed - Draft
Summary of idea: develop a free alternative of cpanel / plesk control panels, 100% compatible with fedora, and redhat enterprise Linux. written in python.
the control panel will be able to create domains and automatically setup apache, postfix, dovecot, mysql, postgresql bind etc...
Knowledge prerequisite: apache, postfix, dovecot, mysql, postgresql, proftpd, bind
Skill level: Medium
Contacts: itamarjp [AT] fedoraproject [DOT] org, kaustubh [DOT] karkare [AT] gmail [DOT] com
Mentor(s): Luis Bazan
Co-Mentor: Eduardo Echeverria
Notes: webhosting control panel draft
Infrastructure for FreeMedia group
Status: Proposed
Summary of idea: Fedora freemedia is a group of volunteers who ship fedora media on request to users worldwide. They use Trac to track these requests. The process is manual, the idea is to automate the process as much as possible.
Knowledge prerequisite: PHP, PostgreSQL
Skill level: Medium
Contacts: bckurera
Mentor(s):
Notes:
Collaboration projects with other organizations
- TBA
Muon – KDE package management
Status: Proposed
Summary of idea: The current package manager front-end used in Fedora KDE, Apper, is unmaintained and full of bugs. Muon OTOH is under active development. It has originally been written for Kubuntu and was tied to Apt but it gained a preminarily PackageKit back-end in 2013. The idea is to make Muon 2.1 ready for production use in Fedora.
Knowledge prerequisite: C++, Qt/KDE development
Skill level: Medium
Contacts: https://projects.kde.org/projects/extragear/sysadmin/muon
Mentor(s): ?? (Aleix Pol Gonzalez is a confirmed mentor for a similar Debian proposal)
Notes: Debian has a similar proposal. Even though that one would focus on the Apt back-end, their tasks of cleaning up ubuntuisms would benefit Fedora as well.
Git shell prompt daemon
Status: Proposed
Summary of idea: Fedora packaging is heavily dependant on git. Without specialized git tools, maintenance of tens or hundreds of Fedora packages can become tedious.
This project is about implementing a deamon which would listen on named pipe to requests from system shell (like bash) and it would respond with command line prompt dependant on context (like status of git repository in given directory) and user configuration.
The core of the daemon should not rely on git, but instead be written using plugin framework allowing different plugins to be implemented. Each plugin could provide different information to be displayed in shell prompt.
Besides the core, a git plugin should be implemented. This plugin should not call git executable, but instead use a git library (such as libgit2 which has bindings for many languages).
Knowledge prerequisite: Git, Linux, any programming language which has bindings for libgit2
Skill level: Medium
Contacts: Mikolaj Izdebski
Mentor(s): Mikolaj Izdebski, Stanislav Ochotnicky (backup)
Notes:
Improving Fedora Packager for Eclipse
Status: Proposed
Summary of idea: This project is about implementing new Eclipse plugins and contrubuting them to eclipse-fedorapackager project.
- Copr integration
This plugin should provide interface for Copr. It should allow obtaining API token using login/password, launching builds, querying build statuses. Ideally full Copr API would be implemented, even if it is not used in GUI. This plugin should provide command(s) in Fedora Packaging perspective.
- Fedora Infrastructure Message Bus integration
This plugin should provide Java API and implementation for datagrepper. It should also provide a SWT widget which would allow accessing past events and filtering them by specified criteria. Optional Mylyn integration is also welcome (for example failing build creates a Mylyn task).
Knowledge prerequisite: Java, Eclipse plugin development
Skill level: Medium
Contacts: Mikolaj Izdebski, Alexander Kurtakov
Mentor(s): Mikolaj Izdebski, Alexander Kurtakov
Notes:
Eclipse plugin for XMvn
Status: Proposed
Summary of idea: This project ia about creating an Eclipse plugin for editing XMvn configuration in Eclipse.
The plugin should:
- implement Java model(s) for XMvn configuration
- allow reading and writing model(s) as XML files
- implement configuration editor providing raw XML view and one or more high-level views
- allow converting configuration to sequence of RPM macro calls
XMvn plugin should integrate with Eclipse Linux Tools and/or Fedora Packager for Eclipse where possible (adding commands in perspectives, integration with spec file editor etc.)
Knowledge prerequisite: Java, Eclipse plugin development
Skill level: Medium
Contacts: Mikolaj Izdebski, Alexander Kurtakov
Mentor(s): Mikolaj Izdebski, Alexander Kurtakov
Notes:
Implement a battery of unit tests for SSSD
Status: Proposed
Summary of idea: The purpose of this project is to develop a suite of unit tests for the SSSD. The unit tests would leverage mock objects to be able to exercise code that is otherwise only ever reachable when the SSSD is connected to the network. Contributing the set of unit tests to the SSSD would greatly improve its stability long-term and would help raise confidence when pushing new SSSD versions into Fedora or other distributions.
Knowledge prerequisite: Python scripting, Linux system services knowledge, basic LDAP knowledge is helpful but not needed.
Skill level: intermediate to high
Contacts: Jakub Hrozek
Mentor(s): Jakub Hrozek
Notes: