[IAEP] Fructose = Sugar essentials (was: ASLO Suggestion)

[Tomeu Vizoso]

On Thu, Jun 11, 2009 at 18:18, Jonas Smedegaard<dr at jones.dk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> On Thu, Jun 11, 2009 at 04:33:29PM +0200, Tomeu Vizoso wrote:
>
>>IMO, the only reason for an activity to be part of Fructose is to be
>>tied closely to the release cycle. For most activities this will be a
>>bad thing, but for some it's good. I think it's good for activities
>>that depend closely on some part of the platform, so that when the
>>platform updates, say, xulrunner or evince, the activity for this
>>release cycle won't work in the past releases and past versions won't
>>work in the last release cycle. Using the same release cycle as the
>>platform makes things much easier.
>
> I strongly disagree with above: Sugarlabs should provide a minimal,
> core, essential system, that other activities are supposed to rely on as
> sole platform.

Agreed, that's http://wiki.sugarlabs.org/go/Development_Team/SugarPlatform/0.84

> Essentially you are saying (or I am reading into it) that Fructose
> activities are those relying on unstable/missing Sugar ABI.

No, released stable versions of fructose activities rely on at least
the last stable version of Sugar Platform.

> With your logic, activities that rely on non-Sugar libraries, like
> TamTam, should be part of Fructose, as future releases of CSound cannot
> be trusted to keep binary compatibility.  Just to name a single example.

I think you misunderstood me but cannot see in which way. TamTam, as
any well-behaved activity, relies solely on a released version of the
sugar platform. They are free to follow or not the sugar release
cycle.

> In my opinion *no* activities should be tied to the Sugar release cycle.
> Instead, *all* Activities, Fructose or not, should strive to be
> backwards compatible, but might fail to do so for various reasons.

I would like them to be backwards compatible but we should accept the
fact that some won't be. Right now I'm adding tabs to Browse and I'm
not going to try to find a way to make it backwards compatible because
I have a ton of other things to work on. If someone else has the time
and will to do so, patches are welcome.

> I agree with Gary on this (which you didn't comment on, Tomeu):
>
>>> For me, the only reason for Fructose is for those Activities
>>> considered an essential part of the Sugar platform, i.e without
>>> Browse it's going to be tough to install other Activities, without
>>> Read you won't be able to read documentation. Most Activities ended
>>> up in Fructose because their developers were also 'core' developers
>>> (those also working on the core Sugar platform), and they usually
>>> needed specific Activities to actually test and exercise the various
>>> features they were working on and integrating in Sugar.

As I said, I disagree with the explanation that Gary gives about why
activities are in Fructose, though I agree it's confusing. I don't
have nothing against having a list of basic activities, but are some
activities that are going to depend closely on the last released Sugar
Platform and those being in Fructose is going to make things easier
for everybody.

Regards,

Tomeu

>
>
> Kind regards,
>
>  - Jonas
>
> P.S.
>
> Please pretty please cleanup your emails: strip quoted text that you do
> not comment on.  That goes to all of you.
>
>
> P.P.S.
>
> If you read this far, it is most likely because I did not include a few
> miles of dead quotes of earlier mails.  :-P
>
> - --
> * Jonas Smedegaard - idealist og Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEAREDAAYFAkoxLj0ACgkQn7DbMsAkQLh2JwCfWg+QRX+A2ApnNvisp3LaTAK6
> wpUAmwTScLwIkweEBBSuOzswgLcPeyoH
> =a2Uv
> -----END PGP SIGNATURE-----
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>