Transfer tikv/minitrace as fastracelabs/fastrace

[breezewish]

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.

Alternatives

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.

Votes

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

[BusyJay]

As said in the original issue, I vote against this proposal. This makes no sense to me. The project was developed and maintained by TiKV developers. It's owned by TiKV, rather than by some specific people. I thank a lot for their contributions and respect their decisions that stop contributing as part of TiKV community. But I can't agree on just throw projects away, otherwise any members that decide to leave the community can just claim ownership of their major contributed projects and ask for a transfer. This is not how open source work, at least not the way I understand and agree.

[breezewish]

@BusyJay How about moving and clearify in the fastrace repository that fastrace is grown and incubated by the TiKV community and now it becomes a standalone project for better community goverance? I would like to emphersize that the purpose of the transfer is not claiming the code or contribution ownership -- the maintainers of the project are unchanged. The transfer is to enable better community goverance and be more swift for community activities. For example, the project will not be constrained by TiKV and CNCF's community goverance rules and could raise their own meetups and make decisions. Currently, as you can see, the right of all activities (except for code contribution) needs some kind of procedural works from the TiKV organization, while, as you can see in the original issue, other TiKV committee members are actually not caring about these community activities. It would be just better to let it grow independently, instead of affected by a vegetative committee.

[BusyJay]

fastrace already has its own org and repository, and they can raise their own meetups and decisions already. TiKV's governance only applies to TiKV community, not fastrace community. You can think it as mysql and mariadb, mariadb is also a fork of mysql and can have its own org and community.

[breezewish]

@BusyJay However there is no developers actually developing the TiKV's minitrace :) So what's the purpose of leaving a repository there? Only to keep history issues and PRs?

[BusyJay]

There is no one developing minitrace at the moment, but future is hard to say. And I don't agree with the logic that you don't utilize it (yet) so you should give it to me.

[breezewish]

@BusyJay I respect your concern about future development. It is indeed true. If minitrace is no longer tikv/minitrace, then there could be possibility that it cannot address the need of TiKV.

There are two directions to solve this after the transfer:

• When TiKV and minitrace's goals are not conflicted, the improvement can be done just through the normal community way. As TiKV maintainers are also minitrace maintainers, I think this process would be rather easy to be adopted.
• When TiKV and minitrace's goals (efficient tracing) are conflicted, TiKV could bring a new project, or utilizing an existing one. There are a wide range of choices in the wild when talking about the rich set of features. Even when minitrace stays inside tikv/minitrace, we should be still very careful when changing the project goals, because this is usually not what the community expects and TiKV should not break this kind of promise inplace.

In one word, considering that Minitrace and TiKV are maintained by the same set of developers, I think this kind of concern could be relaxed.

On the other hand, the major paradox currently exists that, "minitrace"'s maintainers are capable of bringing a README and encourage users to use fastrace instead, because maintainers have code maintainance rights, and actually this is what's going on currently. They are simply not capable of changing the belonging GitHub organization, which is more like to be a procedural thing.

This is unlike what happen to Mariadb and MySQL, both are developing concurrently and Mariadb is a real fork.

One more thing, when minitrace is a standalone project, its maximum community benefits could be released, as it is no longer a TiKV sister project and the community's benefit will be its first-class citizen. This is usually hard to maintain when it stays inside the TiKV org, as currently it is too easy to be envolved into something that only TiKV can adopt. There are existing examples: tikv/rust-rocksdb is hard to be used just as an open-source project. TiKV impacts it too much. Users can easily find it hard to adopt it in an open-source project and users are also hard to treat it as a real RocksDB binding in Rust. Before the tikv/tikv is "pulluting" the minitrace, I think it is not too late to utilize this chance, keep and ensure minitrace community-oriented.

[breezewish]

I don't agree with the logic that you don't utilize it (yet) so you should give it to me.

This is not what happens. A standalone minitrace organization structure is not because tikv is not using it. It is because the current tikv's organization structure is not suitable for a growing community like minitrace, which requires more freedom and flexibility in order to grow better. Even when TiKV is using minitrace, it would be great to be a standalone org, where minitrace could fully grow for the community, not only for TiKV.

[BugenZhao]

Shall we first mark the unmaintained status in the RustSec Advisory Database following the documentation here? This will help to notice users (who enable RustSec checks) about the deprecation and the migration of minitrace.

[Xuanwo]

Shall we first mark the unmaintained status in the RustSec Advisory Database following the documentation here? This will help to notice users (who enable RustSec checks) about the deprecation and the migration of minitrace.

rustsec/advisory-db#2037 has been created.