ArtBuilderImprovements

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.

  • The use of apt-ftparchive is not incorporated yet, the built packages are not published yet.

  • The work flow will not involve a huge artwork branch (this is the current workflow), but checking out a list of branches first, then checking those branches out consecutively.
  • Some fixes in the code that updates the build system have to be done.
  • The HTML generation code is not written at all yet.

Design & Implementation

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

  • Package related code:

    • run apt-ftparchive at the end of the process. [DONE]

  • bzr related code:

    • check out a list of branches and check out each one of them consecutively. (The list will have the format <branch> <theme> to indicate to what theme the package belongs.) [DONE]

    • publish changed bzr branches [DONE]

    • mail a bzr merge <url> command to the Maintainer of the individual package to easily incorporate the changes the artwork builder deemed useful.

  • tarball related code:

    • change configure.ac to reflect deleted and added directories

    • update SUBDIRS variable in Makefile.am

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

  • build individual <theme>.html pages, including the relevant graphics of the packages (*.png, *.jpg) belonging to the theme, include the branch names and package names

  • convert *.svg to *.png
  • shrink *.png files that are too big them

  • when it comes to icon themes, re-use csv data from iconprio to pick only the prio 10 icons.

  • link to .deb
  • link to old revisions of the package

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)