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 <[EMAIL PROTECTED]> 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 [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
_______________________________________________ Sugar mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/sugar
