Discussion of Gitea roadmap

[lunny]

@go-gitea/maintainers

After #1029 closed, I think we should make a new plan about next big step. Any idea about that?

[sapk]

A plugin (including theme) solution for extending gitea.

[ghost]

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.

[xor-gate]

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.

[BNolet]

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.

[Perflyst]

Federated pull requests / issues / forks

[Amolith]

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.

[strypey]

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)

[strk]

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

[sapk]

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

[tboerger]

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

[kolaente]

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

[Morlinest]

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

[tboerger]

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.

[lunny]

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.

[mrsdizzie]

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

[belliash]

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

[jonasfranz]

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

[zeripath]

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

[tboerger]

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.

[jonasfranz]

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

[tboerger]

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

[lunny]

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.

[strk]

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.

[lunny]

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

[small75]

Need mail template customization
See #6037

[zeripath]

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.

[small75]

Reverting a pull request needed.
See #6375

[SomeGeek]

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

[lonix1]

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.

[kolaente]

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

[lonix1]

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

[crueber]

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.

[Mikaela]

I think the issue for gists would be #693 (linking as it doesn't seem to be referenced from here yet).

[bagasme]

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.

[lafriks]

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

[brandonkal]

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.

[lonix1]

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.

[guillep2k]

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

[lonix1]

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

[zeripath]

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

[alexanderadam]

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 Repo indexer not searching some method names #5694 Search for text that includes underscore returns nothing #5277 Support stemming / partial matches / unicode normalizing in issue search #3448, Unable to search issues for part of a word. #2967, Global issues search #2434, Search index not updated when editing some fields #8366, Support search qualifiers  #8386 and Repo indexer multi-term search is broken #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 (Hierarchy (sub directory) in Wiki #823 Uploads on the wiki #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

[DemiusAcademius]

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

[lunny]

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

[mxmehl]

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

[strk]

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)

[Be-ing]

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.

[OKNoah]

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.

[lafriks]

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

[OKNoah]

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

[brandonkal]

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.

[XVilka]

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.

[techknowlogick]

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.

[sapk]

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

[lunny]

Close as we have a plan for every release.