From Fedora Project Wiki

 
(71 intermediate revisions by 16 users not shown)
Line 1: Line 1:
{{Admon/tip | 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 [[GSOC Guide students|GSoC Getting Started Guide]].
}}
 
 
 
Find an idea you like?  Want to propose your own?  See the Getting Started Guide with GSoC:
 
 
 
[[GSOC 2014]]
 
 
 
You may be interested in ideas from [[Summer_coding_ideas_for_2014|2014]] [[Summer_coding_ideas_for_2013|2013]], [[Summer_coding_ideas_for_2012|2012]], [[Summer_coding_ideas_for_2011|2011]], [[Summer_coding_ideas_for_2010|2010]], [[Summer_coding_ideas_for_2009|2009]] and [[Summer_coding_ideas_for_2008|2008]].
 
  
 
Further, last year accepted ideas from the Fedora Project can be found at [http://www.google-melange.com/gsoc/org/google/gsoc2014/fedora GSoC 2014 web site]
 
Further, last year accepted ideas from the Fedora Project can be found at [http://www.google-melange.com/gsoc/org/google/gsoc2014/fedora GSoC 2014 web site]
Line 12: Line 5:
 
== Students Welcome ==
 
== 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 [[FAS|Fedora Account System(FAS)]] if you are willing to continue with the Fedora project. <code>#fedora-devel</code>, IRC channel can be used to get instant support.
+
If you are a student looking forward to participate the GSoC 2016 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 <code>#fedora-summer-coding</code> IRC channel.
 +
 
 +
If you are new to The Fedora project, the following material would help you to get started. Further please sign-up with the [[FAS|Fedora Account System(FAS)]] if you are willing to continue with the Fedora project. <code>#fedora-devel</code>, IRC channel can be used to get instant support.
  
 
# [[Foundation|The Foundation]]
 
# [[Foundation|The Foundation]]
 
# [http://docs.fedoraproject.org/en-US/index.html Fedora Documentation (Users/ Contributors)]
 
# [http://docs.fedoraproject.org/en-US/index.html Fedora Documentation (Users/ Contributors)]
# [[Communicate/IRCHowTo|How to work with IRC?]]
+
# [[Communicate/IRCHowTo|How to work with IRC?]] [https://fedoramagazine.org/begginers-guide-to-irc Beginner's Guide to IRC]
 
# [[FAS|Fedora Account System]]  
 
# [[FAS|Fedora Account System]]  
 
# [[Development]]
 
# [[Development]]
Line 22: Line 17:
 
== Supporting Mentors ==
 
== 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.
+
Following contributors are also willing to support the GSoC 2016 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.
  
[[User:Sgallagh|Stephen Gallagher]]
+
#[[User:Sgallagh|Stephen Gallagher]]
 +
#[[User:Lsd|Lali Devamanthri]]
 +
#[[User:corey84|Corey Sheldon]] (linuxmodder)
  
 
==Draft of an idea==
 
==Draft of an idea==
Line 47: Line 44:
 
'''!!!The draft was changed slightly, please add required field as required!!!'''
 
'''!!!The draft was changed slightly, please add required field as required!!!'''
  
== Idea list for GSoC 2015 ==
+
== Idea list for GSoC 2016 ==
  
==== AskFedora UX/UI & Functionality Overhaul ====
+
 
 +
=== Implement Tinykdump ===
  
 
''Status:'' Proposed - draft
 
''Status:'' Proposed - draft
  
''Summary of idea:''  
+
''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:'' [[User:caiqian|CAI Qian]]
 +
 
 +
''Mentor(s):'' [[User:caiqian|CAI Qian]]
  
[https://ask.fedoraproject.org/  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 [http://askubuntu.com/ 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.
+
''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.
  
'' 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.
+
=== Improve Fedora Review ===
  
''Status right now: '' Mockups during the last Design Fedora Activity Day (FAD) 2015 were done. Checkout [https://suchakra.wordpress.com/2015/01/20/ask-fedora-ux-redesign-updates-1/ this] and [https://suchakra.wordpress.com/2015/01/21/ask-fedora-ux-redesign-updates-2/ this] blogpost for latest updates on mockups. An [http://askbotstg-suchakra.rhcloud.com/questions/  openshift instance] has also been created and source for testing [https://github.com/fedoradesign/askbot-test repository] is available for setting up your own staging instance.
+
''Status:'' Proposed - draft
  
''Knowledge prerequisites:'' Front-end (HTML/CSS/JS) development, UI/UX design experience, some knowledge of Django/Python
+
''Summary of idea:'' Every package that is included into Fedora needs to go through a review to ensure it matches the [[Packaging:Guidelines]]. [https://fedorahosted.org/FedoraReview/ Fedora Review] is a tool to help with the review. It needs constant development to be updated for changes in the guidelines. Also there is currently no process to ensure that existing packages adhere to the packaging guidelines. This project is meant to improve this.
  
''Skill level:'' Beginner/Intermediate
+
''Knowledge prerequisite:'' Python 2&3 programming skills
  
''Contacts:'' suchakra at fedoraproject dot org
+
''Skill level:'' intermediate (programming)
  
''Mentor(s):''  
+
''Contacts:'' [[User:Leamas|Alec Leamas]], [[User:Till|Till Maas]]
  
TD;LR The infra and some ideas for testing is all ready, we need someone to improve AskFedora's UI/UX.
+
''Mentor(s):'' [[User:Till|Till Maas]]
  
 +
''Notes:''
 +
Possible tasks:
  
==== Glitter Gallery Improvements ====
+
* Make Fedora Review PEP8 compliant, fix its current test cases
 +
* Help running Fedora Review regularly for existing packages e.g., updating the Jenkins continuous builds and/or integrate it into [[Taskotron]]
 +
* Add static code checker support to Fedora Review (e.g. with [https://git.fedorahosted.org/git/csmock.git csmock])
 +
* Build a web service mockup supporting the review process [http://fedoraproject.org/wiki/Package_Review_Process] replacing current bugzilla workflow.
  
 +
=== Enhance Fedora build setup ===
 
''Status:'' Proposed - draft
 
''Status:'' Proposed - draft
  
''Summary of idea:''  
+
''Summary of idea:'' Fedora uses the [http://koji.fedoraproject.org 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.
  
[[Design/GlitterGallery | 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
+
''Knowledge prerequisite:'' Python programming skills, ideally some packaging knowledge
* [http://sparkleshare.org Sparkleshare] - a git-backed, Dropbox like system that will automatically check in and push files in project directly to a shared git repo
 
* [https://github.com/garrett/magicmockup Magic Mockup] - a javascript library you can insert into an SVG of mockups to enable interactive, click-through mockups ([http://blog.linuxgrrl.com/2011/08/12/interactive-svg-mockups-with-inkscape-javascript/ see a demo here]
 
* [http://inkscape.org 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.
+
''Skill level:''  intermediate (programming), high (understanding/analysing code, GNU/Linux)
* 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
+
''Contacts:'' [[User:Till|Till Maas]], [[User:Ausil|Dennis Gilmore]], {{fpchat|#fedora-releng}}
  
''Skill level:'' Intermediate
+
''Mentor(s):''[[User:Till|Till Maas]], [[User:Ausil|Dennis Gilmore]]
  
''Contacts:'' emichan at fedoraproject dot org, sarupbanskota at fedoraproject dot org
+
''Notes:''
 +
Rough roadmap:
 +
* Make select [https://fedorahosted.org/rel-eng/ releng scripts] PEP8 compliant/python3 ready
 +
* Make other python tools PEP8 compliant, python3 ready:
 +
** [https://fedorahosted.org/fedpkg/ fedpkg]
 +
** [https://git.fedorahosted.org/cgit/mash/ mash]
 +
** [https://fedorahosted.org/rpkg/ rpkg]
 +
* 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
  
''Mentor(s):'' [[User:Emichan | Emily Dirsh]], [[User:Sarupbanskota | Sarup Banskota]]
+
=== Improve Sigul Signing Server ===
  
''Notes:'' The [https://github.com/glittergallery/GlitterGallery GlitterGallery repository] is hosted on GitHub.
+
''Status:'' Proposed - draft
  
== Open Ideas From GSoC 2014 ==
+
''Summary of idea:'' The [https://fedorahosted.org/sigul/ Sigul] signing server is used by release engineering to [[Release_package_signing|sign Fedora RPMs]] when [[pushing fedora updates]]. There are two major problems that make it hard to release updated packages in a timely manner: It crashes and it cannot be used simultaneously.
  
==== FedmsgSobumper ====
+
''Knowledge prerequisite:'' Python programming skills, ideally some background knowledge about GPG, security and networking
  
''Status:'' Proposed (as a maturity level in [http://tools.ietf.org/html/rfc6410 RFC6410])
+
''Skill level:'' intermediate (programming), high (understanding/analysing code, GNU/Linux)
  
''Summary of idea:'' Automatically rebuild the whole dependency subtree in rawhide if any ABI-backwards-incompatible so-bump occures.
+
''Contacts:'' [[User:Till|Till Maas]], [[User:Ausil|Dennis Gilmore]], [[User:ralph|Ralph Bean]], {{fpchat|#fedora-releng}}
  
''Knowledge prerequisite:'' Python, shell
+
''Mentor(s):'' [[User:Till|Till Maas]], [[User:Ausil|Dennis Gilmore]], [[User:ralph|Ralph Bean]]
  
''Skill level:'' Low-Medium
+
''Notes:''
 +
Rough roadmap:
 +
* To test whether everything works, a test instance needs to be setup. This is rather complex because it requires interaction with [[koji]]. Maybe it is possible to add a test instance to [[Infrastructure]] that can use the koji staging system, but the latter is not fully functional right now.
 +
* Debug why sigul hangs sometimes when using the [https://git.fedorahosted.org/cgit/sigul.git/tree/src/client.py#n1090 sign-rpms] command (called by <code>--batch-size</code> greater than one with <code>sigulsign_unsigned.py</code>
 +
* Enable sigul to process multiple tasks at once, e.g. sign for multiple releases or architectures at once.
 +
* Fix other bugs/issues, examples:
 +
** Currently [http://linux.die.net/man/8/logrotate logrotate] does not make sigul properly re-open its logfiles, which is why sigul does not log to the new logfile after rotation. This needs to be fixed in sigul
 +
** The GPG defaults in sigul might not be up-to-date, they should be reviewed and improved if necessary
 +
** Add support for e.g. signing and revoking GPG keys, to build a local web of trust between [https://getfedora.org/keys/ Fedora release keys]
  
''Contacts:'' jpacner @ @ redhat @ @ com
+
Ressources:
 +
* [https://git.fedorahosted.org/cgit/releng/tree/scripts/sigulsign_unsigned.py Script used by rel-eng to run sigul]
 +
* [https://git.fedorahosted.org/cgit/sigul.git/tree/doc/protocol-design.txt Protocol description]
  
''Mentor(s):'' jpacner @ @ redhat @ @ com
+
=== AskFedora UX/UI & Functionality Overhaul ===
  
''Notes:'' The script will be hooked to [http://www.fedmsg.com/en/latest/ Fedmsg bus] and should be as small as possible (for details, please contact the mentor). This will save rawhide contributors much time.
+
''Status:'' Proposed - draft
  
==== Bugspad ====
+
''Summary of idea:''
  
''Status:''  Proposed
+
[https://ask.fedoraproject.org/  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 [http://askubuntu.com/ 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.
  
''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.
+
'' 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.
  
Project details can be found at http://bugspad.readthedocs.org/en/latest/
+
''Status right now: '' Mockups during the last Design Fedora Activity Day (FAD) 2015 were done. Checkout [https://suchakra.wordpress.com/2015/01/20/ask-fedora-ux-redesign-updates-1/ this] and [https://suchakra.wordpress.com/2015/01/21/ask-fedora-ux-redesign-updates-2/ this] blogpost for latest updates on mockups. An [http://askbotstg-suchakra.rhcloud.com/questions/ openshift instance] has also been created and source for testing [https://github.com/fedoradesign/askbot-test repository] is available for setting up your own staging instance.
  
Minimal required TODO
+
''Knowledge prerequisites:'' Front-end (HTML/CSS/JS) development, UI/UX design experience, some knowledge of Django/Python
  
* Fully working frontend, primary idea is to go fully selfhosted. All bugs should be filed in that instance against Bugspad.
+
''Skill level:'' Beginner/Intermediate
  
 +
''Contacts:'' kushal at fedoraproject dot org, suchakra at fedoraproject dot org
  
''Knowledge prerequisite:''  
+
''Mentor(s):'' [[User:Kushal | Kushal Das]], [[User:Suchakra | Suchakra]]
 
  * 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
+
''co-Mentor(s):'' [[User:Sarupbanskota | Sarup Banskota]]
  
''Contacts:'' kushal AT fedoraproject DOT org
 
  
''Mentor(s):'' Kushal Das
+
TL;DR The infra and some ideas for testing is all ready, we need someone to improve AskFedora's UI/UX.
  
''Notes:'' The backend is written in golang. Before you start talking have at least one instance up somewhere (hints: your laptop).
+
=== Glitter Gallery Improvements ===
  
==== Waartaa ====
+
''Status:'' Proposed - draft
  
'''Status:''' Proposed
+
''Summary of idea:''  
  
'''Summary of idea:''' Waartaa is an open source communication tool for teams and
+
[[Design/GlitterGallery | 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
groups. It is built on top of IRC. Currently, Waartaa is an IRC client as a
+
* [http://sparkleshare.org Sparkleshare] - a git-backed, Dropbox like system that will automatically check in and push files in project directly to a shared git repo
service and it supports centralized logging, 24x7 idling, notifications and
+
* [https://github.com/garrett/magicmockup Magic Mockup] - a javascript library you can insert into an SVG of mockups to enable interactive, click-through mockups ([http://blog.linuxgrrl.com/2011/08/12/interactive-svg-mockups-with-inkscape-javascript/ see a demo here]
unique identity to a user on IRC. You can visit the project’s homepage:
+
* [http://inkscape.org Inkscape] is our preferred design tool of choice
https://www.waartaa.com for more details. A demo instance of Waartaa is hosted
 
at https://try.waartaa.com.
 
  
Roadmap:
+
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
  
* Build a central hub for searching/reading channel logs for Open Source communities and projects.
+
''Knowledge prerequisites:'' git, Ruby on Rails, front-end (HTML/CSS/JS) development, design experience would be great but optional
* 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:'' Intermediate
  
'''Skill level:''' Medium
+
''Contacts:'' emichan at fedoraproject dot org, sarupbanskota at fedoraproject dot org
  
'''Contacts:'''
+
''Mentor(s):'' [[User:Emichan | Emily Dirsh]], [[User:Sarupbanskota | Sarup Banskota]], [[User: Rohitpaulk | Rohit Paul Kuruvilla]]
* rtnpro at fedoraproject dot org
 
* sayanchowdhury at fedoraproject dot org
 
  
'''Mentor(s):''' [[User:Rtnpro|Ratnadeep Debnath]], [[User:Kushal|Kushal Das]], [[User:Sayanchowdhury|Sayan Chowdhury]]
+
''Notes:'' The [https://github.com/glittergallery/GlitterGallery GlitterGallery repository] is hosted on GitHub.
  
'''Notes:'''
+
=== Multimonitor wallpaper submission and download for Nuancier===
  
==== Afterthought ====
+
''Status:'' Proposed
  
'''Status:''' Proposed
+
''Summary of idea:'' Purpose for this project is to extend [https://apps.fedoraproject.org/nuancier/ Nuancier], Fedoras supplemental wallpaper submission application with an system that allow to submit and downlad wallpapers for multi-monitor setup.
  
'''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.
+
Knowledge prerequisite: some Python knowledge
  
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).
+
''Skill level:'' starter
  
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 <s>know</s> get what I mean. Other such possibilities are:
+
''Contacts:'' Sirko Kemter gnokii@fedoraproject.org
  $ 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
+
''Mentor(s):'' [[User:Pingou | Pierre-Yves Chibon]], [[User:Gnokii  | Sirko Kemter]]
  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).
+
=== Cockpit UI for Rolekit ===
 +
''Status:'' Proposed
 +
''Summary of idea:'' The [https://fedorahosted.org/rolekit Rolekit Project] provides a platform API for deploying Server Roles onto a system. Currently, it supports creating a Domain Controller (based on [http://freeipa.org FreeIPA]) or a Database Server (based on [http://www.postgresql.org/ PostgreSQL]). A major component of the Fedora Server is the [http://cockpit-project.org 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 prerequisite:''' *nix && (Rust || C/C++ || Go) && (Node.js::FlatIron/Express || Python::Flask/Pyramids || Ruby::Rails/Camping)
+
''Knowledge prerequisites:'' JavaScript (ideally jQuery). Preferred familiarity with D-BUS.
  
'''Skill level:''' Intermediate
+
''Skill Level:'' Beginner to intermediate
  
'''Contacts:''' [[User:Debloper|Soumya Deb (Debloper)]]
+
''Contacts:'' [[User:Sgallagh|Stephen Gallagher]]
  
'''Mentor(s):''' [[User:Debloper|Soumya Deb (Debloper)]]
+
''Mentor(s):'' [[User:Sgallagh|Stephen Gallagher]]
  
'''Notes:'''
+
''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.
  
<!-- Interested students:  
+
=== Cockpit support for systemd timers ===
[[User:Arcolife|Archit Sharma]] Dibs!, [[User:Ahi| Ahmed Hisham]] -->
+
''Status'': Proposed Summary of idea: systemd provides timers for calendar time events and monotonic time events (http://www.freedesktop.org/software/systemd/man/systemd.timer.html, https://wiki.archlinux.org/index.php/Systemd/Timers). 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. Some preliminary designs for timers in Cockpit exist at https://trello.com/c/1B2lZViZ/74-timers-and-cron, although these are just intended as guidelines to get started.
  
 +
''Knowledge prerequisites'': JavaScript (ideally jQuery). Preferred familiarity with D-BUS.
  
==== Web hosting control panel ====
+
''Skill Level'': Beginner to intermediate
  
''Status:'' Proposed - Draft
+
''Contacts'': [[User:Sgallagh|Stephen Gallagher]]
  
''Summary of idea:''
+
''Mentor(s)'': Dominik Perpeet, [[User:Sgallagh|Stephen Gallagher]]
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...
+
''Success Conditions'': A user of the Cockpit UI must be able to view existing timers, edit existing ones or create new timers while providing the minimum set of necessary information to the UI. The UI must optionally allow more advanced settings to be selected.
  
''Knowledge prerequisite:'' apache, postfix, dovecot, mysql, postgresql, proftpd, bind
+
=== Docker Volume Support in Cockpit ===
 +
''Status'': Proposed Summary of idea: Docker (https://www.docker.com/) allows building, running, and sharing of software in containers. A major component of the Fedora Server is the Cockpit Project, a web-based management console for servers. Docker is already supported in Cockpit, including features such as downloading images, running/stopping/deleting containers, exposing additional ports, inspecting console output as well as linking containers. The goal of this effort would be to enhance the Cockpit UI so that an administrator can use Docker 'Data volumes' (http://docs.docker.com/userguide/dockervolumes/) via the Cockpit web interface. Some preliminary designs for Docker Volume Support in Cockpit exist at https://trello.com/c/4juwxCaE/94-docker-volume-support, although these are just intended as guidelines to get started.
  
''Skill level:'' Medium
+
''Knowledge prerequisites'': JavaScript (ideally jQuery). Preferred familiarity with D-BUS.
  
''Contacts:'' itamarjp [AT] fedoraproject [DOT] org, kaustubh [DOT] karkare [AT] gmail [DOT] com
+
''Skill Level'': Beginner to intermediate
  
''Mentor(s):'' [[User:lbazan|Luis Bazan]]
+
''Contacts'': [[User:Sgallagh|Stephen Gallagher]]
  
''Co-Mentor:'' [[User:echevemaster|Eduardo Echeverria]]
+
''Mentor(s)'': Dominik Perpeet, [[User:Sgallagh|Stephen Gallagher]]
  
''Notes:''
+
''Success Conditions'': A user of the Cockpit UI must be able to create, view and (to a sensible extent) edit Docker 'Data Volume Containers' while providing the minimum set of necessary information to the UI. It should also be possible to select host directories or host files as Data Volumes. The UI must optionally allow more advanced settings to be selected. Optionally this can be extended by further functionality, such as backup, restoration or migration of data volumes.
[[User:Itamarjp/gsoc-2012|webhosting control panel draft]]
 
  
==== Infrastructure for FreeMedia group ====
+
=== Shumgrepper/summershum ===
  
 
''Status:'' Proposed
 
''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.
+
''Summary of idea:'' Finish and deploy the shumgrepper project
 +
 
 +
''Knowledge prerequisite:'' python, flask, sqlalchemy and some system administration
 +
 
 +
''Skill level:'' Intermediate
  
''Knowledge prerequisite:'' PHP, PostgreSQL
+
''Contacts:'' [[User:pingou|Pierre-Yves Chibon]]
  
''Skill level:'' Medium
+
''Mentor(s):'' [[User:pingou|Pierre-Yves Chibon]] [[User:ralph|Ralph Bean]]
  
''Contacts:'' [[User:bckurera|bckurera]]
+
''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.
  
''Mentor(s):''
+
Dev instance: http://209.132.184.120/
  
''Notes:''
+
=== fresque ===
  
=== Collaboration projects with other organizations ===
+
''Status:'' Proposed
  
* TBA
+
''Summary of idea:'' Fedora Review Server: take package reviews off bugzilla
  
=== Muon – KDE package management ===
+
''Knowledge prerequisite:'' python, flask, sqlalchemy and some ideas about packaging
  
''Status:'' Proposed
+
''Skill level:'' Intermediate
  
''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.
+
''Contacts:'' [[User:abompard|Aurélien Bompard]]
  
''Knowledge prerequisite:'' C++, Qt/KDE development
+
''Mentor(s):'' [[User:abompard|Aurélien Bompard]]
  
''Skill level:'' Medium
+
''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.
  
''Contacts:'' https://projects.kde.org/projects/extragear/sysadmin/muon
+
=== Patch Tracker ===
 +
''Status:'' Proposed
  
''Mentor(s):'' ?? (Aleix Pol Gonzalez is a confirmed mentor for a [https://wiki.debian.org/SummerOfCode2014/Projects/Get%20Muon%20ready similar Debian proposal])
+
''Summary of idea:'' One of Fedoras goals as a distribution is [[staying close to upstream projects]]. However, sometimes it is necessary for Fedora packages to deviate from upstream, for example if upstream is dead or if a fix is backported to an older release. Also other distributions sometimes carry patches that are not submitted upstream but fix bugs also present in Fedora packages. Therefore it is interesting for Fedora packagers or packagers of other distributions to get easy access to information about patches. Fedora already contains a web app, that shows information about patches in Fedora, for example the [https://apps.fedoraproject.org/packages/ipython/sources/ patches for the ipython package]. However, this is not a designated app to make the patch information as useful as possible and does not contain support for other distros. Debian used to provide a [https://anonscm.debian.org/cgit/users/seanius/patch-tracker.git/tree/ patch tracker] that is currently offline due to a missing maintainer. For other distributions, there only [http://oss-security.openwall.org/wiki/distro-patches manual methods] to find out about patches. Therefore the idea is to create a web application with the purpose to make it easier for others to find patches in Fedora and to make it easier for Fedora maintainers to find patches in other distributions.
 +
FedoraCreate/adjust a webapp to track patches that are used in Fedora and other distributions
  
''Notes:'' [https://wiki.debian.org/SummerOfCode2014/Projects/Get%20Muon%20ready 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.
+
''Knowledge prerequisite:'' Python programming, web application development
  
 +
''Skill level:'' Intermediate
  
=== Git shell prompt daemon ===
+
''Contacts:'' [[User:till|Till Maas]]
  
''Status:'' Proposed
+
''Mentor(s):'' [[User:till|Till Maas]]
  
''Summary of idea:''
+
''Notes:''
Fedora packaging is heavily dependant on git. Without specialized git
+
Potential features:
tools, maintenance of tens or hundreds of Fedora packages can become
+
* Show a clear overview for patches in Fedora for a certain package
tedious.
+
** Link to bugs that were mentioned, extract key information from the bug
 +
* Allow to get notifications for new patches, e.g. via fedmsg
 +
* Allow to get information about patches for the package in other distros
 +
* Try to figure out if patches are already upstream
 +
* ...
  
This project is about implementing a deamon which would listen on
+
Rough potential roadmap:
named pipe to requests from system shell (like bash) and it would
+
* Get the debian patch tracker running on a test system, maybe with some example debian packages
respond with command line prompt dependant on context (like status of
+
* Port it for one example Fedora package
git repository in given directory) and user configuration.
+
* 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
 +
* Add more features
  
The core of the daemon should not rely on git, but instead be written
+
Basic requirements:
using plugin framework allowing different plugins to be implemented.
+
* Target platform is RHEL/CentOS7 with EPEL
Each plugin could provide different information to be displayed in
+
* All dependencies should be available on the target platform as RPM packages or possible to be packaged (e.g. requiring newer versions of packages already included in the target platform might not be easily possible)
shell prompt.
+
* It needs to be possible to package the final project for Fedora/EPEL, i.e. there may not be bundled libraries included
 +
* The code needs to be PEP8 compliant and contain proper docstrings
 +
* Proper automtatic tests should be included to allow meaningful continuous integration
  
Besides the core, a git plugin should be implemented.  This plugin
+
Recommended basic knowledge:
should not call git executable, but instead use a git library (such as
+
* Know about PEP8, pylint, continuous integration,
libgit2 which has bindings for many languages).
+
* Understand the different diff formats
  
''Knowledge prerequisite:'' Git, Linux, any programming language which has bindings for [http://libgit2.github.com/ libgit2]
+
=== Better OVAL development tools in OpenSCAP ===
 +
''Status:'' Proposed
  
''Skill level:'' Medium
+
''Summary of idea:'' The [https://www.open-scap.org 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.
  
''Contacts:'' [[User:Mizdebsk|Mikolaj Izdebski]]
+
''Knowledge prerequisites:'' Intermediate C, familiarity with the OpenSCAP project
  
''Mentor(s):'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Sochotni|Stanislav Ochotnicky]] (backup)
+
''Skill Level:'' Intermediate
  
''Notes:''
+
''Contacts:'' [[User:Mpreisle|Martin Preisler]]
  
=== Improving Fedora Packager for Eclipse ===
+
''Mentor(s):'' [[User:Mpreisle|Martin Preisler]]
  
''Status:'' Proposed
+
''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, ...
  
''Summary of idea:''
+
=== Fix bugs in packages that break compiling as position independent executable ===
This project is about implementing new Eclipse plugins and
 
contrubuting them to [https://fedorahosted.org/eclipse-fedorapackager/ eclipse-fedorapackager] project.
 
  
; Copr integration
+
''Status:'' proposed
This plugin should provide interface for [https://fedorahosted.org/copr/ 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
+
''Summary of idea:'' Starting with Fedora 23, Fedora will try to ship all binaries as [http://en.wikipedia.org/wiki/Position-independent_code position independent executable] to benefit from the [http://en.wikipedia.org/wiki/Address_space_layout_randomization address space layout randomization (ASLR)] of the Linux kernel to increase the security of Fedoras packages. However, not all code/packages are ready for this, therefore the [[Changes/Harden_all_packages_with_position-independent_code|current change proposal]] plans to handle these cases by just disabling this improvement for affected packages. Ideally all packages would be fixed to not require it to be disabled, this is where you can help.
This plugin should provide Java API and implementation for
 
[https://apps.fedoraproject.org/datagrepper/ 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
+
''Knowledge prerequisite:'' low-level programming skills, compiler development, build systems configuration, maybe python programming skills
  
''Skill level:'' Medium
+
''Skill level:'' intermediate to high, depending on the actual problem
  
''Contacts:'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Akurtakov|Alexander Kurtakov]]
+
''Contacts:'' [[User:Orion|Orion Poplawski]], [[User:till|Till Maas]], [[User:halfie|Dhiru Kholia]], {{fpchat|#fedora-devel}}
  
''Mentor(s):'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Akurtakov|Alexander Kurtakov]]
+
''Mentor(s):'' [[User:Orion|Orion Poplawski]], [[User:till|Till Maas]], [[User:halfie|Dhiru Kholia]]
  
 
''Notes:''
 
''Notes:''
 +
Currently not all Fedora packages were rebuilt with the new hardening flags, therefore it is not yet clear how many packages need to be fixed. However, it might be that there are also some languages that need to be adjusted in general to produce position-independent code (for example go), so adding support to (some) of these languages would be in the scope of this project as well, after all build failures were handled. Additionally Fedora tools like [https://fedorahosted.org/FedoraReview/ Fedora Review] and [[Taskotron]] should be adapted to properly report packages that are not built with the hardening flags for example by running <nowiki>checkseck</nowiki> on all created executables.
  
=== Eclipse plugin for XMvn ===
+
Example problems that block some packages to be built with the right flags:
 +
* https://bugzilla.redhat.com/show_bug.cgi?id=1199775
  
''Status:'' Proposed
+
Helpful documentation:
 +
* [[Using Mock to test package builds]]
  
''Summary of idea:''
+
=== Enhance PostgreSQL GSSAPI Support ===
This project ia about creating an Eclipse plugin for editing [http://mizdebsk.fedorapeople.org/xmvn/ XMvn] [http://mizdebsk.fedorapeople.org/xmvn/site/config.html configuration] in Eclipse.
 
  
The plugin should:
+
''Status:'' proposed
* 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
+
''Summary of idea:'' The Fedora Server Edition includes a Database Server Role powered by a PostgreSQL database. In order to integrate it better with Fedora Server's Domain Controller, we want to enhance the GSSAPI authentication and communication in the server.
Packager for Eclipse where possible (adding commands in perspectives,
 
integration with spec file editor etc.)
 
  
''Knowledge prerequisite:'' Java, Eclipse plugin development
+
''Knowledge prerequisite:'' C Programming, Kerberos/GSSAPI
  
''Skill level:'' Medium
+
''Skill level:'' intermediate to high (probably grad-student level)
  
''Contacts:'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Akurtakov|Alexander Kurtakov]]
+
''Contacts:'' [[User:Sgallagh|Stephen Gallagher]], [[User:Simo|Simo Sorce]]
  
''Mentor(s):'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Akurtakov|Alexander Kurtakov]]
+
''Mentor(s):'' [[User:Simo|Simo Sorce]]
  
''Notes:''
+
''Notes:'' This will require modifications to the authentication subsystem as well as the TCP/IP layer of PostgreSQL. It will likely be a very involved project.
  
=== Implement a battery of unit tests for SSSD ===
+
=== Tweak specific packages to play well with MIPS architecture ===
  
''Status:'' Proposed
+
''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.
+
''Summary of idea:'' We are planning to bootstrap Fedora for MIPS architecture. Even though the majority of packages should build with little to no modifications, there are some challenging packages that will need extra attention.
  
''Knowledge prerequisite:'' Python scripting, Linux system services knowledge, basic LDAP knowledge is helpful but not needed.
+
''Knowledge prerequisite:'' C or Python Programming, packaging basics, some idea about non-x86 architectures
  
 
''Skill level:'' intermediate to high
 
''Skill level:'' intermediate to high
  
''Contacts:'' [[User:jhrozek|Jakub Hrozek]]
+
''Contacts:'' [[User:Mtoman|Michal Toman]], [[User:Anibal|Anibal Monsalve Salazar]], [[User:wzssyqa|YunQiang Su]] {{fpchat|#fedora-mips}}
  
''Mentor(s):'' [[User:jhrozek|Jakub Hrozek]]
+
''Mentor(s):'' [[User:Mtoman|Michal Toman]]
  
''Notes:''
+
''Notes:'' Possible work areas:
 +
* kernel
 +
* anaconda
 +
* openjdk
 +
* ghc
 +
* ocaml
 +
* erlang
 +
* fpc
 +
* ...
 +
 
 +
== Open Ideas From GSoC 2016 ==
  
 +
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.
  
=== Applications for Testers ===
+
Previous years:
 +
* [[Summer_coding_ideas_for_2015|2015]]
 +
* [[Summer_coding_ideas_for_2014|2014]]
 +
* [[Summer_coding_ideas_for_2013|2013]]
 +
* [[Summer_coding_ideas_for_2012|2012]]
 +
* [[Summer_coding_ideas_for_2011|2011]]
 +
* [[Summer_coding_ideas_for_2010|2010]]
 +
* [[Summer_coding_ideas_for_2009|2009]]
 +
* [[Summer_coding_ideas_for_2008|2008]]
  
 +
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.
  
[[Category:Summer coding 2015]]
+
[[Category:Summer coding 2016]]

Latest revision as of 15:01, 12 March 2016

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

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 2016 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, the 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? Beginner's Guide to IRC
  4. Fedora Account System
  5. Development

Supporting Mentors

Following contributors are also willing to support the GSoC 2016 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
  3. Corey Sheldon (linuxmodder)

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 2016

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.

Improve Fedora Review

Status: Proposed - draft

Summary of idea: Every package that is included into Fedora needs to go through a review to ensure it matches the Packaging:Guidelines. Fedora Review is a tool to help with the review. It needs constant development to be updated for changes in the guidelines. Also there is currently no process to ensure that existing packages adhere to the packaging guidelines. This project is meant to improve this.

Knowledge prerequisite: Python 2&3 programming skills

Skill level: intermediate (programming)

Contacts: Alec Leamas, Till Maas

Mentor(s): Till Maas

Notes: Possible tasks:

  • Make Fedora Review PEP8 compliant, fix its current test cases
  • Help running Fedora Review regularly for existing packages e.g., updating the Jenkins continuous builds and/or integrate it into Taskotron
  • Add static code checker support to Fedora Review (e.g. with csmock)
  • Build a web service mockup supporting the review process [1] replacing current bugzilla workflow.

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:

  • Make select releng scripts PEP8 compliant/python3 ready
  • Make other python tools PEP8 compliant, python3 ready:
  • 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 when pushing fedora updates. There are two major problems that make it hard to release updated packages in a timely manner: It crashes and it cannot be used simultaneously.

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, Ralph Bean, #fedora-releng[?]

Mentor(s): Till Maas, Dennis Gilmore, Ralph Bean

Notes: Rough roadmap:

  • To test whether everything works, a test instance needs to be setup. This is rather complex because it requires interaction with koji. Maybe it is possible to add a test instance to Infrastructure that can use the koji staging system, but the latter is not fully functional right now.
  • Debug why sigul hangs sometimes when using the sign-rpms command (called by --batch-size greater than one with sigulsign_unsigned.py
  • Enable sigul to process multiple tasks at once, e.g. sign for multiple releases or architectures at once.
  • Fix other bugs/issues, examples:
    • Currently logrotate does not make sigul properly re-open its logfiles, which is why sigul does not log to the new logfile after rotation. This needs to be fixed in sigul
    • The GPG defaults in sigul might not be up-to-date, they should be reviewed and improved if necessary
    • Add support for e.g. signing and revoking GPG keys, to build a local web of trust between Fedora release keys

Ressources:

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, suchakra at fedoraproject dot org

Mentor(s): Kushal Das, Suchakra

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, Rohit Paul Kuruvilla

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.

Cockpit support for systemd timers

Status: Proposed Summary of idea: systemd provides timers for calendar time events and monotonic time events (http://www.freedesktop.org/software/systemd/man/systemd.timer.html, https://wiki.archlinux.org/index.php/Systemd/Timers). 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. Some preliminary designs for timers in Cockpit exist at https://trello.com/c/1B2lZViZ/74-timers-and-cron, although these are just intended as guidelines to get started.

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

Skill Level: Beginner to intermediate

Contacts: Stephen Gallagher

Mentor(s): Dominik Perpeet, Stephen Gallagher

Success Conditions: A user of the Cockpit UI must be able to view existing timers, edit existing ones or create new timers while providing the minimum set of necessary information to the UI. The UI must optionally allow more advanced settings to be selected.

Docker Volume Support in Cockpit

Status: Proposed Summary of idea: Docker (https://www.docker.com/) allows building, running, and sharing of software in containers. A major component of the Fedora Server is the Cockpit Project, a web-based management console for servers. Docker is already supported in Cockpit, including features such as downloading images, running/stopping/deleting containers, exposing additional ports, inspecting console output as well as linking containers. The goal of this effort would be to enhance the Cockpit UI so that an administrator can use Docker 'Data volumes' (http://docs.docker.com/userguide/dockervolumes/) via the Cockpit web interface. Some preliminary designs for Docker Volume Support in Cockpit exist at https://trello.com/c/4juwxCaE/94-docker-volume-support, although these are just intended as guidelines to get started.

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

Skill Level: Beginner to intermediate

Contacts: Stephen Gallagher

Mentor(s): Dominik Perpeet, Stephen Gallagher

Success Conditions: A user of the Cockpit UI must be able to create, view and (to a sensible extent) edit Docker 'Data Volume Containers' while providing the minimum set of necessary information to the UI. It should also be possible to select host directories or host files as Data Volumes. The UI must optionally allow more advanced settings to be selected. Optionally this can be extended by further functionality, such as backup, restoration or migration of data volumes.

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.

Patch Tracker

Status: Proposed

Summary of idea: One of Fedoras goals as a distribution is staying close to upstream projects. However, sometimes it is necessary for Fedora packages to deviate from upstream, for example if upstream is dead or if a fix is backported to an older release. Also other distributions sometimes carry patches that are not submitted upstream but fix bugs also present in Fedora packages. Therefore it is interesting for Fedora packagers or packagers of other distributions to get easy access to information about patches. Fedora already contains a web app, that shows information about patches in Fedora, for example the patches for the ipython package. However, this is not a designated app to make the patch information as useful as possible and does not contain support for other distros. Debian used to provide a patch tracker that is currently offline due to a missing maintainer. For other distributions, there only manual methods to find out about patches. Therefore the idea is to create a web application with the purpose to make it easier for others to find patches in Fedora and to make it easier for Fedora maintainers to find patches in other distributions. FedoraCreate/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: Potential features:

  • Show a clear overview for patches in Fedora for a certain package
    • Link to bugs that were mentioned, extract key information from the bug
  • Allow to get notifications for new patches, e.g. via fedmsg
  • Allow to get information about patches for the package in other distros
  • Try to figure out if patches are already upstream
  • ...

Rough potential roadmap:

  • Get the debian 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
  • Add more features

Basic requirements:

  • Target platform is RHEL/CentOS7 with EPEL
  • All dependencies should be available on the target platform as RPM packages or possible to be packaged (e.g. requiring newer versions of packages already included in the target platform might not be easily possible)
  • It needs to be possible to package the final project for Fedora/EPEL, i.e. there may not be bundled libraries included
  • The code needs to be PEP8 compliant and contain proper docstrings
  • Proper automtatic tests should be included to allow meaningful continuous integration

Recommended basic knowledge:

  • Know about PEP8, pylint, continuous integration,
  • Understand the different diff formats

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, ...

Fix bugs in packages that break compiling as position independent executable

Status: proposed

Summary of idea: Starting with Fedora 23, Fedora will try to ship all binaries as position independent executable to benefit from the address space layout randomization (ASLR) of the Linux kernel to increase the security of Fedoras packages. However, not all code/packages are ready for this, therefore the current change proposal plans to handle these cases by just disabling this improvement for affected packages. Ideally all packages would be fixed to not require it to be disabled, this is where you can help.

Knowledge prerequisite: low-level programming skills, compiler development, build systems configuration, maybe python programming skills

Skill level: intermediate to high, depending on the actual problem

Contacts: Orion Poplawski, Till Maas, Dhiru Kholia, #fedora-devel[?]

Mentor(s): Orion Poplawski, Till Maas, Dhiru Kholia

Notes: Currently not all Fedora packages were rebuilt with the new hardening flags, therefore it is not yet clear how many packages need to be fixed. However, it might be that there are also some languages that need to be adjusted in general to produce position-independent code (for example go), so adding support to (some) of these languages would be in the scope of this project as well, after all build failures were handled. Additionally Fedora tools like Fedora Review and Taskotron should be adapted to properly report packages that are not built with the hardening flags for example by running checkseck on all created executables.

Example problems that block some packages to be built with the right flags:

Helpful documentation:

Enhance PostgreSQL GSSAPI Support

Status: proposed

Summary of idea: The Fedora Server Edition includes a Database Server Role powered by a PostgreSQL database. In order to integrate it better with Fedora Server's Domain Controller, we want to enhance the GSSAPI authentication and communication in the server.

Knowledge prerequisite: C Programming, Kerberos/GSSAPI

Skill level: intermediate to high (probably grad-student level)

Contacts: Stephen Gallagher, Simo Sorce

Mentor(s): Simo Sorce

Notes: This will require modifications to the authentication subsystem as well as the TCP/IP layer of PostgreSQL. It will likely be a very involved project.

Tweak specific packages to play well with MIPS architecture

Status: proposed

Summary of idea: We are planning to bootstrap Fedora for MIPS architecture. Even though the majority of packages should build with little to no modifications, there are some challenging packages that will need extra attention.

Knowledge prerequisite: C or Python Programming, packaging basics, some idea about non-x86 architectures

Skill level: intermediate to high

Contacts: Michal Toman, Anibal Monsalve Salazar, YunQiang Su #fedora-mips[?]

Mentor(s): Michal Toman

Notes: Possible work areas:

  • kernel
  • anaconda
  • openjdk
  • ghc
  • ocaml
  • erlang
  • fpc
  • ...

Open Ideas From GSoC 2016

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.