-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ Issue #509 + #510] Series views #589
base: main
Are you sure you want to change the base?
Conversation
Sorry for the absurd delay getting to this: my free time for Patchwork is pretty much zero recently... 😅 I've taken a look at this locally but have yet to go into depth on it. There are two obvious issues starting out though. Firstly, you need to do some serious work on the queries: I loaded up the patchwork archives (following the guide in our development docs and loading the
Other changes:
This is rather beefy PR so if you have the ability to do, I'd suggest submitting v2 via the mailing list if you have the ability/know-how to do so. That'll be easier for me to review. Feel free to stick to GitHub if you can't/aren't comfortable using the mailing list though 🙂 |
This view is meant to give a quickoverview on a project since some of them can have hundreds of patches actives. This view also allows the user to apply changes on all of the series patches at once Signed-off-by: andrepapoti <[email protected]>
Signed-off-by: andrepapoti <[email protected]>
Signed-off-by: andrepapoti <[email protected]>
Signed-off-by: andrepapoti <[email protected]>
Signed-off-by: andrepapoti <[email protected]>
Signed-off-by: andrepapoti <[email protected]>
@stephenfin I've completed the adjustments you specified and also added pagination to the series list, the page is displaying 100 series at once and It's making 7 requests per page. |
@andrepapoti I gave this a run. Main issue I have noticed is the default sorting, patches in Series view should be sorted from newest to the oldest, like they are in patches. It doesnt really make sense to have it sorted the other way around. Should a navigation bar within a patch - next/previous be visible If there is a single patch in a series,? edit: Finally on the sorting bit, patches view allows for sorting by different tables (submitter, state, date etc.) and it allows to reverse sorting as well, so that if something is sorted by date (oldest -> newest), if one clicks date again it changes to newest->oldest, or if one clicks on patch, then it sorts it alphabetically by patch name. I think it would be nice to have that in series view as well, to keep it constant. |
# Patchwork - automated patch tracking system | ||
# Copyright (C) 2012 Jeremy Kerr <[email protected]> | ||
# | ||
# SPDX-License-Identifier: GPL-2.0-or-later | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this correct? For example is the year in copyright correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed this header, I'll change it to the correct one
'id', | ||
) | ||
.select_related('project') | ||
.order_by('date') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this not be reversed then to sort it from newest to oldest?
Also are we fetching all of them or are we skipping the archived ones?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Also, the query needs more work. I'm seeing ~300 queries for listing series (once I remove the lookup for series-detail
from above and am able to render the page).
This is a problem. Fortunately it should be easy join. If you click on that SQL tab, you'll see a description of the (many) queries:
Clicking on one of these, we can see an example of the kind of issue:
That indicates that you need to join on submitter also, which you can do with select_related
. You also need to join on patches
and a few others. You should be able to get this down to < 30 queries once you resolve these.
There is no planned design for the task, I kept each button disabled if there are no next/previous values, but if you believe it's best to remove them I don't have any issues with it Regarding the sorting I'll add a new commit to this MR to allow the user to change it by clicking on the table |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The queries still need work, and I have a few other comments on top of @hero24's comments, but this is getting there.
<a href="{% url 'series-detail' project_id=project.linkname series_id=series.id %}"> | ||
{{ series.name|default:"[no subject]"|truncatechars:100 }} | ||
</a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
{% endif %} | ||
|
||
<th> | ||
<span class="colinactive">Series</span> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You shouldn't need the colinactive stuff since this is only used for bundles, which don't apply to series.
<span class="colinactive">Series</span> | |
<span>Series</span> |
Below also.
path( | ||
'project/<project_id>/list/', | ||
'project/<project_id>/patches/', | ||
patch_views.patch_list, | ||
name='patch-list', | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you rename this you need to provide a redirect. There are existing examples of redirects here. Don't forget to preserve query string arguments though since those matter here but didn't matter for fetching e.g. patch mboxes.
This should also be a separate commit, ideally placed before this one in the series.
'id', | ||
) | ||
.select_related('project') | ||
.order_by('date') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Also, the query needs more work. I'm seeing ~300 queries for listing series (once I remove the lookup for series-detail
from above and am able to render the page).
This is a problem. Fortunately it should be easy join. If you click on that SQL tab, you'll see a description of the (many) queries:
Clicking on one of these, we can see an example of the kind of issue:
That indicates that you need to join on submitter also, which you can do with select_related
. You also need to join on patches
and a few others. You should be able to get this down to < 30 queries once you resolve these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please fold this into the previous patch 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need tests for this also.
prelude: > | ||
Some projects can have hundreds of patches actives at once, by giving the user | ||
the ability to have an overview of all of the series makes knowing what's the | ||
current state of a project much more simple. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The prelude
section is used to provide a high level overview of a release. Only a maintainer should create one of these. You can drop this.
Add series-list view, a view containing all of the series for a project and that also | ||
implements the SeriesBulkUpdatePatchesForm, allowing the user to edit all of the patches | ||
within a series using the web ui. | ||
Add series-detail view, a view containing details about a series and all of it's patches |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you be a little more generic here since series-list
and series-detail
mean nothing to a user of Patchwork that hasn't read the code. How about:
A series view is now available, allowing users to list available series and
view details of individual series.
<a | ||
class="btn btn-default {% if not previous_submission %} disabled {% endif %}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: can you put this on one line like above
{% if previous_submission %} href="{% url 'patch-detail' project_id=project.linkname msgid=previous_submission.encoded_msgid %}" {% endif %} | ||
> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
Just to make this clear. As it is the series view aren't exactly appealing, they show every patch series that has been ever submitted. Series should have states - open/closed, so they can be filtered on the web interface. |
Description
This PR adds a new series-list and series-detail view.
Some projects can have hundreds of patches actives at once, by giving the user the ability to have an overview of all of the series makes knowing what's the current state of a project much more simple.
Series-list also allows the user to apply changes to all of the patches of a determined series, making the management of them easier
Added navigation within a series for the patch-detail view
Related