Priorities for Develop?

[Morgan Collett]

2008/5/16 Jameson Chema Quinn <jquinn at cs.oberlin.edu>:
> I am planning to apply to OLPC for a job as a contractor, working on
> Develop. I have been told that my first-priority feature, automatic code
> localization, would be hard to justify on the OLPC roadmap. So I'd like to
> hear some votes/priorities on the following "dream" features, listed roughly
> from easiest to hardest (+/- two slots):
>
> 1. auto-pylint
> 2. doctools
> 3. peekaboo-like (figleaf with xmacro - throw autogenerated events at an
> activity, watch coverage, and log stack traces. When I worked at
> Palm/3Com/PalmSource, they called it "gremlins".)
> 4. autocompletion
> 5. move towards collaboration, starting with support for merges and
> changelogs (new-version notification and real-time collaboration would both
> come later than this)
> 6. automatic code localization (program in Python with
> Spanish/Chinese/whatever keywords, but it is real python on-disk)
> 7. debugger
> 8. Gui designer (a la glade)
> 9. other (bug tracking)
>
> (for those unfamiliar with Develop currently, it has source coloring, good
> find-replace, log viewing, rudimentary version control through the journal.
> Currently I am working on updating Sugar's bundle format, this will make
> Develop more useful for existing activities, and make sugar smarter about
> updates; for instance you will be able to have a dev version and a stable
> version of your activity coexist on a given XO. This current work would be
> done before I would even begin with anything from the above list.)
>
> Personally, I would most like to work on feature number 6 (code
> localization). In my view, with hundreds of thousands of Spanish-speaking
> kids on the xo, this feature would be, not only a great addition to the
> education mission of OLPC, not only (if done right) an advancement for
> computer science in general, but also an investment in getting future
> activities written. So I would be happy if that got a broad acclaim of
> support. But I want to be able to feed my family and code for the XO at the
> same time, so I will apply for a contract with whatever looks to me has the
> best cost/votes ratio.
>
> For easier voting, I have pretty much copied this same email to
> http://wiki.laptop.org/go/Develop/roadmap . Feel free to vote here on mail
> if you have something to contribute to the discussion, and I will copy any
> results of this thread to that page, but if you just have some votes you can
> just vote there.

Here's my take on Develop. Some of these are no doubt already
implemented - please indicate which.

Develop should be really really good at creating new activities, and
editing existing ones, without any need for using Terminal and other
editors. That should be stable, reliable and effective.

Features required for this, IMHO, are:
* Integration with the View Source key for arbitrary activities
* NO TOTAL LOSS OF JOURNAL CONTENTS.
* No need for DoppelJournal
* Support for editing single file activities
* Support for editing multiple file activities
* Producing valid activity bundles as they now exist
* Access to activity/activity.info
* Icon editing for activity/*.svg
* Ability to easily continue editing an activity (keep version number,
service name, other metadata) or do a new release (increment version
number) or fork (change relevant metadata)
* Ability to start a new activity, populated with relevant minimum
boilerplate code (Hello World) that runs immediately and can be worked
on immediately ("Look, I did a program!")

Some of the above require changes to Sugar or Journal. Take that as
your responsibility to keep those patches up to date and get them
reviewed and merged.

I would recommend that you do the following as part of achieving the above:
1. A custom build demoing Develop completely working with View Source
-> editing -> running, with your changes to sugar/journal etc applied
in that build so no need for DoppelJournal, and View Source not
needing any activity hooks like Chat needs for Pippy
2. Your patches to sugar/journal etc reviewed and merged into git master
3. Your patches applied in a sugar release (see
http://wiki.sugarlabs.org/go/Roadmap - presumably by 0.81.3 release
before feature freeze)
4. A Develop release suitable for public use, working seamlessly with
a joyride build after the sugar release is included

I recommend NOT proceeding with your list of features until the above
list is complete and in an activity release with a corresponding build
with sugar/journal, suitable for inclusion in the next OLPC stable
release. It's been too long that there has been no usable Develop
activity. If we can get something useful to activity developers of all
ages, then we boost the usefulness of the XO out of the box.

As a lower priority feature, I would be interested in seeing the
ability to view (and possibly edit) python "system" (non activity)
code, including sugar, sugar-toolkit (sugar libs), presence service,
journal, datastore. As someone said of having a Free Software kernel
on the XO, it's not like the kids will start developing the platform,
but at least they will see that it is developed by mere mortals and
say "Oh, Python! So *I* can get from here (my simple activity) to
there (sugar itself)!"

My Zim$4091314.55 worth (US$ 0.02!) - hope it helps.

Morgan