Ubuntu Wiki

• Launchpad Entry: port-architecture-handling

• Created: April 27th, 2009

• Contributors: Michael Casadevall

• Packages affected: None directly, this is an informative specification meeting

Summary

The ports architectures of Ubuntu have not been regularly maintained in Ubuntu as community-maintained architectures due to lack of resources, and lack of direction on how the community should become involved in handling it. Based on responses to my request for people to help with PowerPC and SPARC architectures, there is still a fairly large community interested in Ubuntu on these architectures.

Release Note

TBD on resolution of ports handling

Rationale

To build a community-supported architecture, we need to lower the bar to allow people to contribute and clearly document how ports shall be handled w.r.t. to kernel management, installer manager, SRU and security management, and so on.

User stories

Ports often have had broken releases, and aside from PowerPC, in poor shape. Users often came into #ubuntu-powerpc after the Intrepid release trying to figure out why they couldn't install due to a bug that had slipped by the ports team last minute that broke the installer (specifically the PowerPC alternate images were not being built until the very end of the cycle, and by time the bug had been discovered, it was too late to do a last minute update to upload the d-i files. This has been fixed in jaunty, but remains broken in all other ports it seems).

Assumptions

• There is sufficient technical basis within the community to keep these ports going

Design

• Creating of a community-driven process to handle
  • toolchain configuration
  • kernel configuration and SRUs
    • - Effective kernel testing enviornment - Effective means of updating deployed kernels including any changes
  • FTBFS chasing
    • - Documentation of port specific uploads - Coordination of a team to get updates in (plus means to get these uploads in affectively)
  • Testing of milestone images, and coordinating release activities
    • - Staffing #ubuntu-testing to test and report on images - Release note drafted + image selection
  • Installer changes

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec