This work is licensed under a Creative Commons Attribution 3.0
Unported License.

StoryBoard support for branches

StoryBoard needs to support branch-specific tasks in order to be usable for OpenStack bug tracking.

Problem description


StoryBoard is a task tracker, and its main use case is the ability to track resolution of a specific issue (story) across multiple teams.

Most OpenStack projects maintain stable/* branches. A few of them use feature branches. As we near release, projects make use of temporary proposed/* branches. All bugs need to be fixed in the master branch, but some of them will also need to be fixed in other branches, and that involves the work of a lot of separate subteams. So we need the ability to track tasks across branches (bugfix or vulnerability fix backports) as much as we need to track tasks across projects.

Historical usage

Launchpad supports series-specific tasks, which can be used to emulate branch support. A series in Launchpad is like a release cycle (“juno”, “kilo”) which contains multiple release “milestones”. By default in Launchpad a task applies to the series under development, but you can create series-specific tasks to target past series. An example of that can be seen at:

That said, Launchpad implementation becomes very confusing because you can also explicitly create a task targeting the current series, in which case the main task is disabled with a confusing “status tracked in…” message.

Proposed change

Task branches

Projects in StoryBoard may define multiple task branches. Each project has at least one task branch (called “master”). If a project has only one task branch, the UI should optimize and ignore that concept altogether, to simplify the views.

If a project is linked to a git repository, task branches may be created automatically from branches defined in that git repository (using for example a daily cron job). Each project may opt to have task branches autocreated from its code repository branches. This should not prevent them from manually creating an additional task branch.

Task branches should be able to expire: they would still show in past tasks, but you would not be able to select them for new tasks. Deleted branches would automatically result in expired task branches.

Note that the task branch concept degrades gracefully for non-code projects, which can opt to manually define several areas of work as task branches, or ignore the concept altogether and use the default branch.


Implementation details should be left to the person that would do the implementation work. What follows is just a suggestion.

The Project table would have two new columns:

  • ‘code_repo’, which would hold a URL describing the code repository, like

  • ‘autocreate_branches’, which would tell StoryBoard to try to create task branches automatically from the branches declared on that code repository

A new Branch table would be created, with the following columns:

  • ‘project_id’, mapping to the owner project

  • ‘branch_name’, with the name of the task branch

  • ‘creation_date’, date of creation

  • ‘expired’, a binary flag that marks branches that should no longer be selectable in tasks

  • ‘expiration_date’, last date the expired flag was switched to True

  • ‘autocreated’, a flag that marks autocreated entries, so that they can be auto-expired when the corresponding branch is deleted in the git repo

By default, all projects would start with a single “master” branch.

The Task table would have one new column:

  • ‘task_branch’, which would point to the affected branch in the project. Defaults to the ‘master’ branch for that project.

The UI would show the ‘branch’ only if multiple different branches are defined in the project, saving valuable horizontal space for projects that don’t have a use for this concept.


Primary Assignee:


Work Items



No new repositories.


No new servers.

DNS Entries

No new DNS entries.




Manual branch creation should be restricted to an admin set of users, to avoid accidental or spurious creation of project branches.




This proposal is not dependent on any other, but it is a prerequisite for task milestone or story type support.