Sugar Labs

Version support for datastore/Proposal: Difference between revisions

← Older edit
Homunq (talk | contribs)
273 edits
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Note to self: Need to apply at [http://socghop.appspot.com melange, google's web app], too till 19h UTC.
{{TOCright}}
{{TOCright}}
Please note that this proposal isn't fully fleshed out because I decided to apply only last minute (my diploma thesis would have been within the same time frame originally, but got delayed for external reasons so I can participate now). A proper design will be the first part of the project, see the time line given below. The issues and possible solutions are well-known and the scope is sufficiently limited to ensure this project will be a success.




Line 11: Line 6:
* Name: Sascha Silbe
* Name: Sascha Silbe
* Age: 29
* Age: 29
* EMail: user silbe, domain sugarlabs.org
* EMail: domain sugarlabs.org, user silbe (obfuscated for SPAM reasons)
* Wiki user name: sascha_silbe
* Wiki user name: sascha_silbe
* IRC nickname: silbe
* IRC nickname: silbe
* Primary language: german
* Native language: german (english preferred for technical communication)
* Location: Germany
* Location: Germany
* Work hours: about 12h to 00h local time, i.e. 10h to 22h UTC
* Work hours: about 12h to 00h local time, i.e. 10h to 22h UTC
* Open source projects (with other developers beside me) I participated in: [http://husky.sourceforge.net/ Husky (Fidonet on Linux)] (many years ago, co-founded the project; my profile on that page is rather outdated), [http://www.openstreetmap.org OSM], contributed bug reports and patches to a large number of projects. Try a web search on my name, it's unique (AFAIK at least).
* Open source projects (with other developers beside me) I participated in: [http://husky.sourceforge.net/ Husky (Fidonet on Linux)] (many years ago, co-founded the project; my profile on that page is rather outdated), [http://www.openstreetmap.org OSM], contributed bug reports and patches to a large number of projects. Try a web search on my name, it's unique (AFAIK at least).
* Current affiliation with Sugar Labs: maintainer of the [[Development Team/Buildbot|build infrastructure]]


==About my project==
==About my project==


* Name of project: Version support for [[DevelopmentTeam/DatastoreRewrite|data store]] / [[Design_Team/Designs/Journal|Journal]]
* Name of project: Version support for [[Development Team/Datastore Rewrite|data store]] / [[Design_Team/Designs/Journal|Journal]]
* Technologies used: The ones currently in use by the data store / journal. The bonus part might introduce additional ones (e.g. sqlite) for indexing.
* Technologies used: The ones currently in use by the data store / journal. The bonus part might introduce additional ones (e.g. sqlite) for indexing.


Line 28: Line 24:
and happens automatically), but rather add a new version to the entry. Enhance the UI to allow easy (and simple to understand)  
and happens automatically), but rather add a new version to the entry. Enhance the UI to allow easy (and simple to understand)  
access to "old" versions, including modification (which means automatically saving in a new branch).
access to "old" versions, including modification (which means automatically saving in a new branch).
As "easy and simple to understand" isn't actually easy to implement, I'll concentrate on enhancing (by listing
As "easy and simple to understand" isn't actually easy to implement, I'll concentrate on enhancing the current Journal view
each version separately) the linear, time-based view of the current
by adding previous/next buttons to the details view of each entry for the primary part of the project.  
[[Design_Team/Designs/Journal|Journal design]] for the primary part of the project. Adding a version tree details view
Adding a version tree details view and possibly other ways of presenting versions are planned for the optional  
and possibly other ways of presenting versions are planned for the optional (based on remaining time) "bonus part".
(based on remaining time) "bonus part". Metadata is going to be part of each version (and mutable without creating
a new version) at first.


===Rationale===
Version support for data store / Journal already  
Version support for data store / Journal already  
[http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience#Implicit_Versioning_System was part of] the  
[http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience#Implicit_Versioning_System was part of] the  
[http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience#The_Journal original design concept]
[http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience#The_Journal original design concept]
for the Journal, but [[DevelopmentTeam/DatastoreRewrite#Versioned_entries_.28not_fulfilled_yet.29|hasn't been finished yet]].  
for the Journal, but [[Development Team/Datastore Rewrite#Versioned_entries_.28not_fulfilled_yet.29|hasn't been finished yet]].  


There are several prototypes ([http://wiki.laptop.org/go/Olpcfs Olpcfs], [http://dev.laptop.org/git/users/cscott/olpcfs2/ olpcfs2])
There are several prototypes ([http://wiki.laptop.org/go/Olpcfs Olpcfs], [http://dev.laptop.org/git/users/cscott/olpcfs2/ olpcfs2])
Line 48: Line 46:
For this reason, I don't believe that any of these prototypes will mature enough to get integrated
For this reason, I don't believe that any of these prototypes will mature enough to get integrated
in Sugar even mid-term. My project focusses on the version support instead, enhancing the
in Sugar even mid-term. My project focusses on the version support instead, enhancing the
[[DevelopmentTeam/DatastoreRewrite|current data store]] instead of replacing it, with the Journal as the only
[[Development Team/Datastore Rewrite|current data store]] instead of replacing it, with the Journal as the only
intended user of the versioning API (though, at least in theory, regular activities could access it as well).
intended user of the versioning API (though, at least in theory, regular activities could access it as well).


Line 57: Line 55:
=== Time line ===
=== Time line ===


;2009-04-03
:Application deadline
;2009-04-12
:Easter (sunday); UI mockup submitted for review by [[Design_Team|Design Team]]
;2009-04-20
:start of (university) term; announcement of accepted GSoC proposals
;2009-05-10
:submitted API draft for review by [[Development_Team|Development Team]]
;2009-05-16
:[[Marketing Team/Events/MiniCamp Paris 2009|SugarCamp Europe 2009]]
;2009-05-23
:start of GSoC
;2009-05-31
:current code examined and understood; API, on-disk format and UI design chosen
;2009-06-07
:data store enhanced to be able to deal with versions (basic API)
;2009-06-14
:added (working) prev/next buttons to Journal details view
;2009-06-21
:added support for importing from existing data store
;2009-06-28
:added unit tests (and potentially regression tests), fixed all known bugs, submitted for review by [[Design_Team|Design Team]]
;2009-07-06
:GSoC midterm evaluation ("working and 90% done"); added indexing (e.g. using sqlite)
;2009-07-13
:code integrated upstream for increased exposure (testing!); started discussion on extended UI design (version tree etc.)
;2009-07-25
:end of (university) term
;2009-08-10
:end of GSoC
;2009-10-31
:Fedora 12 release; Sugar 0.86 release short time later?


== Me and the community ==


Note: remaining part of proposal needs to be written (below are just notes and copies from the template page).
=== Action after getting stuck ===


(to be written)
For this project, getting stuck means needing advice on UI issues. As I can ask both the whole [[Design_Team|Design Team]] and a friend of mine for input, it's rather unlikely that nobody will be around for a significant amout of time. Also I don't see the code produced by this project as the one and only answer to the problem, but rather as a start of a process. So I could just do an arbitrary choice and continue with the project, it's still adaptable later.


2009-04-12: Easter
=== Impact of this project ===
2009-04-20: start of (university) term
2009-05-23: start of GSoC
2009-07-06: GSoC midterm evaluation ("working and 90% done")
2009-07-25: end of (university) term
2009-08-10: end of GSoC


The Summer of Code work period is 7 weeks long,  
One of the initial design goals will actually be provided. Instead of giving users the choice of irrevocably deleting either the
May 23 - August 10;
old or the new content upon exit as current desktop applications do (unless the user explicitly invokes a "Save As" operation
prior to exit), the computer will now retain both and provide the user with ways to access them.


# Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described.
=== Sugar Pilot ===
This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing,
but be creative. Link to prior work or other resources as relevant.
For instance, you could avoid facing the issue of automated pruning of old versions for disk space,
or not have a converter for existing datastores.


Note: the work for this idea is ''more than halfway done''.
While I would very much like a Pilot to occur in my vicinity (once both this project and the Rainbow support have been merged),
The olpcfs2 virtual file system linked above is ''working'',
I'm not yet sure what the best target would be as I'm not directly involved with any school.
supporting versions and metadata;
all you need to do is a UI and an
index/searching mechanism on top of that.
And even if your indexing mechanism is just brute-force-search each-time,  
sure, it will be too slow for real use, but we can take it from there, as long you have a working proof-of-concept UI.


*Priority for Sugar: High
=== Keeping the community updated ===


*Coolness factor:++
For regular updates, I'll probably update a wiki page, as those interested in it can subscribe and get notifications via email.
There are going to be several projects going on, so sending the reports to the regular mailing lists feels like spamming.
For problems and questions, I can use both the IRC channel and the mailing lists, depending on the exact nature and target
audience (e.g. details on the current data store are best asked on IRC, while UI design questions are best elaborated in
a mail thread where there's sufficient time to do research to back up arguments).


*Difficulty: Hard
==Miscellaneous==


*Skills needed: primarily Python UI (pygtk); also FUSE/file systems (this part is mostly done); and Packaging and building.
I'm skipping the screenshot of the simple text replacement task for time reasons. I guess being the maintainer of the
 
[[Development Team/Buildbot|build infrastructure]] and having committed several patches on the bugtracker should be
sufficient substitute. :)


==You and the community==
* T-Shirt size: depending on the actual size (instead of just what's printed on the label) it's M up to XXL. Usually I go for L.
=== Great learning experience as a child ===
Wow, good question. I don't remember any particular event right now. In general, I learned most (and most easily) when I was
actually doing something, without any external help. Reading books (even text books, though not the school ones) was fun as well and
helped me get further insight and new ideas. That's still the case, though "the internet" has replaced books for me.


# If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.
=== Anything else to like the project more ===
# Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?
# What will you do if you get stuck on your project and your mentor isn't around?
# How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?


==Miscellaneous==
I don't think there's any need for raising the priority of this projects even higher, but as you asked I'll give a reason nonetheless:
[[Image:New-developer-challenge.png|thumb|right|An example of the kind of screenshot of your first modification to your development environment which you should include in your application. Note that the drop-down menu text has Mel's email address in place of the word "Restart" - your screenshot should contain your email instead.]]
Working on this project will significantly increase my understanding of the data store, the Journal and the whole Glucose software
# We want to make sure that you can set up a [[DevelopmentTeam#Development_systems|development environment]] before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.
stack. As a result, [http://dev.sugarlabs.org/ticket/593 adding Rainbow support] is going to get a lot easier.
# What is your t-shirt size? (Yes, we know Google asks for this already; humor us.)
# Describe a great learning experience you had as a child.
# Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?


The NeL project has some good general recommendations for [http://dev.ryzom.com/projects/nel/wiki/GSoC2009WritingProposals writing proposals]. We endorse them all; although Sugar is (regrettably) not test driven development (yet - your project could change that!), we encourage GSoC code to include tests.


[[Category:2009 GSoC applications]]
[[Category:2009 GSoC applications]]
Retrieved from "https://wiki.sugarlabs.org/go/Version_support_for_datastore/Proposal"