launchpad development|
Size: 3247
Comment:
|
Size: 3994
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| The /distribution/series/+queue page should enable buildd admins to accept, override and reject packages in bulk, providing quick access to all the information necessary for the decision. | The /distribution/series/+queue page should enable archive admins to accept, override and reject packages in bulk, providing quick access to all the information necessary for the decision. |
| Line 5: | Line 5: |
| ? Is part of the purpose also for uploaders to check progress? | ? Is part of the purpose also for uploaders to check progress? That would affect the design too. |
| Line 13: | Line 13: |
| == Performance restrictions == To enable a larger set of uploads to be included while bulk-reviewing, the resulting binaries (with any relevant 'old' publishing info) can be loaded into the page *after* the initial page load. There are several options for how this could be done, the most obvious being to include an 'expand all' option both at the top of the page as well as for each source package release grouping. Another option would be to automatically load in the expanded info as soon as the initial page has loaded, but hopefully that's not necessary? |
|
| Line 15: | Line 19: |
| (Note: these use-cases are with the assumption that we'll be able to group by source package release and order by the max upload date of the grouped uploads) | (Note: these use-cases are with the assumption that we'll be able to group by source package release and order by the latest (max) upload date of the grouped uploads) |
| Line 19: | Line 23: |
| Colin opens '/ubuntu/karmic/+queue' and sees that there are currently over fifty source package releases with related binaries in the queue. Noticing that nearly all of the packages are debian imports, Colin tabs to 'select all' (the first form input) and hits <SPACE> to select all the binaries associated with the listed source package releases. He then tabs down through the list deselecting the two packages that are not debian imports, tabs to the Accept button and hits <ENTER>. | Colin opens '/ubuntu/karmic/+queue' and sees that there are currently over fifty source package releases with their related binary uploads displayed in the New queue as well as a number of source uploads. Noticing that nearly all of the packages are debian imports, Colin tabs to 'select all' (the first form input) and hits <SPACE> to select all the binary uploads associated with the listed source package releases. He then tabs down through the list deselecting all the binaries for the two packages that are not debian imports - simply by unchecking the checkbox next to each source package release. He then tabs to the Accept button and hits <ENTER>. === Overriding one or more uploads === While bulk-reviewing the uploads for 50 source package releases, one particular source package release near the bottom of the list catches Martin's attention - he clicks (keys?) 'Expand all' for that source package release which loads in the resulting binaries for all the binary uploads, as well as any previous old publishings of the same binary from other packages. Martin notices that one of the resulting binaries has been published in main in the past via a different source package, and so updates the destination of the new binary to main. |
| Line 23: | Line 31: |
| Rob opens '/ubuntu/karmic/+queue' and sees that there are quite a few packages requiring closer inspection. He tabs to 'Expand all' which immediately begins expanding the source package releases with the related binary debs and existing overrides information. Rob works his way down the list, checking the box next to the source package release for some packages (which automatically selects all the binaries) and manually selecting certain binaries for others. When he reaches the bottom of the list, he tabs to the Accept button and hits <ENTER> === Overriding one or more uploads === <add more detail> Override a set of NEW packages (source and/or binary) to use a different component etc. |
Rob opens '/ubuntu/karmic/+queue' and sees that there are quite a few packages requiring closer inspection. He tabs to 'Expand all' which immediately begins expanding the binary uploads for each source package release with the resulting binaries and existing overrides information. Rob works his way down the list, checking the box next to the source package release for some packages (which automatically selects all the binaries) and manually selecting certain binaries for others. When he reaches the bottom of the list, he tabs to the Accept button and hits <ENTER>. |
| Line 32: | Line 35: |
| * What information is *always* necessary? and progressively, what information is needed to make a more detailed judgement. (Specifically, I'm wondering if there is ever a case that the group source-package-release would be enough, or whether we always want to see the binaries uploads and just load in output debs with Colin's existing overrides (OLD rows) dynamically) | * I wonder if it would be handy to reject certain binaries inline - so it disappears immediately from the queue? I'm assuming that currently, if someone selects all, then deselects one or two, accepts all the select uploads, they would then need to go manually navigate the list again to select and reject the uploads that they previously deselected. |
| Line 34: | Line 37: |
| * I wonder if it would be handy to reject certain binaries inline - so it disappears immediately from the queue? Currently I'm not sure what people do after selecting some uploads - how are the non-selected ones rejected? Manually going through the list again after the page reloads to reject those ones? | * Is the workflow substantially different for reviewing source uploads vs binary uploads? Or is it easy to bulk-review a mixed list of source/binary uploads. |
| Line 36: | Line 39: |
| * I'm assuming from the current UI that different binaries for the same source package can have different destinations even though they typically do not. Is this the case? (seems to be confirmed by comment in Colin's mail: "one is reduced to checking each binary upload individually rather than together with its typically nearly identical fellows for other architectures") * Have there ever been concurrency issues with doing bulk reviewing of the queue? Or perhaps the latest review would just over-write? |
* Have there ever been concurrency issues with doing bulk reviewing of the queue (multiple people reviewing the same uploads)? Or perhaps the latest review would just over-write? |
Purpose
The /distribution/series/+queue page should enable archive admins to accept, override and reject packages in bulk, providing quick access to all the information necessary for the decision.
? Is part of the purpose also for uploaders to check progress? That would affect the design too.
You can also view the input information regarding this page.
Target user audience
- The primary users of this page are technically very adept Launchpad users / admins who will prefer a console script if it gets the job done faster.
Performance restrictions
To enable a larger set of uploads to be included while bulk-reviewing, the resulting binaries (with any relevant 'old' publishing info) can be loaded into the page *after* the initial page load. There are several options for how this could be done, the most obvious being to include an 'expand all' option both at the top of the page as well as for each source package release grouping. Another option would be to automatically load in the expanded info as soon as the initial page has loaded, but hopefully that's not necessary?
Use-cases
(Note: these use-cases are with the assumption that we'll be able to group by source package release and order by the latest (max) upload date of the grouped uploads)
Bulk-accepting a bunch of debian imports
Colin opens '/ubuntu/karmic/+queue' and sees that there are currently over fifty source package releases with their related binary uploads displayed in the New queue as well as a number of source uploads. Noticing that nearly all of the packages are debian imports, Colin tabs to 'select all' (the first form input) and hits <SPACE> to select all the binary uploads associated with the listed source package releases. He then tabs down through the list deselecting all the binaries for the two packages that are not debian imports - simply by unchecking the checkbox next to each source package release. He then tabs to the Accept button and hits <ENTER>.
Overriding one or more uploads
While bulk-reviewing the uploads for 50 source package releases, one particular source package release near the bottom of the list catches Martin's attention - he clicks (keys?) 'Expand all' for that source package release which loads in the resulting binaries for all the binary uploads, as well as any previous old publishings of the same binary from other packages. Martin notices that one of the resulting binaries has been published in main in the past via a different source package, and so updates the destination of the new binary to main.
Excluding one binary from the review
Rob opens '/ubuntu/karmic/+queue' and sees that there are quite a few packages requiring closer inspection. He tabs to 'Expand all' which immediately begins expanding the binary uploads for each source package release with the resulting binaries and existing overrides information. Rob works his way down the list, checking the box next to the source package release for some packages (which automatically selects all the binaries) and manually selecting certain binaries for others. When he reaches the bottom of the list, he tabs to the Accept button and hits <ENTER>.
Questions
- I wonder if it would be handy to reject certain binaries inline - so it disappears immediately from the queue? I'm assuming that currently, if someone selects all, then deselects one or two, accepts all the select uploads, they would then need to go manually navigate the list again to select and reject the uploads that they previously deselected.
- Is the workflow substantially different for reviewing source uploads vs binary uploads? Or is it easy to bulk-review a mixed list of source/binary uploads.
- Have there ever been concurrency issues with doing bulk reviewing of the queue (multiple people reviewing the same uploads)? Or perhaps the latest review would just over-write?
