BazaarImportsEditing

Editing Bazaar Imports Details

Status

Introduction

The Bazaar Imports RCS details sometimes need to be updated, we need to find a workflow to do it and database schema constraints to avoid Arch namespace collisions over time.

Rationale

We must never reuse an Arch name that has already been used for publishing version control information, even if the ProductSeries that initially used that Arch name has switched to another name.

We need to allow product owners to edit RCS details.

Updated RCS details must be reviewed by admins to ensure they are sane.

Admins may have to take some specific manual action, for example if upstream changes version control system.

Scope and Use Cases

Notation: fqver means "fully-qualified revision", that is the archive/category--branch--version name that identifies a branch in the Arch namespace.

Filling Arch Details

When filling in the Arch details for a productseries import.

  • We must prevent use a fqver that was already used to publish an import.

Avoiding Promiscuity

  1. A web browser product is first imported as firebird@arch.ubuntu.com/firebird--MAIN--0

  2. We publish revisions in that namespace.
  3. The product changes name.
  4. We continue the import in mozilla@projects.ubuntu.com/firefox--MAIN--0.

  5. We import the firebird database.

We must not use the firebird@arch.ubuntu.com/firebird--MAIN--0 for this new import. That is addressed by the "filling arch details" use case.

We should not use the firebird@arch.ubuntu.com archive, that contains the web browser import, for the database product import.

Updating Upstream RCS

The RCS details for a product can have to change for various reasons:

  • A given version control repository can change location.
  • A product can change version control systems.
  • The product owner can create a fork of the product.

Modifying the RCS source for an import may require manual operations by the import admins.

  • Users may not be allowed to modify the RCS details for a running import.
  • Import admins must be allowed to change the details.
  • Users may be allowed to modify the RCS details if

Implementation Plan

Filling Arch Details

In addition to the schema details documented below:

ProductSeries(targetarcharchive, targetarchcategory, targetarchbranch, targetarchversion):

Stub? How does that translate into schema?

Avoiding Promiscuity

A new table is created that records what where the archives historically used by a project/product. Stub? More details?

Schema Changes

Filling Arch Details

Make ProductSeries(targetarcharchive, targearchcategory, targetarchbranch, targetarchversion) UNIQUE.

Updating Upstream RCS

Ensure rcstype, cvsroot, cvsmodule, cvsbranch, cvstarfileurl, svnrepopsitory, bkrepository cannot be changed if importstatus is >= 5 (AUTOTESTED) or datesyncapproved IS NOT NULL. This constraint may be relaxed in the future if we develop a better workflow.

Data Preservation and Migration

Packages Affected

Launchpad.

User Interface Requirements

The productseries source form should make the RCS details uneditable when they cannot be edited.

Arch namespace collision errors in the productseries admin page should be reported in an understandable manner.

Outstanding Issues

UDU BOF Agenda

UDU Pre-Work


CategoryUdu CategorySpec

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