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.

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.