Difference between revisions of "0.86/Roadmap"

Revision as of 01:30, 25 May 2009

Team Home · Join · Contacts · Resources · FAQ · Roadmap · To Do · Meetings

Sucrose Development

Sucrose 0.85.x is an unstable development series intended for testing and development purposes. Sucrose uses odd minor version numbers to indicate development status, so this unstable 0.85.x series will eventually become the 0.86 stable release.

Schedule

Date	Task	Notes
2009 Jun 05	Release goals proposal
Jun 12	New modules proposal
Jun 25	Sucrose 0.85.1 Tarballs Due
Jun 26	Sucrose 0.85.1 Development Release
Jul 23	Sucrose 0.85.2 Tarballs Due
Jul 24	Sucrose 0.85.2 Development Release
Aug 20	Sucrose 0.85.3 Tarballs Due
Aug 21	Sucrose 0.85 Alpha (0.85.3)	Feature and API Freeze, String Cooling*
Aug 27	Sucrose 0.85.4 Tarballs Due
Aug 28	Sucrose 0.85.4
Sep 03	Sucrose 0.85.5 Tarballs Due
Sep 04	Sucrose 0.85.5 Beta (0.85.5)	String Freeze**
Sep 10	Sucrose 0.85.6 Tarballs Due
Sep 11	Sucrose 0.85.6
Sep 17	Sucrose 0.86 Tarballs Due	Hard code freeze
Sep 18	Sucrose 0.86 Final Release!

* String changes have to be announced, but no exceptions have to be requested.

** Every string change has to be requested and to be approved.

Glucose Development Team/Release/Modules

Fructose Development Team/Release/Modules

Glucose Dependencies

Fructose Dependencies

pyabiword
hulahop

Proposal Goals

Switch to a standard WM

Switch to a standard compliant window manager (possibly Metacity)

better non-sugarized activity support
our current version of matchbox is unmaintained
#602
goal: test patch in a custom Soas image
Owner: Tomeu?

New toolbar widget

add new widget and switch basic activities to it
keep the old widget if some of the activities do not change in this cycle
Eben's mockups
Owner: Marco?

Browse

tabs support (open popup windows in tabs, saving of tabs history, standard behavior of Browse should not change -> no open tab by default)
better naming of files to be uploaded (change temp name to something based on the title)
export for offline viewing (Web page - HTML only, Web page - Complete)
creating of web pages (highlighting support in Write, Activity with special HTML based features(can happen outside of the official cycle))
bookmarks (global bookmarks, at the moment we only have session bookmarks and the autocompletion functionality)
Owner: Simon?

Tags in the Journal

auto completion for already existing tags, tag clouds
- its implemented in Library activity as well
Owner: ?

More Accelerators (short cuts)

make sure we use the accelerators where possible, get discussion about which modifiers to use for which settings as early as possible going
Owner: ?

Printing support

Google summer of code project
Owner: IwikiwI

Search in home view

the search is recently builds disabled
Owner: ?

Collaboration

Scalable presence service - Integrate gadget in the Sugar UI #7711
Make collaboration more stable
Owner: ?

Flash activities

using the sugar gnash widget - a blog post from Tomeu has some more info
Owner: ?

Groups

tagging buddies to build up relations, tagging can happen by a teacher tagging a class or the learner can tag himself
Owner: ?

List views

in the mesh view a list view of the access points
switching to use gtk-tree-view for the lists (journal, activity) - this has accessibility support already
Owner: ?

Mesh View

use buddy color to seed the position to get a more stable positioning in the mesh view
Owner: ?

Ad-hoc networking

as an alternative to the mesh
Owner: ?

Bindings

Moving Sugar to PyBank to save memory and improve startup speed. Pybank builds the bindings as you need them, so you don't import all the bindings for gtk at startup of every process.
Vala bindings for the toolkit
- (?) could we move vala binding to #Decoupling of Sucrose/bridge level? i.e. use for core only dbus API and provide bride level in vala binding Alsroot 06:15, 25 May 2009 (UTC)
Owner: Tomeu

Keyboard control panel extension

(Sayamindu would prefer to keep it as a separate module, since everyone may not choose to go with XKB)
Owner: Sayamindu

Dictionary support in the shell

Dictionary Proposal
Owner: Sayamindu

CP - Language in native language

link to ticket here
Owner: Sayamindu

TA

de-couple the portfolio from the base TA
Owner: Walter

Library activity

Library Activity Proposal
in honey
maybe we want a pluggable Views(Home/Journal) to ease the use of such kinds of activities(activities that can browse sugar objects)
- another option - add autostart activities
Owner: Alsroot

API work

backwards compability
(http://wiki.sugarlabs.org/go/Development_Team/sugar-port will take care for the activities needs for a working activity on 0.82 for example) see "Decoupling of Sucrose" section Alsroot 16:16, 21 May 2009 (UTC)
(?) start moving to pure dbus interface for glucose
- dbus method to resume/open activities(instead of sugar-toolkit API)
  - something simple like dbus_object.activate(uid) or
- etc.
Owner: ?

Decoupling of Sucrose

The major idea is to have tough core(with stable release cycle) <=> dbus-API/sugar-toolkit-API(in ideal only dbus) <=> unlimited count of activities that uses core functionality and do not follow 6 months release cycle(which could be overmuch for activity).

It could looks like:

core - glucose, six months(or so) release cycle, w/o any activities, only API
bridge - sugar-port for example, between all(in ideal) already deployed sugars and activities i.e. it provides backwards compatibility(so the same activity code will work on all sugars) and at the same time provides features from newest sugar(so the same activity code will use last sugar's features)
world - the rest of sugar world i.e. fructose/honey (but now there are no differences between them) that use core directly, if all deployed sugars have the same API for desired functionality(for example in case of preselected mime type, ObjectsChooser has different API for 0.82-0.86), or use bridge otherwise.
imho another point to have activities outside of core release cycle - activities have more shorter release cycle then core has

And of course deployers can form any sets from these components

+------------+                                           +------------+
| Sugar-0.82 |---+                                   +---| Activity A |
+------------+   |   +---------------------------+   |   +------------+
+------------+   |   | bridge level              |   |   +------------+
|     ...    |---+---| do not fail on 0.82       |---+---|    ...     |
+------------+   |   | but uses all 777 features |   |   +------------+
+------------+   |   +---------------------------+   |   +------------+
| Sugar-777  |---+                                   +---| Activity Z |
+------------+                                           +------------+

Owner: ?

Version support for datastore

See Version_support_for_datastore/Proposal.

Owner: Silbe

Datastore features that could benefit Library

These features can benefit Activities/Library activity. At present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get bundle_id value. So its not good.

With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).

Get collapsed find()'s resultset Let user call datastore.find() to get list of collapsed objects(all versions by one item).

That should mean that any datastore object should have "object id":

activity_id for objects that were generated by activities (already implemented)
bundle_id for .xo bundles in the Journal
uid for other objecets (already implemented)

History of collapsed object Let datastore clients browse history of collapsed objects:

for activity_id objects - sort by timestamp (already impelemented)
for bundle_id objects - sort by activity_version(or so) field

Sort find()'s resultset Let datastore clients sort objects by any field(not only predefined like uid, activity_id etc).

Sort by buddies count

Owner: ?

Security

Add support for the current version of Rainbow so

security flaws in Browse (which are the norm rather than the exception) don't allow an attacker to take over the machine and
programming mistakes cannot affect other activities (like deleting all Journal contents).

Owner: ?

Testing

Add some automated testing to catch bugs earlier and ease integration work:

SugarBot (activity-level testing)
some system-level tests (e.g. verify datastore works correctly)
regression tests
Owner: ?

Activities updates

Let users update theirs activities.

There could be several options:

Use XO's mechanism to have update item in control panel(pretty common choice)
- we will have specific option - update only activities
Follow Unified Objects paradigm, one of implementation of this idea is Activities/Library, so give user more freedom in upgrading procedure(i.e. w/o ceilings) - incorporate updating procedure into browsing tool(like Journal, Library), so users get one unified method to browse and update(sync) theirs objects(not only activities).
- in case of Activities/Library we could have 0.82+ upgrading tool

Owner: ?

Old items

Accessibility in Sugar [1]
Unified Bundles merge .xol bundles to .xo

Proposed modules

nothing proposed yet