What does being soft-fork mean for reporting issues? #114

Aminda commented 2023年01月19日 12:32:27 +01:00

I haven't knowingly interacted with soft-forks before and I am confused on where I should open issues and feature requsts regarding Forgejo and Gitea.

My intuition says that being a soft-fork means that I report issues to Gitea unless I cannot reproduce it on try.gitea.io and thus confirm it being caused by Forgejo instead.

However there is #110 giving a guideline of Forgejo first (implied Gitea second?) so maybe I shouldn't be interacting with Gitea directly? Wouldn't requesting features in Forgejo mean that it diverges from Gitea further that I think may be counterproductive for a soft-fork while that is possible (until Gitea starts rejecting features introduced by Forgejo or goes closed source)?

There is also #69 where this may be related to, but I think this question falls between both issues so thus may be better to be asked separately.

Oh and there is the question of what do I do with existing feature requests, should I be reopening them towards Forgejo?

I haven't knowingly interacted with soft-forks before and I am confused on where I should open issues and feature requsts regarding Forgejo and Gitea. My intuition says that being a soft-fork means that I report issues to Gitea unless I cannot reproduce it on try.gitea.io and thus confirm it being caused by Forgejo instead. However there is #110 giving a guideline of Forgejo first (implied Gitea second?) so maybe I shouldn't be interacting with Gitea directly? Wouldn't requesting features in Forgejo mean that it diverges from Gitea further that I think may be counterproductive for a soft-fork while that is possible (until Gitea starts rejecting features introduced by Forgejo or goes closed source)? There is also #69 where this may be related to, but I think this question falls between both issues so thus may be better to be asked separately. Oh and there is the question of what do I do with existing feature requests, should I be reopening them towards Forgejo?

fsologureng commented 2023年01月19日 22:34:52 +01:00

Great questions. Is not easy to explain. In a nutshell: we are being busy involved trying to release Forgejo while yet there isn't a governance nor enough documentation nor communication strategy.

PD: I miss @onepict skills.

Great questions. Is not easy to explain. In a nutshell: we are being busy involved trying to release Forgejo while yet there isn't a governance nor enough documentation nor communication strategy. PD: I miss @onepict skills.

KaKi87 commented 2023年01月20日 02:28:56 +01:00

Users choose Forgejo because they want to join our community, not Gitea's, so they shouldn't be required to join theirs, much less be required to have a GitHub account for it.

So, users should be allowed to report issues at Forgejo regardless of Gitea reproducibility.

If reproducible on Gitea, Forgejo contributors should report the issue at Gitea, and report back here.

If useful and needed, I'd volunteer for triaging reproducibility and communicating between communities.

Users choose Forgejo because they want to join our community, not Gitea's, so they shouldn't be required to join theirs, much less be required to have a GitHub account for it. So, users should be allowed to report issues at Forgejo regardless of Gitea reproducibility. If reproducible on Gitea, Forgejo contributors should report the issue at Gitea, and report back here. If useful and needed, I'd volunteer for triaging reproducibility and communicating between communities.

Daeraxa commented 2023年01月31日 18:30:53 +01:00

I was asking this question in the Matrix space to understand what the preference would be.

As I already have and am active on GitHub I had no issues in creating upstream issues on the GH repos but agree with @KaKi87 that it shouldn't be a requirement for a reporting user to sign up an account, particularly as people on Codeberg or using Forgejo locally may have good reasons not to want to make or use a GH account.

What I ended up doing was making an issue here then opening one in the Gitea repo once I had reproduced the behaviour, I then linked the issue to the very top of the original post (which is what @crystal had already done for a different upstream issue I logged (not Gitea)).

image

Having it logged in both I think is a good idea as it enables it to be tracked here in case other people search for it or are looking to report it. It also shows that if this is upstream and they want to fix it then it may be better to submit the PR to the upstream project.

So maybe a policy could be:

• See if the issue can be replicated in Gitea as well as Forgejo
• If possible, log the issue in both Forgejo and the upstream repo
  • If not then indicate and somebody else can do it
• Edit the Forgejo issue to place the upstream issue link in a standardised location, maybe this should be part of the issue template?

I was asking this question in the Matrix space to understand what the preference would be. As I already have and am active on GitHub I had no issues in creating upstream issues on the GH repos but agree with @KaKi87 that it shouldn't be a requirement for a reporting user to sign up an account, particularly as people on Codeberg or using Forgejo locally may have good reasons not to want to make or use a GH account. What I ended up doing was making an issue here then opening one in the Gitea repo once I had reproduced the behaviour, I then linked the issue to the very top of the original post (which is what @crystal had already done for a different upstream issue I logged (not Gitea)).  Having it logged in both I think is a good idea as it enables it to be tracked here in case other people search for it or are looking to report it. It also shows that if this is upstream and they want to fix it then it may be better to submit the PR to the upstream project. So maybe a policy could be: - See if the issue can be replicated in Gitea as well as Forgejo - If possible, log the issue in both Forgejo and the upstream repo - If not then indicate and somebody else can do it - Edit the Forgejo issue to place the upstream issue link in a standardised location, maybe this should be part of the issue template?

crystal commented 2023年02月01日 02:12:42 +01:00

I feel obliged to point out that I made a mistake when I edited your post the first time, which was quickly corrected by @dachary. The dependency references at the top of the description should look like this:

First heading: Dependency references. List of links to upstream issues and/or pull requests. Second heading: Context.

Sorry about that.

I feel obliged to point out that I made a mistake when I edited your post the first time, which was quickly corrected by @dachary. The dependency references at the top of the description should look like this:  Sorry about that.

Daeraxa commented 2023年02月01日 02:14:10 +01:00

Not a problem, so long as it is made clear if that is the standard that is going to be used then it is easy enough to do.

Not a problem, so long as it is made clear if that is the standard that is going to be used then it is easy enough to do.

Ghost commented 2023年02月01日 07:43:23 +01:00

It is still unclear what the best way is to keep related issues together when tracking an issue across forges. Although I prefer that it is prominently displayed at the beginning of the description, it is not something that was really discussed so far. Maybe that should be?

It is still unclear what the best way is to keep related issues together when tracking an issue across forges. Although I prefer that it is prominently displayed at the beginning of the description, it is not something that was really discussed so far. Maybe that should be?

Ryuno-Ki commented 2023年02月01日 09:52:53 +01:00

I feel like „tracking issues across forges" is a topic that could also be discussed in the scope of Forge federation.

@Daeraxa Issue template in terms of https://codeberg.org/forgejo/forgejo/src/branch/forgejo/.gitea/ISSUE_TEMPLATE ? Or as part of the UI?

I feel like „tracking issues across forges" is a topic that could also be discussed in the scope of Forge federation. @Daeraxa Issue template in terms of https://codeberg.org/forgejo/forgejo/src/branch/forgejo/.gitea/ISSUE_TEMPLATE ? Or as part of the UI?

Daeraxa commented 2023年02月01日 14:43:24 +01:00

@Daeraxa Issue template in terms of https://codeberg.org/forgejo/forgejo/src/branch/forgejo/.gitea/ISSUE_TEMPLATE ? Or as part of the UI?

I was indeed thinking the ISSUE_TEMPLATE. For example in the starting commented out section:

6. Can the issue be replicated in [Gitea](link/to/gitea or try.gitea.io)? If you are able to replicate it then please indicate as such. If possible then please open a new issue in the [Gitea](github/go-gitea) repository and link it back to this issue by adding the following section to the start of the issue:

## Dependency references
* [Gitea issue](https://github.com/go-gitea/gitea/issues/xxxxxx)

I think the "if possible" should be emphasised here as I was saying before, there are good cases where people may not want to make or use a GH account. In which case another person can log it on their behalf and comment it to the Forgejo issue.

> @Daeraxa Issue template in terms of https://codeberg.org/forgejo/forgejo/src/branch/forgejo/.gitea/ISSUE_TEMPLATE ? Or as part of the UI? I was indeed thinking the ISSUE_TEMPLATE. For example in the starting commented out section: 6. Can the issue be replicated in `[Gitea](link/to/gitea or try.gitea.io)`? If you are able to replicate it then please indicate as such. If possible then please open a new issue in the `[Gitea](github/go-gitea)` repository and link it back to this issue by adding the following section to the start of the issue: ``` ## Dependency references * [Gitea issue](https://github.com/go-gitea/gitea/issues/xxxxxx) ``` I think the "if possible" should be emphasised here as I was saying before, there are good cases where people may not want to make or use a GH account. In which case another person can log it on their behalf and comment it to the Forgejo issue.

fsologureng commented 2023年02月01日 14:54:38 +01:00

@Daeraxa Issue template in terms of https://codeberg.org/forgejo/forgejo/src/branch/forgejo/.gitea/ISSUE_TEMPLATE ? Or as part of the UI?

I was indeed thinking the ISSUE_TEMPLATE. For example in the starting commented out section:

6. Can the issue be replicated in [Gitea](link/to/gitea or try.gitea.io)? If you are able to replicate it then please indicate as such. If possible then please open a new issue in the [Gitea](github/go-gitea) repository and link it back to this issue by adding the following section to the start of the issue:

## Dependency references
* [Gitea issue](https://github.com/go-gitea/gitea/issues/xxxxxx)

I think the "if possible" should be emphasised here as I was saying before, there are good cases where people may not want to make or use a GH account. In which case another person can log it on their behalf and comment it to the Forgejo issue.

I like the proposal but you should consider that Gitea dependencies are not just the only one dependencies, as you are already know, so the approach should be more general.

There is a proposal of instance similar to try.gitea.io for forgejo, but is WIP.

> > @Daeraxa Issue template in terms of https://codeberg.org/forgejo/forgejo/src/branch/forgejo/.gitea/ISSUE_TEMPLATE ? Or as part of the UI? > > I was indeed thinking the ISSUE_TEMPLATE. For example in the starting commented out section: > > 6. Can the issue be replicated in `[Gitea](link/to/gitea or try.gitea.io)`? If you are able to replicate it then please indicate as such. If possible then please open a new issue in the `[Gitea](github/go-gitea)` repository and link it back to this issue by adding the following section to the start of the issue: > > ``` > ## Dependency references > > * [Gitea issue](https://github.com/go-gitea/gitea/issues/xxxxxx) > ``` > > I think the "if possible" should be emphasised here as I was saying before, there are good cases where people may not want to make or use a GH account. In which case another person can log it on their behalf and comment it to the Forgejo issue. I like the proposal but you should consider that Gitea dependencies are not just the only one dependencies, as [you are already know](https://codeberg.org/forgejo/forgejo/issues/288), so the approach should be more general. There is a proposal of instance similar to try.gitea.io for forgejo, but is WIP.

Daeraxa commented 2023年02月01日 15:25:43 +01:00

I like the proposal but you should consider that Gitea dependencies are not just the only one dependencies, as you are already know, so the approach should be more general.

I think there is a big difference between "normal" upstream dependencies (like the one of mine you linked where you can't really expect everyone to know what the upstream project is so you do rely on people more familiar with the project to let you know) vs the major upstream project for this entire endeavor.

The former is a very familiar case to the majority of open source contributors but the relationship between Gitea and Forgejo is different and I think needs special consideration when reporting and replicating issues - particularly as the majority of issues raised here are are more than likely also going to affect Gitea until/unless a day comes where Forgejo goes "hard fork".

> I like the proposal but you should consider that Gitea dependencies are not just the only one dependencies, as you are already know, so the approach should be more general. I think there is a big difference between "normal" upstream dependencies (like the one of mine you linked where you can't really expect everyone to know what the upstream project is so you do rely on people more familiar with the project to let you know) vs the major upstream project for this entire endeavor. The former is a very familiar case to the majority of open source contributors but the relationship between Gitea and Forgejo is different and I think needs special consideration when reporting and replicating issues - particularly as the majority of issues raised here are are more than likely also going to affect Gitea until/unless a day comes where Forgejo goes "hard fork".

fsologureng commented 2023年02月01日 17:41:54 +01:00

I like the proposal but you should consider that Gitea dependencies are not just the only one dependencies, as you are already know, so the approach should be more general.

I think there is a big difference between "normal" upstream dependencies (like the one of mine you linked where you can't really expect everyone to know what the upstream project is so you do rely on people more familiar with the project to let you know) vs the major upstream project for this entire endeavor.

The former is a very familiar case to the majority of open source contributors but the relationship between Gitea and Forgejo is different and I think needs special consideration when reporting and replicating issues - particularly as the majority of issues raised here are are more than likely also going to affect Gitea until/unless a day comes where Forgejo goes "hard fork".

I totally agree with you, but we are talking about a template, how do we open the possibility to other dependencies in the bug report? leaving empty the Gitea fields? it wouldn't bias the origin of the problem? we share almost all the dependencies with Gitea.

> > I like the proposal but you should consider that Gitea dependencies are not just the only one dependencies, as you are already know, so the approach should be more general. > > I think there is a big difference between "normal" upstream dependencies (like the one of mine you linked where you can't really expect everyone to know what the upstream project is so you do rely on people more familiar with the project to let you know) vs the major upstream project for this entire endeavor. > > The former is a very familiar case to the majority of open source contributors but the relationship between Gitea and Forgejo is different and I think needs special consideration when reporting and replicating issues - particularly as the majority of issues raised here are are more than likely also going to affect Gitea until/unless a day comes where Forgejo goes "hard fork". > > > I totally agree with you, but we are talking about a template, how do we open the possibility to other dependencies in the bug report? leaving empty the Gitea fields? it wouldn't bias the origin of the problem? we share almost all the dependencies with Gitea.

Daeraxa commented 2023年02月01日 18:16:56 +01:00

Honestly not sure what the correct answer is, I've gone over this a few times and each time I think of something else or invalidate my previous idea. This is the first time I've really even looked at a "soft fork" project so these are things I've never even considered before as to how they should be handled.

Ultimately there are two sides to the issue reporting:

1. Users/contributors submitting issues to the best of their ability (well, hopefully anyway, you will always get low quality reports)
2. Collaborators/team members performing triage and maintaining the issues

The goal I see of the template is to prompt the users/contributors to provide as much info as possible with the assumption that they know very little or nothing about the project itself. This then makes the quality of the issue logging better and makes the next step of triage etc. easier with a view to fixing.

So in this case I don't think there is a perfect solution. I totally see what you mean, for example the issue with syntax highlighting caused by the upstream Chroma dependency is also an issue for Gitea but I haven't logged an issue there. Should I? Probably (in fact I will), but either way it is something that will likely be resolved by just updating to a newer version of that dependency so (in theory) it would be a really easy fix for Forgejo independent of Gitea and wouldn't break compatability.

Ultimately I think suggesting to see if the issue can be replicated in Gitea (specifically with try.gitea.io - forcing people to try a binary or build Gitea from source seems a bit too much) and logging the issue there as well if they want to.

The rest then comes down to the triage step, people with knowledge of Gitea/Forgejo can then chime in to see if it is probably a different dependency issue or if the upstream issue stops at Gitea itself and if necessary create the issue on Gitea themselves and link it.

That is where I think there should probably be a more official procedure in the triage side of things, that is where you want to really set down the rules to find where the dependency is and track it - "complete these steps before tagging issue with x, y, z".

Sorry for the rambling, I'm still trying to make my mind up as I write it, but I think in this case an official policy on the triage side of things probably needs to be made first to then feed into the issue reporting side. i.e. for an issue to be correctly tagged and triaged should it be replicated on Gitea with an issue submitted there and a link created. The information in the issue template is therefore just trying to reduce some of the burden on that part of the process.

Honestly not sure what the correct answer is, I've gone over this a few times and each time I think of something else or invalidate my previous idea. This is the first time I've really even looked at a "soft fork" project so these are things I've never even considered before as to how they should be handled. Ultimately there are two sides to the issue reporting: 1) Users/contributors submitting issues to the best of their ability (well, hopefully anyway, you will always get low quality reports) 2) Collaborators/team members performing triage and maintaining the issues The goal I see of the template is to prompt the users/contributors to provide as much info as possible with the assumption that they know very little or nothing about the project itself. This then makes the quality of the issue logging better and makes the next step of triage etc. easier with a view to fixing. So in this case I don't think there is a perfect solution. I totally see what you mean, for example the issue with syntax highlighting caused by the upstream Chroma dependency is *also* an issue for Gitea but I haven't logged an issue there. Should I? Probably (in fact I will), but either way it is something that will likely be resolved by just updating to a newer version of that dependency so (in theory) it would be a really easy fix for Forgejo independent of Gitea and wouldn't break compatability. Ultimately I think suggesting to see if the issue can be replicated in Gitea (specifically with `try.gitea.io` - forcing people to try a binary or build Gitea from source seems a bit too much) and logging the issue there as well *if they want to*. The rest then comes down to the triage step, people with knowledge of Gitea/Forgejo can then chime in to see if it is probably a different dependency issue or if the upstream issue stops at Gitea itself and if necessary create the issue on Gitea themselves and link it. That is where I think there should probably be a more official procedure in the triage side of things, that is where you want to really set down the rules to find where the dependency is and track it - "complete these steps before tagging issue with x, y, z". Sorry for the rambling, I'm still trying to make my mind up as I write it, but I think in this case an official policy on the triage side of things probably needs to be made first to then feed into the issue reporting side. i.e. for an issue to be correctly tagged and triaged should it be replicated on Gitea with an issue submitted there and a link created. The information in the issue template is therefore just trying to reduce some of the burden on that part of the process.

fsologureng commented 2023年02月01日 21:26:23 +01:00

I agree that formalize a triage procedure would be very helpful.

However, I tend to think if someone point to Gitea as dependency with clarity (f.e. with bug opened there, or with a complete report of the problem) is because is pretty sure the bug is there. Is the unique case in which triage is simpler. Any other requires to check from our side at which level or dependency is the bug. That's my reluctance to suggest Gitea as dependence in the template, but I am very open to add the Dependency section as you propose, empty with an html comment inviting to fill it.

The check in the "next" instance will be an add in its moment.

I agree that formalize a triage procedure would be very helpful. However, I tend to think if someone point to Gitea as dependency with clarity (f.e. with bug opened there, or with a complete report of the problem) is because is pretty sure the bug is there. Is the unique case in which triage is simpler. Any other requires to check from our side at which level or dependency is the bug. That's my reluctance to suggest Gitea as dependence in the template, but I am very open to add the Dependency section as you propose, empty with an html comment inviting to fill it. The check in the "next" instance will be an add in its moment.

Daeraxa commented 2023年02月02日 00:11:01 +01:00

I think that is probably the best approach then. Leave the template generic and make sure that when the issue is triaged that it is logged upstream as part of the triage process - if not documented already it probably should be and ideally still be made obvious for non-collaborators if they want to go further and log the upstream issues themselves.

I think that is probably the best approach then. Leave the template generic and make sure that when the issue is triaged that it is logged upstream as part of the triage process - if not documented already it probably should be and ideally still be made obvious for non-collaborators if they want to go further and log the upstream issues themselves.