Summary

The artwork builder is supposed to run on a central server and is designed to reduce the workload of artists and the artists in chief, additionally it helps testing artwork. A rudimentary automatic art package builder already exists and is able to update the packaging and build system of artwork packages but has some outstanding issues which hindered the deployment and adoption by the art team late during in the Edgy release.

The spec will identify the problems and lay out the direction of its development.

Rationale

Artists generally have a hard time to build and update packages on their own, especially if it comes to changing the build system or the packaging. Using a version control system, they want to be able to commit their changes and get packages to test and distribute in short time.

Primarily the Artist in Chief but also other members of the Artwork community want to have a quick, visual overview of changes between commits - webpages to see changes in one glance are the way to go.

Use cases

Frank wants to check the latest commits of the Blubuntu team. While synaptic downloads and installs the newest Blubuntu theme packages, he checks the web page and is able to see the overview page, check how the colors fit together and read the last commit messages.

Thomas has an idea for a new theme. He downloads the source of an example theme, makes his changes and pushes his changes to launchpad. Half an hour later, the package was built and he can ask for a theme review on the ubuntu art mailing list.

Scope

To achieve these goals, some changes to the existing art builder are necessary.

Design & Implementation

The top priority changes and areas that are touched in the process are:

While the HTML pages are nice to look at, they are of a lesser priority. The following changes are necessary:

Outstanding issues

Problematic is the generation of new Makefiles (in the case of added directories). It is possible to simply install "interesting files" like .svg, .png, .theme and the like, but necessary actions (like running icon-naming-utils in the case of icon themes) can not be just 'implemented like that'.

Deferred to the next cycle

All the HTML related changes are not going to happen in the Feisty cycle.


CategorySpec
CategoryArtwork

Spec/ArtBuilderImprovements (last edited 2008-08-06 16:31:32 by localhost)