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

Reply via email to