<html> <head> <style></style> </head> <body class='hmmessage'> Hello All,   In wanting to have Teachers and Developers try Sugar are best bet may be to attack this with a two-fold approach. The idea would be to give the prospective Teacher/Deployer Two SoaS-A stable version-say Strawberry explaining exactly what Sugar Labs means by Stable. Then the Newer Developer edition Mirabelle that allows them to test and be part of the Future Research and Development portion of Sugar. This would seem to get around many of the issues and draw support for stable and cutting edge versions. Sugar Today-Sugar Tomorrow 2Pack-Add in SoaS Creation Kit with both images and Instructions and we could have something very helpful to all participants.   If this route is chosen then the Developer release of Mirabelle should have many of the broken activities. These broken activities would seem to be a perfect place for many new community members to get acquainted with Sugar(Testing, Learning the Bug reporting system, Fixing activities). Activities are at the core of the "Learning How To Learn" portion of the Sugar Learning Platform so the appropriate level of resources making sure the communication is in place to keep them maintained should be of key focus, since it will be one the largest keys to our success in the classroom.   Best!   John Tierney     > Date: Mon, 22 Mar 2010 15:35:14 +0100 > From: tomeu@tomeuvizoso.net > To: pbrobinson@gmail.com > CC: martin.langhoff@gmail.com; mel@melchua.com; marketing@lists.sugarlabs.org; walter.bender@gmail.com; iaep@lists.sugarlabs.org; sdz@sugarlabs.org > Subject: Re: [Marketing] [IAEP] SoaS change of direction: heads-up on convos in other lists > > On Mon, Mar 22, 2010 at 15:24, Peter Robinson <pbrobinson@gmail.com> wrote: > > On Mon, Mar 22, 2010 at 2:21 PM, Tomeu Vizoso <tomeu@tomeuvizoso.net> wrote: > >> On Mon, Mar 22, 2010 at 15:11, Peter Robinson <pbrobinson@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). > > Yes, the issue as I understand it is with xulrunner. Frequent major > releases will mean more work for the mozilla team at ubuntu, and they > also could mean more broken embedders, so they want to eliminate > embedders so they don't have to fix them after every major release. > That's how I interpret that page, could be wrong though. > > Regards, > > Tomeu > > > Peter > > > _______________________________________________ > Marketing mailing list > Marketing@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/marketing </body> </html>