Talk:OpenSUSE

return to openSUSE

One Click Install of Sugar

Not working yet-IN DEVELOPMENT 08/22/2011

11-4 One Click Install of Sugar:

TESTING 08/22/2011

• sugar 0.84.2 one step installs:

sugar-cellulose Basic install

sugar-sucrose activities

sugar-honey 10 more activites

sugar-desktop 39 packages

• Terminal: sugar-emulator (produces blank xephyr)

logout:gdm will not login sugar

software manager-install evince; openSuse edu branding

• Terminal: sugar-emulator (produces blank xephyr)
• This Procedure Does Not work at this time

General observations of the Sugar Camp meeting in Paris

16th and 17th of May 2009.=

Introduction

Massive strides were made in community integration and community driven projects which will be considered or worked on in the coming months for the next release of Sugar, referred at this time as 0.86, and to be officially released in August of this year, following a 6 month release cycle of Gnome and many other open source projects.

Some of the more interesting changes that will happen are a move away from matchbox to metacity, the well known and supported backend window manager used by Gnome. This should in theory allow for much greater integration into Gnome itself of individual sugar activities, as well as the launching of sugar in Gnome, and even speed improvements. This move is possible because the XO 1.5 will have more memory and better cpu speeds, as well as a move away from sugar being agnostic to that hardware. Sugar on a Stick was the big focus, which is now working quite well, but still not perfect.

A desire for a revival of the help application was shown and that will become one of the core fructose activities, though likely it will be totally updated and perhaps even interactive. Browse will be upgraded to have tabbed browsing, and have better support for integrated flash/gnash, pdf support and youtube casts. A demo was shown of a screencast of the usage of an activity coded at the camp, using turtle art. These quick advances show that it is not only possible to strengthen the Sugar Core and its activities, but also that one day soon we will have a ubiquitous sugar solution that will run on all distributions and platforms and most hardware.

The mention of fundraising was raised and there is a target in place of aquiring 100,000 euros within the next release cycle which will be used primarily in marketing and gathering core sugar people to the places they need face to face talks like the one provided in Paris.

Our particular subgroup was asked to come up with a solution for better support, performance, security, testing, triaging, and quality assurance. The following is a report of what we came up with:

Future of Sugar – Support, triaging and quality assurance– Famework for 0.86

There were various discussion topics that included various subtopics. Our group was responsible for the Autopackaging group, or better known as the support, testing and quality assurance group.

The other groups were: M – Marketing A – Autopackaging SE – School Environment R – Roadmap

Sadly, the School Environment topic got canceled, though it is of particular importance to larger deployments and anything including the school server. The subtopics for that group included: Teacher Training; Primers – paperbacks; Technical feedback; Centralised admin for deployments and Mass deployments

Autopackaging

We can define this as the process of going from the code that developers write going into the git version control system to the public. There is an easy way of automating this without spending too much time on the development. This is currently a task being taken up by Aleksey Lim, who sadly could not be at Sugar Camp but is pretty much a core developer at this point.

The name of the project is jhconvert and it will be responsible for generating spec files and policy files for the various distributions Sugar chooses to support. This is somewhat of a political issue, as usually it is the package maintainers who do such a task, but automation will make it much easier for Sugar to reach the public, and I for one, being the maintainer for Sugar packages on OpenSUSE am happy about this. For those distributions that choose not to support this approach, they can always either take the code directly from git and re-invent the wheel or do this manually, or take the src rpms or src debs. I can speak only for openSUSE, but there, this direct automation from git to the opensuse build system will be a reality, and will allow for a direct transition from new revisions to activities being uploaded to git, to them being available for all distros and all platforms automatically.

Method of communication between wishers/bugsquad and core development team

At the moment, the centralised programmers upload their stuff and apply patches to git as and when and the review queue is up to the programmers. This needs to change drastically and a methodology of collecting support and feature data efficiently and effectively must be the part of people other than the core developers, who have far more pressing needs and no time to review the thousands of requests coming through the support pipeline. We need people to review the tracker and review queue. 2-3 core people should be looking through the bug tracker, and inform the programmers. This task used to be done by Greg Smith of OLPC who did an incredibly difficult job in a great way under extreme conditions. Finding a replacement will not be easy, but currently there are many active volunteers who want to help in this area.

They are out there in groups doing Q/A, support, testing and triaging, but someone needs to be the user experience leader, a person who both the developers know and trust, and who can weed out the support or feature requests that are unrealistic or irrelevant. One possibility was to automate this by putting a voting mechanism in place for something like trac, but it would unlikely be used and could be easily tampered with. If there is anyone out there willing to take on this difficult and demanding task, but extremely rewarding experience, please contact the Sugar team, via the mailing lists, IRC, the wikis, OLPC, or support forums.

Methodology for bug tracking and triaging – to peer reviewing and fixing:

1. The user finds a bug in the latest release and then puts it into track.
2. The bugsquad does triage. Triage means assessing the bug, validating it, and giving it a priority, and milestone (which release its going to be fixed in.)
3. At some time, someone will try to fix it, usually a core developer. If it’s not a core developer, it will always be attached as a patch and reviewed.
4. Next step is peer review.
5. Patch gets improved, turned down, or accepted. This loop will continue until the parties are happy with the code status.
6. Someone with commit access commits the patch.

• When will 0.82 be end of life?

  There is no answer to this currently as it is to early to know what people in the field need. Should it be long term, short term, very long term? These answers will come at some stage, but not right now.

Currently packaging happens to fructose and glucose only. This will not be the issue in the next release. RPMS will be automatically created, though it will be the decision of the distribution in question whether and how to use them. The .xo bundles will still be there but will be overwritten (basically put into a different place and given priority over the older relkease.)

• Should we use package kit to standardize the packaging?

  This was a question that came up and it is an interesting proposal, what do we think?

Auto testing of activities

There is something called sugarbot that should auto test activities. It’s a google summer of code activity, but should be there for the next release. It tests honey, not glucose, fructose.

We need a testing roadmap for glucose and fructose. Doing something like what Gnome does would be good. We could also look at KDE. Are there any other ideas on how to do this?

Buildbot will not run on the current hardware. We need to find a sponsor for the machines and hosting?

This has now been communicated and should be fixed... As I understand it, buildbot takes a look at some of the automation of testing packages being built. Maybe alsroot can expand...