36
edits
Changes
General observations of the Sugar Camp meeting in Paris, France held 16th and 17th of May 2009 - relational to opensuse and autpackaging
General observations of the Sugar Camp meeting in Paris, France held
16th and 17th of May 2009.
====================================================================
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 cancelled, 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 Aleksy Lin, 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:
=======================================================================
a. The user finds a bug in the latest release and then puts it into track.
b. 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.)
c. 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.
d. Next step is peer review.
e. Patch gets improved, turned down, or accepted. This loop will
continue until the parties are happy with the code status.
f. 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...
16th and 17th of May 2009.
====================================================================
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 cancelled, 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 Aleksy Lin, 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:
=======================================================================
a. The user finds a bug in the latest release and then puts it into track.
b. 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.)
c. 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.
d. Next step is peer review.
e. Patch gets improved, turned down, or accepted. This loop will
continue until the parties are happy with the code status.
f. 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...