Discussion of Gitea roadmap #3357

@sapk commented on GitHub (May 20, 2019):

A plugin (including theme) solution for extending gitea.

@sapk commented on GitHub (May 20, 2019): A plugin (including theme) solution for extending gitea.

GiteaMirror commented

@ghost commented on GitHub (May 20, 2019):

Would it be possible add proper OS packages to the build process? I have been trying to put something together for fedora but go seems kind of a mess to package. #31 kind of talks about this but still seems to be open.

@ghost commented on GitHub (May 20, 2019): Would it be possible add proper OS packages to the build process? I have been trying to put something together for fedora but go seems kind of a mess to package. #31 kind of talks about this but still seems to be open.

GiteaMirror commented

@xor-gate commented on GitHub (May 22, 2019):

We are using ansible to deploy the tarball on Debian system, this is not very handy but it works. Repositories for the most common distros would be nice, but it needs to be put in place and maintained.

@xor-gate commented on GitHub (May 22, 2019): We are using ansible to deploy the tarball on Debian system, this is not very handy but it works. Repositories for the most common distros would be nice, but it needs to be put in place and maintained.

GiteaMirror commented

@BNolet commented on GitHub (May 26, 2019):

A few suggestions:

Option to automatically integrate Drone CI/CD into Gitea during the build process.
More Site Administration configurability from the Gitea UI, post-install. For example, I'd like to be able to change the stuff in Service Configuration from the Configuration page.
Option to make a user hidden from the Explore page.

@BNolet commented on GitHub (May 26, 2019): A few suggestions: * Option to automatically integrate Drone CI/CD into Gitea during the build process. * More Site Administration configurability from the Gitea UI, post-install. For example, I'd like to be able to change the stuff in _Service Configuration_ from the _Configuration_ page. * Option to make a user hidden from the Explore page.

GiteaMirror commented

@Perflyst commented on GitHub (May 26, 2019):

Federated pull requests / issues / forks

@Perflyst commented on GitHub (May 26, 2019): Federated pull requests / issues / forks

GiteaMirror commented

@Amolith commented on GitHub (May 26, 2019):

Federated pull requests / issues / forks

Maybe not federated in the Fediverse sense of the word (ActivityPub, OStatus, diaspora*, etc.) but I would like the ability to interact with remote instances from one's own implemented in whatever way fits the project best.

It might also be cool to have teams and organisations made of users from across multiple instances, though that would likely be incredibly difficult to implement.

@Amolith commented on GitHub (May 26, 2019): >Federated pull requests / issues / forks Maybe not federated in the Fediverse sense of the word (ActivityPub, OStatus, diaspora*, etc.) but I would like the ability to interact with remote instances from one's own implemented in whatever way fits the project best. It might also be cool to have teams and organisations made of users from across multiple instances, though that would likely be *incredibly* difficult to implement.

GiteaMirror commented

@strypey commented on GitHub (May 26, 2019):

Two suggestions from the POV of an end user with minimal coding skills who tries to help open source projects I use by reporting bugs and giving UX feedback:

Help standardize ForgeFed! I would love the UX of filing bugs on instance of Gitea (and other community-hosted code forges) to be like one huge, decentralized GH.
Make each part of a project a Git repo, so issues, wiki etc, can be easily pulled from, branched, pushed to, or forked. GL and sr.ht do this with at least some of their components. As well as just being useful, this would potentially help with point 1)

@strypey commented on GitHub (May 26, 2019): Two suggestions from the POV of an end user with minimal coding skills who tries to help open source projects I use by reporting bugs and giving UX feedback: 1) Help standardize ForgeFed! I would love the UX of filing bugs on instance of Gitea (and other community-hosted code forges) to be like one huge, decentralized GH. 2) Make each part of a project a Git repo, so issues, wiki etc, can be easily pulled from, branched, pushed to, or forked. GL and sr.ht do this with at least some of their components. As well as just being useful, this would potentially help with point 1)

GiteaMirror commented

@strk commented on GitHub (May 26, 2019):

The ability to reply to tickets by email would be a big step forward for usability

@strk commented on GitHub (May 26, 2019): The ability to reply to tickets by email would be a big step forward for usability

GiteaMirror commented

@sapk commented on GitHub (Jun 1, 2019):

Allow the edition of all the config from the UI (and maybe change the config file format during the process)

@sapk commented on GitHub (Jun 1, 2019): Allow the edition of all the config from the UI (and maybe change the config file format during the process)

GiteaMirror commented

@tboerger commented on GitHub (Jun 1, 2019):

Maybe store majority of config within database and provide proper cli and api for it

@tboerger commented on GitHub (Jun 1, 2019): Maybe store majority of config within database and provide proper cli and api for it

GiteaMirror commented

@kolaente commented on GitHub (Jun 1, 2019):

@sapk @tboerger I'd say we should switch to viper for config, that way we could get rid of ini (and some of the bugs we had with it) and get stuff like reloading the config while Gitea is running and proper env variables.

I'd be willing to tackle this, but I'm not sure if I'll find the time in the nearer future.

@kolaente commented on GitHub (Jun 1, 2019): @sapk @tboerger I'd say we should switch to [viper](https://github.com/spf13/viper) for config, that way we could get rid of ini (and some of the bugs we had with it) and get stuff like reloading the config while Gitea is running and proper env variables. I'd be willing to tackle this, but I'm not sure if I'll find the time in the nearer future.

GiteaMirror commented

@Morlinest commented on GitHub (Jun 1, 2019):

I am for Viper too. I was trying to do it 2 years ago, but had no time to finish it... but I can try it again :)

@Morlinest commented on GitHub (Jun 1, 2019): I am for Viper too. I was trying to do it 2 years ago, but had no time to finish it... but I can try it again :)

GiteaMirror commented

@tboerger commented on GitHub (Jun 2, 2019):

I'm for getting a more minimal config file... A lot of these settings doesn't need to be set via a static config file and could be easily added to the db and and get cached for performance reasons.

@tboerger commented on GitHub (Jun 2, 2019): I'm for getting a more minimal config file... A lot of these settings doesn't need to be set via a static config file and could be easily added to the db and and get cached for performance reasons.

GiteaMirror commented

@lunny commented on GitHub (Jun 2, 2019):

I think we could at first add a database config table and move most changeable config items there from ini file and only left items which need to reload.

@lunny commented on GitHub (Jun 2, 2019): I think we could at first add a database config table and move most changeable config items there from ini file and only left items which need to reload.

GiteaMirror commented

@mrsdizzie commented on GitHub (Jun 2, 2019):

@lunny and all: agree moving many settings to the database and letting them be configured in the Web interface (either site wide or repo wide) feels like a good step forward. It would also then be easy to have a tool like tea or gitea itself be able to change those values from the command line, so you could still script a default setup.

@mrsdizzie commented on GitHub (Jun 2, 2019): @lunny and all: agree moving many settings to the database and letting them be configured in the Web interface (either site wide or repo wide) feels like a good step forward. It would also then be easy to have a tool like tea or gitea itself be able to change those values from the command line, so you could still script a default setup.

GiteaMirror commented

@belliash commented on GitHub (Jun 12, 2019):

Module system sounds great. I believe there are many people out there willing to add new functionality to gitea.

@belliash commented on GitHub (Jun 12, 2019): Module system sounds great. I believe there are many people out there willing to add new functionality to gitea.

GiteaMirror commented

@jonasfranz commented on GitHub (Jun 13, 2019):

@belliash @sapk IMO plugins/modules cannot be implemented efficiently without refactoring the models package completely and adding more abstraction. I've tested multiple technologies like the native plugin support of Go.

The result was giant binaries which are hard-depended on the Gitea binary.

I think improving webhook support and adding custom pages by webhooks is more realistic to become implemented since we already have a quiet mature API that can be used for database operations.

@jonasfranz commented on GitHub (Jun 13, 2019): @belliash @sapk IMO plugins/modules cannot be implemented efficiently without refactoring the models package completely and adding more abstraction. I've tested multiple technologies like the native plugin support of Go. The result was giant binaries which are hard-depended on the Gitea binary. I think improving webhook support and adding custom pages by webhooks is more realistic to become implemented since we already have a quiet mature API that can be used for database operations.

GiteaMirror commented

@zeripath commented on GitHub (Jun 13, 2019):

@jonasfranz I'd be very much in favour of refactoring models to remove a lot of its dependencies.

go list -f  '{{ .Imports }}' code.gitea.io/gitea/models

reveals 98 (!) direct imports. 50 of which are non-go core.

go list -f  '{{ .Deps }}' code.gitea.io/gitea/models

reveals 437 (!!) transitive dependencies. (304 of which are non-go core)

@zeripath commented on GitHub (Jun 13, 2019): @jonasfranz I'd be very much in favour of refactoring models to remove a lot of its dependencies. ``` go list -f '{{ .Imports }}' code.gitea.io/gitea/models ``` reveals 98 (!) direct imports. 50 of which are non-go core. ``` go list -f '{{ .Deps }}' code.gitea.io/gitea/models ``` reveals 437 (!!) transitive dependencies. (304 of which are non-go core)

GiteaMirror commented

@tboerger commented on GitHub (Jun 13, 2019):

Look at the drone source, there we got a lot of pluggable stuff based on webhooks.

Beside that a plugin model like packer makes sense, a grpc-based plugin system.

@tboerger commented on GitHub (Jun 13, 2019): Look at the drone source, there we got a lot of pluggable stuff based on webhooks. Beside that a plugin model like packer makes sense, a grpc-based plugin system.

GiteaMirror commented

@jonasfranz commented on GitHub (Jun 13, 2019):

@tboerger Can you provide a example from drone's pluggable stuff? Do you mean the plugin system based on docker images?

@jonasfranz commented on GitHub (Jun 13, 2019): @tboerger Can you provide a example from drone's pluggable stuff? Do you mean the plugin system based on docker images?

GiteaMirror commented

@tboerger commented on GitHub (Jun 13, 2019):

I'm talking about the extensions for configs, secrets and so on, the interfaces should be defined at https://github.com/drone/drone/tree/master/plugin

@tboerger commented on GitHub (Jun 13, 2019): I'm talking about the extensions for configs, secrets and so on, the interfaces should be defined at https://github.com/drone/drone/tree/master/plugin

GiteaMirror commented

@lunny commented on GitHub (Jun 14, 2019):

I agree with you, Gitea's next big step should be plugin system. I'm also thinking this these days. I will give the plugin system a try.

I think it should be similar with drone's plugin system but have more. We have to allow a plugin have a UI and should login with Gitea's OAuth2 automatically. And we should have some security policy on the plugins. and etc.

@lunny commented on GitHub (Jun 14, 2019): I agree with you, Gitea's next big step should be plugin system. I'm also thinking this these days. I will give the plugin system a try. I think it should be similar with drone's plugin system but have more. We have to allow a plugin have a UI and should login with Gitea's OAuth2 automatically. And we should have some security policy on the plugins. and etc.

GiteaMirror commented

https://wiki.osgeo.org/wiki/GitInfrastructureComparison

@strk commented on GitHub (Jun 15, 2019):

I want to share a comparison table we made in circa 2016 to decide which hosting platform to choose for the Open Source Geospatial Foundation. In that table we listed features that were important for us. Gitea is in one of the columns:

You will see that an important feature which was missing in 2016 is still missing today: reply-by-mail (comment/reply) --- some others have been implemented as of today.

@strk commented on GitHub (Jun 15, 2019): I want to share a comparison table we made in circa 2016 to _decide_ which hosting platform to choose for the Open Source Geospatial Foundation. In that table we listed features that were important for us. Gitea is in one of the columns: https://wiki.osgeo.org/wiki/GitInfrastructureComparison You will see that an important feature which was missing in 2016 is still missing today: reply-by-mail (comment/reply) --- some others have been implemented as of today.

GiteaMirror commented

@lunny commented on GitHub (Jun 15, 2019):

@strk tool to migrate from github and Comments on diff lines are done.

@lunny commented on GitHub (Jun 15, 2019): @strk tool to `migrate from github` and `Comments on diff lines` are done.

GiteaMirror commented

@small75 commented on GitHub (Jun 21, 2019):

Need mail template customization
See #6037

@small75 commented on GitHub (Jun 21, 2019): Need mail template customization See #6037

GiteaMirror commented

@zeripath commented on GitHub (Jun 21, 2019):

So there's quite a bit of template customisation already possible - the subject line is the only thing I don't think we have.

What we really should be doing however is enabling i18n for email and the git serv hook messages.

@zeripath commented on GitHub (Jun 21, 2019): So there's quite a bit of template customisation already possible - the subject line is the only thing I don't think we have. What we really should be doing however is enabling i18n for email and the git serv hook messages.

GiteaMirror commented

@small75 commented on GitHub (Jun 24, 2019):

Reverting a pull request needed.
See #6375

@small75 commented on GitHub (Jun 24, 2019): Reverting a pull request needed. See #6375

GiteaMirror commented

@SomeGeek commented on GitHub (Jun 27, 2019):

Full support of tags in the UI. Create, assign, change, delete, etc. I really miss this feature.

@SomeGeek commented on GitHub (Jun 27, 2019): Full support of tags in the UI. Create, assign, change, delete, etc. I really miss this feature.

GiteaMirror commented

@DblK commented on GitHub (Jun 28, 2019):

I am in favor of config in database (with cli or api to configure it, like create user and authentication ldap,etc..) and plugin system.
Those two should push gitea a big step forward.

@DblK commented on GitHub (Jun 28, 2019): I am in favor of config in database (with cli or api to configure it, like create user and authentication ldap,etc..) and plugin system. Those two should push gitea a big step forward.

GiteaMirror commented

@zeripath commented on GitHub (Jun 29, 2019):

LFS

We need some way of managing LFS files in a repository - at present they're totally opaque #7199 is an attempt to provide this - but to be efficient likely needs...
- Bloom filter for blob lookup - it would be very good to have some slightly efficient way of finding the commit and at what tree path that introduced a blob
At present there is no reliable way of restarting an upload to LFS - so very large uploads can repeatly fail. Implement tus.io as per #1723
We should provide an option to just use .gitattributes for determining if a file is an LFS pointer rather than just assuming that any file that looks like a pointer is a pointer. Although that is likely to make functionality in #7199 very difficult...
LFS files should be viewable in the diff view.

Hardening

Shutdown and the beginning of making Gitea really clusterable

We need to harden Gitea's response to shutdown.
- This means graceful shutdown of listening connections, particularly the inbuilt SSH - which currently could cause corruption of git repositories through abrupt shutdown. #7274 is a start of an attempt to fix this.
- but also it means that notification like jobs need to be serializable - e.g. indexing queues should through on-disk or db queues, similarly mail queues, etc. We have some of this already but these queues don't gracefully shutdown.
As a corollary to the above, we should separate the action of indexing from searching. Graceful shutdown requires this in any case - but it's part of the step towards clustering. I'm not certain which architecture we should take but, there are multiple options - separate the indexer out to a separate process & have Gitea read-only the index, or export the whole indexing out.

Diff and Reading data of arbitrary length in to memory

Diff code needs refactoring - it's fragile, reads the entire diff into memory and requires huge diffs to be parsed by the browser before the user can respond. This requires both UI and server changes - presumably an infinite scroll backed with Ajax is the correct technique for this. At present a sufficiently evil large diff could take down both server and browser.
Our diff architecture currently pollutes the base repository with pre-merged branches and objects.
In general we MUST stop just reading data of arbitrary length into memory. If there is a place where the browser might want this - we should limit what we read and then use either an infinite scroll technique or full link with browser rendering or rendered in a pipeline to ensure that it is not buffered entirely in memory. Even relatively new code still suffers from this problem.
(If we are running a git process which may return arbitrarily long data we should try to avoid reading all of it directly into a stdout buffer entirely but do more go-routine pipelines.)

Merge

We must refactor merge to use the git index entirely as we currently do a sparse checkout for merging - basically because git merge will drop down to https://git-scm.com/docs/git-merge-one-file to handle non-fast-forward merges. This forces the creation of semi-arbitrary paths on the server - which are unnecessary and dependent on the charset/filesystem factors. It's not necessary to do this - we can do these merges with temporary files, hashing and adding to the index directly.

Escaping and Repository locations

We must check everywhere for escaping. Legacy Gogs code was poorly escaped in general and has been responsible for multiple security issues.
The assumption that the username and repository names don't need escaping is forcing an architecture decision on us that we don't need. It didn't even protect us properly for git signatures hence #5774.
Although it's pleasant for users to have the underlying repository location match the filesystem location - e.g. $GITEA_ROOT/owner/reponame it's a bad architectural decision IMHO and leads to assumptions by users that our repositories can still be used by git on the server without further thought - THEY SHOULD NOT. We should move to $GITEA_ROOT/repository-$ID, possibly sharded. (Doing this would allow the removal of a lot of calls to repo.MustOwner() or repo.GetOwner())
- Once we move to the above and we're escaping everything properly we can then relax constraints on the usernames and repository names - although this would have to be carefully thought about to ensure that we do it in a way that doesn't allow faking through issues similar to #5774.
We should enforce server git processes to have to run with a sufficient Gitea environment - there are repeated users who try to use Gitea's repositories on the server without going through Gitea so then complain that Gitea is not updated etc. #6961 is a necessary step to this and following the merging of this we simply change bf55276189/cmd/hook.go (L72) to enforce the setting of SSH_ORIGINAL_COMMAND or otherwise enforce that the rest of the standard environment is set.
We should be able to cope with NO_EXEC mounted repositories - and in fact we should probably recommend this. It's probably not actually difficult to do - simply change the .git/config or the central .gitconfig core.hooksPath variable and think about where we're going to place hooks otherwise.
We're basically storing lines of code directly in the database for comments - which doesn't work if the data being stored is not in UTF-8. This means that you simply cannot comment on a non-UTF8 code.

API / SDK

It's crazy the amount of work that we have to do to build an API when we go to all the effort to have swagger. We should just autogenerate this from swagger, or autogenerate as much as possible as we can
We have no way testing a fixed API version against our development Gitea so we can't tell when we're making breaking changes.
We should be able to use an autogenerated API/SDK to create simple test harnesses

Testing

We currently run our unit tests at TRACE level - this limits our ability to add proper trace to things. Since https://gitea.com/gitea/log/pulls/3 and if we backport into Gitea we can change this from our makefile.
Need more Unit tests and consider if some of the integration tests are actually unit and vice versa. e.g. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
We need more integration tests that try to run through user stories. That is - A user logins, does X, then Y and Z happens. It's fine to test things in isolation eg. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go but that's not really integrated and it misses testing what the user experiences. I keep saying this but more tests should look like: https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go and https://github.com/go-gitea/gitea/blob/master/integrations/git_test.go which actually test whether a feature integrates correctly.
Our testing regime takes too long - CI is taking 30-40 minutes to run at present! We should be running these in parallel.
There is no easy way to create migration tests.

Go Package Architecture

Models

code.gitea.io/gitea/models depends on way too many things this has to stop.
models.x must be destroyed. It's a terrible architectural decision.
For too many of the models it's way too easy to cause a nil pointer dereference because you don't know what state it is in. Can we use go's typing system a bit better here?
We should just stick OwnerName in the repository table as every time we get a repository we then have to go and get the Owner. It's silly and a waste of time. Repositories don't change owner very often so the cost of having to handle that is not major.
Too many things are still done in models and more should be moved out.
It may make sense to split models into core and non-core.

Modules

There are essentially two type of modules: those that depend on models and those that models depend on. Let's separate these, one could be called services.

Macaron

I think we should take seriously the move to ~~gin~~chi proposed by @lunny
Our codebase is splattered with dependencies on macaron this should not be the case

Setting

Depends on macaron too(!)
Is tightly linked to go-ini, another dependency we should consider disconnecting ourselves from.

Internationalisation

EMail not internationalised
Git messages not internationalised
Error messages not internationalised
We should automate stripping out our hugo website documentation so it can be internationalised with CrowdIn
It's weird that we have the languages using lowercase forms e.g. français, español in the language selector lists - this represents the start of a sentence in each of those languages so AFAICS they should be capitalised. Oui, si j'écris en français j'écris "français", mais si j'écris une liste á puces, j'écris:
- English
- Français
- Español

Gitea Dump & Restore

Gitea dump is broken for converting between SQL variants
We have no restore command

@zeripath commented on GitHub (Jun 29, 2019): ## LFS - [x] We need some way of managing LFS files in a repository - at present they're totally opaque #7199 is an attempt to provide this - but to be efficient likely needs... - [ ] Bloom filter for blob lookup - it would be very good to have some slightly efficient way of finding the commit and at what tree path that introduced a blob - [ ] At present there is no reliable way of restarting an upload to LFS - so very large uploads can repeatly fail. Implement tus.io as per #1723 - [x] We should provide an option to just use .gitattributes for determining if a file is an LFS pointer rather than just assuming that any file that looks like a pointer is a pointer. Although that is likely to make functionality in #7199 very difficult... - [ ] LFS files should be viewable in the diff view. ## Hardening ### Shutdown and the beginning of making Gitea really clusterable - [ ] We need to harden Gitea's response to shutdown. - [x] This means graceful shutdown of listening connections, particularly the inbuilt SSH - which currently could cause corruption of git repositories through abrupt shutdown. #7274 is a start of an attempt to fix this. - [ ] but also it means that notification like jobs need to be serializable - e.g. indexing queues should through on-disk or db queues, similarly mail queues, etc. We have some of this already but these queues don't gracefully shutdown. - [ ] As a corollary to the above, we should separate the action of indexing from searching. Graceful shutdown requires this in any case - but it's part of the step towards clustering. I'm not certain which architecture we should take but, there are multiple options - separate the indexer out to a separate process & have Gitea read-only the index, or export the whole indexing out. ### Diff and Reading data of arbitrary length in to memory - [ ] Diff code needs refactoring - it's fragile, reads the entire diff into memory and requires huge diffs to be parsed by the browser before the user can respond. This requires both UI and server changes - presumably an infinite scroll backed with Ajax is the correct technique for this. At present a sufficiently evil large diff could take down both server and browser. - [ ] Our diff architecture currently pollutes the base repository with pre-merged branches and objects. - [ ] In general we MUST stop just reading data of arbitrary length into memory. If there is a place where the browser might want this - we should limit what we read and then use either an infinite scroll technique or full link with browser rendering or rendered in a pipeline to ensure that it is not buffered entirely in memory. Even relatively new code still suffers from this problem. - [ ] (If we are running a git process which may return arbitrarily long data we should try to avoid reading all of it directly into a stdout buffer entirely but do more go-routine pipelines.) ### Merge - [ ] We must refactor merge to use the git index entirely as we currently do a sparse checkout for merging - basically because git merge will drop down to https://git-scm.com/docs/git-merge-one-file to handle non-fast-forward merges. This forces the creation of semi-arbitrary paths on the server - which are unnecessary and dependent on the charset/filesystem factors. It's not necessary to do this - we can do these merges with temporary files, hashing and adding to the index directly. ### Escaping and Repository locations - [ ] We must check everywhere for escaping. Legacy Gogs code was poorly escaped in general and has been responsible for multiple security issues. - [ ] The assumption that the username and repository names don't need escaping is forcing an architecture decision on us that we don't need. It didn't even protect us properly for git signatures hence #5774. - [ ] Although it's pleasant for users to have the underlying repository location match the filesystem location - e.g. `$GITEA_ROOT/owner/reponame` it's a bad architectural decision IMHO and leads to assumptions by users that our repositories can still be used by git on the server without further thought - THEY SHOULD NOT. We should move to `$GITEA_ROOT/repository-$ID`, possibly sharded. (Doing this would allow the removal of a lot of calls to `repo.MustOwner()` or `repo.GetOwner()`) - [ ] Once we move to the above and we're escaping everything properly we can then relax constraints on the usernames and repository names - although this would have to be carefully thought about to ensure that we do it in a way that doesn't allow faking through issues similar to #5774. - [x] We should enforce server git processes to have to run with a sufficient Gitea environment - there are repeated users who try to use Gitea's repositories on the server without going through Gitea so then complain that Gitea is not updated etc. #6961 is a necessary step to this and following the merging of this we simply change https://github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72 to enforce the setting of SSH_ORIGINAL_COMMAND or otherwise enforce that the rest of the standard environment is set. - [ ] We should be able to cope with NO_EXEC mounted repositories - and in fact we should probably recommend this. It's probably not actually difficult to do - simply change the `.git/config` or the central `.gitconfig` `core.hooksPath` variable and think about where we're going to place hooks otherwise. - [ ] We're basically storing lines of code directly in the database for comments - which doesn't work if the data being stored is not in UTF-8. This means that you simply cannot comment on a non-UTF8 code. ## API / SDK - [ ] It's crazy the amount of work that we have to do to build an API when we go to all the effort to have swagger. We should just autogenerate this from swagger, or autogenerate as much as possible as we can - [ ] We have no way testing a fixed API version against our development Gitea so we can't tell when we're making breaking changes. - [ ] We should be able to use an autogenerated API/SDK to create simple test harnesses ## Testing - [ ] We currently run our unit tests at TRACE level - this limits our ability to add proper trace to things. Since https://gitea.com/gitea/log/pulls/3 and if we backport into Gitea we can change this from our makefile. - [ ] Need more Unit tests and consider if some of the integration tests are actually unit and vice versa. e.g. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go - [ ] We need more integration tests that try to run through user stories. That is - A user logins, does X, then Y and Z happens. It's fine to test things in isolation eg. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go but that's not really integrated and it misses testing what the user experiences. I keep saying this but more tests should look like: https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go and https://github.com/go-gitea/gitea/blob/master/integrations/git_test.go which actually test whether a feature integrates correctly. - [x] Our testing regime takes too long - CI is taking 30-40 minutes to run at present! We should be running these in parallel. - [ ] There is no easy way to create migration tests. ## Go Package Architecture ### Models - [ ] `code.gitea.io/gitea/models` depends on way too many things this has to stop. - [ ] `models.x` must be destroyed. It's a terrible architectural decision. - [ ] For too many of the models it's way too easy to cause a nil pointer dereference because you don't know what state it is in. Can we use go's typing system a bit better here? - [x] We should just stick OwnerName in the repository table as every time we get a repository we then have to go and get the Owner. It's silly and a waste of time. Repositories don't change owner very often so the cost of having to handle that is not major. - [ ] Too many things are still done in models and more should be moved out. - [ ] It may make sense to split models into core and non-core. ### Modules - [x] There are essentially two type of modules: those that depend on models and those that models depend on. Let's separate these, one could be called services. ### Macaron - [x] I think we should take seriously the move to ~~gin~~chi proposed by @lunny - [x] Our codebase is splattered with dependencies on macaron this should not be the case ### Setting - [x] Depends on macaron too(!) - [ ] Is tightly linked to go-ini, another dependency we should consider disconnecting ourselves from. ## Internationalisation - [ ] EMail not internationalised - [ ] Git messages not internationalised - [ ] Error messages not internationalised - [ ] We should automate stripping out our hugo website documentation so it can be internationalised with CrowdIn - [ ] It's weird that we have the languages using lowercase forms e.g. français, español in the language selector lists - this represents the start of a sentence in each of those languages so AFAICS they should be capitalised. Oui, si j'écris en français j'écris "français", mais si j'écris une liste á puces, j'écris: * English * Français * Español --- ### Gitea Dump & Restore - [ ] Gitea dump is broken for converting between SQL variants - [ ] We have no restore command

GiteaMirror commented

@sapk commented on GitHub (Jun 29, 2019):

On the UI part, I would suggest to deliver two UI :

one plain HTML (similar to the currentone without js)
a full JS which rely only on API call. This would force to rethink few API but it will also allow more interaction from other external app.

@sapk commented on GitHub (Jun 29, 2019): On the UI part, I would suggest to deliver two UI : - one plain HTML (similar to the currentone without js) - a full JS which rely only on API call. This would force to rethink few API but it will also allow more interaction from other external app.

GiteaMirror commented

@tboerger commented on GitHub (Jun 29, 2019):

think we should take seriously the move to gin proposed by @lunny

I would suggest go-chi instead of gin.

We should automate stripping out our hugo website documentation so it can be internationalised with CrowdIn

IMHO the website/docs should not be translated at all, it's anyway always outdated...

@tboerger commented on GitHub (Jun 29, 2019): > * think we should take seriously the move to gin proposed by @lunny I would suggest go-chi instead of gin. > * We should automate stripping out our hugo website documentation so it can be internationalised with CrowdIn IMHO the website/docs should not be translated at all, it's anyway always outdated...

GiteaMirror commented

@kolaente commented on GitHub (Jun 30, 2019):

IMHO the website/docs should not be translated at all, it's anyway always outdated...

But with crowdin, it being outdated would notify people and invalidate the current translations.

@kolaente commented on GitHub (Jun 30, 2019): > IMHO the website/docs should not be translated at all, it's anyway always outdated... But with crowdin, it being outdated would notify people and invalidate the current translations.

GiteaMirror commented

@jtl999 commented on GitHub (Jul 19, 2019):

Would it be possible add proper OS packages to the build process? I

Perhaps PPA style packages controlled and versioned by the GItea developers would be a good idea, but I'm not a fan of Debian-style "freeze and backport security patches" way of versioning for fast moving projects (such as GItea)

@jtl999 commented on GitHub (Jul 19, 2019): > Would it be possible add proper OS packages to the build process? I Perhaps PPA style packages controlled and versioned by the GItea developers would be a good idea, but I'm not a fan of Debian-style "freeze and backport security patches" way of versioning for fast moving projects (such as GItea)

GiteaMirror commented

@typeless commented on GitHub (Jul 24, 2019):

I'd still like to have https://github.com/go-gitea/gitea/issues/3840.
I think it can be implemented with backward-compatibility.
But this will become clear only after the migration of the new routing lib is settled down.
A prerequisite foundational cleanup/refactor would make it easier too.

@typeless commented on GitHub (Jul 24, 2019): I'd still like to have https://github.com/go-gitea/gitea/issues/3840. I think it can be implemented with backward-compatibility. But this will become clear only after the migration of the new routing lib is settled down. A prerequisite foundational cleanup/refactor would make it easier too.

GiteaMirror commented

@tboerger commented on GitHub (Jul 24, 2019):

I'd still like to have #3840.
I think it can be implemented with backward-compatibility.
But this will become clear only after the migration of the new routing lib is settled down.
A prerequisite foundational cleanup/refactor would make it easier too.

In that case it's possible that you will loose Drone support, as it's currently also not implemented for Gitlab.

@tboerger commented on GitHub (Jul 24, 2019): > I'd still like to have #3840. > I think it can be implemented with backward-compatibility. > But this will become clear only after the migration of the new routing lib is settled down. > A prerequisite foundational cleanup/refactor would make it easier too. In that case it's possible that you will loose Drone support, as it's currently also not implemented for Gitlab.

GiteaMirror commented

@lafriks commented on GitHub (Jul 24, 2019):

I'd still like to have #3840.
I think it can be implemented with backward-compatibility.
But this will become clear only after the migration of the new routing lib is settled down.
A prerequisite foundational cleanup/refactor would make it easier too.

We probably don't need this group feature to affect repository urls, we could just make folders that repository could be palced into display but keep repo urls same as it is now

@lafriks commented on GitHub (Jul 24, 2019): > I'd still like to have #3840. > I think it can be implemented with backward-compatibility. > But this will become clear only after the migration of the new routing lib is settled down. > A prerequisite foundational cleanup/refactor would make it easier too. We probably don't need this group feature to affect repository urls, we could just make folders that repository could be palced into display but keep repo urls same as it is now

GiteaMirror commented

@typeless commented on GitHub (Jul 25, 2019):

@tboerger
My thought was the URL can remain the same if a repo does not nested in a group/directory.
The URLs need to be "upgraded" only if the repo uses the group/directory feature.
But yes, the repos with the new URLs probably couldn't have Drone support out of the box.

@lafriks
That sounds like a good idea. My use scenario of the feature is to host Git modules or the subprojects of Repo projects. So, I am not sure it covers that case.

No worries. I am reluctant to make such an extensive, and possibly breaking, change too.

@typeless commented on GitHub (Jul 25, 2019): @tboerger My thought was the URL can remain the same if a repo does not nested in a group/directory. The URLs need to be "upgraded" only if the repo uses the group/directory feature. But yes, the repos with the new URLs probably couldn't have Drone support out of the box. @lafriks That sounds like a good idea. My use scenario of the feature is to host Git modules or the subprojects of Repo projects. So, I am not sure it covers that case. No worries. I am reluctant to make such an extensive, and possibly breaking, change too.

GiteaMirror commented

@DblK commented on GitHub (Jul 25, 2019):

This issue has a lot a good idea and we should keep them and address them.
However, when and how we should choose? This discussion can go on forever.

I would suggest either the owner pick the subjects or a vote between them and members.
What do you think?

@DblK commented on GitHub (Jul 25, 2019): This issue has a lot a good idea and we should keep them and address them. However, when and how we should choose? This discussion can go on forever. I would suggest either the owner pick the subjects or a vote between them and members. What do you think?

GiteaMirror commented

@lunny commented on GitHub (Jul 25, 2019):

@DblK That's right. But I think we could do that after we migrated to gitea.com. Currently we need more feedback from users.

@lunny commented on GitHub (Jul 25, 2019): @DblK That's right. But I think we could do that after we migrated to gitea.com. Currently we need more feedback from users.

GiteaMirror commented

@slavus commented on GitHub (Jul 26, 2019):

Mercurial support
better sorting and filtering for PR and issues

@slavus commented on GitHub (Jul 26, 2019): - Mercurial support - better sorting and filtering for PR and issues

GiteaMirror commented

@strk commented on GitHub (Jul 26, 2019):

Mercurial support

No please. It's called "git"ea for a reason.
I understand the desire to have wider scope but
bloat is around the corner...

@strk commented on GitHub (Jul 26, 2019): > - Mercurial support No please. It's called "git"ea for a reason. I understand the desire to have wider scope but bloat is around the corner...

GiteaMirror commented

@Perflyst commented on GitHub (Jul 26, 2019):

mercurial import would be an alternative

On July 26, 2019 1:52:50 PM UTC, Sandro Santilli notifications@github.com wrote:

Mercurial support

No please. It's called "git"ea for a reason.
I understand the desire to have wider scope but
bloat is around the corner...

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/go-gitea/gitea/issues/6998#issuecomment-515461704

@Perflyst commented on GitHub (Jul 26, 2019): mercurial import would be an alternative On July 26, 2019 1:52:50 PM UTC, Sandro Santilli <notifications@github.com> wrote: >> - Mercurial support > >No please. It's called "git"ea for a reason. >I understand the desire to have wider scope but >bloat is around the corner... > > >-- >You are receiving this because you commented. >Reply to this email directly or view it on GitHub: >https://github.com/go-gitea/gitea/issues/6998#issuecomment-515461704

GiteaMirror commented

@mxmehl commented on GitHub (Jul 27, 2019):

Federated pull requests / issues / forks

Maybe not federated in the Fediverse sense of the word (ActivityPub, OStatus, diaspora*, etc.) but I would like the ability to interact with remote instances from one's own implemented in whatever way fits the project best.

There already is some discussion about this in #1612. ForgeFed collects some interesting ideas to get federation into code forges like Gitea. It would be awesome if this would be the next big feature of Gitea!

@mxmehl commented on GitHub (Jul 27, 2019): >> Federated pull requests / issues / forks > > Maybe not federated in the Fediverse sense of the word (ActivityPub, OStatus, diaspora*, etc.) but I would like the ability to interact with remote instances from one's own implemented in whatever way fits the project best. There already is some discussion about this in #1612. ForgeFed collects some interesting ideas to get federation into code forges like Gitea. It would be awesome if this would be the next big feature of Gitea!

GiteaMirror commented

@arthur-bauer commented on GitHub (Jul 30, 2019):

I'd love a visual diff tool for graphic files (JPEG, PNG, but also PDF), similar to what Github offers.

@arthur-bauer commented on GitHub (Jul 30, 2019): I'd love a visual diff tool for graphic files (JPEG, PNG, but also PDF), similar to what [Github offers](https://help.github.com/en/articles/rendering-and-diffing-images).

GiteaMirror commented

@lunny commented on GitHub (Jul 30, 2019):

We have already a PR to diff images

@lunny commented on GitHub (Jul 30, 2019): We have already a PR to diff images

GiteaMirror commented

@arthur-bauer commented on GitHub (Jul 30, 2019):

We have already a PR to diff images

True, but that doesn't cover swipe or onion skin preview, only side-by-side. In addition, I don't think it covers PDF files. We're using Gitea here for development of graphic material (including manuals and brochures), and a good visual diff for PDFs would be a life changer.

@arthur-bauer commented on GitHub (Jul 30, 2019): > We have already a PR to diff images True, but that doesn't cover swipe or onion skin preview, only side-by-side. In addition, I don't think it covers PDF files. We're using Gitea here for development of graphic material (including manuals and brochures), and a good visual diff for PDFs would be a life changer.

GiteaMirror commented

@tamalsaha commented on GitHub (Jul 30, 2019):

I have some ideas that I just want to throw out there 😸

Use Cloud KSM to transparently encrypt/descrypt any secret. This will protect against DB hacked and exposed. The idea is that we can use a custom type with XORM encoding/decoding methods to encrypt the secret data before writing to DB. We made a demo example here: https://github.com/gomodules/ksm-xorm
OIDC Support: Return id_token in addition to oauth2 token when logged in via Gitea
Gitea user profile can show user's profile across any verified Git repo. Example: user can pin Github/Gitlab/BitBuket/Gitea repos. The idea is that users can't ignore the other ones either. So, can gitea be the one global user profile?
Custom domain support for repos (go)
Full compat with Github (I have seen some work on this front, I don't know how much is already done.)
Optional Language server integration. Something like Sourcegraph like navigation built into the UI.

I would like to contribute towards 1 & 2 in short order.

@tamalsaha commented on GitHub (Jul 30, 2019): I have some ideas that I just want to throw out there :smile_cat: 1. Use Cloud KSM to transparently encrypt/descrypt any secret. This will protect against DB hacked and exposed. The idea is that we can use a custom type with XORM encoding/decoding methods to encrypt the secret data before writing to DB. We made a demo example here: https://github.com/gomodules/ksm-xorm 2. OIDC Support: Return id_token in addition to oauth2 token when logged in via Gitea 3. Gitea user profile can show user's profile across any verified Git repo. Example: user can pin Github/Gitlab/BitBuket/Gitea repos. The idea is that users can't ignore the other ones either. So, can gitea be the one global user profile? 4. Custom domain support for repos (go) 5. Full compat with Github (I have seen some work on this front, I don't know how much is already done.) 6. Optional Language server integration. Something like Sourcegraph like navigation built into the UI. I would like to contribute towards 1 & 2 in short order.

GiteaMirror commented

@ajaskiewiczpl commented on GitHub (Aug 1, 2019):

Maybe we can show diff in a form of tree of folders and files that have changed - like in BitBucket, instead of one huge page with all the changes in it. It would be much, much more readable.

@ajaskiewiczpl commented on GitHub (Aug 1, 2019): Maybe we can show diff in a form of tree of folders and files that have changed - like in BitBucket, instead of one huge page with all the changes in it. It would be much, much more readable.

GiteaMirror commented

@triantium commented on GitHub (Aug 2, 2019):

Maybe an Option to aggregrate Notifications on all Repositories per day or per week.
Kind of like a summary of last weeks Activities.

@triantium commented on GitHub (Aug 2, 2019): Maybe an Option to aggregrate Notifications on all Repositories per day or per week. Kind of like a summary of last weeks Activities.

GiteaMirror commented

@titou10titou10 commented on GitHub (Aug 4, 2019):

Add the possibility to define custom webhooks via custom templates and a pool of standard variables.

@titou10titou10 commented on GitHub (Aug 4, 2019): Add the possibility to define custom webhooks via custom templates and a pool of standard variables.

GiteaMirror commented

@sapk commented on GitHub (Aug 14, 2019):

Not a Gitea evolution but a side project that would be usefull : #7853

@sapk commented on GitHub (Aug 14, 2019): Not a Gitea evolution but a side project that would be usefull : #7853

GiteaMirror commented

@lonix1 commented on GitHub (Aug 16, 2019):

Feature parity with github!

Or, at the very least, an up-to-date list on the wiki, which shows all those features we still need before we achieve parity. This would be a good way to structure future development efforts.

@lonix1 commented on GitHub (Aug 16, 2019): Feature parity with github! Or, at the very least, an up-to-date list on the wiki, which shows all those features we still need before we achieve parity. This would be a good way to structure future development efforts.

GiteaMirror commented

@kolaente commented on GitHub (Aug 17, 2019):

@lonix1 take a look at https://docs.gitea.io/en-us/comparison/ for that list

@kolaente commented on GitHub (Aug 17, 2019): @lonix1 take a look at https://docs.gitea.io/en-us/comparison/ for that list

GiteaMirror commented

@lonix1 commented on GitHub (Aug 17, 2019):

@kolaente looks like we have almost all the tick marks! yeah!

@lonix1 commented on GitHub (Aug 17, 2019): @kolaente looks like we have almost all the tick marks! yeah!

GiteaMirror commented

@crueber commented on GitHub (Aug 28, 2019):

I am very new here, but a willing coder too; I would love it if gitea supported gists. That's one of the biggest holes for my usage. Easily enough worked around, but I'd rather just have a gist system in place.

@crueber commented on GitHub (Aug 28, 2019): I am very new here, but a willing coder too; I would love it if gitea supported gists. That's one of the biggest holes for my usage. Easily enough worked around, but I'd rather just have a gist system in place.

GiteaMirror commented

@Mikaela commented on GitHub (Aug 28, 2019):

I think the issue for gists would be https://github.com/go-gitea/gitea/issues/693 (linking as it doesn't seem to be referenced from here yet).

@Mikaela commented on GitHub (Aug 28, 2019): I think the issue for gists would be https://github.com/go-gitea/gitea/issues/693 (linking as it doesn't seem to be referenced from here yet).

GiteaMirror commented

@bagasme commented on GitHub (Sep 26, 2019):

Add also Help documentation, which can be accessed by Help link. The initial source for this documentation can be from GitHub Help, with Gitea-specific modifications.

@bagasme commented on GitHub (Sep 26, 2019): Add also `Help` documentation, which can be accessed by `Help` link. The initial source for this documentation can be from [GitHub Help](https://help.github.com), with Gitea-specific modifications.

GiteaMirror commented

@lafriks commented on GitHub (Sep 26, 2019):

@bagasme help can not be taken from github, that would be copyright violation. Someone will have to write Gitea help from zero

@lafriks commented on GitHub (Sep 26, 2019): @bagasme help can not be taken from github, that would be copyright violation. Someone will have to write Gitea help from zero

GiteaMirror commented

@brandonkal commented on GitHub (Oct 15, 2019):

Creation of issues via email (see GitLab service desk).

If more people start adopting self-hosting for sharing their open-source projects, there needs to be a way for non-registered users to submit issues without having to create an account on each instance (most people are extremely unlikely to register for a bug report).

Something akin to GitLab's AutoDevOps. This means the ability to define a default CI job when no CI yaml file is in the repository.

2a. Container registry UI tab and auth.

Bots
GPG for web commits
Ability to block merges based on conditions
Ability to create file in web UI (including in a blank bare repo)
Manage snippets attached to repo via the UI (see GitLab)
Git protocol v2 support
Improved Web IDE option
Kubernetes integration (via UI plugin a la GitLab)
Add a 400ms delay before a tooltip is displayed on hover
Better CI integration (show pipelines, Concourse support, etc)
Refine UI
Enforce 2FA
File locking
Auto close linked issues with PR merge.

@brandonkal commented on GitHub (Oct 15, 2019): 1. Creation of issues via email (see GitLab service desk). If more people start adopting self-hosting for sharing their open-source projects, there needs to be a way for non-registered users to submit issues without having to create an account on each instance (most people are extremely unlikely to register for a bug report). 2. Something akin to GitLab's AutoDevOps. This means the ability to define a default CI job when no CI yaml file is in the repository. 2a. Container registry UI tab and auth. 3. Bots 4. GPG for web commits 5. Ability to block merges based on conditions 6. Ability to create file in web UI (including in a blank bare repo) 7. Manage snippets attached to repo via the UI (see GitLab) 8. Git protocol v2 support 9. Improved Web IDE option 10. Kubernetes integration (via UI plugin a la GitLab) 11. Add a 400ms delay before a tooltip is displayed on hover 12. Better CI integration (show pipelines, Concourse support, etc) 13. Refine UI 14. Enforce 2FA 15. File locking 16. Auto close linked issues with PR merge.

GiteaMirror commented

@lonix1 commented on GitHub (Oct 15, 2019):

Some kind of plugin / extension system.

Most of the suggestions are good, but they'll create problems in the core codebase.

It would be best to have official (and unofficial) plugins. This would also mean that plugin authors could release more frequently.

@lonix1 commented on GitHub (Oct 15, 2019): Some kind of plugin / extension system. Most of the suggestions are good, but they'll create problems in the core codebase. It would be best to have official (and unofficial) plugins. This would also mean that plugin authors could release more frequently.

GiteaMirror commented

@guillep2k commented on GitHub (Oct 15, 2019):

@lonix1 Well, git hooks, webhooks and the Swagger API can be considered plugin connect points. I'm all for more plugin support, but stating a list with specifics could help. For example, I'd like support for a command-line equivalent of webhooks.

@guillep2k commented on GitHub (Oct 15, 2019): @lonix1 Well, git hooks, webhooks and the Swagger API can be considered plugin connect points. I'm all for more plugin support, but stating a list with specifics could help. For example, I'd like support for a command-line equivalent of webhooks.

GiteaMirror commented

@lonix1 commented on GitHub (Oct 16, 2019):

@guillep2k For example all the project management features discussed above. Those would be very useful - but they probably touch so many parts of the codebase that 1) they might cause issues even for those who don't use those features, and 2) because of that, such development is very slow because those responsible for merging new features know that this scenario is possible, so they are cautious.

If these new features could be released separately, they could be tried by willing users before being merged into the main branch.

And there are other examples of these sort of big new features, just scroll up.

@lonix1 commented on GitHub (Oct 16, 2019): @guillep2k For example all the project management features discussed above. Those would be very useful - but they probably touch so many parts of the codebase that 1) they might cause issues even for those who don't use those features, and 2) because of that, such development is very slow because those responsible for merging new features know that this scenario is possible, so they are cautious. If these new features could be released separately, they could be tried by willing users before being merged into the main branch. And there are other examples of these sort of big new features, just scroll up.

GiteaMirror commented

@zeripath commented on GitHub (Oct 16, 2019):

@brandonkal GPG signing of auto generated commits is now possible with the merging of #7631

@zeripath commented on GitHub (Oct 16, 2019): @brandonkal GPG signing of auto generated commits is now possible with the merging of #7631

GiteaMirror commented

@alexanderadam commented on GitHub (Oct 18, 2019):

I guess the roadmap should be divided into those four categories (I added some example issues — it should be obvious that it's far from complete 😉):

Basic functionality

There are still some basic functions that aren't working properly.
For instance:

it still needs a good search solution as mentioned in issues like #5694 #5277 #3448, #2967, #2434, #8366, #8386 and always running processes from 1.14.5=>1.15.2 (#7825)
the PDF viewer is broken
the SVG viewer is broken
it seems that there are non-free dependencies used

Security

There are also some security issues:

the Docker image still runs as root although the Docker guide is very clear about it and there's no reason in using the root user (you can remap ports on the outside anyway)
enforcing 2FA is still not possible
Enable the setting of stricter CSP headers by removing inline styles
there's no check whether someone is allowed to access attachments

Integration

I guess integration with other applications/services are a good thing in general.
Because software development usually don't just rely on a single tool.
And it will probably help to convince some folk to use Gitea in their workplace.

Those two issues would improve interoperability a lot:

automatically integrate Drone CI/CD (like @BNolet proposed earlier)
API integration for automated PR reviews through tools like Pronto
easy integration with a Container Registry
a generic webhook solution that allows users to setup custom webhooks easily (like proposed by @bkcsoft earlier)

Also generic webhooks would avoid the need of having other people knowing the internals of gitea. @guillep2k had a wonderful idea that an "external command" integration could be done similar to the generic webhook integration.
⚠️ This would probably solve most of the problems on what most people in this issue want as 'plugin support'. Because that would enable to call whatever users need to call. However, @lunny just mentioned that this is practically already possible via git hooks. I'm just not quite sure whether this really is the best way to integrate other tools/plugins/services.

On-top-features

Furthermore there are obviously some nice features in competing applications (i.e. Git[Hub/Lab]) (most of them are probably rather nice to have):

Revert PRs
Improved diff for non-textual things as mentioned by @arthur-bauer
edits from maintainers
Confidential issues
show more repository details (i.e. repository size, contributors graph, languages bar)
some wiki improvements (#823 #574)
having a diff like BitBucket as mentioned by @SignumPL (i didn't know that before but it looks indeed useful)
integrate a functionality like Octotree

@alexanderadam commented on GitHub (Oct 18, 2019): I guess the roadmap should be divided into those four categories (I added some example issues — it should be obvious that it's far from complete :wink:): ### Basic functionality There are still some _basic functions_ that aren't working properly. For instance: * it still needs a good search solution as mentioned in issues like #5694 #5277 #3448, #2967, #2434, #8366, #8386 and #7825 * [the PDF viewer is broken](https://github.com/go-gitea/gitea/issues/8294) * [the SVG viewer is broken](https://github.com/go-gitea/gitea/issues/1095) * [it seems that there are non-free dependencies used](https://github.com/go-gitea/gitea/issues/8575) ### Security There are also some security issues: * [x] [the Docker image still runs as root](https://github.com/go-gitea/gitea/issues/1190) although [the Docker guide is very clear about it](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user) and there's no reason in using the `root` user (you can remap ports on the outside anyway) * [ ] [enforcing 2FA is still not possible](https://github.com/go-gitea/gitea/issues/880) * [ ] [Enable the setting of stricter CSP headers by removing inline styles](https://github.com/go-gitea/gitea/issues/305) * [x] [there's no check whether someone is allowed to access attachments](https://github.com/go-gitea/gitea/issues/7908) ### Integration I guess integration with other applications/services are a good thing in general. Because software development usually don't just rely on a single tool. And it will probably help to convince some folk to use Gitea in their workplace. Those two issues would improve interoperability a lot: * [ ] automatically integrate Drone CI/CD ([like @BNolet proposed earlier](https://github.com/go-gitea/gitea/issues/6998#issuecomment-496013605)) * [x] [API integration for automated PR reviews](https://github.com/go-gitea/gitea/issues/5733) through tools like [Pronto](https://github.com/prontolabs/pronto#pronto) * [x] [easy integration with a Container Registry](https://github.com/go-gitea/gitea/issues/2316) * [ ] a generic webhook solution that allows users to setup custom webhooks easily ([like proposed by @bkcsoft earlier](https://github.com/go-gitea/gitea/issues/1089)) Also generic webhooks would avoid the need of having other people knowing the internals of gitea. [@guillep2k had a wonderful idea that an "external command" integration could be done similar to the generic webhook integration](https://github.com/go-gitea/gitea/issues/1089#issuecomment-536006866). :warning: **This would probably solve most of the problems on what most people in this issue want as 'plugin support'**. Because that would enable to call whatever users need to call. However, @lunny just mentioned that this is practically already possible via git hooks. I'm just not quite sure whether this really is the best way to integrate other tools/plugins/services. ### On-top-features Furthermore there are obviously some nice features [in competing applications (i.e. Git[Hub/Lab])](https://github.com/go-gitea/gitea/issues/6998#issuecomment-522128044) (most of them are probably rather nice to have): * [ ] [Revert PRs](https://github.com/go-gitea/gitea/issues/6375) * [ ] [Improved diff for non-textual things as mentioned by @arthur-bauer](https://github.com/go-gitea/gitea/issues/6998#issuecomment-516325459) * [x] [edits from maintainers](https://github.com/go-gitea/gitea/issues/717) * [ ] [Confidential issues](https://github.com/go-gitea/gitea/issues/3217) * [ ] show more repository details (i.e. [repository size](https://github.com/go-gitea/gitea/issues/7796), [contributors graph](https://github.com/go-gitea/gitea/issues/847), [languages bar](https://github.com/go-gitea/gitea/issues/2165)) * [ ] some wiki improvements (#823 #574) * [ ] [having a diff like BitBucket as mentioned by @SignumPL](https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615) (i didn't know that before but [it looks indeed useful](https://chrome.google.com/webstore/detail/bitbucket-diff-tree/pgpjdkejablgneeocagbncanfihkebpf)) * [ ] [integrate a functionality like Octotree](https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388)

GiteaMirror commented

@DemiusAcademius commented on GitHub (Oct 24, 2019):

May be use Oracle Database as option? If it possible technically.

@DemiusAcademius commented on GitHub (Oct 24, 2019): May be use Oracle Database as option? If it possible technically.

GiteaMirror commented

@lunny commented on GitHub (Oct 24, 2019):

@DemiusAcademius If xorm supports oracle better, I think that's possbile.

@lunny commented on GitHub (Oct 24, 2019): @DemiusAcademius If xorm supports oracle better, I think that's possbile.

GiteaMirror commented

@mxmehl commented on GitHub (Oct 24, 2019):

More and more people are starting to use Gitea, e.g. also caused by the recent GitLab tracker announcement. But GitHub/GitLab still have the network effect on their side.

Federation would be a big driver to improve the ability to collaborate between users of different Gitea instances and thereby increase the whole Gitea network: #1612

@mxmehl commented on GitHub (Oct 24, 2019): More and more people are starting to use Gitea, e.g. also caused by the recent GitLab tracker announcement. But GitHub/GitLab still have the network effect on their side. Federation would be a big driver to improve the ability to collaborate between users of different Gitea instances and thereby increase the whole Gitea network: #1612

GiteaMirror commented

@strk commented on GitHub (Oct 25, 2019):

Ability to show large diffs in the UI was reported to be a limiting factor in the adoption of Gitea.
Tickets addressing it: #7341 (feature), #7495 (crasher bug)

@strk commented on GitHub (Oct 25, 2019): Ability to show large diffs in the UI was reported to be a limiting factor in the adoption of Gitea. Tickets addressing it: #7341 (feature), #7495 (crasher bug)

GiteaMirror commented

@Be-ing commented on GitHub (Nov 4, 2019):

Ability to show large diffs in the UI was reported to be a limiting factor in the adoption of Gitea.
Tickets addressing it: #7341 (feature), #7495 (crasher bug)

That's a huge limitation. IMO everything @alexanderadam listed above pales in comparison to this. If I can't review large diffs by commenting inline in the code, that's a big problem.

@Be-ing commented on GitHub (Nov 4, 2019): > Ability to show large diffs in the UI was reported to be a limiting factor in the adoption of Gitea. > Tickets addressing it: #7341 (feature), #7495 (crasher bug) That's a _huge_ limitation. IMO everything @alexanderadam listed [above](https://github.com/go-gitea/gitea/issues/6998#issuecomment-543582502) pales in comparison to this. If I can't review large diffs by commenting inline in the code, that's a big problem.

GiteaMirror commented

@OKNoah commented on GitHub (Nov 4, 2019):

W/R/T the anger at Microsoft and Github that caused many projects to migrate and caused high demand for federation--Gitlab has recently proposed banning employees in China and Russia, 2 of the world's largest countries by land mass and economy. The US military has shifted focus to China and Russia (among others) to weaken the barriers they pose to US imperial expansion/interests. Propaganda and financial incentives have brought Microsoft (Github, Azure), Amazon, Google, Atlassian (Trello, Jira) and even Gitlab into the industries of war, espionage, propaganda and surveillance in an offensive role.

I bring this up to give my thanks to those working on highly available open source remote repositories with few short-comings to the corporate and Pentagon-linked services we use and still rely on now--and to bring to your attention that quickly alternatives are disappearing for those who wish to use the Internet and technology as far away from history's most powerful and hostile empire.

Perhaps the topic is big enough for a separate section of the official website to track progress on this feature, along with a separate fund-raising campaign to capture this demand. Including ForgeFed in the fundraising may be beneficial and fair, seeing their work so far. It's been 17 months to the day since Microsoft bout Github, and I hope in another 17 moths we can be using federated Gitea, or have remaining parts of the 'net worth building on.

@OKNoah commented on GitHub (Nov 4, 2019): W/R/T the anger at Microsoft and Github that caused many projects to migrate and caused high demand for federation--Gitlab has recently proposed banning employees in China and Russia, 2 of the world's largest countries by land mass and economy. The US military has shifted focus to China and Russia (among others) to weaken the barriers they pose to US imperial expansion/interests. Propaganda and financial incentives have brought Microsoft (Github, Azure), Amazon, Google, Atlassian (Trello, Jira) and even Gitlab into the industries of war, espionage, propaganda and surveillance in an offensive role. I bring this up to give my thanks to those working on highly available open source remote repositories with few short-comings to the corporate and Pentagon-linked services we use and still rely on now--and to bring to your attention that quickly alternatives are disappearing for those who wish to use the Internet and technology as far away from history's most powerful and hostile empire. Perhaps the topic is big enough for a separate section of the official website to track progress on this feature, along with a separate fund-raising campaign to capture this demand. Including ForgeFed in the fundraising may be beneficial and fair, seeing their work so far. It's been 17 months to the day since Microsoft bout Github, and I hope in another 17 moths we can be using federated Gitea, or have remaining parts of the 'net worth building on.

GiteaMirror commented

@lafriks commented on GitHub (Nov 4, 2019):

Please do not discuss politics here, let's keep to the subject - improving Gitea for everyone

@lafriks commented on GitHub (Nov 4, 2019): Please do not discuss politics here, let's keep to the subject - improving Gitea for everyone

GiteaMirror commented

@OKNoah commented on GitHub (Nov 5, 2019):

@lafriks Improving Gitea means defining a niche--something unmet by substitute goods. Marketing is the process of finding external opportunities, "political" being 1 of 4 main categories of marketing analysis. A wise brand appeals to people's values equally as much as they deliver features, specs and price. There is a values-based ("political") draw to alternatives like Gitea, and failing to underline and maintain it would be a failure to understand your consumer and the market opportunity.

"Political" as a term has become a thought-terminating cliché, extinguishing discussion of racism, violence and exploitation. I simply came here to thank folks for continuing work on alternatives not associated with US concentration camps, drag-net surveillance and other imperialists interests the majority of our industry is actively aiding in. If you're saying these are not qualities Gitea stands by, I got you wrong and I'll be leaving.

@OKNoah commented on GitHub (Nov 5, 2019): @lafriks Improving Gitea means defining a niche--something unmet by substitute goods. Marketing is the process of finding external opportunities, "political" being 1 of 4 main categories of marketing analysis. A wise brand appeals to people's _values_ equally as much as they deliver features, specs and price. There is a values-based ("political") draw to alternatives like Gitea, and failing to underline and maintain it would be a failure to understand your consumer and the market opportunity. "Political" as a term has become a thought-terminating cliché, extinguishing discussion of racism, violence and exploitation. I simply came here to thank folks for continuing work on alternatives not associated with US concentration camps, drag-net surveillance and other imperialists interests the majority of our industry is actively aiding in. If you're saying these are not qualities Gitea stands by, I got you wrong and I'll be leaving.

GiteaMirror commented

@brandonkal commented on GitHub (Nov 5, 2019):

Note to @OKNoah

Marketing 101 for an open-source project:

Don't bring up concentration camps
Don't mention politics
Lose the tinfoil hat
Don't use antique terms such as imperialism
Know your product's edge. Gitea's advantage is its simplicity.

If GitLab.com's transparency offends you, you can self-host GitLab-FOSS. It's an extremely good all-in-one product. But if you want a simple install or require lower memory usage compared to GitLab or GitHub Enterprise, Gitea is a good option for the basic web features.

This thread is about discussing features that can help close that gap without compromising on simplicity.

@brandonkal commented on GitHub (Nov 5, 2019): Note to @OKNoah Marketing 101 for an open-source project: 1. Don't bring up concentration camps 2. Don't mention politics 3. Lose the tinfoil hat 4. Don't use antique terms such as imperialism 5. Know your product's edge. Gitea's advantage is its simplicity. If GitLab.com's transparency offends you, you can self-host GitLab-FOSS. It's an extremely good all-in-one product. But if you want a simple install or require lower memory usage compared to GitLab or GitHub Enterprise, Gitea is a good option for the basic web features. This thread is about discussing features that can help close that gap without compromising on simplicity.

GiteaMirror commented

@XVilka commented on GitHub (Nov 5, 2019):

My 2 cents - I think this thread became too long, and it's time to open a new issue summarizing any ideas already expressed here. And close this one.

@XVilka commented on GitHub (Nov 5, 2019): My 2 cents - I think this thread became too long, and it's time to open a new issue summarizing any ideas already expressed here. And close this one.

GiteaMirror commented

@techknowlogick commented on GitHub (Nov 5, 2019):

If you're saying these are not qualities Gitea stands by, I got you wrong and I'll be leaving.

This is not what is being said. What is being said is that this thread is the place for discussing what changes/improvements to Gitea can be made (specifically technical ones). These discussions are more than welcome, but not in this specific thread.

As one of the leads I will be locking this thread, as @XVilka said it right, we have solicited a lot of feedback, and it should now be evaluated for next steps.

@techknowlogick commented on GitHub (Nov 5, 2019): > If you're saying these are not qualities Gitea stands by, I got you wrong and I'll be leaving. This is not what is being said. What is being said is that this thread is the place for discussing what changes/improvements to Gitea can be made (specifically technical ones). These discussions are more than welcome, but not in this specific thread. As one of the leads I will be locking this thread, as @XVilka said it right, we have solicited a lot of feedback, and it should now be evaluated for next steps.

GiteaMirror commented