[sugar] Release schedule and process

Marco Pesenti Gritti mpgritti
Wed May 14 05:22:22 EDT 2008


On Wed, May 14, 2008 at 10:56 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>  For example the browse activity - this endorses one specific browser
>  implementation,

It just provides an hint to distributor about what the development
community consider the best browser for the platform. Distributions
are free to ship whatever browser they like. It happens in practice
for the GNOME browser.

>  it pulls in one huge chunk of code, etc.

Most of the code we pull in will be used by several distributors.
Keeping it in the process rather than let each activity evolve as a
third party component will ease their work immensely.

>  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.

Blessing a browser is not going to remove competition.

In practice, GNOME blesses a browser and despite most of the
distributor/users are using another one, with no interoperability
issues.

You can only design good API if you have concrete use cases to design
for. Activities provides those use cases. The fact that a specific
browser is in the release doesn't mean those shouldn't be as generic
as possible

>  IMHO it is better to clearly separate the core from the activities.

We are not developing a set of libraries. We are developing a user
experience. I'm fine with focusing on the core, if that gives us some
advantage. But the activities are totally part of this core.

>  This also forces clean interfaces, you cannot as easily chicken-out
>  when breaking the API (and silently fixing the included activities).

I don't think it forces anything. We can as easily silently fix the
activities we care about, even if they are not integrated in the
release process.

>  We want to encourage third-party activity development, keeping the
>  "core" as small as possible seems beneficial to me.

I agree about encouraging third-party, but I don't think it involves
keeping the core as small as possible.

Marco



More information about the Sugar-devel mailing list