Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plan of Gitea v1.16 #16429

Closed
lunny opened this issue Jul 14, 2021 · 11 comments
Closed

Plan of Gitea v1.16 #16429

lunny opened this issue Jul 14, 2021 · 11 comments
Labels
type/summary This issue aggregates a bunch of other issues

Comments

@lunny
Copy link
Member

lunny commented Jul 14, 2021

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 lunny added the type/summary This issue aggregates a bunch of other issues label Jul 14, 2021
@lunny lunny pinned this issue Jul 14, 2021
@lunny
Copy link
Member Author

lunny commented Jul 14, 2021

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

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
Copy link
Contributor

zeripath commented Jul 14, 2021

Authentication/Authorization refactors

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

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

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.

  • Add directory paging for rendering code trees #16432 adds paging to the directory rendering meaning repos with large directories get paged.

  • Defer Last Commit Info #16467 represents a PR that will allow last commit generation to be aborted to render the page quicker.

  • WIP: Defer last commit info #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:

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 Pause queues #15928. This is likely to be very important for users of things like elasticsearch which may stop or start.

Organization Remove/Leave Modals

@jolheiser
Copy link
Member

jolheiser commented Jul 14, 2021

Existing PRs

Other plans

@lafriks
Copy link
Member

lafriks commented Jul 14, 2021

Automatically pause queues if Elastic becomes unavailable and viceversa

Secrets storage

Advanced labels with priority

CI integration into Gitea UI

  • GitLab runner
  • Woodpecker runner

@a1012112796
Copy link
Member

a1012112796 commented Jul 15, 2021

Existing PRs

@kolaente
Copy link
Member

kolaente commented Jul 17, 2021

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

@richmahn
Copy link
Contributor

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
Copy link
Member

techknowlogick commented Aug 23, 2021

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

these are two required things for joining the fediverse.

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Aug 26, 2021

I am investigating:

Admin user list filter

Issue / Comment content history

(actually they are the same one)

Two-factor authencation

Frontend refactor

@vwbusguy

This comment has been minimized.

@techknowlogick techknowlogick unpinned this issue Nov 23, 2021
@techknowlogick
Copy link
Member

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.

@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/summary This issue aggregates a bunch of other issues
Projects
None yet
Development

No branches or pull requests

10 participants