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

[Peter Robinson]

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

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

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.

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