After a discussion with the initial group, we are now leaning toward using Asyncband as the project name.
Best, tison. tison <[email protected]> 于2026年8月12日周三 13:08写道： > Hi, > > Thanks for your suggestion. Unfortunately, I found [1][2] that may be > existing brands. > > [1] https://www.tryrendez.app/ > [2] > https://play.google.com/store/apps/details?id=com.rendezapp.android&hl=en > > I propose to seek a new name from: > > * AsyncSmith > * Bandaync (band + async, or banda + sync) > * ... > > and correspondingly update the proposal for a new thread. > > Best, > tison. > > > mingcheng <[email protected]> 于2026年8月12日周三 11:08写道： > >> Hi, tison >> >> I'd like to suggest a possible new name for the project: Rendez. >> >> It is short and easy to remember. The meaning matches the project. >> "Rendez" comes from "rendezvous" >> (https://en.wiktionary.org/wiki/rendezvous I asked for GPT, Haha), >> which means a meeting point. >> >> This is basically what synchronization and coordination primitives do: >> let different async tasks meet and coordinate at some point. So the >> name describes the core idea of the project quite well. >> >> And also the crate name is available https://crates.io/crates/rendez :-) >> >> On Wed, Aug 12, 2026 at 9:31 AM tison <[email protected]> wrote: >> > >> > @Juan & @Raúl, >> > >> > Thanks for your feedback! >> > >> > I'm considering AsyncSmith or WakeWeave as alternatives. But of course >> I'd >> > prefer a single-term name. >> > >> > Naming is hard. >> > >> > @Mingcheng, >> > >> > > I'd suggest doing the podling name search >> > >> > Yes. Will do. >> > >> > Now we are seeing a necessity to do the rename now. I'll open a >> > PODLINGNAMESEARCH ticket once we reach a new consensus. >> > >> > Best, >> > tison. >> > >> > >> > Raúl Cumplido <[email protected]> 于2026年8月12日周三 05:40写道： >> > >> > > Thanks for raising it Juan Pablo, >> > > >> > > As a Spanish speaker I also thought the same when I saw the email. >> > > >> > > There was also a comment about the name being too short and not >> > > descriptive. >> > > >> > > I'd ask to consider finding a different name given the issues. >> > > >> > > Regards, >> > > Raúl >> > > >> > > El mar, 11 ago 2026, 21:49, Juan Pablo Santos Rodríguez < >> > > [email protected]> escribió: >> > > >> > > > Hi, >> > > > >> > > > A small comment from the hispanic audience in this list, regarding >> the >> > > MEA >> > > > name (apologies in advance for the grossness): in spanish "mear" >> > > translates >> > > > as "piss", so that Apache MEA == Apache pisses. >> > > > >> > > > Every functional hispanic adult will dismiss the association, but >> from an >> > > > hispanic viewpoint, the name is not the best. >> > > > >> > > > OTOH, hispanic people engaging with the product will most probably >> also >> > > > speak at least english, so perhaps this can all be dismished, but I >> > > thought >> > > > at least I should surface it. >> > > > >> > > > >> > > > best regards, >> > > > juan pablo >> > > > >> > > > El mar, 11 ago 2026, 17:58, mingcheng <[email protected]> >> escribió: >> > > > >> > > > > Hi, All >> > > > > >> > > > > I'm interested in contributing to this project. Besides its >> practical >> > > > > value, I think MEA is also a very good project for learning. It is >> > > > > small, focused, and has few dependencies. Each primitive maps to a >> > > > > clear async concept, so it is a great way to help newcomers >> understand >> > > > > async Rust (Future/Waker/Context, fairness, cancellation, >> coordination >> > > > > patterns, etc.). I'd be happy to help with documentation. For >> example: >> > > > > concept-based guides, small examples for each primitive, and maybe >> > > > > some material that can also be used as a teaching resource for >> async >> > > > > Rust. If the community likes this idea, I'm glad to start from >> some >> > > > > small, well-scoped doc issues after the podling is set up. >> > > > > >> > > > > By the way, I also share the concern about the name. "MEA" is a >> very >> > > > > short and generic as project name. The new meaning "Modular >> Essentials >> > > > > for Async" helps, but I'd suggest doing the podling name search / >> > > > > trademark review early, so we don't have to rename it later after >> > > > > people already know the name. >> > > > > >> > > > > Thanks! >> > > > > >> > > > > Best regards, >> > > > > mingcheng >> > > > > >> > > > > On Tue, Aug 11, 2026 at 9:46 PM Twice <[email protected]> wrote: >> > > > > > >> > > > > > Hi IPMC, >> > > > > > >> > > > > > I would like to propose MEA [1] as a new Apache Incubator >> project, >> > > you >> > > > > > can find the proposal of MEA [2] for more details. >> > > > > > >> > > > > > I'm acting as the champion, and we currently have 4 mentors >> > > (including >> > > > > me). >> > > > > > >> > > > > > The proposal was updated based on the previous discussion [3]. >> We >> > > kept >> > > > > > MEA as the project name, but reinterpreted it as 'Modular >> Essentials >> > > > > > for Async.' >> > > > > > >> > > > > > [1] https://github.com/fast/mea >> > > > > > [2] >> > > > > >> > > > >> > > >> https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/446071349/MEA+Proposal >> > > > > > [3] >> https://lists.apache.org/thread/4gbqnmw15743r55m68q698lj2g2vzyvo >> > > > > > >> > > > > > Full proposal inlined below for easy reading. >> > > > > > >> > > > > > Best regards, >> > > > > > Twice >> > > > > > >> > > > > > ------------------------------------------------------------ >> > > > > > >> > > > > > Abstract >> > > > > > MEA is a runtime-agnostic Rust library of composable >> synchronization, >> > > > > > coordination, channel, and concurrency-control primitives for >> > > > > > asynchronous applications. >> > > > > > >> > > > > > Proposal >> > > > > > MEA provides reusable building blocks for asynchronous Rust >> programs >> > > > > > without coupling applications or libraries to a particular async >> > > > > > runtime. Its primitives interoperate through Rust’s standard >> Future, >> > > > > > Context, and Waker interfaces and can therefore be used with >> Tokio, >> > > > > > async-std, or other executors. >> > > > > > >> > > > > > The proposed project scope includes: >> > > > > > - Synchronization primitives such as Mutex, RwLock, Semaphore, >> > > > > > Barrier, Condvar, Latch, WaitGroup, Once, OnceCell, and OnceMap. >> > > > > > - Communication primitives such as one-shot, bounded and >> unbounded >> > > > > > MPSC, and broadcast channels with different delivery and >> overflow >> > > > > > strategies. >> > > > > > - Composed coordination utilities such as graceful shutdown >> > > signaling. >> > > > > > - Concurrency-control utilities such as admission control and >> > > > > > duplicate-call suppression. >> > > > > > The following areas are intentionally outside the project’s >> scope: >> > > > > > - I/O reactors or proactors for filesystems, networking, >> signals, >> > > > > > timers, or similar facilities. >> > > > > > - Task schedulers or complete async runtimes. >> > > > > > - General-purpose Future or Stream combinator libraries already >> > > > > > covered by the Rust futures ecosystem. >> > > > > > MEA is intended to be a focused, commons-style foundation for >> async >> > > > > > synchronization and coordination in Rust rather than another >> async >> > > > > > runtime. >> > > > > > >> > > > > > Background >> > > > > > MEA was started by Zili Chen (tison) in October 2024 and has >> been >> > > > > > developed publicly on GitHub under the Apache License, Version >> 2.0. >> > > > > > The project publishes the mea crate on crates.io and versioned >> API >> > > > > > documentation on docs.rs. Right now, we have four active >> contributors >> > > > > > and the crate has been downloaded more than 5M times. >> > > > > > >> > > > > > Rationale >> > > > > > Async Rust libraries frequently need synchronization and >> coordination >> > > > > > facilities even when they do not want to impose a particular >> runtime >> > > > > > on downstream applications. Runtime-specific primitive >> > > implementations >> > > > > > can introduce otherwise unnecessary coupling, while repeatedly >> > > > > > implementing low-level concurrency machinery increases >> correctness >> > > and >> > > > > > maintenance risks. >> > > > > > >> > > > > > MEA addresses this gap with a coherent set of >> executor-independent >> > > > > > primitives and a deliberately small runtime dependency surface. >> It >> > > > > > gives libraries a shared implementation for common concurrency >> > > > > > behavior while allowing applications to choose their executor. >> > > > > > >> > > > > > Moving MEA to the ASF would establish durable, vendor-neutral >> > > > > > ownership and a transparent, merit-based governance model. It >> would >> > > > > > also create a neutral place for users of different runtimes and >> > > > > > downstream projects to collaborate on correctness, API design, >> > > > > > performance, documentation, and new primitives within a >> well-defined >> > > > > > scope. >> > > > > > >> > > > > > Initial Goals >> > > > > > By transferring ownership of the project to the ASF, MEA >> expects to >> > > > > > ensure its neutrality and further encourage and facilitate the >> > > > > > adoption of MEA by the community. >> > > > > > >> > > > > > Some of the areas we would like to focus on during the Apache >> > > > > > incubation phase include: >> > > > > > - A healthier community: More contributors could be able to >> > > > > > participate in MEA and own different modules. >> > > > > > - Wider adoption: MEA can be adopted by more Rust projects, >> which in >> > > > > > turn drives its own functionality. >> > > > > > - Strengthening correctness evidence through cross-runtime >> > > integration >> > > > > > tests, stress and property testing, and targeted model checking. >> > > > > > - Establishing reproducible benchmarks and improving performance >> > > > > > without compromising safety, fairness, or API clarity. >> > > > > > >> > > > > > Current Status >> > > > > > Meritocracy >> > > > > > MEA has been developed through public GitHub issues and pull >> > > requests. >> > > > > > Contributors receive credit through the repository history and >> > > release >> > > > > > notes, but project ownership and release authority are currently >> > > > > > concentrated in the founding maintainer, and no formal >> > > > > > committer-governance model exists yet. >> > > > > > >> > > > > > The initial community intends to adopt the Apache Way. >> Technical and >> > > > > > governance decisions will be made transparently on ASF-managed >> > > > > > channels, contributions of code and non-code work will be >> evaluated >> > > on >> > > > > > merit, and contributors who demonstrate sustained positive >> > > > > > participation will be invited to become committers and PPMC >> members. >> > > > > > >> > > > > > Community >> > > > > > Contributors: 9 >> > > > > > >> > > > > > Users: >> > > > > > - Apache OpenDAL >> > > > > > - Prek >> > > > > > - Foyer >> > > > > > - ScopeDB >> > > > > > - ... and more on >> https://crates.io/crates/mea/reverse_dependencies >> > > > > > The donation discussion is public at >> > > > > https://github.com/fast/mea/issues/140. >> > > > > > >> > > > > > Core Developers >> > > > > > The current core developers have experience with Rust, >> asynchronous >> > > > > > systems, and public open-source collaboration. Zili Chen is an >> ASF >> > > > > > Member and IPMC member with experience mentoring incubating >> projects. >> > > > > > Yunze Xu is an Apache Pulsar PMC member. Dian Luo and Haixu >> Ouyang >> > > > > > have contributed to the implementation, documentation, testing, >> and >> > > > > > maintenance of MEA and related projects in the fast GitHub >> > > > > > organization. >> > > > > > >> > > > > > This gives the initial group some ASF experience, but not every >> core >> > > > > > developer is familiar with ASF release, governance, and >> communication >> > > > > > practices. The Mentors will help the whole community learn and >> > > > > > consistently apply those practices. >> > > > > > >> > > > > > Alignment >> > > > > > MEA is already licensed under Apache-2.0, is developed in >> public, and >> > > > > > is directly used by Apache OpenDAL. Its purpose as reusable, >> > > > > > vendor-neutral infrastructure aligns with the ASF’s emphasis on >> > > > > > community-led development and long-term stewardship. >> > > > > > >> > > > > > The ASF hosts a growing set of Rust projects and Rust >> components, >> > > > > > including Apache OpenDAL, Apache DataFusion, and parts of Apache >> > > > > > Arrow. MEA can provide shared async coordination infrastructure >> for >> > > > > > Apache projects where appropriate while remaining useful to the >> wider >> > > > > > Rust community. >> > > > > > >> > > > > > Known Risks >> > > > > > Project Name >> > > > > > “MEA” is a short and generic acronym. The current community >> proposes >> > > > > > that it mean “Modular Essentials for Async” and prefers to >> retain the >> > > > > > existing crates.io name, but a formal ASF podling name search >> and >> > > > > > trademark review have not yet been completed. The community will >> > > > > > complete that review and address any material conflict before >> the >> > > name >> > > > > > is finalized. >> > > > > > >> > > > > > Orphan Products >> > > > > > MEA is a small library whose maintenance has so far been led >> > > primarily >> > > > > > by one person, so loss of interest by the founding maintainer >> is a >> > > > > > real risk. Existing downstream adoption and the commitment of >> four >> > > > > > active contributors reduce the immediate risk, but they do not >> > > > > > eliminate it. >> > > > > > >> > > > > > The central incubation goal is to distribute ownership across a >> > > larger >> > > > > > group of committers and downstream stakeholders. Transparent >> > > > > > governance, documented maintenance practices, and ASF-controlled >> > > > > > project assets will make continuation less dependent on any one >> > > > > > individual. >> > > > > > >> > > > > > Inexperience with Open Source >> > > > > > MEA has been developed openly on GitHub since its inception, >> and all >> > > > > > initial committers have participated in public open-source >> workflows. >> > > > > > Zili Chen and Yunze Xu have substantial ASF experience, while >> other >> > > > > > initial committers are newer to ASF governance, >> mailing-list-based >> > > > > > decision-making, release voting, and policy requirements. >> > > > > > >> > > > > > The project will rely on its Mentors and experienced initial >> > > > > > committers to teach these practices and ensure that knowledge is >> > > > > > shared rather than concentrated. >> > > > > > >> > > > > > Length of Incubation >> > > > > > Expect to enter incubation in two months and graduate in about >> two >> > > > years. >> > > > > > >> > > > > > Homogenous Developers >> > > > > > The initial active developers are geographically concentrated in >> > > China >> > > > > > and share overlapping professional interests in Rust >> infrastructure. >> > > > > > They are not all employed by the same organization, but the >> current >> > > > > > group is still too small and homogeneous for a sustainable >> Apache >> > > > > > community. >> > > > > > >> > > > > > The project will actively recruit contributors through >> downstream >> > > > > > users, Rust runtime communities, ASF Rust projects, >> documentation >> > > > > > work, testing initiatives, and well-scoped issues suitable for >> new >> > > > > > participants. >> > > > > > >> > > > > > Reliance on Salaried Developers >> > > > > > MEA is not known to depend on a development team funded by a >> single >> > > > > > employer. The more significant risk is concentration of >> maintenance >> > > > > > work in the founding maintainer, regardless of whether that >> work is >> > > > > > salaried or voluntary. >> > > > > > >> > > > > > The project will mitigate this risk by sharing release, review, >> > > > > > triage, and technical ownership among multiple committers and by >> > > > > > recognizing sustained non-code contributions as well as code >> > > > > > contributions. >> > > > > > >> > > > > > Relationships with Other Apache Products >> > > > > > - Apache OpenDAL directly depends on MEA and uses it throughout >> its >> > > > > > Rust implementation. >> > > > > > - prek depends on MEA and is used in Apache Airflow’s >> development >> > > > > > workflows, creating an indirect relationship with Apache >> Airflow. >> > > > > > - MEA may be useful to other ASF Rust projects that need >> > > > > > executor-independent synchronization or coordination, but no >> project >> > > > > > will be expected to adopt it merely because it is hosted by the >> ASF. >> > > > > > >> > > > > > An Excessive Fascination with the Apache Brand >> > > > > > The proposal is motivated by neutral ownership, durable >> > > > > > infrastructure, transparent governance, and community growth >> rather >> > > > > > than by endorsement or marketing value. The initial community >> > > > > > understands that the Apache name does not guarantee adoption >> and that >> > > > > > incubation requires sustained work on releases, policy >> compliance, >> > > and >> > > > > > community development. >> > > > > > >> > > > > > Documentation >> > > > > > The API documentation of MEA is hosted at https://docs.rs/mea. >> > > > > > >> > > > > > If the proposal is accepted, the community may establish a >> project >> > > > > > website at mea.apache.org; docs.rs will continue to host API >> > > > > > documentation for published crate versions. >> > > > > > >> > > > > > Initial Source >> > > > > > The project currently holds a GitHub repository and a Cargo >> crate: >> > > > > > - https://github.com/fast/mea >> > > > > > - https://crates.io/crates/mea >> > > > > > The crate will retain its name, while the repository will be >> moved to >> > > > > > the Apache org. >> > > > > > >> > > > > > Source and Intellectual Property Submission Plan >> > > > > > External Dependencies >> > > > > > The published crate currently has one direct runtime dependency: >> > > > > > >> > > > > > MIT >> > > > > > - slab 0.4.12 (It is planned to be removed) >> > > > > > >> > > > > > Cryptography >> > > > > > N/A >> > > > > > >> > > > > > Required Resources >> > > > > > Mailing Lists >> > > > > > - [email protected] >> > > > > > - [email protected] >> > > > > > - [email protected] >> > > > > > - [email protected] >> > > > > > - [email protected] >> > > > > > >> > > > > > Subversion Directory >> > > > > > N/A >> > > > > > >> > > > > > Git Repositories >> > > > > > From https://github.com/fast/mea >> > > > > > To https://gitbox.apache.org/asf/repos/mea >> > > > > > https://github.com/apache/mea >> > > > > > >> > > > > > Issue Tracking >> > > > > > The community would like to continue using GitHub Issues. >> > > > > > >> > > > > > Other Resources >> > > > > > The community has already chosen GitHub Actions as continuous >> > > > > integration tools. >> > > > > > >> > > > > > Initial Committers >> > > > > > - tison [[email protected]] >> > > > > > - Dian Luo [[email protected]] >> > > > > > - Yunze Xu [[email protected]] >> > > > > > - Haixu Ouyang [[email protected]] >> > > > > > >> > > > > > Sponsors >> > > > > > Champion >> > > > > > - Mingyang Liu [[email protected]] >> > > > > > >> > > > > > Nominated Mentors >> > > > > > - tison [[email protected]] >> > > > > > - Hao Ding [[email protected]] >> > > > > > - Jean-Baptiste Onofré [[email protected]] >> > > > > > - Mingyang Liu [[email protected]] >> > > > > > >> > > > > > Sponsor Entity >> > > > > > The Incubator >> > > > > > >> > > > > > >> --------------------------------------------------------------------- >> > > > > > To unsubscribe, e-mail: >> [email protected] >> > > > > > For additional commands, e-mail: >> [email protected] >> > > > > > >> > > > > > >> > > > > >> > > > > >> --------------------------------------------------------------------- >> > > > > To unsubscribe, e-mail: [email protected] >> > > > > For additional commands, e-mail: >> [email protected] >> > > > > >> > > > > >> > > > >> > > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
