Refactoring plan - Revision history

Tavmjong at 08:26, 10 February 2018

2018-02-10T08:26:00Z

← Older revision		Revision as of 08:26, 10 February 2018
Line 1:		Line 1:
	~~{{outdated}}~~
	{{DevDiscussion}}		{{DevDiscussion}}

			<div style="width:75em">
	== Overview ==		== Overview ==
	~~With Inkscape 0.46 wrapping up, it's time to look forward to our next~~
	~~release, 0.47, and our plans for its development.~~

	When we started Inkscape, we began with a codebase with lots of		When we started Inkscape, we began with a codebase with lots of
Line 16:		Line 15:
	accidental code duplication, unfinished code, obsoleted code, etc.		accidental code duplication, unfinished code, obsoleted code, etc.

	What ~~will the~~ codebase cleanup work entail? The work ~~will range~~ from		What does codebase cleanup work entail? The work ranges from
	straightforward “grunt” work like making some simple code changes to all		straightforward “grunt” work like making some simple code changes to all
	files in the codebase, to meatier work like abstracting widely used code		files in the codebase, to meatier work like abstracting widely used code
Line 25:		Line 24:

	=== Objectives ===		=== Objectives ===

	To boil this down into five high level objectives:		To boil this down into five high level objectives:

Line 34:		Line 34:

	=== Principles ===		=== Principles ===

	Now, architectural reworkings can often risk incur massive breakages		Now, architectural reworkings can often risk incur massive breakages
	since fundamental pieces of the code are being changed. In order to		since fundamental pieces of the code are being changed. In order to
	minimize this, ~~I'd~~ like to suggest the following principles:		minimize this, we would like to suggest the following principles:

	* Always keep the tree buildable
	* Always keep unit tests passing (and add new unit tests)
	* Do major refactorings in small steps
	* Hold code review parties with 2–3 others to brainstorm
	* Drop copied-in codebases in favor of external dependencies
	* Make sure every function you touch has some doxygen comments


	~~== Schedule ==~~
	~~This kind of work can go on indefinitely without a clear~~
	~~stopping point, so I think for this release we should use a schedule~~
	~~with a date-based stopping point. This will help everyone know how they~~
	~~should time their work.~~

	~~Mar 10 Release 0.46. 0.47 Refactoring / Cleanup work begins~~
	~~Apr~~
	~~May~~
	~~Jun~~
	~~Jul 1 Completion of refactoring. Focus on Bug Fixing begins.~~
	~~Open 0.48 development tree early, for GSoC work.~~
	~~Aug Put out 0.47-pre releases.~~
	~~Sep Release 0.47.~~

	~~For reference, here are some key GSoC dates:~~

	~~May 26 GSoC work begins~~
	~~Jul 14 GSoC midterm; first delivery of GSoC code~~
	~~Aug 18 GSoC work ends~~

	~~This schedule permits us to focus exclusively on refactoring for several~~		# Always keep the tree buildable
	~~months, with a due date of July 1<sup>st</sup> to complete it.~~ ~~It uses a very~~		# Always keep unit tests passing (and add new unit tests)
	~~early branch point, where we'll split into a stable branch for doing bug~~		# Do major refactorings in small steps
	~~fix and release work, and a development branch for the GSoC students~~ to		# Hold code review parties with 2–3 others to brainstorm
	~~use and for folks to continue right on with refactoring projects if they~~		# Drop copied-in codebases in favor of external dependencies
	~~wish.~~		# Make sure every function you touch has some doxygen comments
			</div>

Kris: dev discussion

2012-01-04T20:08:04Z

dev discussion

← Older revision		Revision as of 20:08, 4 January 2012
Line 1:		Line 1:
	{{outdated}}		{{outdated}}
			{{DevDiscussion}}
	== Overview ==		== Overview ==
	With Inkscape 0.46 wrapping up, it's time to look forward to our next		With Inkscape 0.46 wrapping up, it's time to look forward to our next

Kris: outdated

2012-01-04T19:53:03Z

outdated

← Older revision		Revision as of 19:53, 4 January 2012
Line 1:		Line 1:
	~~= 0.47 Refactoring Plan =~~		{{outdated}}

	== Overview ==		== Overview ==
	With Inkscape 0.46 wrapping up, it's time to look forward to our next		With Inkscape 0.46 wrapping up, it's time to look forward to our next

Kris: moved 0.47 Refactoring Plan to Refactoring plan: We're beyond version 0.47 :)

2012-01-04T18:56:33Z

moved 0.47 Refactoring Plan to Refactoring plan: We're beyond version 0.47 :)

← Older revision

Revision as of 18:56, 4 January 2012

Zearin: Added headings, minor text tweaks.

2009-11-05T20:25:05Z

Added headings, minor text tweaks.

← Older revision		Revision as of 20:25, 5 November 2009
Line 1:		Line 1:
			= 0.47 Refactoring Plan =

			== Overview ==
	With Inkscape 0.46 wrapping up, it's time to look forward to our next		With Inkscape 0.46 wrapping up, it's time to look forward to our next
	release, 0.47, and our plans for its development.		release, 0.47, and our plans for its development.
Line 6:		Line 9:
	resolved. Inkscape has grown rapidly, especially thanks to Google's		resolved. Inkscape has grown rapidly, especially thanks to Google's
	Summer of Code program. Unfortunately, while we've gained a lot of new		Summer of Code program. Unfortunately, while we've gained a lot of new
	features, it hasn't addressed the underlying ~~issues - and~~ in some cases		features, it hasn't addressed the underlying issues—and in some cases
	has exposed new problems.		has exposed new problems.

Line 14:		Line 17:

	What will the codebase cleanup work entail? The work will range from		What will the codebase cleanup work entail? The work will range from
	straightforward ~~"grunt"~~ work like making some simple code changes to all		straightforward “grunt” work like making some simple code changes to all
	files in the codebase, to meatier work like abstracting widely used code		files in the codebase, to meatier work like abstracting widely used code
	into a more concise and powerful algorithm, to advanced work such as		into a more concise and powerful algorithm, to advanced work such as
	extracting distinct code into independent code packages.		extracting distinct code into independent code packages.

			== Objectives and Principles ==

			=== Objectives ===
	To boil this down into five high level objectives:		To boil this down into five high level objectives:

	0. Complete some of the big architectural refactoring efforts		# Complete some of the big architectural refactoring efforts
	1. Reduce source code line count		# Reduce source code line count
	2. Break useful code out into stand-alone libraries		# Break useful code out into stand-alone libraries
	3. Increase code stylistic consistency		# Increase code stylistic consistency
	4. Make the codebase more convenient to code in		# Make the codebase more convenient to code in

			=== Principles ===
	Now, architectural reworkings can often risk incur massive breakages		Now, architectural reworkings can often risk incur massive breakages
	since fundamental pieces of the code are being changed. In order to		since fundamental pieces of the code are being changed. In order to
	minimize this, I'd like to suggest the following principles:		minimize this, I'd like to suggest the following principles:

	* Always keep the tree buildable		* Always keep the tree buildable
	* Always keep unit tests passing (and add new unit tests)		* Always keep unit tests passing (and add new unit tests)
	* Do major refactorings in small steps		* Do major refactorings in small steps
	* Hold code review parties with ~~2-3~~ others to brainstorm		* Hold code review parties with 2–3 others to brainstorm
	* Drop copied-in codebases in favor of external dependencies		* Drop copied-in codebases in favor of external dependencies
	* Make sure every function you touch has some doxygen comments		* Make sure every function you touch has some doxygen comments


	~~Further, this~~ kind of work can go on indefinitely without a clear		== Schedule ==
			This kind of work can go on indefinitely without a clear
	stopping point, so I think for this release we should use a schedule		stopping point, so I think for this release we should use a schedule
	with a date-based stopping point. This will help everyone know how they		with a date-based stopping point. This will help everyone know how they
Line 54:		Line 63:
	For reference, here are some key GSoC dates:		For reference, here are some key GSoC dates:

	May 26 GSoC work begins.		May 26 GSoC work begins
	Jul 14 GSoC midterm. ~~First~~ delivery of GSoC code		Jul 14 GSoC midterm; first delivery of GSoC code
	Aug 18 GSoC work ends.		Aug 18 GSoC work ends

	This schedule permits us to focus exclusively on refactoring for several		This schedule permits us to focus exclusively on refactoring for several
	months, with a due date of July ~~1st~~ to complete it. It uses a very		months, with a due date of July 1<sup>st</sup> to complete it. It uses a very
	early branch point, where we'll split into a stable branch for doing bug		early branch point, where we'll split into a stable branch for doing bug
	fix and release work, and a development branch for the GSoC students to		fix and release work, and a development branch for the GSoC students to
	use and for folks to continue right on with refactoring projects if they		use and for folks to continue right on with refactoring projects if they
	wish.		wish.

BryceHarrington at 18:08, 14 March 2008

2008-03-14T18:08:28Z

← Older revision		Revision as of 18:08, 14 March 2008
Line 32:		Line 32:

	* Always keep the tree buildable		* Always keep the tree buildable
			* Always keep unit tests passing (and add new unit tests)
	* Do major refactorings in small steps		* Do major refactorings in small steps
	* Hold code review parties with 2-3 others to brainstorm		* Hold code review parties with 2-3 others to brainstorm

BryceHarrington at 06:36, 14 March 2008

2008-03-14T06:36:29Z

← Older revision		Revision as of 06:36, 14 March 2008
Line 27:		Line 27:
	4. Make the codebase more convenient to code in		4. Make the codebase more convenient to code in

	, architectural reworkings can often risk incur massive breakages		Now, architectural reworkings can often risk incur massive breakages
	since fundamental pieces of the code are being changed. In order to		since fundamental pieces of the code are being changed. In order to
	minimize this, I'd like to suggest the following principles:		minimize this, I'd like to suggest the following principles:

BryceHarrington: New page: With Inkscape 0.46 wrapping up, it's time to look forward to our next release, 0.47, and our plans for its development. When we started Inkscape, we began with a codebase with lots of pot...

2008-03-14T06:35:27Z

New page: With Inkscape 0.46 wrapping up, it's time to look forward to our next release, 0.47, and our plans for its development. When we started Inkscape, we began with a codebase with lots of pot...

New page

With Inkscape 0.46 wrapping up, it's time to look forward to our next
release, 0.47, and our plans for its development.

When we started Inkscape, we began with a codebase with lots of
potential but with some architectural limitations that we've never quite
resolved. Inkscape has grown rapidly, especially thanks to Google's
Summer of Code program. Unfortunately, while we've gained a lot of new
features, it hasn't addressed the underlying issues - and in some cases
has exposed new problems.

Inkscape's also been extremely successful at gaining a lot of
contributors, yet this comes with a price: Stylistic differences,
accidental code duplication, unfinished code, obsoleted code, etc.

What will the codebase cleanup work entail? The work will range from
straightforward "grunt" work like making some simple code changes to all
files in the codebase, to meatier work like abstracting widely used code
into a more concise and powerful algorithm, to advanced work such as
extracting distinct code into independent code packages.

To boil this down into five high level objectives:

0. Complete some of the big architectural refactoring efforts
1. Reduce source code line count
2. Break useful code out into stand-alone libraries
3. Increase code stylistic consistency
4. Make the codebase more convenient to code in

, architectural reworkings can often risk incur massive breakages
since fundamental pieces of the code are being changed. In order to
minimize this, I'd like to suggest the following principles:

* Always keep the tree buildable
* Do major refactorings in small steps
* Hold code review parties with 2-3 others to brainstorm
* Drop copied-in codebases in favor of external dependencies
* Make sure every function you touch has some doxygen comments

Further, this kind of work can go on indefinitely without a clear
stopping point, so I think for this release we should use a schedule
with a date-based stopping point. This will help everyone know how they
should time their work.

Mar 10 Release 0.46. 0.47 Refactoring / Cleanup work begins
Apr
May
Jun
Jul 1 Completion of refactoring. Focus on Bug Fixing begins.
Open 0.48 development tree early, for GSoC work.
Aug Put out 0.47-pre releases.
Sep Release 0.47.

For reference, here are some key GSoC dates:

May 26 GSoC work begins.
Jul 14 GSoC midterm. First delivery of GSoC code
Aug 18 GSoC work ends.

This schedule permits us to focus exclusively on refactoring for several
months, with a due date of July 1st to complete it. It uses a very
early branch point, where we'll split into a stable branch for doing bug
fix and release work, and a development branch for the GSoC students to
use and for folks to continue right on with refactoring projects if they
wish.