Talk:OpenSUSE - Revision history

FGrose: moved Talk:Community/Distributions/OpenSUSE to Talk:OpenSUSE: restructure

2012-07-02T02:39:38Z

moved Talk:Community/Distributions/OpenSUSE to Talk:OpenSUSE: restructure

← Older revision		Revision as of 22:39, 1 July 2012
(No difference)

Satellit: /* One Click Install of Sugar */

2011-08-22T21:49:02Z

One Click Install of Sugar

← Older revision		Revision as of 17:49, 22 August 2011
Line 1:		Line 1:
	{{TOCright}}		{{TOCright}}
			::[http://wiki.sugarlabs.org/go/Community/Distributions/OpenSUSE return to openSUSE]
	=One Click Install of Sugar=		=One Click Install of Sugar=
	: {{Warning \| Not working yet-IN DEVELOPMENT 08/22/2011}}		: {{Warning \| Not working yet-IN DEVELOPMENT 08/22/2011}}

Satellit at 21:46, 22 August 2011

2011-08-22T21:46:06Z

@@ Line 1: / Line 1: @@
 {{TOCright}}
-General observations of the Sugar Camp meeting in Paris, France held
+=One Click Install of Sugar=
-th and 17th of May 2009.
+:   {{Warning | Not working yet-IN DEVELOPMENT 08/22/2011}}
 ==Introduction==

FGrose at 14:46, 19 May 2009

2009-05-19T14:46:47Z

← Older revision		Revision as of 10:46, 19 May 2009
Line 1:		Line 1:
			{{TOCright}}
	General observations of the Sugar Camp meeting in Paris, France held		General observations of the Sugar Camp meeting in Paris, France held
	16th and 17th of May 2009.		16th and 17th of May 2009.
	==~~================================================================~~==
			==Introduction==

	Massive strides were made in community integration and community		Massive strides were made in community integration and community
Line 39:		Line 41:
	assurance. The following is a report of what we came up with:		assurance. The following is a report of what we came up with:

	~~===========================================================================~~

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

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



	There were various discussion topics that included various subtopics.		There were various discussion topics that included various subtopics.
Line 55:		Line 57:
	R – Roadmap		R – Roadmap

	Sadly, the School Environment topic got ~~cancelled~~, though it is of		Sadly, the School Environment topic got canceled, though it is of
	particular importance to larger deployments and anything including the		particular importance to larger deployments and anything including the
	school server. The subtopics for that group included: Teacher		school server. The subtopics for that group included: Teacher
Line 61:		Line 63:
	for deployments and Mass deployments		for deployments and Mass deployments

	======~~====================================================================~~		===Autopackaging===
			We can define this as the process of going from the
	~~Autopackaging –~~ We can define this as the process of going from the
	code that developers write going into the git version control system		code that developers write going into the git version control system
	to the public. There is an easy way of automating this without		to the public. There is an easy way of automating this without
Line 85:		Line 86:
	distros and all platforms automatically.		distros and all platforms automatically.

	~~=======================================================================~~

	Method of communication between wishers/bugsquad and core development team		==Method of communication between wishers/bugsquad and core development team==

	~~=======================================================================~~

	At the moment, the centralised programmers upload their stuff and		At the moment, the centralised programmers upload their stuff and
Line 116:		Line 115:
	OLPC, or support forums.		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.~~		===Methodology for bug tracking and triaging – to peer reviewing and fixing:===

	~~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.		# The user finds a bug in the latest release and then puts it into track.
			# 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.)
			# 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.
			# Next step is peer review.
			# Patch gets improved, turned down, or accepted. This loop will continue until the parties are happy with the code status.
			# Someone with commit access commits the patch.

	~~======================================================================~~

	When will 0.82 be end of life? – There is no answer to this currently		* When will 0.82 be end of life?
	as it is to early to know what people in the field need. Should it be		*: 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.
	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		::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.)
	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		* Should we use package kit to standardize the packaging?
	question that came up and it is an interesting proposal, what do we think?		*:This was a question that came up and it is an interesting proposal, what do we think?

	~~======================================================================~~

	~~Auto testing of activities~~

	===~~================================================================~~===		===Auto testing of activities===

	There is something called sugarbot that should auto test activities.		There is something called sugarbot that should auto test activities.
Line 172:		Line 148:
	there any other ideas on how to do this?		there any other ideas on how to do this?

	~~======================================================================~~

	Buildbot will not run on the current hardware. We need to find a		Buildbot will not run on the current hardware. We need to find a

Nubae: /* = */

2009-05-18T15:15:30Z

← Older revision		Revision as of 11:15, 18 May 2009
Line 123:		Line 123:

	a. The user finds a bug in the latest release and then puts it into track.		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,		b. The bugsquad does triage. Triage means assessing the bug,
	validating it, and giving it a priority, and milestone (which release		validating it, and giving it a priority, and milestone (which release
	its going to be fixed in.)		its going to be fixed in.)

	c. At some time, someone will try to fix it, usually a core developer.		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		If it’s not a core developer, it will always be attached as a patch
	and reviewed.		and reviewed.

	d. Next step is peer review.		d. Next step is peer review.

	e. Patch gets improved, turned down, or accepted. This loop will		e. Patch gets improved, turned down, or accepted. This loop will
	continue until the parties are happy with the code status.		continue until the parties are happy with the code status.

	f. Someone with commit access commits the patch.		f. Someone with commit access commits the patch.

Alsroot: /* == */

2009-05-18T14:53:45Z

← Older revision		Revision as of 10:53, 18 May 2009
Line 67:		Line 67:
	to the public. There is an easy way of automating this without		to the public. There is an easy way of automating this without
	spending too much time on the development. This is currently a task		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		being taken up by Aleksey Lim, who sadly could not be at Sugar Camp but
	is pretty much a core developer at this point.		is pretty much a core developer at this point.

Nubae: General observations of the Sugar Camp meeting in Paris, France held 16th and 17th of May 2009 - relational to opensuse and autpackaging

2009-05-18T14:48:57Z

General observations of the Sugar Camp meeting in Paris, France held 16th and 17th of May 2009 - relational to opensuse and autpackaging

New page

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