[IAEP] [Marketing] SoaS change of direction: heads-up on convos in other lists

[Peter Robinson]

>> "This is where you start" is definitely the message that should be
>> pushed. Also a "Install and update Activities" control panel which
>> uses PackageKit would make it much easier to automatically find and
>> install Activities as well as update them at a later stage.
>
> There is a lot of discussion about this and other approaches to
> packaging... some movement as well. It will get better. The problem is
> that there is only a partial overlap between what is currently well
> maintained and what is needed by the end users and since there is
> often a issue with network access for our end users, an "install and
> update" model will often fail, regardless of the packaging system
> used. This is why I think it is important to still offer an
> "experimental" build that trades reliability and support for variety
> and inclusiveness. Again, how this is communicated is paramount.

WRT to packagekit. The advantage that it has is that it supports .deb
and .rpm so what ever the underlying distro is it will work and in the
case of the rpm support at least (I don't know enough about the deb
integration) you can use locally hosted repos in the case of a school
server, and it even support static media such as optical and usb
sticks. So it covers a lot more options than just being connected to
the internet.

WRT the "experimental with lots of variety" vs the "stable with not so
much" I personally believe there's pros and cons to both approaches.
The former is what we've done with previous SOAS releases but we've
had the "SOAS SUCKS because Activity X doesn't work" remarks which
isn't good or constructive and its much harder to support for a small
core team. The later approach will have "I wish there was Activity Y"
but at least the included Activities should be more stable. In the
short term for SOAS-3 there will be the "SOAS-3 sucks because previous
releases came with Z" as well. Basically in the short term we're
screwed which ever way. But on the plus side it should give Activity
developers incentive to better support their Activities and make them
more stable so they'll be considered for inclusion in a later release.

>> The move to Fedora is also intended to help reduce the workload for
>> all involved. Like the merger of Moblin and Maemo there is a lot of
>> cross over between Sugar and other Fedora projects with very similar
>> underlying core platforms. Gnome/Sugar/Moblin/Meego are all based on
>> telepathy/gstreamer/xulrunner etc and the last 3 are all designed for
>> small platforms (and if you take gnome-mobile into that as well they
>> all are) so they all meld together and the difference ends up being
>> the GUI on top so to be able to utilise all the associated engineering
>> resources to reduce overall load it helps everyone, especially the
>> smaller projects like SOAS.
>
> The good news is that Collabora is helping Tomeu with a migration of
> the Sugar Telephany work, so we should be better aligned with the
> mainstream there come 0.90. We are also working to better leverage
> gstreamer in order to phase out a dependence on alsa that has causes
> some of the breakage you've experienced with binary blobs. Re
> xulrunner, it is a hot topic of discussion right now... Any insights
> you may have regarding what the future may bring in terms of support
> and maintainability would be welcome.

I'm aware of Tomeu's work. I'm also looking forward to seeing the use
of the new component (can't remember what its called) in gstreamer for
F-13 in Record to make that more stable.

WRT xulrunner I've seen parts of the conversation. I think xulrunner
is improving in both speed and memory usage so I'm not sure what the
problem is. The next minor release (after the one due this week) will
have things like Out Of Process Plugins so that crashing flash etc
won't take down it all. Also things like massively improved I/O are
helping performance etc.

The conversations about discontinuing support for xulrunner are
rubbish, and even though the pyxpcom component was split out in the
latest major release the xulrunner/firefox guys at redhat have been
very helpful to ensure Sugar requirements are met. If there's any
thing I've missed in that regard let me know.

Peter