Ticket and general user interaction

General principles

Ticket itself

Ticket collects metadata about what components and branches to treat as feature branches. It will contain a description of this feature and an ETA (from the registrant). Other informations like against which image number we want to have our test running (generated from ticket creation time) and a proposed list of integration tests will also be provided. Finally, we select which ones we want to run against (automated ticket will have this pre-selected with a default per component).

We want as well the user to know about the status of their current delivery. This one can be a direct MP or a first-class ticket entered into the system.

The ticket will include evolving metadata with time and reflect dynamically the states related to it.

  • what is building right now as per the ticket definition, and the different build status in the isolated environment on all those components.
  • driving the build ordering as well if we have dependencies (but not strict bump) to help upstream only taking care of ABI bump at delivery time.
  • getting a way to do a non change rebuild upload for one or more components.
  • attaching source package instead of branches for features involving more than just projects we handle in bzr branches.
  • knowing where we stands on all those feature branches and sources compared to latest in distro (if the source package isn’t the latest version in the development version anymore)
  • what MP are pending against this ticket, meaning against all attached feature branches.
  • what delta do we have between the various feature branches in this ticket and their corresponding trunks.
  • knowing if we are able to merge or not against those trunks. If we can merge at a T time (and tests are all passing), propose a way to merge trunks easily into those branches.
  • after getting the progress on their build, attaching latest available specific image (3 images per ticket): feature branch + fixed image number, feature branch + latest available image, trunk + feature branch merged + latest available image.
  • knowing what latest image number is available, be able to change with it if test on latest image passed.
  • getting tests progress while they are run dynamically. Represents them clearly against those previous 3 image tests
  • ensuring that involved parties like core-devs and design team are involved if the ticket needs their review. A packaging change will require core-devs to ack their change. The design team will be in the process if there is a design change involved. Those should work through credentials.
  • CI general health and global warnings if needed
  • status on the corresponding components health
  • gives an easy way once all those criteria are met (third-party acking, everything built and all tests passing) to give a “go” to the engine to deliver those different trunks.
  • show the progress on the merging back to trunk, building packages there, tests passing, migration in UNAPPROVED/NEW, -proposed, release pocket and close the ticket completely once the next image is kicked in. Demonstrate explicitly when something is blocking there the whole pipeline for other delivery.

Tickets interactions

We also want to be able to show where their ticket or MP is in the component queue, and what time they can expect (in average) before seeing it delivered.

Global view

Finally, in this global view, we want to show the health of all projects:

  • seeing all components (projects/branches) that we have in the CI system with global/general metadata (what test environment is going to be used, what tests are associated with that components, number of tickets opened against them and so on)
  • giving a view for the managers to see what ticket their team are working on, and what’s the progress on them as well as global status (build/tests/ability to merge to trunk).
  • if a direct commit to trunk blocked the project and that’s the only way to fix it back (another direct commit to trunk), surface that. All other tickets being blocked by that state (as touching that same component) should reflect that info as well.
  • when tickets are expected to be delivered (based on the ETA), so that we can identify hot spots (times where a lot of landing will happen simultaneously and will clash) and try to shuffle them around to not having them in one landing (eventually by a global override on all tickets)
  • a single point to see across all projects where different teams need to assess/review before the delivery takes place (pending packaging changes triggering a core-dev review, design review needed)
  • CI general health