Talk:Summer of Code
Jameson Chema Quinn coordinated the 2009 projects and can be contacted with any questions at jameson.quinn -AT- gmail.com.
2009 results
We had a great year. All 5 of our students were successful, and several of them made really important improvements to Sugar. Here's the results:
Version support for Datastore
Overall I think the project was a success. For various reasons it didn't quite go the way i imagined, but nevertheless got a fully working prototype I can base further development on. Many of my not directly version related patches were merged upstream for 0.86.
VCS benchmark
My VCS benchmark that was geared towards the data store use case has shown there's no perfect match -- depending on the hardware Sugar is running on (CPU speed, IO bandwidth, storage size) different VCSs will perform best. This emphasizes the need for a modular design with runtime-selectable VCS backends in case we're going to use one at all.
Datastore redesign proposal
The current datastore codebase doesn't lend itself very well for adding VCS backend support to it; also the current API (including the names of special properties like uid for the object identifier) has historically grown and isn't well-defined in some aspects. My proposal (follow "raw blob data" link) shows how a future datastore implementation could work, including a new API (that's based on the old one, but with clear definitions and guarantees).
Prototype
The current datastore has been enhanced to add version support - now based on the new API defined in the proposal mentioned above. The UI side has been adjusted to that new API. To the user, it it totally unobtrusive: the text field showing the time of the last modification just got replaced with a combo box showing all existing versions (with the latest one being the default). Selecting a different version will show the details for that version and also allows the user to resume it. While the UI changes are minimal, the impact is large: even after doing any number of modifications the user can "go back" and look at or even continue working on older versions -- similar to undo / redo functionality some applications offer (though most of them can't undo anything once the application has been closed).
Prefix search support
As a test balloon for the code review process I added support for doing full-text searches on specific properties by using prefixes inside the query string: E.g. entering "mime_type:text/plain" in the Journal query field will only show those entries that have the "mime_type" property set to "text/plain". Previously the user could only search all properties for "text/plain".
Test suite
The test suite for sugar-datastore has been revived from an old git version and modified to test the public (=DBus) API instead of the internal ones. It already helped discovering two bugs in my prefix search support changes.
Minor bug fixes
Several pre-existing bugs have been discovered and fixed in all of sugar-toolkit, sugar-datastore and sugar: #1040, #1024, #1053, #1059
Minor enhancements
A trace decorator has been added in order to ease debugging. It helped a lot during version support development. Not having the layoutmanager side-stepped by several parts of the data store helped made the prototype code much cleaner. Patches to clean up quite a bit of redundancy in accessing the data store from sugar (#1198+#1201) and sugar-toolkit (#1197) have not been accepted for 0.86.
Unrelated to my version support work, but operating on the same set of modules is a patch to add a technical details view (file size, MIME type, creation date) to the Journal details view.
Style fixes
The code review process mandated some stylistic conventions that were not yet followed by some of the pre-existing code. I've submitted patches to fix that (#1108, #1109). Also letting the logging code do the formatting of the log message (#1210, #1211, #1213) has been added to the style guide.
Karma
The Karma GSoC project has been a success. Participant Felipe Lopez Toledo set out to create a high-level library for creating interactive digital learning lessons using only openweb technologies. The result is the karma jQuery plugin that provides high-level functions for manipulating image, audio, and internationalization.
The Karma Project is an initiative to create a platform that enables web developers to create compelling interactive learning materials for the Sugar Learning Environment without having to learn a new set of programming tools.
You can view the first example of lesson "Adding up to 10".
The student, Felipe Lopez Toledo, wrote:
- Simplified functions for:
- Drawing using the new canvas API for html5
- Adding images dynamically to the canvas API and manipulating them
- Playing audio
- Methods for loading in localized images and audio
- Mechanism for loading in translated text from a .po file
- Documentation of the Karma API
Thanks to the support of Google and Sugar Labs, Karma can now be used to create interactive activities for the Sugar environment.
Prototype
Groupthink
The Groupthink GSoC Project successfully achieved its specified goals. The student, Benjamin Schwartz, wrote
- a gtk SharedTextView widget that provides live shared editing in a self-contained object
- a network interface to allow sharing this widget over the network
- a SharedTextDemo activity (versions 1, 2, 3, 4, and 5) to demonstrate the use of this widget
- an automated serialization system for saving and loading state with the Journal
- other code necessary so that Sugar activities could seamlessly rejoin a shared instance and merge in changes made offline
- patches to enable live shared editing of Python code, with syntax highlighting and Undo/Redo, in Pippy-35
- extensive API documentation for Groupthink.
Thanks to the support from Sugar Labs and Google, Groupthink has grown from a toy project into a library that developers can really use.
Printing
Printing had been one of the key complementing features of any Desktop that Sugar lacked.
Previous Introduction
The purpose of this page (was) to coordinate a Sugar Labs Summer of Code effort.
What (made) a good project
Our focus is on collaboration and community for the summer 2009 round of projects, though we'll also consider thoughtful proposals that lie outside these two areas and can make a strong case for how they would support the Sugar Labs mission.
Collaboration
This refers to API or activity work that makes collaboration "work better." A good metric for "works better" is to ask the following: "6 months after the summer ends, which projects are likely to have caused the highest increase in children-hours spent collaborating over Sugar Activities?"
Community
This refers to meta-work that makes it easy for Sugar to reach a broader Sugar Labs; this includes development tools (and accompanying implementation of processes and training), internationalization/localization, accessibility, infrastructure-building, and porting Sugar to other platforms.
A good metric for "reaches a broader community" is to ask the following: "6 months after the summer ends, which projects are likely to cause the highest increase in SL community members that have participated consistently on a team for a minimum of 3 months?"
Get involved
Mentors
The preliminary Mentors' application page is now up.
Students
Student applications open on 23 March 2009. Look at the Resources page. It has links to many ideas and development resources. Your may also propose your own development ideas—show your creativity—combine the best aspects from the pool. Bring your proposals to the community, developers, and potential mentors (not limited to Mentors) for feedback on the mailing list or IRC.
Supporters
We're currently in the "get ideas" phase; please see Development Team/Project Ideas for a list of potential projects, and add your own. (There are some more project ideas from a brainstorming session at Sugar Camp that should be ported over; let Mchua know if you'd like to help with this.)
We would welcome help coordinating the overall effort as well; please contact Mchua if you'd like to get involved with this.
Community-building ideas
The mentoring org application includes the following questions:
- What steps will you take to encourage students to interact with your project's community before, during and after the program?
- What will you do to ensure that your accepted students stick with the project after GSoC concludes?
This is a place for brainstorming these issues.
[11:59] <mchua> homunq: we also need a general plan for how we're going to use this as a good community building tool for new developers, though that's a little vague [11:59] <mchua> homunq: stuff like "would a weekly check-in email be a good idea?" "do we require mentor meetings on IRC?" "are students mandated to blog about their work?"