Gitea: Discussion of Gitea roadmap

A plugin (including theme) solution for extending gitea.

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.

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.

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.

Federated pull requests / issues / forks

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.

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)

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

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

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

@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.

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 :)

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.

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 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.

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

@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 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)

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 Can you provide a example from drone's pluggable stuff? Do you mean the plugin system based on docker images?

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

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.

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.

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

Need mail template customization
See #6037

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.

Reverting a pull request needed.
See #6375

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

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.

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
• [ ] 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

• [ ] I think we should take seriously the move to gin 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

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.

• 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...

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.

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)

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.

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.

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

@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.

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 That's right. But I think we could do that after we migrated to gitea.com. Currently we need more feedback from users.

• Mercurial support
• better sorting and filtering for PR and issues

• 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...

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

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!

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

We have already a PR to diff images

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.

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.

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.

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

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

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

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 take a look at https://docs.gitea.io/en-us/comparison/ for that list

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

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.

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).

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 help can not be taken from github, that would be copyright violation. Someone will have to write Gitea help from zero

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).

1. 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.

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

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 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 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.

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

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
• 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](https://github.com/go-gitea/gitea/issues/1190) 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](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)
• [ ] [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)
• [ ] [API integration for automated PR reviews](https://github.com/go-gitea/gitea/issues/5733) through tools like Pronto
• [ ] [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)

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.
: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]) (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)
• [ ] [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, contributors graph, languages bar)
• [ ] 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)
• [ ] [integrate a functionality like Octotree](https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388)

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

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

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

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)

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.

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.

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

@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.

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.

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.

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.

We could change path to FHS compliance for v2. It is already possible with flags but it should be the default for v2.