)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"42b4be59b8ec12a1691b354dadc67b3876e49968","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"c75bb81a_89acfa40","updated":"2024-06-14 14:57:53.000000000","message":"It looks like some items were reverted back to PS1, possibly unintentionally?","commit_id":"16fa3fc1c000fb68a86287b15519ef1a829edd6d"}],"doc/source/developer/specs/status-page-2.0.rst":[{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"a2c69ac0cff453b49ceacb0a755c25568bd624de","unresolved":true,"context_lines":[{"line_number":53,"context_line":"  - see the number of queue items in each pipeline together with their current"},{"line_number":54,"context_line":"    state (queued/waiting, running/succeeding, failing)"},{"line_number":55,"context_line":"  - **see the most relevant/important pipelines at a glance (at the top),"},{"line_number":56,"context_line":"    sorted by number of items [new]**"},{"line_number":57,"context_line":"  - **be able to hide (filter out) empty pipelines and queues [new]**"},{"line_number":58,"context_line":"  - **easily identify failing queue items**"},{"line_number":59,"context_line":"  - be able to dequeue or promote a queue item"}],"source_content_type":"text/x-rst","patch_set":1,"id":"97037f89_e47bd73e","line":56,"updated":"2024-05-13 21:31:42.000000000","message":"The current page honors the pipeline definition order so that an operator can define the pipelines in whatever order they prefer.  For example, opendev uses something akin to patch lifecycle, so check comes first, then gate, then post-merge.  Here you note that the pipelines should be sorted according to what is most important.  I think it\u0027s an open question whether the most important is the one with the most items in it, or if importance is dependent on workflow (for example, in opendev, the periodic pipeline routinely has the most items in it, but is the least important, so it is manually listed last).\n\nI also wonder if the order of the pipelines changing would be difficult to deal with (especially if check and gate both have between 9 and 10 items and switch back and forth).\n\nI\u0027m not sure how to resolve this, as both use cases seem sensible (1: focus on importance related to lifecycle; 2: focus on importance related te resource usage; a third option might be importance related to overall failure rate!)\n\nMaybe we need selectable sort options?","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":9311,"name":"Tristan Cacqueray","email":"tdecacqu@redhat.com","username":"tristanC"},"change_message_id":"b5d0d8ed04f960a28b75fe6e7278ef2bcfd6d612","unresolved":true,"context_lines":[{"line_number":53,"context_line":"  - see the number of queue items in each pipeline together with their current"},{"line_number":54,"context_line":"    state (queued/waiting, running/succeeding, failing)"},{"line_number":55,"context_line":"  - **see the most relevant/important pipelines at a glance (at the top),"},{"line_number":56,"context_line":"    sorted by number of items [new]**"},{"line_number":57,"context_line":"  - **be able to hide (filter out) empty pipelines and queues [new]**"},{"line_number":58,"context_line":"  - **easily identify failing queue items**"},{"line_number":59,"context_line":"  - be able to dequeue or promote a queue item"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1ebece1c_f0bd19f0","line":56,"in_reply_to":"14d75579_372dd551","updated":"2024-05-22 12:32:07.000000000","message":"For another data-point, in rdoproject, the promotion pipelines which happen periodically are the most important for release engineers. Moreover, the manual sort is not very intuitive as the filename order takes precedence. Here is the status page:\n\n  https://review.rdoproject.org/zuul/status\n  \n… which is defined in this zuul.d:\n\n  https://review.rdoproject.org/r/plugins/gitiles/config/+/refs/heads/master/zuul.d","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"34e53c122cc858c475a93a46a35e2c386d23268b","unresolved":true,"context_lines":[{"line_number":53,"context_line":"  - see the number of queue items in each pipeline together with their current"},{"line_number":54,"context_line":"    state (queued/waiting, running/succeeding, failing)"},{"line_number":55,"context_line":"  - **see the most relevant/important pipelines at a glance (at the top),"},{"line_number":56,"context_line":"    sorted by number of items [new]**"},{"line_number":57,"context_line":"  - **be able to hide (filter out) empty pipelines and queues [new]**"},{"line_number":58,"context_line":"  - **easily identify failing queue items**"},{"line_number":59,"context_line":"  - be able to dequeue or promote a queue item"}],"source_content_type":"text/x-rst","patch_set":1,"id":"14d75579_372dd551","line":56,"in_reply_to":"1dbeedad_529990ec","updated":"2024-05-21 18:01:53.000000000","message":"Yeah, perhaps the easiest way forward would be to stick with the current manual sort for now, and then after the end of the refactoring series, put a standalone change to sort by type,length that we can evaluate separately.  I do agree that doing that will make things a bit more stable, but I also worry that with many different independent pipelines of varying importance that may still end up being unintuitive for folks.  The more pipelines people have, the more likely they are to be annoyed that they have to actually read all of their names to find the one that they want rather than using spatial memory.\n\n(And yes, I agree that the current shifting based on layout constraints is also not ideal for the same reason and I look forward to the improvement there.  :)","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"bffb3216e1a2872bcd224c70810569733b64170f","unresolved":true,"context_lines":[{"line_number":53,"context_line":"  - see the number of queue items in each pipeline together with their current"},{"line_number":54,"context_line":"    state (queued/waiting, running/succeeding, failing)"},{"line_number":55,"context_line":"  - **see the most relevant/important pipelines at a glance (at the top),"},{"line_number":56,"context_line":"    sorted by number of items [new]**"},{"line_number":57,"context_line":"  - **be able to hide (filter out) empty pipelines and queues [new]**"},{"line_number":58,"context_line":"  - **easily identify failing queue items**"},{"line_number":59,"context_line":"  - be able to dequeue or promote a queue item"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa11befe_1650c120","line":56,"in_reply_to":"1ebece1c_f0bd19f0","updated":"2024-06-04 23:39:14.000000000","message":"You could still gain control by sorting the files by prefixing numbers (but of course you\u0027d need to split/organize the objects into files to accommodate that).\n\nNot saying it\u0027s great, but it\u0027s an option.","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"9e3146f3ea904d96105cc943940e90c2ae6f2406","unresolved":true,"context_lines":[{"line_number":53,"context_line":"  - see the number of queue items in each pipeline together with their current"},{"line_number":54,"context_line":"    state (queued/waiting, running/succeeding, failing)"},{"line_number":55,"context_line":"  - **see the most relevant/important pipelines at a glance (at the top),"},{"line_number":56,"context_line":"    sorted by number of items [new]**"},{"line_number":57,"context_line":"  - **be able to hide (filter out) empty pipelines and queues [new]**"},{"line_number":58,"context_line":"  - **easily identify failing queue items**"},{"line_number":59,"context_line":"  - be able to dequeue or promote a queue item"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1dbeedad_529990ec","line":56,"in_reply_to":"97037f89_e47bd73e","updated":"2024-05-16 09:48:56.000000000","message":"It\u0027s a good point that the \"importance\" might vary from deployment to deployment. For most tenants in our deployment, gate is the most important pipeline, whereby periodic pipelines could be sorted last. So my current idea would be something like: Order by pipeline type (dependent -\u003e independent -\u003e \u003cothers\u003e -\u003e periodic) and for each pipeline type order by number of items. At least for our deployment this would be a good improvement. (I think I could have been clearer on this point in the spec).\n\nI was also thinking about a selectable sort option, but this might need some more work/exploration to do it right. Do you think we could agree on a sorting option to start with and implement that later on? Otherwise, we could keep the sort order for now (as defined in the zuul config) and do that later on.\n\nRegarding the changing in order during reload: That\u0027s also something we have to deal with, but I assume the impact wouldn\u0027t be too big if we include the order by pipeline type. In the current version of the status page, the auto-reload also often shifts the pipelines back and forth on the screen although the ordering itself doesn\u0027t change. But this is mainly because it shows also all items and jobs which makes each pipeline take a lot more space.","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"a2c69ac0cff453b49ceacb0a755c25568bd624de","unresolved":true,"context_lines":[{"line_number":54,"context_line":"    state (queued/waiting, running/succeeding, failing)"},{"line_number":55,"context_line":"  - **see the most relevant/important pipelines at a glance (at the top),"},{"line_number":56,"context_line":"    sorted by number of items [new]**"},{"line_number":57,"context_line":"  - **be able to hide (filter out) empty pipelines and queues [new]**"},{"line_number":58,"context_line":"  - **easily identify failing queue items**"},{"line_number":59,"context_line":"  - be able to dequeue or promote a queue item"},{"line_number":60,"context_line":"  - see the timestamp of the last reconfiguration"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4b5741e9_1c9b3f3a","line":57,"updated":"2024-05-13 21:31:42.000000000","message":"I would add \"see the entire list of configured pipelines\" as a use case.  That would suggest this should be an option.  This may have been implicit, but it\u0027s probably good to explicitly list it.","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"9e3146f3ea904d96105cc943940e90c2ae6f2406","unresolved":false,"context_lines":[{"line_number":54,"context_line":"    state (queued/waiting, running/succeeding, failing)"},{"line_number":55,"context_line":"  - **see the most relevant/important pipelines at a glance (at the top),"},{"line_number":56,"context_line":"    sorted by number of items [new]**"},{"line_number":57,"context_line":"  - **be able to hide (filter out) empty pipelines and queues [new]**"},{"line_number":58,"context_line":"  - **easily identify failing queue items**"},{"line_number":59,"context_line":"  - be able to dequeue or promote a queue item"},{"line_number":60,"context_line":"  - see the timestamp of the last reconfiguration"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a5c16086_0cb6cd55","line":57,"in_reply_to":"4b5741e9_1c9b3f3a","updated":"2024-05-16 09:48:56.000000000","message":"Ack","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"a2c69ac0cff453b49ceacb0a755c25568bd624de","unresolved":true,"context_lines":[{"line_number":60,"context_line":"  - see the timestamp of the last reconfiguration"},{"line_number":61,"context_line":"  - see the number of events in the tenant event queues"},{"line_number":62,"context_line":"  - **filter for specific queues and changes (maybe also projects,"},{"line_number":63,"context_line":"    branches, ...) [new]**"},{"line_number":64,"context_line":"  - **be able to bookmark a filtered status page [new]**"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"As a developer, I want to:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e52c8813_99b8e98e","line":63,"updated":"2024-05-13 21:31:42.000000000","message":"Clarification: filter by change or project exists, but queue does not.","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"9e3146f3ea904d96105cc943940e90c2ae6f2406","unresolved":true,"context_lines":[{"line_number":60,"context_line":"  - see the timestamp of the last reconfiguration"},{"line_number":61,"context_line":"  - see the number of events in the tenant event queues"},{"line_number":62,"context_line":"  - **filter for specific queues and changes (maybe also projects,"},{"line_number":63,"context_line":"    branches, ...) [new]**"},{"line_number":64,"context_line":"  - **be able to bookmark a filtered status page [new]**"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"As a developer, I want to:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bd5c6e00_101b4d30","line":63,"in_reply_to":"e52c8813_99b8e98e","updated":"2024-05-16 09:48:56.000000000","message":"Ack, although the current implementation is more like a wildcard filter for the content on this page. It also works for pipeline names, but only if they match the search string exactly. I was more thinking about an \"advanced\" filtering like we have on the builds and buildsets page. Maybe I rephrase this to \"Improve the current filtering\".","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"a2c69ac0cff453b49ceacb0a755c25568bd624de","unresolved":true,"context_lines":[{"line_number":61,"context_line":"  - see the number of events in the tenant event queues"},{"line_number":62,"context_line":"  - **filter for specific queues and changes (maybe also projects,"},{"line_number":63,"context_line":"    branches, ...) [new]**"},{"line_number":64,"context_line":"  - **be able to bookmark a filtered status page [new]**"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"As a developer, I want to:"},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"cecd01d5_18943568","line":64,"updated":"2024-05-13 21:31:42.000000000","message":"Clarification: bookmark by change or project exists (eg https://zuul.opendev.org/t/openstack/status#neutron ) but maybe you were thinking of the queue.","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"9e3146f3ea904d96105cc943940e90c2ae6f2406","unresolved":true,"context_lines":[{"line_number":61,"context_line":"  - see the number of events in the tenant event queues"},{"line_number":62,"context_line":"  - **filter for specific queues and changes (maybe also projects,"},{"line_number":63,"context_line":"    branches, ...) [new]**"},{"line_number":64,"context_line":"  - **be able to bookmark a filtered status page [new]**"},{"line_number":65,"context_line":""},{"line_number":66,"context_line":"As a developer, I want to:"},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"4a99aaaa_9e477352","line":64,"in_reply_to":"cecd01d5_18943568","updated":"2024-05-16 09:48:56.000000000","message":"To be honest, I wasn\u0027t aware that the current filter on the status page is populated to the URL, so I will rephrase this use case as well.\n\nSimilar to my comment above, I was thinking about bookmark a status page for a specific project, change, ... (like for the builds and buildsets pages). I will rephrase this use case to be more specific on this.","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"34e53c122cc858c475a93a46a35e2c386d23268b","unresolved":true,"context_lines":[{"line_number":65,"context_line":""},{"line_number":66,"context_line":"As a developer, I want to:"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"  - **easily identify my change in context of it\u0027s pipeline (and queue) [new]**"},{"line_number":69,"context_line":"  - see the jobs for my change and their state (queued, running, succeeded,"},{"line_number":70,"context_line":"    failed)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e2b30d1c_17d93b59","line":68,"range":{"start_line":68,"start_character":35,"end_line":68,"end_character":42},"updated":"2024-05-21 18:01:53.000000000","message":"One more I just thought of:\n\nFollow a change through multiple pipelines including pre- and post-merge.\n\nThis one is tricky.  Imagine that you\u0027re an opendev admin, and you propose a change to a service configuration; it goes through check and is approved, it goes through gate and is merged, one of the change-based post-merge pipelines runs some jobs; one of the ref-based post-merge pipelines runs some jobs, then perhaps a timer-based pipeline runs some jobs.  We often watch that progression in real-time, so we know when production changes are actually deployed, so being able to see what\u0027s going on even as a change mutates form from a gerrit change to a ref-update is helpful.\n\n[I\u0027m not saying we need to support exactly the same workflow here, but we should have an answer for how that will change.]","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"bffb3216e1a2872bcd224c70810569733b64170f","unresolved":true,"context_lines":[{"line_number":65,"context_line":""},{"line_number":66,"context_line":"As a developer, I want to:"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"  - **easily identify my change in context of it\u0027s pipeline (and queue) [new]**"},{"line_number":69,"context_line":"  - see the jobs for my change and their state (queued, running, succeeded,"},{"line_number":70,"context_line":"    failed)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"125359fd_cb29d0b0","line":68,"range":{"start_line":68,"start_character":35,"end_line":68,"end_character":42},"in_reply_to":"c6726a1f_69cd4255","updated":"2024-06-04 23:39:14.000000000","message":"I don\u0027t know the answer to your first question yet, since I haven\u0027t looked at the new page with this in mind.\n\nI do agree that for this to work, you do need to know where to look for the change (but opendev admins know this -- they are explicitly monitoring a change to the system, so they know to expect a specific change and look for it).  The requirement that it not be too crowded, however, is not necessarily the case.  Due to an accident of history, the opendev continuous deployment jobs are actually in the openstack tenant, which is opendev\u0027s most populous tenant (and it frequently has large check and gate pipelines).  It\u0027s easy to search/filter check and gate for the change, and the deployment pipelines are always lightly populated (there is a natural limit to the number of simultaneous things that can be deployed -- often it\u0027s 1), so it\u0027s easy to watch those.\n\nNow that I think about this a bit more, I realize that I often filter the status page by project in this case.  So if you want to imagine this workflow, that\u0027s probably the easiest thing: filter for \"opendev/system-config\" on the openstack status page, and watch an item move from check, then gate then to a deploy pipeline.  Another wrinkle: some deployments happen in a periodic pipeline, so we\u0027re watching to see whether one of those started before or after a change merged.\n\nA single change panel would be great for this, and it would work for change-merged triggered pipelines, but not ref-updated ones (or periodic).","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"d2c43d53aa5c12740b8874a2e6ff46736d483b31","unresolved":true,"context_lines":[{"line_number":65,"context_line":""},{"line_number":66,"context_line":"As a developer, I want to:"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"  - **easily identify my change in context of it\u0027s pipeline (and queue) [new]**"},{"line_number":69,"context_line":"  - see the jobs for my change and their state (queued, running, succeeded,"},{"line_number":70,"context_line":"    failed)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c6726a1f_69cd4255","line":68,"range":{"start_line":68,"start_character":35,"end_line":68,"end_character":42},"in_reply_to":"e2b30d1c_17d93b59","updated":"2024-05-22 07:38:21.000000000","message":"I imagine it would be great to have something like this, but that might indeed be tricky and not possible without any API changes that allow us to identify the change (or the item(s) related to the change) in different pipelines - especially the timer/ref-based ones.\n\nThis might also be more of a \"single change panel\" use case, but I will add it to the list. I think this might work well with what I have in mind for the single change panel after the status view is done - not saying it would be easy to implement.\n\nI\u0027m a little confused by your last sentence:\n\u003e I\u0027m not saying we need to support exactly the same workflow here, but we should have an answer for how that will change.\n\nDo you see this as \"fulfilled\" by the current implementation of the status page? In my opinion this would be a new use case. I mean: On the current status page this works if you know what to look for (the change) and where (in which pipelines). But this only works if the amount of items on the status page is manageable and not too crowded.","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"a2c69ac0cff453b49ceacb0a755c25568bd624de","unresolved":false,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"  - **easily identify my change in context of it\u0027s pipeline (and queue) [new]**"},{"line_number":69,"context_line":"  - see the jobs for my change and their state (queued, running, succeeded,"},{"line_number":70,"context_line":"    failed)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"629434e6_39d76c61","line":70,"updated":"2024-05-13 21:31:42.000000000","message":"I would add: see all of the pipelines my change is currently included in.  (to deal with the semi-common case of, say, multiple check pipelines, or even seeing that a change is simultaneously in check and gate)","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"9e3146f3ea904d96105cc943940e90c2ae6f2406","unresolved":false,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"  - **easily identify my change in context of it\u0027s pipeline (and queue) [new]**"},{"line_number":69,"context_line":"  - see the jobs for my change and their state (queued, running, succeeded,"},{"line_number":70,"context_line":"    failed)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"6b8f302c_57e88c19","line":70,"in_reply_to":"629434e6_39d76c61","updated":"2024-05-16 09:48:56.000000000","message":"I see this more as a use case for the single change panel (where it\u0027s also currently visible).\n\nAs for the status page I\u0027m not sure if this is a \"feature\" in the current implementation. Sure, the same change will be shown in each pipeline it is enqueued, but most of the time you won\u0027t be able to spot this as there are so many changes shown - except you filter for this specific change.\n\nIn the new status page it would be similar. The change will be shown in each pipeline it is enqueued, but as it\u0027s only a box/square you won\u0027t notice that unless you filter only for this change.\n\nWhen viewing a change in the single change panel on the other hand it\u0027s very clear to see if the change is enqueued in multiple pipelines.","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"5bca0225e6cba0aaf92489a4d7be289244fe3644","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"  - **easily identify my change in context of it\u0027s pipeline (and queue) [new]**"},{"line_number":69,"context_line":"  - see the jobs for my change and their state (queued, running, succeeded,"},{"line_number":70,"context_line":"    failed)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5b85976e_426e21c9","line":70,"in_reply_to":"62cddd7f_a2b26cc4","updated":"2024-06-14 05:41:57.000000000","message":"I didn\u0027t see this necessarily as a use case for the status UI itself, as it\u0027s just a link to another page (live log/build result page), which is still available. But reading your comment now, it makes sense to add it to the spec. I will add it to the \"developer\" section. I don\u0027t see those roles as mutually exclusive (so both roles could have the same use cases - as the same person could have both roles).","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"517e9d0e9e112f8b8d5af426d0d26f9902a0bc1b","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"  - **easily identify my change in context of it\u0027s pipeline (and queue) [new]**"},{"line_number":69,"context_line":"  - see the jobs for my change and their state (queued, running, succeeded,"},{"line_number":70,"context_line":"    failed)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b72e0aaa_e4459103","line":70,"in_reply_to":"6b8f302c_57e88c19","updated":"2024-05-16 09:50:27.000000000","message":"This comment wasn\u0027t meant to be \"resolved\", not sure why gerrit did that.","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"34e53c122cc858c475a93a46a35e2c386d23268b","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"  - **easily identify my change in context of it\u0027s pipeline (and queue) [new]**"},{"line_number":69,"context_line":"  - see the jobs for my change and their state (queued, running, succeeded,"},{"line_number":70,"context_line":"    failed)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba2b861d_176cf21a","line":70,"in_reply_to":"b72e0aaa_e4459103","updated":"2024-05-21 18:01:53.000000000","message":"[I\u0027m always accidentally resolving things too.  I wish we could toggle it without leaving another comment.]\n\nI agree that a single change panel with multiple pipelines is likely to satisfy this use case.  Just want to make sure we note it; the existing text only has a singular \"pipeline\".","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"2f5ae4d4738eb598bf1ff2ce1187e1e67f991d79","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"  - **easily identify my change in context of it\u0027s pipeline (and queue) [new]**"},{"line_number":69,"context_line":"  - see the jobs for my change and their state (queued, running, succeeded,"},{"line_number":70,"context_line":"    failed)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"62cddd7f_a2b26cc4","line":70,"in_reply_to":"ba2b861d_176cf21a","updated":"2024-06-12 20:19:54.000000000","message":"Unrelated to the above discussion I think for both developers and operators it is important to be able to find build results from the status page/panels and trace them to build logs to diagnose issues quickly. The entry on line 72 implies this will still be the case but I think this is improtant to call out as I regularly do this as both a zuul operator (determine if system is currently in a sad state) and as a developer (determine problems more quickly and respin if appropriate).","commit_id":"f6d63575068edd9eaac51640a1ec26e46626a9f1"},{"author":{"_account_id":9311,"name":"Tristan Cacqueray","email":"tdecacqu@redhat.com","username":"tristanC"},"change_message_id":"b5d0d8ed04f960a28b75fe6e7278ef2bcfd6d612","unresolved":true,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"  1. Status / pipeline overview"},{"line_number":36,"context_line":"  2. Pipeline details"},{"line_number":37,"context_line":"  3. Individual change"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Based on those scopes, the pages that handle those focus only on the relevant"},{"line_number":40,"context_line":"information, but don\u0027t show too many details about the other scopes."}],"source_content_type":"text/x-rst","patch_set":3,"id":"89815822_53b198d1","line":37,"updated":"2024-05-22 12:32:07.000000000","message":"I can\u0027t tell how the 3 scopes map to the use cases below. It looks like the developer could be split in two categories: maintainer and contributor. That way I guess the individual change scope is for contributors and the pipeline details is for maintainers?","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"},{"author":{"_account_id":9311,"name":"Tristan Cacqueray","email":"tdecacqu@redhat.com","username":"tristanC"},"change_message_id":"f3513f9598cce96ed2272b6a503e45fe256c6cfd","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"  1. Status / pipeline overview"},{"line_number":36,"context_line":"  2. Pipeline details"},{"line_number":37,"context_line":"  3. Individual change"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Based on those scopes, the pages that handle those focus only on the relevant"},{"line_number":40,"context_line":"information, but don\u0027t show too many details about the other scopes."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1b599f5d_e0bc78de","line":37,"in_reply_to":"61c1ee0b_bf3640f9","updated":"2024-06-04 16:52:27.000000000","message":"I see, thanks, that makes sense. My concern then is that I think we need to consider a maintainer role for the pipeline scope (e.g. the status of the gate/periodic) vs a contributor role for the individual change.","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"fb0f7eb343f6300f4e1deacff06c207bee488551","unresolved":true,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"  1. Status / pipeline overview"},{"line_number":36,"context_line":"  2. Pipeline details"},{"line_number":37,"context_line":"  3. Individual change"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"Based on those scopes, the pages that handle those focus only on the relevant"},{"line_number":40,"context_line":"information, but don\u0027t show too many details about the other scopes."}],"source_content_type":"text/x-rst","patch_set":3,"id":"61c1ee0b_bf3640f9","line":37,"in_reply_to":"89815822_53b198d1","updated":"2024-05-24 10:20:28.000000000","message":"The use cases below don\u0027t necessarily fit to a single scope mentioned here. Maybe it is a bit misleading if we split the use cases by role. I started with those as \"user stories\" and those typically include the role of the user. However, after writing them down I found that they were a little short for user stories, so I rephrased it to \"use cases\".\n\nNow regarding the scopes/roles: The idea behind these scopes is to explain the problem I see with the current status page and how it might be improved. Currently, the status page shows a lot of data and I think it could be improved by splitting those data in different scopes - some scopes are more relevant for \"operator-like\" roles while others are more relevant for \"developer-like\" roles. \"operator\" and \"developer\" are no fixed terms here, it was just the first thing that came to my mind.\n\nSo my rough idea is: While \"operators\" are more interested in the overall state of the tenant, they often use the status page as entry point to Zuul (1. scope). So the data that is shown there should - in my opinion - give a good overview about the tenant, but should not distract with too much detail. \"Developers\" on the other hand usually have a change they are currently developing and are interested in the state of this change. They usually submit their change to some kind of versioning system (like github or gerrit) and enter the Zuul UI from there (3. scope). The 2. scope comes in between those. It provides more details on a single pipeline, shows the changes in their context and serves as a transition point between the 1. and 3. scope.\n\nMaybe I should add some of this information to the spec to make it more clear what the scopes/roles are about. However, they are no fixed terms and mainly used as an explanation.","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"2f5ae4d4738eb598bf1ff2ce1187e1e67f991d79","unresolved":true,"context_lines":[{"line_number":59,"context_line":"  - **be able to hide (filter out) empty pipelines and queues [new]**"},{"line_number":60,"context_line":"  - **easily identify failing queue items [improvement]**"},{"line_number":61,"context_line":"  - be able to dequeue or promote a queue item"},{"line_number":62,"context_line":"  - see the timestamp of the last reconfiguration"},{"line_number":63,"context_line":"  - see the number of events in the tenant event queues"},{"line_number":64,"context_line":"  - **be able to filter for different attributes like queue name, change,"},{"line_number":65,"context_line":"    project, branch, ... [improvement]**"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a08c776c_22ded0c1","line":62,"updated":"2024-06-12 20:19:54.000000000","message":"It might also be good to show when a reconfiguration is in progress (and possibly when it started). Sometimes we\u0027re confused why things haven\u0027t taken effect yet and that is due to things being in process.","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"5bca0225e6cba0aaf92489a4d7be289244fe3644","unresolved":true,"context_lines":[{"line_number":59,"context_line":"  - **be able to hide (filter out) empty pipelines and queues [new]**"},{"line_number":60,"context_line":"  - **easily identify failing queue items [improvement]**"},{"line_number":61,"context_line":"  - be able to dequeue or promote a queue item"},{"line_number":62,"context_line":"  - see the timestamp of the last reconfiguration"},{"line_number":63,"context_line":"  - see the number of events in the tenant event queues"},{"line_number":64,"context_line":"  - **be able to filter for different attributes like queue name, change,"},{"line_number":65,"context_line":"    project, branch, ... [improvement]**"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5df78321_2323fba8","line":62,"in_reply_to":"a08c776c_22ded0c1","updated":"2024-06-14 05:41:57.000000000","message":"Good idea, I think we also got this request from some of our projects. However, this would require a backend change as this data (when a reconfiguration is ongoing) is not available yet. I\u0027ll add this use case.","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"},{"author":{"_account_id":9311,"name":"Tristan Cacqueray","email":"tdecacqu@redhat.com","username":"tristanC"},"change_message_id":"b5d0d8ed04f960a28b75fe6e7278ef2bcfd6d612","unresolved":true,"context_lines":[{"line_number":63,"context_line":"  - see the number of events in the tenant event queues"},{"line_number":64,"context_line":"  - **be able to filter for different attributes like queue name, change,"},{"line_number":65,"context_line":"    project, branch, ... [improvement]**"},{"line_number":66,"context_line":"  - **be able to bookmark a filtered status page [improvement]**"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"As a developer, I want to:"},{"line_number":69,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"13107100_6225caa8","line":66,"updated":"2024-05-22 12:32:07.000000000","message":"Not sure it is worth duplicating monitoring data in here, but it would be nice to know for a given pipeline:\n- if it is empty, when was the last time an item was processed?\n- the number of item that was processed\n- the buildset success/failure ratio","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"2f5ae4d4738eb598bf1ff2ce1187e1e67f991d79","unresolved":true,"context_lines":[{"line_number":63,"context_line":"  - see the number of events in the tenant event queues"},{"line_number":64,"context_line":"  - **be able to filter for different attributes like queue name, change,"},{"line_number":65,"context_line":"    project, branch, ... [improvement]**"},{"line_number":66,"context_line":"  - **be able to bookmark a filtered status page [improvement]**"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"As a developer, I want to:"},{"line_number":69,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"38344c5f_a9b2f2ad","line":66,"in_reply_to":"13107100_6225caa8","updated":"2024-06-12 20:19:54.000000000","message":"I\u0027m not sure the buildset success/failure ration is going to be useful over time for installations like OpenDev\u0027s. Gates break regularly due to external factors for example. The first time this happens you\u0027ll get a good \"oh the ratio changed\" indication. But months later after this has occurred enough the ratio changes will just be noise.\n\nThis information is also not that important to zuul operators. I don\u0027t really care too much if people write jobs that fail a lot as long as zuul is accurately running the jobs and reporting the results. What we do care about as operators is whether or not hte system is failing leading to inaccurate results. But that won\u0027t be possible to determine via a pass/fail ratio.","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"5bca0225e6cba0aaf92489a4d7be289244fe3644","unresolved":true,"context_lines":[{"line_number":63,"context_line":"  - see the number of events in the tenant event queues"},{"line_number":64,"context_line":"  - **be able to filter for different attributes like queue name, change,"},{"line_number":65,"context_line":"    project, branch, ... [improvement]**"},{"line_number":66,"context_line":"  - **be able to bookmark a filtered status page [improvement]**"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"As a developer, I want to:"},{"line_number":69,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ecc6c88b_47e1b840","line":66,"in_reply_to":"38344c5f_a9b2f2ad","updated":"2024-06-14 05:41:57.000000000","message":"I\u0027m also not sure if we should show that information in Zuul itself. Especially as this might also require some backend changes first to make the data available. Maybe when the first iteration of \"Status UI changes\" is done, we can think about further improvements and if something like this would be helpful or not?","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"2f5ae4d4738eb598bf1ff2ce1187e1e67f991d79","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"f7dceefc_8d17f02c","line":75,"updated":"2024-06-12 20:19:54.000000000","message":"Another use case that would be good to capture for developers is trying to better expose why things are not yet running. Whether that is waiting for a parent job or artificat dependency or nodes haven\u0027t been allocated or we are outside of the queue window etc one of the most common things we answer questions about in OpenDev is \"why did my jobs not run\" or \"why is my job not running yet\".\n\nThis next idea is probably well beyond the scope of this spec, but it might be cool to have a \"recent events processed by zuul and reason for action taken\" page in the dashboard somewhere. Then when we don\u0027t run jobs for a change we can have an entry that says something like \"for patchset 2 created on change 123456 no jobs were queued because no jobs matched\". Probably don\u0027t need to have records for the positive case since those will show up in the normal status dashboards. Think of this as a brainstorm and not anything I expect to get done as part of this spec.","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"},{"author":{"_account_id":27582,"name":"Simon Westphahl","email":"simon.westphahl@bmw.de","username":"simon.westphahl"},"change_message_id":"08da20584df43c33128087a3e9ca6528f10f5337","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"c0618554_b813bf07","line":75,"in_reply_to":"22e1d631_0f0b071b","updated":"2024-06-14 05:59:31.000000000","message":"re. 1. I think we could show the reason why a job is queued, waiting, ... a bit more prominently than it currently is (just via the tooltip). Maybe keep it as a tooltip in the pipeline view, but expand that on the \"running change\" page?!","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"},{"author":{"_account_id":27952,"name":"Felix Edel","email":"felix.edel@bmw.de","username":"felix.schmidt"},"change_message_id":"5bca0225e6cba0aaf92489a4d7be289244fe3644","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"22e1d631_0f0b071b","line":75,"in_reply_to":"f7dceefc_8d17f02c","updated":"2024-06-14 05:41:57.000000000","message":"1. I\u0027ll add this to the spec. Just for clarification (not relevant to the spec): Do you see this as fulfilled in the way it\u0027s displayed in the current status page or do you think this could need some improvement and we should show this information in a different way (e.g. to be easier accessible)?\n\n2. I think this point is indeed out of scope for this spec, so I will not add it here. This might be worth elaborating as one of the next \"UI improvements steps\" after the status page is done. It might even be worth its own spec ;-)","commit_id":"56a3a7a2fd72d6583e664b1d3ba78aea2f390bba"}]}