Ideas for Student Projects for 2008

Status: Proposed

Summary of idea: The QA team has a half finished port of Ubuntu' Apport, it would greatly enhance the handling of crash reporting if we were able to finish this work.

Contacts: Added by DavidNielsen, I have no skills but hopefully WillWoods will be able to function as mentor. KyleMcMartin is willing to mentor this.

Notes: More information Apport can be found here: https://wiki.ubuntu.com/Apport

Status: Proposed

Summary of idea: We need a web interface that is made for end-users to access information about packages. This will be similar to packages.debian.org or packages.gentoo.org in some ways but we hope to improve on those in several ways.

Contacts: Toshio Kuratomi(abadger1999) has agreed to take point on this. Interaction with other developers will likely be needed as this touches many systems. Luke Macken(lmacken), John Palmieri(J5), Ricky Zhou(ricky), Seth Vidal(skvidal), and Mike Bonnet(mbonnet) are all involved in projects that touch on the work to be done here.

Notes: This needs to be an enhancement of the Package Database . The DB schema will need additional tables to reflect the enduser view of data. We’ll need to generate dynamic web pages to display the information to the end user and allow them to give feedback/enhanced information about a package.

Design Requirements:

A mockup of what a page could look like is in the MyFedora proposal . Note that the header information is MyFedora UI rather than PackageDB Ui and we’d want to be describing gimp as an application rather than gimp as a package.

Status: Proposed

Summary of idea: The Jack Audio Connection Kit enables low latency interapplication audio connections. Many applications currently in Fedora support it and can connect to each other and to the audio card. Audacity is one of them. But its Jack support depends on PortAudio, and to be kind, PortAudio Jack support is sorely lacking. Audacity is an extremely popular audio editor but its main weakness is its lack of a proper native Jack driver. Having one would make it a lot more useful in the context of an audio content creation environment.

Contacts: Added by Fernando Lopez

Notes: Why is the PortAudio driver not so good?

It cannot react dynamically to changes in the Jack graph, that is, Jack applications already running can be seen by Audacity, applications started after Audacity starts are invisible until Audacity is restarted.

Jack ports can only be selected in the Preferences menu of Audacity. The standard way of handling this in Jack applications is that in the preferences menu you select either the Jack driver or an auto discovery mode. If the Jack driver is selected then the application will connect (register ports) to it on startup (if Jack is running) and will register input and output ports with Jack. Those will be seen in the Jack graph and can be source or sink of audio information to/from other apps and/or the soundcard. Normally the connection with other apps or the soundcard is done externally. Some programs add internal means of connecting to other apps and that is generally not done through the preferences menu (Jack is dynamic), and can show applications that started after (in this case) Audacity starts. Some programs have the extra option of connecting automatically on startup to the first n physical audio output ports which facilitates trivial use of the program.

BastienNocera: we use PulseAudio by default in Fedora, and I don’t really see the point of using Jack if we use PulseAudio for "normal" users (most users won’t be changing that default). You’re better off pushing this request to an Audacity SoC project.

Status:

Summary of idea: Func is a network applications framework that allows for powerful remote manipulation and scripting of very large numbers of Fedora machines.

This idea is to expand Func by writing lots of useful modules to do all sorts of powerful remote things, making it into the world’s best API for remote scripting Fedora over lots of machines at once — with an emphasis on integrating Func with other tools we already have in Fedora. This would be a particular good project for someone who had an interest in networking, clusters, automation, or security related topics. Contributions to Func wouldn’t be limited to just writing modules, as anything networking/automation related is fair game. Contact MichaelDeHaan for more information.

Contacts: MichaelDeHaan

Notes: see https://fedorahosted.org/func

Status: Proposed

Summary of idea: For various reasons we need to be able to use a second repo. but still know what was in the build root. or to be able to hide builds for pre-release, security issues. Koji needs to be able to import repodata and know where binaries are while not making them available. We walso want to be able to mark a build as being embargoed and hide it completely. from cvs through to the build happening. to be opened up when embargo is done.

Contacts: DennisGilmore

Notes: https://fedorahosted.org/koji

Status: Proposed

Summary of idea: At present, there is a largely functional specfile editor plugin for Eclipse shipping in Fedora. It would be nice to expand the usefulness of the plugin with the ability to push builds to koji. Using mock from within Eclipse and doing pkgdb and bodhi work would also be nice.

Contacts: AndrewOverholt

Notes:

Status: Proposed

Summary of idea: The Eclipse Communications Framework has shared editing support. It would be nice to have a gobby backend for this so that Eclipse users could take advantage of Fedora’s existing gobby server.

Contacts: AndrewOverholt

Notes: http://blog.mricon.com/2008/02/why-is-there-no-gobby-support-in.html , https://bugs.eclipse.org/bugs/show_bug.cgi?id=219829

Status: Proposed

Summary of idea: Anaconda supports partition resizing (including NTFS) in Rawhide now. It would be great to combine this with a data migration tool for Windows or dual booting users.

Contacts: RahulSundaram

Notes: I only have the general idea. Others more qualified, feel free to volunteer

Status: Proposed

Summary of idea: The idea is to update the system using idle bandwidth in an asynchronous, prioritized and throttled manner, i.e to update packages asynchronously from the server. This way the user can continue working while the updated packages are being downloaded without any noticeable changes in bandwidth.

Updates can be done automatically by a cron job or with yum-updatesd, but this will make yum/pup to use whole of the bandwidth. yum has a throttle option but it decides the upper limit of usage of bandwidth. Whereas, with asynchronous mode, limit can be decided dynamically depending upon the current usage. In many developing countries most of the people are on low bandwidth networks or have limited access to Internet. This will help them to keep their system updated with maximum utilization of their bandwidth.

Contacts: SunilKumarGhai

Notes: [1] We can also have some kind of general framework, which can be used by other applications to use throttling in services they provide. [2] We can implement this with repositories over http only. ftp repositories will not work. [3] Maybe work with PackageKit? — RichardHughes

@RichardHughes: As the idea is moving in development of framework as mentioned in [1] point, we would be able to use it. But still as PackageKit has YUM backend so only http repositories will work. — sunil

Status: Proposed

Summary of idea: Finish design and implement web application that provides downloadable SRPMS for any package+tag in the Fedora Package Source Code Control system. While we provide SRPMS for all packages at release, the updates and rawhide trees churn their packages more rapidly, and will remove the koji-built SRPMS when the binary packages are removed. This would allow people to request source corresponding to the packages they have on ISO media or otherwise.

Contacts: MattDomsch

Notes: http://git.fedorahosted.org/git/?p=correspondingsource.git;a=blob;f=DESIGN;hb=HEAD has mdomsch’s thoughts on how it should work.

Status: Proposed

Summary of idea: Bootchart is a tool for performance analysis, and visualization of the Linux boot process. At present, bootchart uses a logger script to collect the boot information from the /proc interface. It also uses a parser to extract information in a non-standardized format. It would be nice to:

Skills needed: Strong background in Operating Systems. Familiarity with Python, Java/JAXP, XML and C programming. Some experience in kernel internals would be helpful, but not necessary.

Contact: EugeneTeo, eteo_at_fedoraproject_dot_org

Notes: See http://bootchart.org/, http://sourceware.org/systemtap/wiki/, http://people.redhat.com/berrange/systemtap/bootprobe/

Status: Proposed

Summary of idea: SystemTap provides an infrastructure that simplifies the gathering of information about the running Linux kernel, so that it can be further analyzed for performance or functional issues. This project involves writing a graphical tool for visualizing this information in real-time, so that anomalies can be easily identified. The tool should use configuration files in XML format to describe how it should interpret the output of the scripts. Users should be able to extend the tool by adding new SystemTap scripts. How information should be visualized meaningfully requires more thought during the design phase. One of the main objectives is to make SystemTap user-friendly, and easy to use.

Update: I wrote the following to a student recently. Here’s more description of the project: The objective of the project is to create a visualization tool that we can display graphs and statistics in a meaningful way. Another objective is to investigate how we can gather important statistics from SystemTap, and have it formatted in a way that is easy for the tool to display the results. I am not looking at yet another gnome-system-monitor though. A user should be able to specify a systemtap script, have it conform to a specific output format, write a XML configuration file to describe the input format, and output format, and have the visualization tool display it.

For example, we want to monitor lock contention in Linux. We write a script to get hold of futex locks. We write a XML configuration file, specify the output format of the script, and then display the graphs/statistics.

Another example, we want to monitor I/O activities in the system, we take an existing script, modify it to display output for the visualization tool. We write a XML configuration file, specify how the output is like, and then display the statistics:

Skills needed: Strong background in Operating Systems. Familiarity with Python/GTK+, and C programming. Some experience in kernel internals would be helpful, but not necessary.

Contact: EugeneTeo, eteo_at_fedoraproject_dot_org

Notes: See http://sourceware.org/systemtap/wiki/, http://stapgui.sourceforge.net/screenshots.shtml, http://www.kernel.sg/roller/eugene/entry/mortadelo_a_graphical_systemwide_strace, http://lwn.net/Articles/271796/

Status: Proposed

Summary of idea: Many computers are not connected to the Internet and cannot be updated easily. A solution should be found to use libpackagekit and be distribution neutral so all distros can benefit. For this task, first we would generate top-level use-cases for offline use, and expand on existing use cases. This task would involve reviewing Opyum or APTonCD for ideas and ways to do things better.

This would possibly involve using avahi for client→client transfers, and would have to deal with the trust issues that arise from this. It would also involve generating offline packs for automatic install or automatic update. ServicePack CD’s could be shipped on magazine covers with updates to all the typical fedora applications for people without inexpensive network access. This could be investigated further.

Contacts: RichardHughes, richard_at_hughsie_dot_com

Notes: The applicant would need to be familiar with C and a little python, but would be a great way to get into development of a young fast-moving software project.

Status: Proposed

Summary of idea: PackageKit is complex, and relies on many different parts of the stack, e.g. yum, rpm, dbus, etc. There is currently only limited build time self-checks in the PackageKit source package. We would need to design of an end-to-end test harness for packagekit that would test .rpm and yum on local temporary repositories for a complete self check of the code pathways and packages used. This could be used to trivially check each version of these components before being pushed to an update repository.

Contacts: RichardHughes, richard_at_hughsie_dot_com

Notes: The applicant would need to be familiar with C and a little python, but would be a great way to get into development of a young fast-moving software project.

Status: Proposed

Summary of idea: Still we are missing a good non linear editor for ogg videos. This can be a simple GUI based application to do non linear editing of ogg. Like cutting, mixing the videos. Adding still frames to the video etc. Though this is not a project to be finished within 2-3 months, but we should be able to have a basic application running to do simple edits. May be having feature of upload videos to fedoratv or integrate itself with recordmydesktop to get screencasts directly. I am looking for more ideas on this.

Contacts: KushalDas kushaldas AT fedoraproject {NOSPAM} DOT org

Notes: Recommended choice of language is Python or C

ValentTurkovic: I have 2 suggestions; First is to try and resurrect Diva Project who started as GSC project in 2006. Second is to work with Pitivi Project because it is on a good path and has ogg editing functionality and easy enough interface. To get an overview of this Diva Project rise and fall please read these two posts. UPDATE: There are two projects that look promissing: saya-videoeditor 2 and myvideoeditor 3

MDK: State of Diva 4

Comment on Diva 5

also look at video demos of Diva Project: 6 7 8 9

Status: Proposed

Summary of idea: One of the items that other distributions have been able to accomplish that is still lacking in Fedora is the ability to have a web link, which will allow an update and/or install using an approved yum repository. Similar to OpenSUSE’s misnamed One-Click install, or Ubuntu’s AptURL feature, building a package repository reference which then uses PackageKit or something similar.

Contacts: ClintSavage herlo AT fedoraproject DOt org

Notes: Proof of concepts are available from the Ubuntu and OpenSUSE website’s respectively.

http://packages.ubuntu.com/gutsy/admin/apturl

http://en.opensuse.org/Standards/One_Click_Install

Status: Proposed

Summary of idea: ILA is "Sanskrit" word meaning "Terrestrial"…​ The Idea is to integrate all computers reachable (via any kind of network, internet to be most obvious) into a parallel web which is reachable by a single click or shortcut…​

let me put the last line as first…​ "A parallel web which doesn’t depends on a central service provider for any of its functions…​ the core part of the node functionality is loaded with the desktop" so every computer online/lan is capable of being a node depending on the modules activated

Its modular so that new features can be made available…​

The architecture, language, implementation are open to discussion…​ I have a few ideas but most relevant thing to write here would be use-cases which will make the objectives of the project clear..

\1. A User is stuck on some problem he just clicks a shortcut to make visible the desktop application goes to query tab and fills the question then hits 'Ask'…​ now all the other computers (reachable) who have selected i-want-to-answer-this-type-of-questions (which is optional) will be shown a popup on the desktop…​ all the answers that are sent are then shown on the system where they originated. [much better then a search algorithm you are getting reply from real people]

\1. Can be used for file sharing [no need to explain just like any good P2P]

\1. A modular design will allow users to choose from large number of attachable modules like the above two such as Distributed-CPU-Utilization applications (like SETI), Instant messenger, feeds collector, news (users can add news and everyone can see it in diff categories)…​ [use your imagination]

\1. The only requirement to use a feature or service is just network reachability. no dependence on any central service provider

First Issue that I see is…​ It "Should" be usable…​ (still its an abstract statement :-) ) Although I would like it to run on Fedora and other Distros, porting to any plateforms should be possible Idea is still in abstract form is "Remove dependence on centrally controlled systems…​integrate this functionality in the OS" so that new kind of apps/tools/featuers can be created.

Contacts: Added by SiddharthUpmanyu, If you want to take this project contact me at siddharth AT techbugs DOT org.

The following are some ideas on Transifex that came up. Feel free to contact DimitrisGlezos for more info and/or extend them with new points in your application.

If you want to discuss any ideas you might have, please contact DimitrisGlezos right away.

You might also want to take a look at L10N/Tools/Plans .

Status: Proposed

Summary of idea:

Transifex works well as a server and the website workflow works well with new content providers (eg. translators), however not all users find the website efficient enough. Implementing an API callable over http will enable a Command Line Interface, AJAX calls, and integration with other tools.

Contacts:

DimitrisGlezos

Notes:

Status: Proposed

Summary of idea:

Refactor Transifex’s code with hooks (pre, post commit), overridden functions, and classes in order to add a plugin/extension mechanism. Abstract file metaphor, and make support for PO files a plugin and implement a new one for image submissions.

Contacts:

DimitrisGlezos

Notes:

Status: Proposed

Summary of idea:

Add user/authorization/permission layer on top of Transifex, to improve the workflow Transifex creates by identifying key user groups and implementing functionality for each one.

Status: Proposed

Summary of idea:

Currently Tx requires a constant sync with the remote repo. A submission triggers a push, and pulls happen continuously. We need to add a feature to extend this paradigm with submissions living in Tx, until the next push is run (probably by the developer or an editor).

This way we can enable a bunch of nice stuff like, instead of Tx pushing, add support for the developer to pull whenever she needs. Also, having a temporary upload place which needs approval before actually being committed will help QA and get new translators more easily (language leaders can review). These could either be used as a temporary upload space or as a way to allow non-authorized submissions (an authorized user can move a Draft to an actual submission).

Idea: Split files into multiple chunks and submit them all together?

Contacts:

DimitrisGlezos

Status: Proposed

Summary of idea:

Currently Tx supports only a small set of submission methods, all tied in with a version control commit approach. We want to create an abstract submission system decoupled from vcs. On top of that we want to rebuild all the current submission methods and to implement a set of other requested methods such as email delivery, filling a ticket on trac or bugzilla etc.

In addition a primary goal is to build a CLI Client so translators can submit their translations directly from their terminal.

Info: Proposed by Christos Trochalakis (application: Tx Submissions revisited )

Status: Proposed

Summary of idea:

Currently Transifex runs as a web server, running the actual commits within the same process. This could be a bit of a security risk, and we’d like to have the commit service run as a different user. An advantage of this is that any repo can run this committer and control the submissions instead of giving SSH access to a downstream project.

Contacts:

DimitrisGlezos

Status: Proposed

Summary of idea:

One of the most important assets of Tx is its community bridging architecture. When multiple Transifex instances exist, they might want to share stuff, like users, translation statistics and maybe submissions. Eg. a Fedora user could submit something to the Debian server, which will wait the approval of a Debian language leader.

The most important aspect of this idea is architecture design. The student will need to have a very good image of content and translation workflow, the process Transifex adopts, and study how open source projects work together.

Also, most likely the student will want to discuss a lot with the main Transifex developers. Fluent English is probably an important asset for someone applying for this idea.

Status: Proposed

Summary of idea:

Currently our application to submit translations (Transifex) doesn’t have i18n support for translators to be able to translate it. Definitely it is a thing than we have to do. The admin face of transifex needs some enhancements. Currently we just have the option to add modules and repos, but we can’t handle them with edit or remove options. All interactions with the user over the application could be quicker and more efficient using Ajax calls mainly with JSON. It could improve the user experience and make a great application improvement for all translators.

Contacts:

DiegoZacarao, DimitrisGlezos

Notes:

PS: The idea is based on what I’m able to work on.

Status: Proposed

Summary of idea:

Currently, translators have to manually download PO files from outside of Transifex, change them, then use Transifex to submit these changed files to a project’s repository. It would lower the bar of entry quite a bit if they could edit the translations, one at a time (i.e.: not the complete PO file, but individual messages), directly in Transifex. With Pootle , there is a web-based PO file editor which could be integrated with Transifex.

The work proposed here involves getting Pootle and Transifex working together, in a way that Pootle uses Transifex to handle and submit files. The idea is that we have a community that already uses a workflow around traditional, VCS-centric translations, which would like to use a web-based translation for some modules. Here are some details about what could be done:

Contacts:

NilsPhilippsen, DimitrisGlezos

Notes:

Status: Proposed

Summary of idea:

smolts.org stores alot of information already. Getting the information out to the public in the way that is useful to people is hard. There is a number of ways this can be done, and we’ve discussed many. We are looking for someone who is interested in finding out ways to tell people more about their own computer.

The Smolt program collects statistics about hardware running Linux and other data that goes with it. It collects lists of hardware devices, type of CPU, hard drive information and other statistics for each machine. While we can deliver statistics that are useful as fun factoids, they do not help out people looking for detailed information. This also does not inform people about any known issues about their machine. Two classic examples of what we are looking for are these:

These are only guidelines of the things we are looking for. This project is very open ended, and you can do what you feel like. New Ideas are very welcome. You will work concurrently with one or two other developers who will work on parallel ideas, so you will not be completely on your own.

You will need only some basic web skills and a basic understanding of data structures. This project is based on implementing whiz-bang ideas, and not on using technology X. Smolt is based off of Turbogears, SQLAlchemy, and MySQL. Basic experience in any of these technologies, or just Python is a plus..

Contacts:

Notes:

Status: Proposed

Summary of idea: Currently, our election software can only handle one groups (FESCo, FAB, etc.) election at the time. We would like to see it modified to handle multiple groups at a time.

Contacts: ToshioKuratomi, BrianPepple

Notes: The current software we’re using resides at http://cvs.fedoraproject.org/viewcvs/fedora-vote/?root=fedora

If there is enough time during the GSoC, we would advocate rewriting this software as a TurboGears app. This will make it 1) fit into our existing infrastructure (auth will be very easy, for instance). 2) Make it more extensible. So we could add history view of past elections, on-the-fly updates of how the vote is going, etc.

Status: Proposed

''Summary of idea: In this idea spins can be chosen while installing fedora. If somebody has downloaded a dvd or a cd he can chose the a predefined group of packages defined in the package chooser such as choosing gamer will install all games and utilitiess available in the dvd and the rest from internet. This would save people time as they won’t have to select apps one by one in the package chooser ''

Contacts: [email protected]

Notes:

Status: Proposed or Ready for Use

Summary of idea:

Contacts:

Notes: