~larry-e-works/uci-engine/amqp-to-kombu

« back to all changes in this revision

Viewing changes to docs/ticket.rst

  • Committer: Joe Talbott
  • Date: 2014-01-27 14:54:08 UTC
  • mfrom: (126.3.8 webui)
  • mto: This revision was merged to the branch mainline in revision 161.
  • Revision ID: joe.talbott@canonical.com-20140127145408-zpubebx02y6oumxq
merge doanac's cleanup branch

Show diffs side-by-side

added added

removed removed

Lines of Context:
20
20
* 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)
21
21
* what MP are pending against this ticket, meaning against all attached feature branches.
22
22
* what delta do we have between the various feature branches in this ticket and their corresponding trunks.
23
 
* knowing if we are mergeable 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.
 
23
* 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.
24
24
* 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.
25
25
* knowing what latest image number is available, be able to change with it if test on latest image passed.
26
26
* getting tests progress while they are run dynamically. Represents them clearly against those previous 3 image tests
27
27
* 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.
28
28
* CI general health and global warnings if needed
29
29
* status on the corresponding components health
30
 
* gives an easy way once all those criterias are met (third-party acking, everything built and all tests passing) to give a "go" to the engine to deliver those different trunks.
31
 
* 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 explicitely when something is blocking there the whole pipeline for other delivery.
 
30
* 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.
 
31
* 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.
32
32
 
33
33
**Tickets interactions**
34
34
 
39
39
Finally, in this global view, we want to show the health of all projects:
40
40
 
41
41
* 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)
42
 
* 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/mergeable to trunk).
 
42
* 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).
43
43
* 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.
44
44
* 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)
45
45
* 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)