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

[Tomeu Vizoso]

2009/6/13 Jonas Smedegaard <dr at jones.dk>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> On Fri, Jun 12, 2009 at 05:53:30PM +0200, Tomeu Vizoso wrote:
>>On Thu, Jun 11, 2009 at 18:18, Jonas Smedegaard<dr at jones.dk> wrote:
>>> 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
>
> Above looks like the environment required for developing Sucrose
> itself.

No, those are the components that developers can use for their
activity and can expect to be available during runtime.

> Do you mean to say that an activity that contains C code linking
> directly to e.g. GTK+ 2.16 is ok?

Yes.

> IMO well-behaving non-Fructose activities should only require Glucose.
> I.e. to not bind directly to non-Glucose libraries or invoke any
> non-Sucrose commands.

Why so?

>>> 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.
>
> It makes sense to me that you consider some Sucrose releases stable as a
> whole.
>
> It makes no sense to me, however, that you consider individual Fructose
> activities stable and at the same time you say 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."
>
> To me above sounds like a pretty exact description of an unstable ABI.

Gtk+ has stable ABI, but you cannot expect that the latest GEdit will
work in a past release of Gtk+.

About the opposite direction, you are right. We need people to help
with keeping backwards compatibility, but I will note that we have
never promised this. For python activities it's quite easy to add
hacks to make the activity run in several releases, but requires that
the author do a lot of testing.

>>> 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.
>
> Because there is a risk that due to its dependency on CSound, which
> might change its ABI at some point in the future (similarly to xulrunner
> has done recently), "when the platform updates, [...] the activity for
> this release cycle won't work in the past releases and past versions
> won't work in the last release cycle."
>
> But ok - you specifically used evince and xulrunner as examples, and
> CSound did somehow not fit in as alternative. So let me try a different
> example:
>
> You wrote, that in you opinion "the only reason for an activity to be
> part of Fructose is to be tied closely to the release cycle."
>
> If someone writes another activity which needs xulrunner, should that
> new activity then be part of Fructose too?

No activity _needs_ to be part of fructose. It's just a convenience
offered to activity authors that wish to use it.

>>> 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 am not pointing fingers at your work or the work of anyone else.  I am
> simply suggesting that backwards/forward compatibility not be the reason
> for inclusion in Sucrose.
>
> If you agree with me in that, then please elaborate on what you meant
> earlier, as I then clearly got it completely wrong.

The only reason for including an activity in Sucrose is because the
activity authors finds this release cycle convenient because of
synchrony with new releases of components like hulahop and
sugar-toolkit and because translators may have an easier time by
working on translations in one batch.

>>> 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.
>
> Sorry, I cannot parse that last long sentence above.  Could you perhaps
> rephrase?

Just did in the previous paragraph, hope it's a bit clearer now.

Regards,

Tomeu

> Kind regards,
>
>  - Jonas
>
> - --
> * 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)
>
> iEYEAREDAAYFAkoz7hMACgkQn7DbMsAkQLitDQCfZ6tVXGyV8XD5DydeSZRprlnX
> BgQAn2ex/vR+zdGCmgKygJsPC4TSGahC
> =Rqh8
> -----END PGP SIGNATURE-----
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep