[sugar] Release schedule and process

[Tomeu Vizoso]

On Wed, May 14, 2008 at 10:56 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 13.05.2008, at 19:33, Benjamin M. Schwartz 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.
>
>
>  I pretty much agree with that. With the exception of activities that
>  Ben listed there is no reason to include more in Sugar itself.
>
>  For example the browse activity - this endorses one specific browser
>  implementation, it pulls in one huge chunk of code, etc. It is likely
>  that if hooks are added for opening URLs that they are specific to
>  that one browse implementation. If there were several browsers,
>  developers were forced to agree on some API. Competition is good, so
>  we should not pick one flavor over another.
>
>  IMHO it is better to clearly separate the core from the activities.
>  This also forces clean interfaces, you cannot as easily chicken-out
>  when breaking the API (and silently fixing the included activities).
>  We want to encourage third-party activity development, keeping the
>  "core" as small as possible seems beneficial to me.

I agree on this, the Sugar core shouldn't depend on any activity and
should also (aim to) give equal chances to all activity authors.

That said, does this mean that the full-time Sugar team should stop
maintaining any activities and focus on the "core"? I would love to do
so, but I'm afraid that Sugar won't reach its goals if we don't make
sure that some very basic activities keep growing.

As an example, yesterday I assumed Read maintenance because Reinier is
busy with school these days. I did this because we know that Read
fulfills very important use cases and cannot be left until someone
else appears and takes its maintenance.

And I plan to follow the Sugar release process with it because I want
that when the next stable release of Sugar comes along, Read has been
tested with the rest of Sugar and perhaps a new version will be
released that implements generic Sugar goals like could be reduced
memory usage and keyboard bindings.

Does it make sense?

Thanks,

Tomeu