Gitea: Issues and triaging features #12
Labels
No Label
Service
Buildbot
Service
Chat
Service
Gitea
Service
Translate
Type
Bug
Type
Config
Type
Deployment
Type
Feature
Type
Setup
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: infrastructure/blender-projects-platform#12
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
High Priority
Asked Gitea developers to implement.
Medium Priority
<video>linesinfo would be good (starting with e.g. ```lines=10) so we get a scrollbar-- will add that to the first comment
Low Priority
/issuesand/subscriptionspages, not just for issue list within repositories.Issues and Triaging Feature Requeststo Issues and Triaging FeaturesMarkdown: gitea claims to be compliant to commonmark via goldmark, I have tried many things which are just not working afaict, e.g. this example
(I was first interested to somehow get fenced codeblocks to take the max lines info that phabricator had (scrollbars on long codeblocks), turns out this is not possible? then tried with html div styles -- but styles seem to not work at all? am I missing something?)
What do you need for triaging to be effective? If it's that there is no way to add fenced codeblocks and that's a very useful feature for us, we should add it to the list.
However, "make the full commonmark standard work" is not something that I think we should add because it's potentially a lot of work with only minor benefit.
fenced codeblocks with a
linesinfo would be good (starting with e.g. ```lines=10) so we get a scrollbar (currently ignored, se below). To my understanding, this is not even in the spec, but having an equivalent would work around trying to do this with other mardown things like div stylesWill add to the list
The "Copy Link" on attachments (once a file is uploaded in the dropzone) apparently only works the very first time using the dropbox, if you later edit the report description (or comment) again, that feature is gone (ref https://github.com/go-gitea/gitea/pull/22517)
Another request that would be handy:
In commits, we now have every reference nicely visible as a block (thx to the bot adding the commit note)
In issues however, this is scattered in the whole discussion, so you have to scroll all your way through to know where this was referenced. It would help tremendously to see this in a single block (either just below the first comment or in the sidebar).
Not adding this to the list just yet, waiting for feedback if there is other ideas on this.
Yesterday it became clear to me that closing tasks is part of the comment box, as a red button right next to sending a comment ...
The action to close a task need to be somewhere else, imo at the bottom of the right side box.
Here is another one in relation to references:
While we have a flyover box to "expand" on the information of an issue (see screenshot below), there is no such thing for a commit or a PR (you are left with just the number -- having to click on the link for further info...) as we all know, clicking on a large commit can take a hug amount of time, just to see the title or author...
When reporting a bug through blenders UI, we still get phab-style syntax for the commit hash:
Issues: When reading notifications, the page may randomly switch.
@mod_moder : the reload (after having made a change in that list) takes you back to page 1 ... not nice, just saying...
@lichtwerk It's strange, since I can make a lot of changes in time. Now it looks even weirder.
@brecht : when an issue is renamed, it is listed multiple times in commit-notes-references
More for the list: When typing an inline comment on a PR, ctrl+enter will submit as a comment, even though the "start review" button is highlighted as default button. "Start review" is also the desired default for ctrl+enter.
More on references (see this for example): there is also no way to see if an issue already has a PR... you have to scroll all the way through the discussion...
OK, so when you see a list of edits in a comment, the highlighting only works for deletions -- not additions):
No way to see tags in commits, so you cant see quickly if a commit is in a particular release. This is what phabricator had:
As a workaround, I found
git tag --contains <commit>which is the poor mans workaround for now...EDIT: this is working now
While the API provides filtering labels in the "OR" style, the web UI always combines multiple labels using "AND".
This is what the web UI https://projects.blender.org/blender/blender/issues uses as syntax:
labels=369%2c383The API seems to offer "OR" https://projects.blender.org/api/swagger#/issue/issueListIssues
The string spit out there is
labels=383%2C+369Tried that in the web UI, but either gives a 500 Internal server error or still uses "AND". Also tried
labels=369%2c%2b383to no avail.For finding issues tagged with either of multiple labels (say
Interest/Geometry NodesORInterest/Nodes & PhysicsORModule/Nodes & Physics) this would be extremely helpful. There does not seem to be a way to do this atm (well except for using the API - but I dont consider his a valid workflow for everyday work).The parenthesis for such a feature should probably go like this:
Issues and Triaging Featuresto Issues and triaging featuresOn various issues when editing a comment, it will remove all attached images.
I can't reliably reproduce it but it happens quite often.
Can anyone else confirm this?
I think something like that happened here blender/blender#105555 (comment) (comment is edited, pics/attachments are "Not Found")
Will go over additional things we discussed in https://devtalk.blender.org/t/2024-02-15-triaging-module-meeting/33113:
-- this would be solved by "Filter menus on both /issues and /subscriptions pages, not just for issue list within repositories." already mentioned in the first comment, however even without the filter menus, it would be useful to keep the labels on the second page
-- this would be solved by "Date range support in issue list UI" already mentioned in the first comment
-- this is more or less handled in #78 now
-- this is already mentioned as "Summarize references of an issue instead of having to scroll through the entire comments", this would be useful for PRs as well, will add to the first comment
-- this is more or less handled by "Merge issue support without having to manually add label and comment" already mentioned in the first comment
-- this is already mentioned as "Can't move reports across repos, in particular between blender, addons and documentation" in the first comment
-- will add that to the first comment
-- this should have a further discussion first, personally, I would think this should not be changed (users should still e allowed to reopen reports)
-- probably debatable, but it always goes to
Needs Triage(even if it was confirmed before), will double-check in todays meetingFrom https://devtalk.blender.org/t/2024-02-29-triaging-module-meeting/33580:
-- will add that to the first comment
So many of these things were already on the list, just reconfirms that they are still an issue in the everyday triaging workflow :)
Thanks for the overview. Feel free to edit the issue description and reorder things as needed there, to better reflect the priorities of the triaging module.
It could be a good topic for the next admin meeting to discuss if and how we can address these. I'd rather not spend time on implementing these types of things myself, but maybe some other solution can be found.
From https://devtalk.blender.org/t/2024-04-18-triaging-module-meeting/34260 :
-- will add that to the list
Good First Issues) -- which team membership is required?It seems to be anyone that is a member of some team in the Blender organization.
Anyone with write access to issues. Which is mainly Developers and Contributors teams.
Only admins and the reviewers themselves. The reason is that in Gitea you can set up rules about when a PR can be landed based on reviewer approvals or rejection, and so it shouldn't be possible for the author or another developer to bypass that by removing reviewers.
@PratikPB2123 ^^
make sense, Thanks 🙂
There has been interest from a few members now for the option to subscribe to labels (E.g. Subscribe to the
Module|Render & Cycleslabel) so users can recieved notifications on anything that happens with those labels (E.g. Someone comments on a issue with that label)I have created a script that can generally do this, however it would be better if this was integrated into Gitea. I have a few questions related to this.
https://projects.blender.org/api/v1/orgs/blender/activities/feedsto get recent activity. The adding and removing of labels is not included in the activity feed. If that information could be added to the activity feed in the Gitea API, that would be helpful.https://projects.blender.org/api/v1/orgs/blender/activities/feeds(thecomment_idfield that should have that info, is always 0). This might be a bug in the current version of Gitea, or a TODO that hasn't been finished yet. If this could be fixed, I could reduce the number of API calls I make.It would be a useful feature to add to Gitea. But unless there are multiple developers telling us this is very important for them, it's not something I want to prioritize, either as an upstream Gitea feature or something custom.
You're free to make the feature request upstream.
Recently Labels list on report page get few larger (and its wide is depend on list items):
Would be good to fix. The description seems longer than it needs to be in this case, I shortened it.
Is there is chance to change background color for images in commits (like in
b076c1337f)?@mod_moder Surely it would be good to improve, but is something that is to be done upstream.
Issues and triaging featuresto Gitea: Issues and triaging features