[sugar] Develop Activity

[Andrew Clunis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Dec 18, 2006 at 04:04:34PM -0500, Eben Eliason wrote:
> This looks like a really good start to me.  I have comments on a few
> of the sections:
> 
> Version Control:
> 
> This is a rather tricky subject.  It's true that version control will
> be built into the Journal in some manner.  However, the Journal
> typically retains object level changes.  With respect to the Develop
> activity, this means that it would retain a history for the activity
> bundle as a whole (since the object is the bundle, and not the
> individual files within it).  One editing session may change a dozen
> different source files, yet result in only one new journaled version.
> 
> As such, the granularity isn't really what you'd expect for a source
> code repository.  Furthermore, the Journal probably won't have a way
> to handle revisions made by others, and so collaborative code
> generation will have to be handled within the activity itself.  The
> thing to be careful about is to prevent confusion between the
> versioning that the Journal does, and that which the activity itself
> maintains. It's a hard balance, and it will take some care to get
> right. It also means that, unless we can find a way to do everything
> in the Journal itself, we should actually avoid "Write a journal
> entry" and instead use something more similar to "Commit" in order to
> differentiate their functions.

Yes!  Journal isn't (and shouldn't try to be) a full dvcs.  However, a
full dvcs is likely needed to implement the collaboration features I
described in the draft spec.  A lot of people seem keen on it,
implementation issues aside.  Trouble is, how do we make such a system
work sanely with Journal's own version control?  We don't want it
versioning the dvcs' own versioned data, which would be a waste of
space, not to mention confusing.  I *suppose* we could have a special
data-type in Journal that would disable versioning, but that seems ugly.
Perhaps we could add special bazaar (or whatever dvcs we choose,
although bazaar seems most likely) support to Journal.

And yeah, the "Write to Journal" text was imperfect.  I just wasn't sure
what the best metaphor to describe a version control system would be that
wouldn't conflict with the capital-j Journal.

> 
> Bug and Task Tracker:
> 
> This sounds good.  It's also a really good way to emphasize
> collaboration.  I can already envision a list of bugs and tasks, color
> coded by who is responsible for fixing/performing them.
> 
> Furthermore, I could see a bug tracking system that functions really
> well on the mesh.  For an unsigned bundle, perhaps anyone running the
> activity can post a bug, which will then work its way back to the
> developer (anyone who has their ID in the activities watermark).  this
> would create a really positive feedback system via the mesh, and
> encourage a community of kids interested in development to help each
> other out.

Yeah! That would be awesome.  I suggest that the mechanism for this be
the same mechanism for bug/issue tracking the official activities; users
can file bugs against the built-in Activities the same way as ones from
their peers.

One problem with that, though: that might cause a lot of unknowing
children to file nonsense bugs that would drown upstream in an deluge of
useless bugs.  Hmm...

> 
> View Source:
> 
> This is the best real world specification I've seen for view source
> yet, and I like it a lot.  It really seems to make sense to me.  My
> only question is whether we actually need to prompt the user about
> making a copy.  Since we never want to allow direct modification of an
> activity, it goes without saying that any activity a child chooses to
> modify should be a copy (fork, branch, whatever).  I would argue that
> we should take a "copy on write" approach, so that the user doesn't
> need to think about it.

Aw, gee, thanks! :)

As for the CoW approach, I agree. Although, we do want to convey to the
user what they are about to do, and not be too implicit.  Perhaps Sugar
should open the activity up in Develop in read-only mode first and have
an extra toolbar item like "Make Your Own Version" or similar.

> 
> Actually, to refine that point a bit, we already have a distinction
> between signed and unsigned bundles
> (http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/Activities/Activity_Bundles#Bundle_Types).
> It seems that if they view source for a signed bundle, it should copy
> on write.  Similarly, if the bundle isn't watermarked by them, they
> should get a new branch with their watermark.  In cases where they
> have already modified the activity, and therefore it's watermarked by
> them, they should be presented with that Develop project itself, and
> simply edit new versions of the files within it.  This would occur if
> they were testing out their activity, found a glitch, and wanted to
> jump right in to make a change.

Yup, I agree with all of that, save one point:  I would argue against
treating "official" activities any differently from "watermarked
activities from other children".  In fact, I would argue that official
activities merely be "watermarked by a person at the OLPC project".

Right now, the current proposed system differentiates an individual with
an "offical group".  Perhpaps, as a compromise, it might be better to
have offical things watermarked by an individual, but that person signed
by the group (public key signatures?).

I suppose this would have some relevance to whatever sort of OS update
feature makes it in, as well.

I apologise for the braindump.  One thing I'm keeping in mind here is
that Develop should provide the children with a playing field that is
as equal with the OLPC platform people as technically possible.
> 
> - Eben

- --
Regards,
Andrew Clunis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFiOz2ALkUMXSNow8RAtk/AKC0O+2zRLxf4KZWi9f+oFsnJztNuQCdFvAp
25g+y4JRthaN8BFiXn/ryVY=
=VRed
-----END PGP SIGNATURE-----