Re: [DISCUSS] MEA Proposal

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]
>>
>>