[Sugar-devel] FYI, Tincho blog

[James Cameron]

Good progress, thanks.

Our critical problem _now_ is lack of people doing activity
maintenance.

My opinion is that both Flatpak and Snaps seem fragile, bulky, and
difficult to maintain.  It would add more build metadata to activity
sources, which would then bitrot.  We've already faced that with
ASLOv1, ASLOv2, View Source, Social Help, AppStream, and ASLOv3.

I don't mind if someone else does it, but I'd like to understand the
impact on the sources.  Based on https://github.com/tchx84/sugarapp
the impact is another dependency, which could be built-in to the
activities.

I don't think the Sugar activity user experience will be acceptable to
the average desktop user, so Martin's work on changing the experience
is critical.

Some have mentioned the opportunity to involve GCI students, but GCI
should not influence our architectural decisions, rather it should be
the other way around.  A potential student on IRC agreed "I wouldn't
do that task with a 10 foot long pole tbh, I think gci should be left
to fixing well defined tasks"

I've also done some design work on replacing Telepathy entirely with
multicast UDP and unicast TCP, but I'm not ready to publish.  This
could allow Flatpak apps to collaborate.  The Level activity contains
a prototype which shortens the time to collaborate from about seven
seconds to nearly zero.

On Mon, Nov 25, 2019 at 04:27:57PM -0500, Walter Bender wrote:
> [1]https://blogs.gnome.org/tchx84/2019/11/22/
> linux-app-summit-2019-and-sugar-learning-tools/
> 
> --
> Walter Bender
> Sugar Labs
> [2]http://www.sugarlabs.org
> [3]
> 
> References:
> 
> [1] https://blogs.gnome.org/tchx84/2019/11/22/linux-app-summit-2019-and-sugar-learning-tools/
> [2] http://www.sugarlabs.org/
> [3] http://www.sugarlabs.org/

> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel


-- 
James Cameron
http://quozl.netrek.org/