Fix bug of branch/tag selector in the issue sidebar

[hiifong]

Fix: #32731

[yp05327]

Didn’t look into it, but why RepoBranchTagSelector is not used here?

[wxiaoguang]

TBH, this selector should be completely removed.

I don't see it is useful in modern Gitea. It seems that selector was added in old days when Gitea doesn't have proper Issue/PR support.

Anyone is really using that selector?

[yp05327]

It seems that it is used only in this pkace.

[wxiaoguang]

History: Add possibility to record branch or tag information in an issue (#780)

It does nothing more than just saving the branch/tag name into database ..............

[hiifong]

TBH, this selector should be completely removed.

I don't see it is useful in modern Gitea. It seems that selector was added in old days when Gitea doesn't have proper Issue/PR support.

Anyone is really using that selector?

I think it is not a selector here, but a hint.

[yp05327]

I don’t know the usage of this feature if we have development section in the sidebar. They seem similar.

#31899 (comment)

[shugen002]

Just some notice:
this selector , in other word, this sidebar also used in the new issue page.
if someone want to do some refactor, don't forget to check the page.

[lunny]

History: Add possibility to record branch or tag information in an issue (#780)

It does nothing more than just saving the branch/tag name into database ..............

After reviewed the history, the feature aims to record which branch/tag happened of this issue. It looks like it maybe useful when reporting a bug. It's incomplete to have filter in issues page. Since Github has no such feature, we commonly record a version, OS, and other things in the issue content. Another alternative feature is label. Users can create labels with the same name as versions and track them with labels. So is this a really necessary feature? Maybe not.

[yp05327]

I think this feature can be merged into development as it is used for developers to track in which branch/tag happened of this issue.
Or at least, giving it a description and a title. For now, I think most users don’t know the correct usage which it is designed for, especially after the implementation of development section.
Or just remove it.

[hiifong]

remove it

[wxiaoguang]

remove it

Although I suggested to remove it, actually "how to remove it" should be carefully designed.

Since this feature has been there for long time, we are not sure whether it is sure that nobody needs it.

If you just remove it completely and drop the column, then what if some 1.23 users come to complain: please give that selector back to me, what could you do?

Ideally the removal should be like this:

1. only hide it from the UI in 1.23, and collect feedbacks
2. if nobody complains and explains how to use it, remove code and drop database column in 1.24 or 1.25

[eeyrjmr]

Two questions.

1.what is shown/managed for issues that do have this information ? Will this break something for those instances that this was previously used one
2. How is this capability still realised (options were listed at in the OP)

This might not impact how we work... Just trying to collect the information. Multiple LTS feature branches at different branching from MAIN... I guess review comments can mention what branch the chreeypicked fix should be a applied to (or rewritten for). Not sure how 31899 works ATM so I can't comment

[wxiaoguang]

1.what is shown/managed for issues that do have this information ? Will this break something for those instances that this was previously used one

Nobody knows at the momemt, that's why it needs to collect feedbacks. This info is only stored in database and displayed on the UI, no other logic.

2. How is this capability still realised (options were listed at in the OP)

For example: just write the branch/tag name in the issue title? then it is still "stored in database" and "displayed on the UI"

Multiple LTS feature branches at different branching from MAIN...

It could also use other approaches, eg: labels, milestones, projects to bind an issue to a "feature"

[lunny]

Or maybe we can migrate the data to the new table in the coming PR. Then I need to support tag

[wxiaoguang]

Or maybe we can migrate the data to the new table in the coming PR. Then I need to support tag

Why? Have you figured out how end users use that field? Is it certain that the Ref could be used in your PR?

[eeyrjmr]

1.what is shown/managed for issues that do have this information ? Will this break something for those instances that this was previously used one

Nobody knows at the momemt, that's why it needs to collect feedbacks. This info is only stored in database and displayed on the UI, no other logic.

so if it is only for display purposes then how it is being used presently can be complimented (honestly in my dev setup its only me that does this out of 4 of us :) ). Be it labels or text, yes there are ways to indicate to the wider team what branch to consider or what tag to check the issue again. I am just nervous about what happens to the db etc if this is dropped/removed.

[wxiaoguang]

I am just nervous about what happens to the db etc if this is dropped/removed.

So in 1.23 we only hide it, and will drop it in next release if it is not used.

[lunny]

Is this ready to review or merge?

[shugen002]

Few question , will the new feature #31899 block next release if this pr merged?
In the other word, can we make sure there is something to record a tag/branch in next branch.

[lunny]

Few question , will the new feature #31899 block next release if this pr merged? In the other word, can we make sure there is something to record a tag/branch in next branch.

I would like #31899 merged first.

[wxiaoguang]

In the other word, can we make sure there is something to record a tag/branch in next branch.

This PR's question is: how do you use that branch/tag selector?

[lunny]

I moved #31899 from v1.23. And I think that will not be a block of this PR. The purpose is different. That PR added a development sidebar section to record which branches/commits/pull requests which resolved/will resolve the issue. But this feature is recording which branch does the issue happen.

[didim99]

Anyone is really using that selector?

Yes! Our team uses this feature for more than 20 projects with many branches. When your repo has more than 2-3 branches with different stuff (features, refactoring, etc) developing on them, it is a really useful feature to specify a branch in which issue found.

[wxiaoguang]

it is a really useful feature to specify a branch in which issue found.

@didim99 Thank you very much for the feedback, it is valuable. Just have some more questions, could you help us to understand more about "selector"?

• If it is used to "record the branch where a problem is found", what is the difference from "writing the branch name in issue title or description"? I can see the the branch selector's value isn't even searchable .... Could "using issue title/description to record the branch" be a feasible approach?
• Is "GitHub-like development sidebar (#31899)" good enough (or better) for your usage?
  • Add a new section named development in issue view sidebar to interact with branch/pr #31899

[wxiaoguang]

To avoid "breaking" in 1.23, I reverted the selector with the bug fix and added more comments. Then this PR could be merged, the discussion could be continued ( #32744 (comment) ) to figure out how to improve the branch selector in the future.