create issue over multiple repositories #394

New Issue

GiteaMirror · 2025-11-02T03:21:46-06:00

GiteaMirror commented

2025-11-02 03:21:46 -06:00

Originally created by @robinfehr on GitHub (Feb 24, 2017).

we're developing a bigger product right now which has multiple SDK's and with maintaining multiple SDK's there comes the problem that they all must have the same features / bug fixes etc for same versions. So after creating an issue we right now go copy paste it to all the other SDK's. It would come super handy if there was a feature for that which would allow us to create issues over multiple repos with labels and milestones (if they are available in that repo of course).

Originally created by @robinfehr on GitHub (Feb 24, 2017). we're developing a bigger product right now which has multiple SDK's and with maintaining multiple SDK's there comes the problem that they all must have the same features / bug fixes etc for same versions. So after creating an issue we right now go copy paste it to all the other SDK's. It would come super handy if there was a feature for that which would allow us to create issues over multiple repos with labels and milestones (if they are available in that repo of course).

GiteaMirror added the reviewed/wontfix label 2025-11-02 03:21:46 -06:00

GiteaMirror closed this issue

2025-11-02 03:21:46 -06:00

GiteaMirror commented

2025-11-02 03:21:47 -06:00

@lunny commented on GitHub (Feb 24, 2017):

It seems it's a strange requirement.

@lunny commented on GitHub (Feb 24, 2017): It seems it's a strange requirement.

GiteaMirror commented

2025-11-02 03:21:47 -06:00

@thibaultmeyer commented on GitHub (Feb 24, 2017):

@robinfehr You can use an external bug tracker like YouTrack, BugZilla, Mantis, ... or simply create another repository with the only purpose to handle all issue tickets and milestones (like Valve who have open a github repository only for the issue tickets system)

@thibaultmeyer commented on GitHub (Feb 24, 2017): @robinfehr You can use an external bug tracker like YouTrack, BugZilla, Mantis, ... or simply create another repository with the only purpose to handle all issue tickets and milestones (like Valve who have open a github repository only for the issue tickets system)

GiteaMirror commented

2025-11-02 03:21:47 -06:00

@robinfehr commented on GitHub (Feb 24, 2017):

@0xbaadf00d
true that we could look for an external one which supports that - we don't actually like having more tools tough.

I guess the second suggestion wouldn't be an option since we want the issues linked in the commits unless cross referencing is possible (I don't know how). If cross referencing is possible we could help ourselves with putting check boxes for each SDK in the global issue.

what we also could do is using the gitea api and write us a little helper tool to create issues.

@robinfehr commented on GitHub (Feb 24, 2017): @0xbaadf00d true that we could look for an external one which supports that - we don't actually like having more tools tough. I guess the second suggestion wouldn't be an option since we want the issues linked in the commits unless cross referencing is possible (I don't know how). If cross referencing is possible we could help ourselves with putting check boxes for each SDK in the global issue. what we also could do is using the gitea api and write us a little helper tool to create issues.

GiteaMirror commented

2025-11-02 03:21:47 -06:00

@robinfehr commented on GitHub (Feb 24, 2017):

just found https://github.com/go-gitea/gitea/issues/748 - this would solve our problem too then. We'll wait +1

@robinfehr commented on GitHub (Feb 24, 2017): just found https://github.com/go-gitea/gitea/issues/748 - this would solve our problem too then. We'll wait +1

GiteaMirror commented

2025-11-02 03:21:47 -06:00

@robinfehr commented on GitHub (Feb 24, 2017):

@lunny to make this more clear i'd like to show you what i had in mind as the process.

setup of 6 sdk's , one api => all sdks' are on version 0.1.0, api is on version 0.1.0 => several api changes planned, issues for the api created with the milestone 0.2.0 => api changes pushed (referenced to the 0.2.0 issues) => create milestone 0.2.0 for all sdk's => create issues for the changes in all sdk's => sdk maintainers can resolve then.

what we now can access a global overview over the milestone 0.2.0 - we'd to have such an overview because we want to release them all together with the api.

this way the sdk maintainers don't always have to poll and lookup the api changes and create issues for the changes themselves.

but like mentioned - #748 will help us too.

@robinfehr commented on GitHub (Feb 24, 2017): @lunny to make this more clear i'd like to show you what i had in mind as the process. setup of 6 sdk's , one api => all sdks' are on version 0.1.0, api is on version 0.1.0 => several api changes planned, issues for the api created with the milestone 0.2.0 => api changes pushed (referenced to the 0.2.0 issues) => create milestone 0.2.0 for all sdk's => create issues for the changes in all sdk's => sdk maintainers can resolve then. what we now can access a global overview over the milestone 0.2.0 - we'd to have such an overview because we want to release them all together with the api. this way the sdk maintainers don't always have to poll and lookup the api changes and create issues for the changes themselves. but like mentioned - #748 will help us too.

GiteaMirror commented

2025-11-02 03:21:48 -06:00

@lunny commented on GitHub (Feb 24, 2017):

That's OK.

@lunny commented on GitHub (Feb 24, 2017): That's OK.

GiteaMirror commented

2025-11-02 03:21:48 -06:00

@strk commented on GitHub (Feb 24, 2017):

Strange, but we also have it, when adding MAINTAINERs :)

@strk commented on GitHub (Feb 24, 2017): Strange, but we also have it, when adding MAINTAINERs :)

GiteaMirror commented

2025-11-02 03:21:48 -06:00