On Thu, May 8, 2008 at 11:55 AM, C. Scott Ananian<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">ps. SJ, there are no 'core activities' that we ship.  There is only<br> one security-privileged activity (Journal), which we currently ship in the core build because (a) Sugar breaks otherwise, and (b) Rainbow's<br> activity-signing stuff is incomplete.  I hope we can fix both of these<br> in time, and stabilize the APIs enough that we can eventually unbundle even Journal.  </blockquote><div><br>Just fine.  We have more work to do to comply with the GPL in this case...  A build that loads Sugar without successfully loading a bundle stream should give visible indications that it is not yet complete.<br>  </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Your notion of 'core activity' is probably worthwhile<br> for support and documentation reasons<br></blockquote><div><br>There are many related notions of coreness.  While I wasn't trying to define a new one, in the context of feeds and activity status tags, I will offer one:  the intersection of "globally supported" "important to education" "localized into the ambient language" and "moderately demanding" (in size and resource consumption).  This could be one of the default available streams, suitable for priming all machines in a region, and further tweaked by teachers and students on receipt.<br> <br>Preparing / testing / localizing / updating the latest "supported" version of an activity has its own timeframe; smooth deployment depends on all parties involved planning sufficiently far out.   So while your defintion of 'build process' is one which excludes  activity development, there is a parallel build process for named activity-sets which we should be talking about with clarity.  <br> <br>SJ<br></div></div>