On Mon, Mar 22, 2010 at 6:12 AM, Peter Robinson <[email protected]> wrote: > On Mon, Mar 22, 2010 at 9:35 AM, Tomeu Vizoso <[email protected]> wrote: >> On Sat, Mar 20, 2010 at 18:10, Peter Robinson <[email protected]> wrote: >>> On Sat, Mar 20, 2010 at 4:54 PM, Martin Langhoff >>> <[email protected]> wrote: >>>> On Sat, Mar 20, 2010 at 12:46 PM, Peter Robinson <[email protected]> >>>> wrote: >>>>> On Sat, Mar 20, 2010 at 10:26 AM, Sean DALY <[email protected]> wrote: >>>>>> The problem with this approach is that it renders SoaS ineffective for >>>>>> new tryers of Sugar (i.e. the overwhelming majority of teachers and >>>>>> parents we are trying to reach). >>>>> >>>>> I don't think it will be any less ineffective than having 20 >>>>> activities of which half have issues, crash or just don't run. >>>> >>>> Are people saying _only 6 activities work reliably?_ >>>> >>>> My question of "which is it?" was assuming there are more than 6 that >>>> run well, demo well, maintained, etc. So it meant "which plan is it, 6 >>>> activities that allow downloading and installing of more, or the good >>>> ones?" >>>> >>>> If there are only 6 good ones... would focus on making that list longer. >>>> >>>> Did APIs break with Sugar churn, Fedora churn? Developers upload >>>> without testing? (Rethorical! Flamefest warning! Those questions are >>>> bound to be a flamefest blaming people who don't deserve to be >>>> blamed... :-( ) >>> >>> I think some of or all of the above are to blame. I'm still trying to >>> get time to test. I should do so in the next couple of weeks. Record >>> is one of the classic ones with issues. It was broken horribly for >>> SOAS-2 and possibly even v1 but there's been no real attempt to fix >>> it. Part of it is also that to be in Fedora the precompiled binary >>> crud needs to be removed and in a lot of cases Activity developers >>> don't test it with the native libraries. Also I know Write isn't >>> currently on the list because it doesn't work properly [1] but >>> obviously it would be a good one to have as its a great demo of the >>> collaboration. >>> >>> We also want to get away from the point where a few people are running >>> around doing 20 hour days trying to get the release out the door. >>> >>> I know just prior to to the last release that Sebastian was >>> re-spinning the release into the early hours of the morning to fix >>> Activity bugs to get the release out the door on time for marketing >>> the day before an exam. If people aren't going to spend the time to >>> make sure their activity works prior to a release there's only only >>> limited time the main people have to do the testing along with all the >>> other release process as well as getting on with the rest of their >>> life. So I think its better we ship with less Activities better tested >>> that cover the core functionality. >> >> FWIW, Peter's words resonate with my feelings on this issue, but maybe >> this change could have been communicated differently (or maybe I'm >> misunderstanding its ultimate cause). > > Agreed, it should have been bought up and discussed more openly first > but ultimately there's all too few people doing the work and all too > many people with an opinion. I feel those actually doing the work > should have more say.
I don't know if the people actually doing the work should have more say in the discussion itself... it is an open discussion. But certainly the people doing the work should have more say in what decision gets made. In practice, since they are the ones doing the work, they will presumably do what they think is in the best interest of the project. >> How I see this issue is that the Sugar community has come to expect >> the SoaS maintainer(s) to test dozens of activities each release cycle >> and fix all the issues that may have crept in. Of course, this is an >> unreasonable expectation and the SoaS team has decided to reduce the >> scope of their work so it becomes more doable. >> >> What the SoaS team could have said instead of "we'll ship half a dozen >> activities", is "we have agreed on a criteria for activities that are >> to be included in a SoaS release". Such a criteria could have been >> something like: >> >> - the activity has been tested and works with the last Sugar release, >> >> - the community has voted this activity as sufficiently relevant to be >> present in SoaS, >> >> - the activity has a maintainer that will react to issues with the >> activity, answer questions, etc. >> >> - the activity has been packaged as a rpm and is part of Fedora. > > 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 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. (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. (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. -walter >> This may be more effective in tackling with the root cause, which I >> feel to be unreasonable expectation for the actual resources. The >> community would understand that the SoaS team currently doesn't have >> enough resources to include so many activities, and also would feel >> compelled to find more resources to maintain activities. > > Agreed. > > Peter > _______________________________________________ > Marketing mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/marketing > -- Walter Bender Sugar Labs http://www.sugarlabs.org _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
