[Sugar-devel] sugar-meeting notes today

[Tony Anderson]

Hi James

When you use the word activities, do you mean Sugar Activities?

At least in the original Sugar design, each activity is to supply its 
own dependent packages in the bundle. The 'owner' of the activity is 
expected to test the activity to verify that it works with a new Sugar 
release. In addition, activities generally are expected not to be 
release dependent but that new releases of Sugar also support them.

There may be certain activities such as Record that are inherently part 
of a Sugar release, but except for these there should be no connection 
between an activity bundle and the build system.

If the activities are kept separate from specific Sugar releases, the 
problems you cite should not apply. Users of a Sugar release can install 
activity bundles from ASLO as needed.

Tony



On 06/29/2017 01:05 AM, James Cameron wrote:
> On the team's question of making the image stable.
>
> (Probably they mean fixing problems, although for me "stable" is a
> software engineering term meaning "unchanging; no longer fixing the
> problems".)
>
> It will be up to the team to decide the method for fixing problems;
> the choices are either;
>
> 1.  applying fixes to the image builder itself; but these fixes will
> be lost as soon as packages are upgraded in the field, which makes the
> image only useful as an example, not as an ongoing system,
>
> 2.  applying fixes to activity files during image build; but these
> fixes will be lost as soon as packages are upgraded in the field,
>
> 3.  applying fixes to packages before image build; but not all desired
> activities are packaged, and maintaining separate packages to Debian
> is not going to be sustainable,
>
> 4.  applying fixes to packages in the Debian archive; but this
> requires your engagement with the Debian project,
>
> 5.  applying fixes to activities in Sugar Labs GitHub; but this
> requires waiting for the activity to be released, and then the Debian
> package to be released.
>
> My recommendations to the team are;
>
> a.  do not use SoaS as the basis for activities to be preinstalled,
> since SoaS activities are determined by whether they are packaged for
> Fedora, but rather use Debian packaged activities only,
>
> b.  preinstall the old version of Physics from the Debian archive, and
> work through the Debian project to get that updated, and meanwhile
> don't support the latest version of Physics as a download,
>
> c.  do not start into maintaining separate packages to Debian, as the
> skills just aren't there in the team and it will take weeks to gain
> those skills.
>
> Comments?
>