[sugar] Release schedule and process

[Marco Pesenti Gritti]

On Fri, May 16, 2008 at 12:24 PM, Simon Schampijer <simon at schampijer.de> wrote:
> Marco Pesenti Gritti wrote:
>>
>> On Wed, May 14, 2008 at 4:30 PM, Benjamin M. Schwartz
>> <bmschwar at fas.harvard.edu> wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>  Hash: SHA1
>>>
>>>  Marco Pesenti Gritti wrote:
>>>  | 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.
>>>
>>>  This is the key example:  Gnome has an official browser (Epiphany) and
>>> an
>>>  official mail client (Evolution).  I don't know anybody who uses either
>>> on
>>>  their own computers.  Yet most still have both installed.  This is
>>> stupid
>>>  and wasteful.
>>
>> That's a distribution choice. Fedora doesn't install epiphany by default.
>>
>>>  In truth, I think we are in agreement.
>>>
>>>  As I said before, we should maintain two builds: sugar-base and
>>>  sugar-demo.  sugar-base is essentially a virtual machine for Activities.
>>>  It does not come with any activities; it is just the empty shell.
>>>  sugar-demo is an example build, containing a complete set of activities
>>> to
>>>  show what we imagine a typical sugar installation to look like.  Both of
>>>  these builds should be built whenever there is a change, like joyride.
>>>  Most developers will run sugar-demo.  Most users will run custom builds
>>>  created by their deployments.  Deployments will create custom builds by
>>>  starting with a release version of the sugar-base build and using a
>>>  customization system to add Activities.  The resulting custom build may
>>> be
>>>  similar to sugar-demo, but need not contain all the activities in
>>> sugar-demo.
>>
>> I'm thinking and talking about upstream development, schedule and
>> sources, not about builds. But yeah, leaving that aside I don't think
>> we disagree.
>>
>> Marco
>
> Actually I want to add to this activities discussion that even that we do
> not
> have the activities installed by default the dependencies are.
> xulrunner/hulahop for browse, libabiword for write...
>
> What is the plan for those? I know that we do not have dependency handling
> at
> the moment but maybe we would have to then.

We should list the dependencies on the Roadmap page. I'm going to do
so when we made a call about which activities to include next week.

Marco