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

[Tomeu Vizoso]

On Mon, Mar 22, 2010 at 15:11, Peter Robinson <pbrobinson at gmail.com> wrote:
>>> "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.