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

[Peter Robinson]

On Mon, Mar 22, 2010 at 2:21 PM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> 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.
>
> From the Fedora side, it's true that I haven't heard anything pointing
> to discontinued support for pyxpcom, but people have mentioned that we
> may have trouble in Ubuntu-land:
>
> https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/
>
> I don't know how much serious is that, but there are lots of
> Ubuntu-derivatives used for education, so it would be great if someone
> could get some kind of official statement (maybe David?).
>
> If there's in no push from the community in the Ubuntu side, then
> maybe the upstream developers should be less concerned about it and
> expect that PPAs will be used to solve any eventual problems.

Well pyxpcom has been split out of the main source so it would just
need to be packaged up separately like was done in Fedora. As for
upstream development the same organisation that wrote it is still
supporting at using it AFAIA (the people developing the Komodo IDE
from memory).

Peter