Editing Bazaar Imports Details
Status
Created: 2005-04-27 by DavidAllouche
Priority: NeedsPriority
People: DavidAlloucheLead, StuartBishopSecond
Contributors: RobertCollinsInterested
Interested: MorganColletInterested
Status: BrainDump, BreezyGoal, UduBof, NewSpec
- Branch:
- Malone Bug:
- Packages:
- Depends:
- Dependents:
UduSessions: 1, 4, 8, etc
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
A web browser product is first imported as firebird@arch.ubuntu.com/firebird--MAIN--0
- We publish revisions in that namespace.
- The product changes name.
We continue the import in mozilla@projects.ubuntu.com/firefox--MAIN--0.
- 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):
may not be set to a fqver already present in ArchNamespace
unless the ArchNamespace for this fqver belongs to the Branch that belongs to the ProductSeries.
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