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