(Dockrie) |
Echevemaster (talk | contribs) |
||
(47 intermediate revisions by 20 users not shown) | |||
Line 4: | Line 4: | ||
Find an idea you like? Want to propose your own? See the Getting Started Guide with GSoC: | 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_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]]. | You may be interested in ideas from [[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]]. | ||
Line 12: | Line 12: | ||
== 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 [ | 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. | ||
# [ | # [[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?]] | ||
# [ | # [[FAS|Fedora Account System]] | ||
# [ | # [[Development]] | ||
== Supporting Mentors == | == Supporting Mentors == | ||
Line 31: | Line 31: | ||
#[[User:Kumarpraveen|Praveen Kumar(praveenkumar)]] | #[[User:Kumarpraveen|Praveen Kumar(praveenkumar)]] | ||
#[[User:Shreyankg|Shreyank Gupta(Shrink)]] | #[[User:Shreyankg|Shreyank Gupta(Shrink)]] | ||
#[[User:Debloper|Soumya Deb (Debloper)]] | |||
#[[User:Sayanchowdhury|Sayan Chowdhury(sayanchowdhury)]] | |||
#[[User:Rtnpro|Ratnadeep Debnath(rtnpro)]] | |||
#[[User:Mizdebsk|Mikolaj Izdebski (mizdebsk)]] | |||
#[[User:Sochotni|Stanislav Ochotnicky (sochotni)]] | |||
#[[User:lbazan|Luis Bazan (lbazan)]] | |||
#[[User:echevemaster|Eduardo Echeverria (echevemaster)]] | |||
==Draft of an idea== | ==Draft of an idea== | ||
Line 54: | Line 61: | ||
== Idea list for GSoC 2014 == | == Idea list for GSoC 2014 == | ||
==== FedmsgSobumper ==== | |||
''Status:'' Proposed (as a maturity level in [http://tools.ietf.org/html/rfc6410 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 [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. | |||
==== 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):''' [[User:Rtnpro|Ratnadeep Debnath]], [[User:Kushal|Kushal Das]], [[User:Sayanchowdhury|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 <s>know</s> 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:''' [[User:Debloper|Soumya Deb (Debloper)]] | |||
'''Mentor(s):''' [[User:Debloper|Soumya Deb (Debloper)]] | |||
'''Notes:''' | |||
<!-- Interested students: | |||
[[User:Arcolife|Archit Sharma]] Dibs!, [[User:Ahi| Ahmed Hisham]] --> | |||
==== Shumgrepper ==== | |||
''Status:'' Proposed - draft | |||
''Summary of idea:'' summershum is a project collecting the md5sum, sha1sum and sha512sum of every file in every package in Fedora. This would allow detecting how many time we bundle certain files or how many different copies of the GPL license are present. Shumgreppper would be the web frontend/json-api to this data. The idea would be to fork the code present in [https://apps.fedoraproject.org/datagrepper datagrepper] and adjust it to work on top of summershum. | |||
''Knowledge prerequisite:'' python and basic html/css | |||
''Skill level:'' intermediate | |||
''Contacts:'' pingou at fedoraproject dot org | |||
''Mentor(s):''[[User:pingou|Pierre-Yves Chibon]] & [[User:ralph|Ralph Bean]] | |||
''Notes:'' | |||
==== Glitter Gallery Improvements ==== | ==== Glitter Gallery Improvements ==== | ||
Line 98: | Line 232: | ||
''Contacts:'' echevemaster [AT] fedoraproject [DOT] org, yohangraterol, [AT] fedoraproject [DOT] org | ''Contacts:'' echevemaster [AT] fedoraproject [DOT] org, yohangraterol, [AT] fedoraproject [DOT] org | ||
''Mentor(s):'' [[User:echevemaster|Eduardo Echeverria]] | ''Mentor(s):'' [[User:echevemaster|Eduardo Echeverria]] | [[User:yograterol|Yohan Graterol]] | ||
''Co-Mentor:'' [[User:lbazan|Luis Bazán]] | ''Co-Mentor:'' [[User:lbazan|Luis Bazán]] | ||
Line 104: | Line 238: | ||
''Code:'' https://github.com/echevemaster/fedora-college, welcome to contributors | ''Code:'' https://github.com/echevemaster/fedora-college, welcome to contributors | ||
''Interested Students:'' [http://github.com/hammadhaleem Hammad] | |||
==== Web hosting control panel ==== | ==== Web hosting control panel ==== | ||
Line 144: | Line 279: | ||
''Notes:'' | ''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 [https://wiki.debian.org/SummerOfCode2014/Projects/Get%20Muon%20ready similar Debian proposal]) | |||
''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. | |||
=== Mock improvements === | |||
''Status:'' Proposed | ''Status:'' Proposed | ||
''Summary of idea:'' | ''Summary of idea:'' | ||
This project is about improving [https://fedorahosted.org/mock/ mock utility] used in building packages | |||
in Fedora and some other RPM-based distributions. It focuses on | |||
improving interactive mock use cases to improve packaging workflows. | |||
Some ideas for mock improvement: | |||
; Add real-time logging to TTY | |||
Improve interactive mock use by logging more things to console in real | |||
time. Things like DNF output or build logs should be considered. | |||
; Implement LVM-based root cache | |||
Currently mock creates root directory tree under existing file system | |||
and caches chroot as compressed tarball, which has negative | |||
performance impact. The idea is to use LVM logical volume to store | |||
guest file system. Cache would be created by creating LVM snapshot, | |||
which could be later restored. | |||
; Use DNF instead of yum and yum-builddep | |||
Mock uses YUM and YUM Utils to install initial packages and build | |||
dependencies. The idea is to replace all YUM usage with DNF. | |||
As DNF is still in development, it is expected to have a few bugs | |||
related to installroot support, which may have to be fixed and | |||
contributed to DNF project. | |||
; Improve chroot locking | |||
Currently most of mock operations inside chroot are performed after | |||
acquiring exclusive lock. This makes it impossible to run two | |||
separate shells inside mock. The idea is to implement read-write | |||
(shared-exclusive) locking scheme. Some operations (like creating | |||
chroot or restoring snapshot) would need exclusive lock, other would | |||
need just shared lock (like running a shell). | |||
'' | ''Knowledge prerequisite:'' Python, Linux, RPM Packaging | ||
'' | ''Skill level:'' Medium | ||
'' | ''Contacts:'' [[User:Mizdebsk|Mikolaj Izdebski]] | ||
'' | ''Mentor(s):'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Sochotni|Stanislav Ochotnicky]] (backup) | ||
''Notes:'' | |||
=== | === Git shell prompt daemon === | ||
''Status:'' Proposed | ''Status:'' Proposed | ||
''Summary of idea:'' | ''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:'' | ''Knowledge prerequisite:'' Git, Linux, any programming language which has bindings for [http://libgit2.github.com/ libgit2] | ||
''Skill level:'' Medium | ''Skill level:'' Medium | ||
''Contacts:'' [[User: | ''Contacts:'' [[User:Mizdebsk|Mikolaj Izdebski]] | ||
''Mentor(s):'' [[User: | ''Mentor(s):'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Sochotni|Stanislav Ochotnicky]] (backup) | ||
''Notes:'' | ''Notes:'' | ||
=== | === Improving Fedora Packager for Eclipse === | ||
''Status:'' Proposed | ''Status:'' Proposed | ||
''Summary of idea:'' | ''Summary of idea:'' | ||
This project is about implementing new Eclipse plugins and | |||
contrubuting them to [https://fedorahosted.org/eclipse-fedorapackager/ eclipse-fedorapackager] project. | |||
; Copr integration | |||
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 | |||
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 | |||
''Skill level:'' Medium | ''Skill level:'' Medium | ||
''Contacts:'' | ''Contacts:'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Akurtakov|Alexander Kurtakov]] | ||
''Mentor(s):'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Akurtakov|Alexander Kurtakov]] | |||
''Notes:'' | |||
=== Eclipse plugin for XMvn === | |||
''Status:'' Proposed | |||
''Summary of idea:'' | |||
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: | |||
* 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:'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Akurtakov|Alexander Kurtakov]] | |||
''Mentor(s):'' [[User:Mizdebsk|Mikolaj Izdebski]], [[User:Akurtakov|Alexander Kurtakov]] | |||
''Notes:'' | |||
=== | === Implement a battery of unit tests for SSSD === | ||
''Status:'' Proposed | ''Status:'' Proposed | ||
''Summary of idea:'' The | ''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:'' | ''Knowledge prerequisite:'' Python scripting, Linux system services knowledge, basic LDAP knowledge is helpful but not needed. | ||
''Skill level:'' | ''Skill level:'' intermediate to high | ||
''Contacts:'' | ''Contacts:'' [[User:jhrozek|Jakub Hrozek]] | ||
''Mentor(s):'' | ''Mentor(s):'' [[User:jhrozek|Jakub Hrozek]] | ||
''Notes:'' | ''Notes:'' | ||
== Open Idea list from GSoC 2013== | == Open Idea list from GSoC 2013== | ||
Line 403: | Line 643: | ||
* Mentor(s): [[User:sgallagh|Stephen Gallagher]] (Backup) | * Mentor(s): [[User:sgallagh|Stephen Gallagher]] (Backup) | ||
* Notes: https://fedorahosted.org/fedpkg/ticket/6 | * Notes: https://fedorahosted.org/fedpkg/ticket/6 | ||
==== Financial IS for Fedora project (cont.)==== | |||
* Status: Proposed | |||
* Summary of idea: There is a need of an information system where it can be used with in the project to track and analyse the financial activities. It may be a customization of a open source solution or a solution from scratch. | |||
* Skill Level: Medium | |||
* Mentor : [[User:Charindu100|Charindu Thiwanka]] - Technical | |||
* Co-Mentor(s): [[User:Bckurera|Buddhike Kurera]] - Functional | |||
* Notes: knowledge in PHP is required. MVC design pattern | |||
===Linux system services=== | ===Linux system services=== | ||
Line 504: | Line 755: | ||
=== Applications for Testers === | === Applications for Testers === | ||
[[Category:Summer coding 2014]] | [[Category:Summer coding 2014]] |
Latest revision as of 18:13, 8 April 2014
Find an idea you like? Want to propose your own? See the Getting Started Guide with GSoC:
You may be interested in ideas from 2013, 2012, 2011, 2010, 2009 and 2008.
Further, last year accepted ideas from the Fedora Project can be found at GSoC 2013 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 2014 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.
- Buddhike Kurera(Bckurera)
- Kushal Das(Kushal)
- Nitish Upreti(Myth17)
- Lali Devamanthri(LSD)
- Haïkel Guémar(number80)
- Praveen Kumar(praveenkumar)
- Shreyank Gupta(Shrink)
- Soumya Deb (Debloper)
- Sayan Chowdhury(sayanchowdhury)
- Ratnadeep Debnath(rtnpro)
- Mikolaj Izdebski (mizdebsk)
- Stanislav Ochotnicky (sochotni)
- Luis Bazan (lbazan)
- Eduardo Echeverria (echevemaster)
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 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:
Shumgrepper
Status: Proposed - draft
Summary of idea: summershum is a project collecting the md5sum, sha1sum and sha512sum of every file in every package in Fedora. This would allow detecting how many time we bundle certain files or how many different copies of the GPL license are present. Shumgreppper would be the web frontend/json-api to this data. The idea would be to fork the code present in datagrepper and adjust it to work on top of summershum.
Knowledge prerequisite: python and basic html/css
Skill level: intermediate
Contacts: pingou at fedoraproject dot org
Mentor(s):Pierre-Yves Chibon & Ralph Bean
Notes:
Glitter Gallery Improvements
Status: Proposed - draft
Summary of idea:
GlitterGallery is GitHub for 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 coffeescript/javascript 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, a successful GSoC took Glitter Gallery from a prototype to a fully featured web app, but there are still plenty of features to be added, and improvements to be made. Some things that still need work:
- Transitioning to test-driven development, which means writing unit and integration tests for all of the components
- 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
- UI improvements - the current UI is functional and pretty nice looking, but it could be more responsive and polished
- 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
- Issue tracking - allow the designer to track requested changes as issues
- More social features - such as the ability to follow a file/project/user, an activity feed, private messaging, easy sharing outside the application
- Your own ideas
Knowledge prerequisite: 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
Mentor(s): Emily Dirsh
Notes: The GlitterGallery repository is hosted on GitHub. GlitterGallery will run locally, but due to a dependency, isn't yet compatible with ruby 2.0.0 which is the version provided with the latest Fedora release - you can install an older version of ruby with rvm. Ruby 1.9.3 is recommended. GlitterGallery can also be deployed on OpenShift.
Fedora College
Status: Proposed - Draft
Summary of idea: Fedora College is a project that searches to deploy the use of virtual classrooms in the training of Fedora new contributors, using known educational resources, by relying primarily on video
Knowledge prerequisite: apache, postgresql, python, Flask, SQlAlchemy
Skill level: Medium
Contacts: echevemaster [AT] fedoraproject [DOT] org, yohangraterol, [AT] fedoraproject [DOT] org
Mentor(s): Eduardo Echeverria | Yohan Graterol
Co-Mentor: Luis Bazán
Code: https://github.com/echevemaster/fedora-college, welcome to contributors
Interested Students: Hammad
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.
Mock improvements
Status: Proposed
Summary of idea: This project is about improving mock utility used in building packages in Fedora and some other RPM-based distributions. It focuses on improving interactive mock use cases to improve packaging workflows.
Some ideas for mock improvement:
- Add real-time logging to TTY
Improve interactive mock use by logging more things to console in real time. Things like DNF output or build logs should be considered.
- Implement LVM-based root cache
Currently mock creates root directory tree under existing file system and caches chroot as compressed tarball, which has negative performance impact. The idea is to use LVM logical volume to store guest file system. Cache would be created by creating LVM snapshot, which could be later restored.
- Use DNF instead of yum and yum-builddep
Mock uses YUM and YUM Utils to install initial packages and build dependencies. The idea is to replace all YUM usage with DNF.
As DNF is still in development, it is expected to have a few bugs related to installroot support, which may have to be fixed and contributed to DNF project.
- Improve chroot locking
Currently most of mock operations inside chroot are performed after acquiring exclusive lock. This makes it impossible to run two separate shells inside mock. The idea is to implement read-write (shared-exclusive) locking scheme. Some operations (like creating chroot or restoring snapshot) would need exclusive lock, other would need just shared lock (like running a shell).
Knowledge prerequisite: Python, Linux, RPM Packaging
Skill level: Medium
Contacts: Mikolaj Izdebski
Mentor(s): Mikolaj Izdebski, Stanislav Ochotnicky (backup)
Notes:
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:
Open Idea list from GSoC 2013
Applications for desktop end users
These are coding projects that benefit end users of the Linux desktop.
Integrate Proxy Settings and Network Connections(Locations)
Status: Proposed
Summary of idea: The system should use an appropriate networking profile (e.g. Proxy settings) for each network connection.
Gnome 2 had a concept of network locations in its Network Proxy configuration window. However, user should selected the appropriate location whenever he moves between networks. This idea is about providing an integration between NetworkManager and Desktop environments so that a user can create network profiles for each network location(connection) providing appropriate settings like proxy settings which is the main proposed setting here. NetworkManager can have a "Network Location" concept: for wireless networks, usually the name of the network (ESSID) is usually enough. For wired connections, DHCP servers can and usually do provide network's domain name, which can be used as the name of the location. It is nice if a user can associate each network location with a network settings profile which will be used whenever the user is connected to that network automatically. So, when you connect to a network, a corresponding network settings profile is activated automatically.
Knowledge prerequisite:
Skill level:
Contacts: Hedayat Vatankhah
Mentor(s):
Notes: There is an entry with some description in NetworkManager TODO which should be considered for the implementation
Assemble a toolchain for recording screencasts easily
Status: Proposed - Draft - Need a mentor
Summary of idea: Creating screencasts on Fedora and post-processing them for upload should be easy and fool proof.
The Fedora Videos project has been launched to bring together a collection of screencasts that help people learn how to use Fedora. There's only one major hurdle, though. Capturing really good screencasts on Fedora, post-processing them to include an intro and outro and other effects, and finally exporting them to an open format is challenging. There are lots of different tools, but each one only gets you part of the way there and you have to be the glue to make it all work. And then there are the bugs.
The goal of this project is to assemble a toolchain (a recommended collection of software available in the Fedora repositories) and write a comprehensive tutorial for how to create an professional-looking screencast. That may included chasing down & fixing bugs in the existing tools, discovering new tools and getting them packaged and learning about techniques in the environment around the computer, such as how to select & setup a microphone or how to draft a good speaking script. One possible task in the project is to add sound recording support to the Gnome 3 desktop recorder. Currently, the desktop recorder only grabs the video of the screen.
The student will get support and advice from the Fedora Videos team since they are trying to learn how to create these screencasts.
Knowledge prerequisite: gstreamer, video and sound editing, blender
Skill level: Medium
Contacts: Fedora Videos Team
Mentor(s): -
Notes:
Improve Fedora's Tablet User Experience
Status: Proposed - Draft
Summary of idea: Improving Fedora's Tablet User Experience.
The window managers/desktop environments officially supported by Fedora do not match the expectations of people with low power touch devices.
Fedora features new technology to reduce system load and - requirements, the user interface has not seen too much love.
Currently available interfaces for users are:
- Too Ressource Consuming
- Too Overloaded or
- Too Feature Poor
- Not Customizable With Reasonable Effort
The E17 Desktop Shell, developed as part of the Enlightenment Project, is a perfect match. It provides a rich interface, whilst consuming very little ressources. The Enlightenment Foundation Libraries, on which E17 is built upon, were chosen as Foundation Block of Tizen, the MeeGo successor backed by Samsung and Intel. If things work out, E17 will be the first "real" Desktop Shell for Wayland.
Though it already provides special behaviour for touchscreen devices through certain modules, there's still room for improvement.
The overall goal of this project would be to improve the user experience of people who want to use Fedora on low power devices such as tablets.
The student will get support and advice from the Enlightenment Project developers.
Knowledge prerequisite: C, X11, Wayland, Enlightenment Foundation Libraries
Skill level: Medium to High
Contacts: Michael Bouchaud (yoz [at] efl [dot] so), Leif Middelschulte (leif [dot] middelschulte [at] student [dot] kit [dot] edu)
Mentor(s): Michael Bouchaud (yoz [at] efl [dot] so)
Notes: If this idea gets realized, a proper tablet spin can be created, that honors the spirit of Fedora.
Applications for programmers
Implement a binding translator for GlusterFS
Status: Proposed - Draft
Summary of idea: In transporting data across networks, programmers need GlusterFS language bindings to be able to create apps in their language of choice. A language binding translator would greatly increase the number of programmers who would be able to more easily extend GlusterFS. It's also a fun project for someone wanting to get some experience with multi-threaded architecture and design in the context of distributed systems and data.
Knowledge prerequisite: C, Python, embedded Python
Skill level: Medium to High
Contacts: johnmark [AT]redhat [DOT] com , abperiasamy [AT] gmail [DOT] com
Mentor(s): Anand Avati - Mentor, AB Periasamy - Co-mentor, John Mark Walker - Co-mentor
Notes: -
Implement a Cassandra/NoSQL Connector or Translator for GlusterFS
Status: Proposed - Draft
Summary of idea: In general, there is a need for the ability to store and access NoSQL data on general purpose distributed filesystems. Currently, there are a host of single-purpose methods for storing and retrieving NoSQL data, which are difficult to access from legacy applications. Creating a NoSQL translator for GlusterFS would help mitigate this problem and give developers more options for storing and accessing "big data" in a way that is accessible via a variety of standard toolkits and protocols.
Knowledge prerequisite: C, GlusterFS internals
Skill level: High
Contacts: johnmark [AT]redhat [DOT] com , abperiasamy [AT] gmail [DOT] com
Mentor(s): Anand Avati - Mentor, AB Periasamy - Co-mentor, John Mark Walker - Co-mentor
Notes: -
Embedded Cli tool for most popular DBMS
Status: Proposed - Students' Idea - Need a mentor
Summary of idea: Today, many developers are working with different DBMS. I propose to develop a common command line interface for most popular databases. For example: MySQL, Oracle Database, PostgreSQL.
Knowledge prerequisite: Java, JDBC, MySQL, Oracle Database, PostgreSQL.
Skill level: Medium
Contacts: Alexandr Egorov 0x0j023 [AT] gmail [DOT] com
Mentor(s):
Notes:
Linux kernel project
Implement nfs/fscache writeback cache (Dropped)
Status: Dropped -- This is a GSoC _2012_ idea and is being working on by Hongyi Jia although he didn't get the GSoC slot (http://www.jiayi.net/works/nfsfscache-writeback-cache/). So, I'm not going to mentor the idea this year and if anyone is really interested in it, feel free to contact me and I'll be happy to answer questions:-)
Summary of idea: Currently, the flashcache/bcache only works for local filesystems. For network filesystems, nfs only supports write through cache based on fscache/cachefiles. With wider adoption of SSD on nfs client side, it would be great for nfs to support writeback cache to speed up write intensive clients. This project would implement a writeback mechanism for nfs, which need to make necessary changes to kernel nfs, fscache and cachefiles modules, and take care of nfs close-to-open semantics.
Knowledge prerequisite: C, Linux kernel, nfs
Skill level: High
Contacts: bergwolf [AT] gmail [DOT] com
Mentor(s): Peng Tao - Mentor
Infrastructure for Fedora contributors and users
Dorrie: A web-interface for building Fedora spins/remixes
Status: Proposed
Summary of idea: Contribute to Dorrie, and make it more usable, add test coverage and deployable. Details at Dorrie.
Knowledge prerequisite: Python, Django
Skill level: Intermidiate
Contacts: Shreyank Gupta
Mentor(s): Shreyank Gupta, Ratnadeep Debnath
Notes: Features that I am looking to target:
* User management/FAS integration * Un-linerize the workflow. * Default wallpaper/Hostname/user-password/root-password * Custom repos/RPMs * Home directory content * Search Packages * Image type: ISO, virt image, raw disk
Code at https://github.com/shreyankg/Dorrie, fork and send pull request, if you are interested to contribute.
Fedpkg: Chain-builds for non-Rawhide branches
- Status: Proposed
- Summary of idea: Contribute to the fedpkg project, enabling the building of a series of interdependent packages in a single action for released Fedora branches
- Knowledge Prerequisite: Python, Fedora Packaging
- Skill Level: Low - Medium
- Contacts: Stephen Gallagher
- Mentor(s): Stephen Gallagher (Backup)
- Notes: https://fedorahosted.org/fedpkg/ticket/6
Financial IS for Fedora project (cont.)
- Status: Proposed
- Summary of idea: There is a need of an information system where it can be used with in the project to track and analyse the financial activities. It may be a customization of a open source solution or a solution from scratch.
- Skill Level: Medium
- Mentor : Charindu Thiwanka - Technical
- Co-Mentor(s): Buddhike Kurera - Functional
- Notes: knowledge in PHP is required. MVC design pattern
Linux system services
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: C programming
- Skill level: intermediate to high
- Contacts: Jakub Hrozek
- Mentor(s): Jakub Hrozek
Improving Fedora packaging
AUR Clone for Fedora
Status: Proposed - Students' Idea - Need a mentor
Summary of idea: The idea is to make an AUR clone for Fedora where users can submit buildfiles, which need to be hosted. These set of files can compile packages on the user side, and installed locally.
The benefit of this method is:
- No need to host the entire packages (saving space on servers hosting the RPMs)
- Make changes to the buildfile, and not compile the package
- Can pull sources from any version control system/stored tarballs to make a very upto-date package. (See blog entry for an example)
Contacts: Anuj More
Notes: Need mentor. Need advice on feasibility of the software and issues that can arise. Also, read the extensive blog post on my blog.
Analogy: This is a lot like "having your own library" vs "getting a book from a bookstore". If you refer a book often, you'd keep it in your library. This would occupy space and consume resources. Otherwise, you'd just pull out a separate paper with instructions about the bookstore to find the book, and fetch the book from the store. Though the first method is hassle-free, it is not possible to have all the books in the world with you.
Maven FOSS Repository Extension
Status: Proposed
Summary of idea: With the inception of Maven we have a means to standardize the building of Java projects. However it has also resulted in the usage of a very wide dependency set by these Java projects. This makes it very hard to integrate those projects on a single platform (be it Fedora or JBoss Application Server (or the combination)).
In essence during packaging all these dependencies must be lined up to form a single consistent component set. Thus each project will only have those components available which are actually available on the target platform. This is very hard to enforce using standard Maven setup.
For Fedora I'm envisioning a Maven extension that makes sure only sanctioned components are used during the build (without putting a burden on the packager). This will allow developers who are not on Fedora to also build with this extension and thus verify (and fix) issues which are the result of "Fedora packaging".
A prototype can be viewed at Maven FOSS Repository Extension.
Knowledge prerequisite: Knowledge of Maven
Skill level: Medium
Contacts: Carlo de Wolf, Mikolaj Izdebski
Mentor(s): Carlo de Wolf, Mikolaj Izdebski
Notes: You can find us at irc.freenode.net #fedora-java: wolfc and mizdebsk
Fedora Spins and remixes
Educational Application for Fedora Robotics Suite
Status: Proposed
Summary of Idea: Create an educational app introducing software from Fedora Robotics Suite
The Fedora Robotics SIG is creating a Robotics Suite consisting of many packages useful in robotics. We want to develop a demonstration application introducing new users step by step to core packages like Fawkes and Player/Stage. It would feature multiple game-like levels with increasing complexity. The general task would be to instruct the robot to fulfill a specific task in a simulation environment.
Knowledge prerequisite: Developing this requires a strong background in C++, a background in robotics is preferred but not necessary. You should be able to familiarize yourself with new software quickly. User visible parts will require GUI programming using Gtkmm.
Skill level: Medium to High
Contacts: Tim Niemueller
Mentor(s): Tim Niemueller
Applications for systems administrators
Improving the RHQ-PyAgent to interface with OpenLMI
Status: Proposed
Summary of idea: Improve the current RHQ-PyAgent written in Python that interfaces RHQ with OpenLMI to pick up metrics that are provided by OpenLMI from Fedora or RHEL systems. The agent is talking to the RHQ server via the REST api and push metrics to RHQ etc. This agent does/will not implement the full functionality of the RHQ java agent. The previous work is already pretty good, but it is cumbersome to add new OpenLMI-enabled servers and the types of the data model. The work of this year should concentrate on automating that process - perhaps after providing a range of IP addresses to query for servers. Similar for resource types, the agent would talk to the server to see what types are available and then check with the OpenLMI provider if this supports the same.
While RHQ is written in Java, this project does not require any Java knowledge.
Knowledge prerequisite: Python, Linux system administration, principles of REST
Skill level: Medium to High
Contacts: Heiko Rupp <pilhuhn>
Mentor(s): Heiko Rupp <pilhuhn>
Notes: RHQ wiki is at http://jboss.org/rhq, Previous years work: http://rhqagent.blogspot.com