From Fedora Project Wiki

Revision as of 16:52, 5 March 2015 by Kragniz (talk | contribs)

Open For Ideas ! - This page is open for Ideas !, This page contains ideas from last year, that necessarily does not mean that they are valid for this year too. We are in the process of cleaning up the page.

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

GSOC 2015

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. You also should find some like-minded people on the #fedora-summer-coding IRC channel.

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.

  1. The Foundation
  2. Fedora Documentation (Users/ Contributors)
  3. How to work with IRC?
  4. Fedora Account System
  5. 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.

  1. Stephen Gallagher
  2. Lali Devamanthri

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 switching 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
  • Sigul
  • 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: kushal at fedoraproject dot org

Mentor(s): Kushal Das

co-Mentor(s): Sarup Banskota


TL;DR 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.

Multimonitor wallpaper submission and download for Nuancier

Status: Proposed

Summary of idea: Purpose for this project is to extend Nuancier, Fedoras supplemental wallpaper submission application with an system that allow to submit and downlad wallpapers for multi-monitor setup.

Knowledge prerequisite: some Python knowledge

Skill level: starter

Contacts: Sirko Kemter gnokii@fedoraproject.org

Mentor(s): Pierre-Yves Chibon, Sirko Kemter

Cockpit UI for Rolekit

Status: Proposed Summary of idea: The Rolekit Project provides a platform API for deploying Server Roles onto a system. Currently, it supports creating a Domain Controller (based on FreeIPA) or a Database Server (based on PostgreSQL). A major component of the Fedora Server is the Cockpit Project, a web-based management console for servers. The goal of this effort would be to enhance the Cockpit UI so that an administrator could deploy these Roles using rolekit via the Cockpit web interface.

Knowledge prerequisites: JavaScript (ideally jQuery). Preferred familiarity with D-BUS.

Skill Level: Beginner to intermediate

Contacts: Stephen Gallagher

Mentor(s): Stephen Gallagher

Success Conditions: A user of the Cockpit UI must be able to deploy a Domain Controller while providing the minimum set of necessary information to the UI. The UI must optionally allow more advanced settings to be selected. The UI must also provide a link post-deployment that allows the user to browse to the Domain Controller administration UI. Providing the same functionality for the Database Server role would be bonus functionality for this project, provided that the Domain Controller is completed early.

Shumgrepper/summershum

Status: Proposed

Summary of idea: Finish and deploy the shumgrepper project

Knowledge prerequisite: python, flask, sqlalchemy and some system administration

Skill level: Intermediate

Contacts: Pierre-Yves Chibon

Mentor(s): Pierre-Yves Chibon Ralph Bean

Notes: shumgrepper was started last year and offers an API to query the data stored by summershum. This data corresponds to the md5, sha1, sh256 and sha512 of every files in every packages in Fedora, allowing to easily find out files duplicated in multiple packages.

Dev instance: http://209.132.184.120/

fresque

Status: Proposed

Summary of idea: Fedora Review Server: take package reviews off bugzilla

Knowledge prerequisite: python, flask, sqlalchemy and some ideas about packaging

Skill level: Intermediate

Contacts: Aurélien Bompard

Mentor(s): Aurélien Bompard

Notes: fresque aims at providing a dedicated application for package (RPM) reviews. This would be integrate with a git backend and integrates the fedora-review tool for automatic testing of new reviews and changes.

Fedora Patch Tracker

Status: Proposed

Summary of idea: Create/adjust a webapp to track patches that are used in Fedora and other distributions

Knowledge prerequisite: Python programming, web application development

Skill level: Intermediate

Contacts: Till Maas

Mentor(s): Till Maas

Notes: There was a patch tracker for Debian that should be ported to Fedora or made generic for several distributions. Rough roadmap:

  • Get the patch tracker running on a test system, maybe with some example debian packages
  • Port it for one example Fedora package
  • Port it to a modern web framework such as Flask or Pyramid
  • Make sure it is PEP8 compliant
  • Make it generic to work for Fedora and Debian
  • Add feature to patches that are present only in Fedora or Debian
  • Add more distros, e.g. OpenSUSE, Arch, Ubuntu, Gentoo
  • References: http://oss-security.openwall.org/wiki/distro-patches

Better OVAL development tools in OpenSCAP

Status: Proposed

Summary of idea: The OpenSCAP project implements the Security Content Automation Protocol standards. It provides users with a way to automatically audit their infrastructure. One of the standards is OVAL - Open Vulnerability and Assessment Language - it is the language in which the automated checks are written. Unfortunately the check authors have it tough right now. They have to edit XML files manually, there is no debugger, no static analysis of any sort (like pylint or cppcheck). To make matters worse the OVAL checks are hard to write and the learning curve is steep.

Knowledge prerequisites: Intermediate C, familiarity with the OpenSCAP project

Skill Level: Intermediate

Contacts: Martin Preisler

Mentor(s): Martin Preisler

Success Conditions: SCAP content developers are able to interactively debug their checks, they can browse the execution, looking at inputs and outputs of each step. They are able to analyze their OVAL content for common mistakes using the lint-like tool. Such common mistakes include ID mismatches, wrong usage of regexes, ...

Open Ideas From GSoC 2014

Despite the list of ideas, you may want to check out the ideas of the previous years and contact the admins to see if they are still interested in mentoring someone this year.

Previous years:

Please: Do not submit a proposal for an idea from a previous year without previously contacting the admin to ensure their will to mentor someone this year. Without mentor, proposals will be rejected.