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

[Walter Bender]

On Mon, Mar 22, 2010 at 9:22 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>> I would like to add to this that the activity developer is at least
>>> CCed on bugs in Fedora so they can more actively see the issues with
>>> their activity and react to the bugs.
>>
>> Where my activity developer hat, this would be very useful. I suspect
>> that at least some of the non-responsiveness of developers is due to
>> their not knowing there is a problem in the first place. Also, some of
>> the problems among activities seem to be clustered around specific
>> components, e.g., multimedia support. Ideally, we'd (those who live in
>> the boundary between Sugar and Fedora) have a better handle on these
>> sorts of changes and perhaps be able to come up with some
>> recommendations to the activity developers as well., e.g., such and
>> such has changed in F13 so consider using such and such.
>
> I agree with some of your points here. There have been cases where I'm
> aware of things going on upstream that I've been able to advocate and
> give people information on. One example of this was dracut where it
> was used for the XO-1.5 rather than cutting a new system. This helps
> out olpc as its supported upstream. But we also have issues where
> activities include binary blobs that we are not aware of and hence I
> have no idea that a change in gstreamer ABI and hence soname will
> break the Activity because the repoquery command doesn't tell me. I'm
> quite happy to go through and fix simple breakages like that and
> assist in the process if I'm aware it will be a problem. I went
> through a week or two ago and fixed about 12 packages that were broken
> by the changes in the DSO linker that directly affect SOAS. Also both
> Sebastian and I have Proven Packager credentials so we can fix other
> breakages as necessary.
>
> I've also seen instances with the bug tracker at bugs.sugarlabs.org
> where it doesn't seem to assign the bug to a maintainer of an
> activity. I'm not sure if that's by design or whether it generally
> does but the bugs I've seen are special cases. It would be great to
> get the activity developers added as a CC: to the bug reports in the
> Fedora bugzilla. I strongly suspect that the emails will be very low
> but at least they can get viability of the issues.

Not by design, although not every developer requests a component for
their project. It would be great if you could file a ticket (assigned
to component bugs.sugarlabs.org) when you come across such a situation
so a new component can be assigned. Of course, this presumes that
someone knows whom is the maintainer.

>
>> I agree that there seems to have been some miscommunication that has
>> lead to some anxiety and mismatched expectations. My understanding is:
>>
>> (1) The SoaS team is trying to position their work as a Fedora spin in
>> order to better leverage the Fedora community processes, with the goal
>> of a system that is easier to maintain and easier for people to
>> contribute. This effort was announced broadly early in the release
>> cycle and has been in the roadmap, but the implications were not
>> necessarily clear to either the SoaS team or the SoaS user community.
>> Of course, the first time is always full of surprises.
>
> Yes, and SOAS as a project in general is still young so the process
> has evolved and changed substantially on each release to date.
>
>> (2) The recent communications about the spin has been interpreted by
>> the user community (end users and activity developers) as "this is
>> what you get" when -- tell me if I am wrong -- the real intention is
>> "this is where you start". The SoaS team has been trying to
>> communicate the latter of late, but I hope that he is not over
>> committing his time in an unsustainable way.
>
> "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.

> 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.

>
>> (3) We (Sugar Labs) have not been clear enough in our communications
>> that SoaS is not complete... it is still a work in progress. That
>> said, we do need to make it easy for people to use it or we will never
>> get the feedback we need to make it something that is reliable,
>> maintainable, *and* useful. I think the idea of a baseline "spin" that
>> is the official Fedora spin as per the roadmap needs to be coupled
>> with a "rawhide-like" version with many more activities, many of which
>> will not work properly. The key is how to make sure that those using
>> the latter understand that it is experimental and thus they should not
>> expect the degree of support they would get from a spin.
>
> The communications out of SugarLabs in general seem to be slowly
> improving which can only be a good thing.
>
>> -walter
>
> Peter
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org