Difference between revisions of "Refactoring plan"

From Inkscape Wiki
Jump to navigation Jump to search
m (Added headings, minor text tweaks.)
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.

Revision as of 20:25, 5 November 2009

0.47 Refactoring Plan

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

Objectives and Principles

Objectives

To boil this down into five high level objectives:

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

Principles

Now, 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
  • 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 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.