[sugar] Develop Activity

[Eben Eliason]

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.

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.

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.

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.

- Eben

On 12/18/06, Andrew Clunis <orospakr at linux.ca> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folks!
>
> I just spent an hour or two on this:
>
> http://wiki.laptop.org/go/Develop
>
> Thoughts?
>
> - --
> Regards,
> Andrew Clunis
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQFFhjU/ALkUMXSNow8RAs/bAKDLol+ZHNbxDCO+SAP1wXXYLPJ73wCgvbjG
> Pk94UkjN6zwqBKjpM18nR/A=
> =JJim
> -----END PGP SIGNATURE-----
> _______________________________________________
> Sugar mailing list
> Sugar at laptop.org
> http://mailman.laptop.org/mailman/listinfo/sugar
>