Talk:Development Team/Release/0.82 - Revision history

Dfarning: Talk:DevelopmentTeam/Release/0.82 moved to Talk:Development Team/Release/0.82

2009-04-08T16:46:35Z

Talk:DevelopmentTeam/Release/0.82 moved to Talk:Development Team/Release/0.82

← Older revision	Revision as of 12:46, 8 April 2009
(No difference)

Dfarning-bot: Talk:ReleaseTeam/0.82 moved to Talk:DevelopmentTeam/Release/0.82: Robot: moved page

2008-11-13T00:55:09Z

Talk:ReleaseTeam/0.82 moved to Talk:DevelopmentTeam/Release/0.82: Robot: moved page

← Older revision	Revision as of 20:55, 12 November 2008
(No difference)

Marcopg: Talk:ReleaseTeam/Roadmap moved to Talk:ReleaseTeam/0.82

2008-09-23T12:40:58Z

Talk:ReleaseTeam/Roadmap moved to Talk:ReleaseTeam/0.82

← Older revision	Revision as of 08:40, 23 September 2008
(No difference)

Dfarning: Talk:Roadmap moved to Talk:ReleaseTeam/Roadmap: move under release team hierarchy.

2008-05-29T01:53:00Z

Talk:Roadmap moved to Talk:ReleaseTeam/Roadmap: move under release team hierarchy.

← Older revision	Revision as of 21:53, 28 May 2008
(No difference)

Morgs at 19:18, 13 May 2008

2008-05-13T19:18:12Z

← Older revision		Revision as of 15:18, 13 May 2008
Line 17:		Line 17:
	I think we should just be flexible in this respect:		I think we should just be flexible in this respect:

	* In the normal case maintainers of activities included in the Sugar		* In the normal case maintainers of activities included in the Sugar release process should be willing to follow the schedule, i.e. provide
	release process should be willing to follow the schedule, i.e. provide		development and stable releases more or less in sync with the Sugar process.
	development and stable releases more or less in sync with the Sugar		* If there is a need to skip a development cycle (for example because the developers are working on large features or refactoring of the
	process.
	* If there is a need to skip a development cycle (for example because
	the developers are working on large features or refactoring of the
	code) it's fine to do so.		code) it's fine to do so.
	* Activities are encouraged to release stable updates outside the		* Activities are encouraged to release stable updates outside the Sugar dev cycle when there is need to do so.
	Sugar dev cycle when there is need to do so.

	:> In some cases, there is more than one choice for a core activity:		:> In some cases, there is more than one choice for a core activity:

Walter: New page: I've posted this email exchange as I think it gives a good rationale for the Activity release process. --~~~~ On Tue, May 13, 2008 at 6:41 PM, Walter Bender wrot...

2008-05-13T17:16:54Z

New page: I've posted this email exchange as I think it gives a good rationale for the Activity release process. --~~~~ On Tue, May 13, 2008 at 6:41 PM, Walter Bender <walter.bender@gmail.com> wrot...

New page

I've posted this email exchange as I think it gives a good rationale for the Activity release process. --[[User:Walter|Walter]] 17:16, 13 May 2008 (UTC)

On Tue, May 13, 2008 at 6:41 PM, Walter Bender <walter.bender@gmail.com> wrote:
:> Ah. I was missing a subtly: do we agree that activities can be
:> released on their own timeframe, but that some activities are released
:> with the Sugar releases? For example, Write could be updated whenever
:> the Abiword team feels it is appropriate, perhaps in sync with other
:> Abiword releases, but a Sugar release would always include a working
:> Write? Is this the Gnome model?

In GNOME applications tend to sync up with GNOME at least until the
stable release. Then usually distributions start to ship them and each
projects does his own releases in response to critical bugs reported
etc. It also happens that some applications skip a cycle and GNOME
ship with the latest stable release.

I think we should just be flexible in this respect:

* In the normal case maintainers of activities included in the Sugar
release process should be willing to follow the schedule, i.e. provide
development and stable releases more or less in sync with the Sugar
process.
* If there is a need to skip a development cycle (for example because
the developers are working on large features or refactoring of the
code) it's fine to do so.
* Activities are encouraged to release stable updates outside the
Sugar dev cycle when there is need to do so.

:> In some cases, there is more than one choice for a core activity:
:> there are at least three credible Draw programs at the moment. Which
:> one is folded into the Sugar release is an interesting
:> question--somewhat different from the question of what are core
:> activities.

The Sugar community would bless one of these. And that's fine I think.
Distributors are obviously free to disregard the blessing.

:> Michael and Scott's Customization process takes care of
:> some aspects of both of these questions,

I think the customization process will work in specific distribution
context. It's not the right solution for Sugar/Fedora or Sugar/Ubuntu,
for example.

:> but it doesn't address the
:> question of whether or not Sugar would issue a release that was
:> incompatible with *any* Draw activity.

That's another reason the Sugar release should include activities imo.
It will give good criteria to decide when API changes are ready to be
released (yeah we should aim for API stability, but at some you always
need to break).

Marco