[sugar] Release schedule and process

[Tomeu Vizoso]

On Tue, May 13, 2008 at 7:33 PM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
>
>  Tomeu Vizoso wrote:
>  | I agree that limiting the number of components released as a whole
>  | brings important benefits. I think that the idea of releasing some
>  | activities as part of Sugar is because they provide "services" that
>  | are considered a basic part of the user experience inside Sugar.
>
>  Could you name an example of such an Activity?
>
>  It seems to me that the presence of any such Activity represents a design
>  bug in Sugar.  In the case of Chat and Journal, these are known design
>  bugs.  Chat will eventually be rendered mostly obsolete by pervasive
>  overlay chat, and the Journal is planned to be merged into the Sugar
>  interface itself.
>
>  The question of whether activities are included "by default" refers either
>  to prefabricated disk images or packages for distros like Fedora and
>  Ubuntu.  Regarding disk images, the answer is clear: do both.  We should
>  have minimal disk images, with just the Sugar base, and also demo images
>  with all the activities we think someone might want.

Obviously, it depends on what meaning "Sugar release" has to you. I
agree in that the Sugar shell + API shouldn't depend on any activity,
but some definition of Sugar may include some activities.

If we consider that browsing the web is an important use case to be
considered inside the Sugar experience, then it may make sense to
consider releasing Sugar along with a Browse activity. Same for Read
or Write.

Of course that the line needs to be drawn somewhere, that's what I was asking.

>  Determining what to do in the case of packages for other distros, the
>  situation is much muddier.  The plan for Activity packaging is designed
>  around the idea of thousands of unknown authors writing code that installs
>  and runs with minimal privileges.  Users will be able to install multiple
>  distinct activities with the same name, distinguished by cryptographic
>  authorship and history, upgrade or downgrade them, and modify their source
>  code, all without superuser access.  It's already difficult to harmonize
>  this with yum/rpm and apt/deb, and it's only going to get harder with the
>  new Activity bundle system.  I think our best option is to let Sugar
>  retain control of Activity installation, even when running on a system
>  with its own package management.

Not sure about it, I see arguments on both sides.

Thanks,

Tomeu