Plan of Gitea v1.17

[zeripath]

Hi all Gitea contributors,

Gitea v1.16rc1 is now out! We have created the release/v1.16 branch and tagged v1.17.0-dev opening up main for 1.17 development. As mentioned in our CONTRIBUTION, it will spend three or four months before feature freeze.

I'm aware now is the time for the regular planning thread. Please use it to discuss your own plans for the 1.17 development cycle.

(Reminder, this thread is for things you PLAN TO DO YOURSELF, not things you want other people to do.)

Thanks,
zeripath

[zeripath]

Previous planning threads:

• Plan of Gitea v1.16 #16429
• Discussion of v1.15.x Roadmap #14477

[zeripath]

I guess I'll start with some of things I'd like to do:

Context Propagation + "Process" management

This is a series of refactors that will cause the request context to be passed down in called functions. Doing this allows newly created child contexts to be scoped to the request context - enabling process hierarchies to work, better logging, easier db functions, easier permissions checking and scoping. The first steps of this process was in #17125 and the DBContext work.

• Propagate context and ensure git commands run in request context #17868 - means that all git contexts will now be scoped to the request context.
• - Do the same for the DB functions
  • Use ctx instead of db.DefaultContext in some packages(routers/services/modules) #19163 by @wxiaoguang is a good initial start on this.
• - pass context into log calls to allow these to print the process ID (or even get the logger from the ctx...)
• - add gitea manager process or create admin API for process management
• - Once we have context propagation complete we can actually consider dropping the global dependence on setting.AppURL and setting.AppSubURL and make Gitea be possible to be hydra-headed.

Authentication/Authorization

We still need to continue work on the DB password authentication.

• - The DB password authentication things really need to be moved out user
• - I'd like to make it possible to enforce 2fa
• - I want to consider if users want to use their sec key as their method of login without a password

Then there are OAuth scoping and tokens:

• - OAuth Tokens scopable to github like permissions
  • With the context propagation above permissions checks could actually be performed a bit more clearly.
• - Deprecate the old Token scheme

We also need to make it possible to force logout of sessions for the current user - useful additionally for admin.

• - Refactor sessions infrastructure to account for this.

Dump/Restore

I think we should stop dumping to "SQL" - and instead dump to a SQLite db file. We should then be able to restore from this a lot easier!

Internal SSH Server

This is currently broken for modern ssh versions. See #17798 - we've gotta sort this out...

If the underlying library is not fixed by February I think I'm gonna have to consider forking this and fixing this 😢 (Unless someone else wants to do this?!)

Federation

This work stream will be discussed elsewhere

Misc

• Add option to purge users #18064 - this allows admins to purge a user and all of their repositories
• Add apply-patch, basic revert and cherry-pick functionality #17902
  • I think this work also shows the basics of how to approach resolve conflicts - but I'm not sure if I will get to this.
• Change initial TrustModel to committer #18335
• Pause queues #15928 - This also contains some protection against 0 worker/0 boost worker configurations.
• - I think the notifications UI could do with some work. It currently just shows all of the notifications but I think we should really be able to make it searchable etc. The problem is when I will be able to get to this.

Work with others

• Enable deprecation error for v1.17.0 #18341 - Adds more deprecation notices to the settings
• Refactor Router Logger #17308 - Contains a significant refactor for Wrap that means instead of performing reflection at routing time these are precalculated

That's probably enough to be getting on with however, I'd like to list some potential refactors that I'd like to consider:

Potential Refactors

• As mentioned above, context passing means we can consider "hydra" heading dropping the dependence on the global AppURL and instead get this set at the server level.
  • This would allow users to more easily mount gitea in two places and also reduce the problems from the ROOT_URL setting.
• Once we stop having global dependence on setting.AppURL we'll likely find that a lot of packages really only look at particular settings. If we implement configurable we can actually consider having packages do this themselves.
• I think we need to use more generation especially in the routers.
• I think we should either consider using the go-sdk in the (especially the API) integration tests or get swagger to generate an API.

[techknowlogick]

Placeholder for my plan, will edit this post as I have things to add.

Currently just maintenance tasks are on top of my head:

• Due to crowdin API deprecation, the cron task needs to be updated.
• With upcoming release of golang 1.18, we will need to build with that (update drone, docker, & xgo)

refactor:

• move some user columns to use user_settings table instead

features:

• labels for milestones

As mentioned above, federation tasks will be discussed elsewhere.

Also, general upkeep of our infra & coordination with sponsors

[silverwind]

• Start refactoring out jQuery with the help of https://github.com/dgraham/eslint-plugin-jquery
• Finish removal of icon fonts
• Finish removal of all color values in CSS in favor of variables

[lunny]

• Finish Add support to import repository data from an exported data of Github #18165 and finally move the Gitea repository itself to https://gitea.com/gitea/gitea.git
• More refactors backend code (models, modules, services) refactor context to add a BaseContext and reduce private context struct size #16455 Move project files into models/project sub package #17704
• Move git command as a standalone package so that it's easier to move the repositories to another machine #18147 So that we can move towards distributed git storage.
• Allow custom default merge message with .gitea/default_merge_message/<merge_style>_TEMPLATE.md #18177
• Never use /api/v1 from Gitea UI Pages #19318 & Remove dependent on session auth for api/v1 routers #19321 Make API & Web routes separately, then API should have a slight better performance and less memory usage.
• Add system setting table with cache and also add cache supports for user setting #18058 Move some configuration from app.ini to admin WebUI. At first those don't need to restart Gitea.
• Internal CI/CD which is similar as Github Actions and compatible with Github Actions configuration files.

[KN4CK3R]

• Finish Add Package Registry #16510
• Once the package registry is ready, finish the docker/container registry
• Work towards federation

[Gusted]

Bit late to the party.

• Get Adding private issues functionality #17711 merged
• Do some more security stuff (unintentionally vague)
• Improve QoL of Gitea, with little quirks that other Git services have.

[richmahn]

Still in great need of a UI for conflict resolving #9014. I said 1.5 years ago I would work on this...still seeking to find the time, hopefully for 1.17.

[delvh]

• Getting Allow to mark files in a PR as viewed #19007 merged.

[more-pepsi]

• Start refactoring out jQuery with the help of https://github.com/dgraham/eslint-plugin-jquery
• Finish removal of icon fonts
• Finish removal of all color values in CSS in favor of variables

I'm looking for some starter tasks if you want to pas some tasks on. I"m a JavaScript expert, but a little rusty with frameworks, its been years. So i'll just follow your lead.

[silverwind]

• Start refactoring out jQuery with the help of https://github.com/dgraham/eslint-plugin-jquery
• Finish removal of icon fonts
• Finish removal of all color values in CSS in favor of variables

I'm looking for some starter tasks if you want to pas some tasks on. I"m a JavaScript expert, but a little rusty with frameworks, its been years. So i'll just follow your lead.

Feel free to have a look at integrating https://github.com/dgraham/eslint-plugin-jquery with a few starter rules. I think no-ajax is a prime candidate where we can replace AJAX calls with native fetch. There will be many such AJAX cases in the code, so getting this rule alone to work will already be quite an extensive task.

Other starter candidates might be rules that only trigger a few errors in the code, those should be easy to refactor to native DOM usage.

[wxiaoguang]

There are some work for refactoring:

1. replace all .data('xxx') by .attr('data-xxx') for static HTML data attributes data-xxx="...", it makes the developers easier to find the data-xxx usages. Dynamic .data('yyy', val) might be kept at the moment.
2. clean legacy / incorrect CSS styles. eg, the polluted .ui .left

[6543]

1. The initial RSS support is already done 🎉 '( RSS/Atom support for Repos #19055, RSS/Atom support for Orgs #17714 )
2. Now I'm focusing on Auto merge pull requests when all checks succeeded via API #9307