Running minitrace as a standalone project?

[tisonkun]

Hi guys!

Recently, I had a talk with @andylokandy (one of minitrace's maintainers) about the growth and future of this project. Basically, the minitrace subproject within TiKV owns these repos:

• https://github.com/tikv/minitrace-go
• https://github.com/tikv/minitrace-rust

While minitrace-rust has updated 2 days ago, the last time minitrace-go got updated should go back to 2 years ago. In the recent months, minitrace grows a series of new adoptions, like:

• foyer
• Databend
• Apache OpenDAL
• ConsDB
• ...

However, TiDB and TiKV itself doesn't use minitrace, which can cause users feeling strange why it's under the TiKV organization. And also, @andylokandy and our active contributor @Xuanwo, found it more motivated to run minitrace as a standalone project.

I believe it would be a net win to let minitrace go and form its community, while we still record the history that it's incubated from within the TiKV organization. In this way, we can see that TiKV as a graduated project in CNCF can spawn new vivid OSS project, and minitrace can use its own branding for operating and growth.

For the policy and process part, I consult one of the TOC member in CNCF and it's said that as long as the commitee of TiKV, defined in the GOVERNANCE file, reach a consensus to split minitrace from its organization, it should be fine.

For what exactly to be done:

1. Create a separated organization, perhaps named minitrace.
2. Move minitrace-rust and minitrace-go to that organization.
3. Record a consensus with a vote that this project is now a standalone OSS project, not part of TiKV or the CNCF.

What do you think?

For minitrace maintainers: @andylokandy @zhongzc

For TiKV committee: @fredchenbj @lidaobing @BusyJay @sunxiaoguang @siddontang @winkyao @zhangjinpeng87 @ngaut @c4pt0r

[BusyJay]

However, TiDB and TiKV itself doesn't use minitrace, which can cause users feeling strange why it's under the TiKV organization.

Ownership is not defined by usage, isn't it?

I can't represent other committee, but I will vote against this proposal as it doesn't make any sense to me. If as TiKV committers/maintainers and don't feel comfortable contribute to projects in TiKV org, or contributors don't feel comfortable to join TiKV community, I suggest to setup a new organization and fork the project.

[zhongzc]

I completely understand the concerns about ownership and the potential implications for the TiKV community.

I genuinely think that forking is a practical suggestion. It provides a solution that allows us to achieve nearly the goal mentioned by @tisonkun without imposing on the TiKV committee’s preferences. However, forking might not be the most favorable path in terms of optics and could create unnecessary fragmentation.

I advocate for a more lenient approach from the TiKV community. If separating minitrace does not impact the core operations or goals of TiKV, a graceful transition might be more conducive for both communities. Minitrace can flourish with its own identity, while TiKV can showcase its ability to incubate and nurture successful projects.

While I understand and respect @BusyJay’s stance, I believe that allowing minitrace to stand on its own could be a win-win scenario. It would present a more unified and professional front, both internally and to the broader open-source community.

[kevin-wangzefeng]

For the policy and process part, I consult one of the TOC member in CNCF and it's said that as long as the commitee of TiKV, defined in the GOVERNANCE file, reach a consensus to split minitrace from its organization, it should be fine.

It’s essential to emphasize that consensus-building is a crucial but also initial step. Additionally, I'd recommend verifying with CNCF whether there are any implications related to branding, as there may be a potential brand transfer. While I’m not an expert on branding, my understanding is that “Minitrace” is currently a TiKV associated brand.

As a CNCF TOC member, I’m happy to answer questions if any of you need help on understanding CNCF rules and guidelines. However, I don’t have a preference for a specific path. Typically, the TOC doesn’t directly intervene in project governance decisions. Instead, it’s essential to consider how the TiKV community prefers to handle this transition first.

[tisonkun]

I genuinely think that forking is a practical suggestion. It provides a solution that allows us to achieve nearly the goal mentioned by @tisonkun without imposing on the TiKV committee’s preferences. However, forking might not be the most favorable path in terms of optics and could create unnecessary fragmentation.

Yes. Forking is possible and can be done independently.

However, since it's one of the major maintainers' suggestion, I'm trying to find a way to reduce the fragmentation, i.e., the new "foo-trace" build its own branding from scratch, the minitrace project being unmaintained, which is a lose-lose.

[Xuanwo]

The fork has been created: https://github.com/fastracelabs/fastrace. We are beginning the migration from minitrace to fastrace. It's unfortunate that the community is splitting like this. We hope the tikv community continues to maintain minitrace effectively as well.

[andylokandy]

I'm closing this issue since we have come to this conclusion: fork with name fastrace, and the minitrace maintainer will continue development there. Thank you all for supporting us all the time!

[breezewish]

Currently user needs a manual click in order to reach fastrace from minitrace. How about just moving the repository so that GitHub will automatically do the redirection for users? This seems to be a broader adopted way.