tikv / community Goto Github PK
View Code? Open in Web Editor NEWTiKV community content
TiKV community content
To evolve towards the next generation database engine kernel, we reimplemented RocksDB using rust. This is our project address: https://github.com/rust-lib-project/rocksdb-rs. Of course, we will not implement all the functions of RocksDB. Our purpose is to create a more general KV data engine for TiKV services, not a transactional data engine for MyRocks services. In this project, we will eliminate most of the features that TiKV in RocksDB does not use, including transactions and two-phase commit code, in order to simplify our code as much as possible and make the project easier to maintain.
For the cloud ecosystem, asynchronous IO is essential for high-latency cloud disks. Fortunately, rust provides an asynchronous framework that is easier to use than C++, allowing us to easily write asynchronous IO code. Therefore, most of the interfaces of this project are provided as asynchronous method. Thanks to all interfaces supporting asynchrony, we can merge the compaction thread pool with other background thread pools in tikv to reduce thread switching and control CPU resources more precisely.
At present, rocksdb-rs still maintains similar interface methods and functions as rocksdb, but it adopts a low-coupling architecture, which can be easily refactored into a more friendly interface for TiKV in the future.
At present, the project has implemented the basic functions of rocksdb, including read and write queries and background merging. But it still lacks a lot of tests, and some key functions (you can see more details in https://github.com/rust-lib-project/rocksdb-rs/issues), I hope he can get help from more developers under the tikv organization and play a bigger role.
subtask of #118
Here is the dedicated issue for making decision on member : team : repository mappings.
A team has its reviewer, committer and maintainer, and owns one or more repositories.
The permission of reviewer and committer is similar with current state but indistinguishable among the team. It means a reviewer of the team can review all pull requests in repositories owned by the teams.
The permission of maintainer, based on that of committer, is mainly for exit mechanism and other team level decision making, which will be elaborated later.
I create a pull request #122 with the proposed teams and their members as well as repositories associated with.
subtask of #118
Since our permissions are flatten into repository level. @hi-rustin and I tend to use GitHub team to maintain the permission and leave the bot simply respect GitHub permission.
ti-chi-bot can apply such rules according to this page
use_github_permission: Use GitHub permissions and have write and admin collaborators as reviewers and committers
And for repositories where bot is not configured (bot has a limit on events received), the model retains.
As discussed in #152, we use alphabetical order in team member json files. Therefore, we may need a style checker for this enforcement.
Due to historical reasons, components like tidb_query_aggr, tidb_query_expr etc. are put in tikv repository as they are part of coprocessor. But it may not be a good choice as they are highly tidb specific, may not suitable for a general KV project. And we also lack of active maintainers/committers for these components. So I suggest to move these components to pingcap org.
The components to be moved include:
They also depend on some of internal components including
They should be either published to crates.io or inlined all used functions/types.
After this change, these projects will not be part of tikv/tikv anymore. But they will still be part of release binaries.
Any thoughts?
As one of the founders of TiKV project, Qi Liu has made significant contributions to TiKV. I hereby nominate Qi Liu as member of TOC.
Everyone is welcome to comment.
Due to the fact that the governance document has been outdated for some time. I hereby propose a refresh of governance document according to the new affiliations of steering committee members and infra members.
The changes are:
Please make comments if you have any concern, thanks
Maybe when he is not that tired, he'd like to contact someone who knows the community rule of the tikv to help him solve the problem.
Based on my knowledge, only tikv committers can push tags directly.
Possible solutions include as follows:
pprof-rs
is not heavy traffic.pprof-rs
but don't have permission to push tags.Also, ping @tisonkun for more advice about the current situation.
Databend depends heavily on pprof-rs
and I'm interested in maintaining pprof-rs
, we can help maintain this project.
Originally posted by @Xuanwo in tikv/pprof-rs#139 (comment)
As one of the founders of project TiKV, Dongxu Huang has made significant contributions to TiKV. I hereby nominate Dongxu Huang as member of TOC.
Everyone is welcome to comment.
In voting-150, we passed the scheme of using commit message in the PR to associate the issue, so that the squash commit can also associate with the issue.
But in the process of practice, it will bring some troubles to code contributors, especially in the case where we have multiple release branches, we need to submit meaningless commits or modify the commit message many times to pass the check.
For now, we forked out a customized version of prow, which is the upstream code repository of the @ti-chi-bot .
Based on it, we add some functions to make @ti-chi-bot be able to automatically extract issue numbers from the PR body and automatically populate the issue number to the squash commit message when merging.
For example:
We just need to fill in a line starting with Issue Number:
of text in the PR body. (For concrete rules, please refer to the description in the TiDB development guide.)
The robot will extract the issue number section in the squash commit message when merging.
I think that this schema replacing our original schema will make our work easier. If that makes sense to everyone, I will
Disable the format-checker on tikv and pd repo, no longer enforcement requires issue number in PR's commmit.
Call for a public vote on the new schema, continue to complete the issue #149 ( cc: @zhangyangyu )
See previous discussions in tikv/minitrace-rust#229
TL;DR. The TiKV organization is where minitrace is grown, and so minitrace is governed uner the tikv and CNCF organization. However as minitrace becomes more and more broadly adopted, its standalone governance and growth becomes more necessary.
This issue is a proposal to transfer the repository ownership of tikv/minitrace
into fastracelabs/fastrace
to enable better user experience and a more fluent transition.
Currently fastrace is a fork of minitrace. However it looks wired, because the maintainers of fastrace and minitrace are actually the same, and the minitrace maintainers choose to write a big notice about the transition on the project README. The user experience is not well, because all history issues, pulls are just missed and cannot be linked together.
As the maintainer of the minitrace, and as the maintainer of TiKV project, I think there are rights for the minitrace maintainers to choose where the project stands, for good purposes.
Currently there is no requirement of the votes about transfering out repositories according to TiKV's goverance, so I'm opening a new issue for this specific purpose.
/cc @andylokandy @zhongzc
/cc @tisonkun
/cc TiKV committee: @fredchenbj @lidaobing @BusyJay @sunxiaoguang @siddontang @winkyao @zhangjinpeng87 @ngaut @c4pt0r
match_template is a procedural macro that generates repeated match arms by pattern, which is almost the only way to dispatch code path to static types depending on a runtime value. Since it's general enough, I propose to move it to TiKV org and then publish it to crates.io so that the rust community could be benifit from it.
subtask of #118
With consensus in #118 we'd like to formalize the governance and make it no longer a draft. This issue is a subtask tracing all contents updates. So far, it seems containing
Also we should remove all stale contents including committee/
, sig/
, and wg/
.
subtasks
Subtasks:
A team has its reviewer, committer and maintainer, and owns one or more repositories.
The permission of reviewer and committer is similar with current state but indistinguishable among the team. It means a reviewer of the team can review all pull requests in repositories owned by the team.
The permission of maintainer, based on that of committer, is mainly for exit mechanism and other team level decision making, which will be elaborated later.
Within this proposal, there are 4 teams proposed.
Every repository of TiKV org will be associated with one and only one team. Reviewer and committer of that team has the review or commit permission to the repository.
As we build 4 teams above, the relation between team and repository as listed below. Comment if you think it is not the real case.
The exceptions are tikv/community and tikv/rfcs.
A team has its reviewer, committer and maintainer.
The maintainers is able to evict member by majority decision and thus we have an exit mechanism. It is suggested that a team defines its own bylaws to elaborate other team level decision making process.
Besides the teams, the whole TiKV community has its TOC members for evolving the community. The TOC members consist of part of maintainers of teams and are in charge of community level decision making process like build a new team, or arbitrate divergence between team by majority decision.
SIG itself means expert group, which always exists in fact, and serves for better reference to help. However, this concept should never be associated with permission.
Yes and no. We name it as "Team" for distinguished from "SIG", but the authentication #123 is quite similar as "SIG at repo granularity" or said GitHub teams. There is no much difference.
Proposal: TiKV Development Guide was posted at 2021-07-21, and during the last half year we finished several chapter of the guide at https://github.com/tisonkun/tikv-dev-guide.
However, there're still 36 outstanding issues and thus at least 36 sections to be written. After a discussion with @zz-jason, he proposed that we can transfer the dev guide to tikv org and proceed the work.
I'm glad to see any pull requests to fulfill new sections, and don't insist on what owner the repo belongs to. The important thing, from my side, is the content itself. If transferring the repo to tikv org can help moving forward the progress, I'm willing to do so.
So here is the issue to discuss about such a transfer. Looking forward to responses.
For achieving the transfer, I think I have all required permission to do it.
subtask of #124
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.