HCT Training and Feedback



This specification addresses the current lack of experience by the distro team with HCT.


HCT needs feedback and experience by the distro team to be sure it is well suited to their needs. Giving a series of small training sessions should allow good interaction and feedback.

Scope and Use Cases

The use-cases that have been discussed for the initial push of HCT to the distro team are as follows:

  • Management of a package on the dogfood server
  • Direct Modification of package components (orig.tar.gz, diff.gz, etc.)
  • Adding new patches to the package
  • Adding patches that, rather than creating patch files, get applied to the diff.gz
  • Converting patches between "patch file" and "apply to diff"
  • Removal of obsolete patches
  • Generation of source package

Implementation Plan

On return from the conference and post-conference holiday:

  • Source package imports of Ubuntu into dogfood
  • Hosting archive on either mawson or casey
  • Make HCT packages available through APT
  • Save relationships between branches in the database

Data Preservation and Migration

As the source packages will be imported into dogfood, they are by definition "throw away" and scratch. Attempts will be made to preserve patch information where the user wants that, and at the same time providing a "clear it out and start again" service.

HCT will need to ensure that the MD5sums of generated original tarballs match the original, we have it in the Library so can use that; we could also determine whether we have changed the tarball or not and just take the original.

User Interface Requirements

The following HCT features have been requested that will need to be implemented:

  • "hct get" without a source directory; to just get a patch to work on (could do an implicit source)
  • same for hct patch, etc.
  • "hct get" should take an alternate destination path for throw-away patch changes
  • "hct contents" without a source directory, but with the URL of a known package
  • Better heuristics for branching packages into a local archive.
  • "hct status" and "hct diff" should accept an option (--all or --branch?) that accumulates all of the changes for the entire patch branch, not just the uncommitted ones. Use case is "what does this patch change?" without calling assemble and reading it.
  • "hct assemble" should warn when creating empty patches
  • "hct rmpatch" should deal with removing patches which have children; possibly by reparenting them, or asking for removal.
  • "hct commit" in the top-level could use debian/changelog to provide default commit message.
  • "hct fix" should take changes to any tree, not just the assembled one, and make a patch out of them
  • "hct commit" could assemble as well
  • it was felt that "patch", "fix", etc. could do with better names
  • limit the size of the hct archive by killing unused branches

None of these are complicated, and the work requirements are low.

Outstanding Issues

The following BOFs have been scheduled to discuss outstanding issues:

CategoryUdu CategorySpec

UbuntuDownUnder/BOFs/HctTrainingAndFeedback (last edited 2008-08-06 16:37:19 by localhost)