Plan of Gitea v1.16

[lunny]

Hi all Gitea contributors,

Gitea 1.15rc1 will be out sooner (🎉!) and after that we will create a new branch for 1.16 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.16 development cycle.

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

Thanks, Lunny

[lunny]

I plan to finish some of my previous PRs at first,

• [ ] #16083
• [ ] #16052
• [ ] #15398
• [ ] #6918

And I also want to resolve the problems when migrating Gitea from Github to gitea.com .

If I have more time, I would like to try to support Github actions on Gitea.

[zeripath]

Authentication/Authorization refactors

models/login_source needs to be simplified and we need to make authentication and authorization a bit clearer.

• 16199 is the beginning of this and following on from this I intend to look at Oauth providers a bit to make adding additional ones a lot simpler. I suspect we can prevent the creation of these goth users etc.

• Following on from #16199 I think we should be able to make it possible to create and use OAuth tokens with restricted permissions. This would require a clearer idea of context and permissions but it's something we need to do.

• 16523 follows on from this and allows the sending of notification emails on autoregister.

• 16544 also follows on from this and adds support for Azure and other MS Oauth providers - in doing so providers have been slightly refactored.

• 16594

  • Following on from this I've extended this to LDAP, SMTP, and PAM sources.

  • 16954

  • 17078

• 16766

• 16851

This is likely to represent a large refactoring series with multiple PRs and will probably represent the bulk of the things.

(It's worth noting that although this may appear orthogonal to things like federation - this is key to making federation possible.)

• I should probably look at #16376 once the above PR is in. (This appears to be a configuration issue.)

Rendering repositories

• Now we pass a context in to get last commit we can give the last commit generator a deadline and make it return what it has found within that deadline. A simple solution would then refresh the page to find the missing entries but if we paged the repository viewer we could actually make things a lot quicker there too.

• 16432 adds paging to the directory rendering meaning repos with large directories get paged.

• 16467 represents a PR that will allow last commit generation to be aborted to render the page quicker.

• 16063 represents an alternative earlier idea using an unique queue to defer last commit generation. I think this isn't going to completely work but it's showing at least part of the idea. We may want to revisit the unique queue generation aspect though.

Diff generation

It's way past time we improve this.

My work on 1.15 was massively derailed by the git and go-git problems so this might actually finally pop to the top of the list again.

I've got three four PRs ready at this:

• 16775

• 16635

• 16773

• 16829

I have some code that will allow you to request specific files to be diffed but it's dependent on #16775.

Once #16773 is in I can add in support for linguist-language to diffs.

We then couple the per-file diff with #16773 and a small amount of other work and we get a way of avoiding creating diffs for vendored files etc.

Caching

Now we have a memory cache implementation (twoqueue) that is not unbounded in the number of objects it will and can store we can consider caching more things. A good candidate could be commit verification as the cache invalidation is predictable.

It's likely that the simplistic solution within twoqueue may need further optimization as people try it - but hopefully we'll be able to consider it ready to make it the default for 1.16. Another thing is that it may be helpful to consider having a two level cache.

Queues

• We still need to merge/consider the Pause Queues PR #15928. This is likely to be very important for users of things like elasticsearch which may stop or start.

Organization Remove/Leave Modals

• 16471 These unfortunately didn't get in to 1.15 but I think they're sufficiently annoying that I've just added a PR to add these

[jolheiser]

Existing PRs

• [ ] #14686
• [x] #14538
  • Another PR after this that uses bundles instead of bare repos in archives
• [ ] #14334

Other plans

• [ ] #14693
• [ ] Continue working on OpenGraph image implementation
• [ ] Possibly #12233

[lafriks]

Automatically pause queues if Elastic becomes unavailable and viceversa

• [ ] #15066 (based on @zeripath pausable queues #15928)

Secrets storage

• [ ] #14483

Advanced labels with priority

• [ ] #11669

CI integration into Gitea UI

• [ ] GitLab runner
• [ ] Woodpecker runner

[a1012112796]

Existing PRs

• [x] #14295
• [x] #15870
• [x] #16125
• [ ] #13585

[kolaente]

I hope to finally find the time to work on these two:

• [ ] #9307
• [ ] #14003.

[richmahn]

Having got into CSV/TSV for my company and how they render, I noticed a lot of bugs, which I created issues for last week. Will at least be fixing those, and back porting to v1.15.X if needed.

[techknowlogick]

For this milestone, the two things I am for sure working on are:

• [x] #16758
• [x] #16717

these are two required things for joining the fediverse.

[wxiaoguang]

I am investigating:

Admin user list filter

• [x] https://github.com/go-gitea/gitea/pull/16770 Merged

Issue / Comment content history

• [x] https://github.com/go-gitea/gitea/pull/16909 Merged
  • [x] https://github.com/go-gitea/gitea/issues/12886
  • [x] https://github.com/go-gitea/gitea/issues/5255

(actually they are the same one)

Two-factor authencation

• [ ] https://github.com/go-gitea/gitea/pull/16880
  • [ ] https://github.com/go-gitea/gitea/issues/880 , I think a global setting in app.ini is enough for most people, just like what GitLab does. And it's better to keep things simple enough. More thoughts: if there is an option for login sources to indicate the 2FA requirement, it would be better. eg: OAuth2 skips local 2FA, LDAP requires local 2FA, SPNEGO can use local 2FA optionally.

Frontend refactor

• [x] https://github.com/go-gitea/gitea/issues/17149 Basic work has been done. Future works need new separate PR.

[vwbusguy]

These are some low hanging fruit that have been asked for over several releases that I'd love to see picked up:

• https://github.com/go-gitea/gitea/pull/7225
• https://github.com/go-gitea/gitea/pull/7182
• https://github.com/go-gitea/gitea/issues/822

[techknowlogick]

Now that the RC is coming soon(tm) I will close this, and when 1.17-dev is here we can open a new one for that.