Thank you all! I'll start a vote soon. Best, Twice
On Thu, Aug 13, 2026 at 11:44 PM tison <[email protected]> wrote: > > Thanks! > > I just updated those refs. > > Best, > tison. > > > mingcheng <[email protected]> 于2026年8月13日周四 23:28写道： > > > Hi tison, > > > > Fair enough, point taken. > > > > BTW one thing for @Twice, before the VOTE thread: Required Resources > > still lists the OpenDAL mailing lists (private@ / dev@ / commits@ / > > issues@ / [email protected]), looks like a copy-paste leftover, > > should be the podling's own lists once the name is confirmed. > > > > On Thu, Aug 13, 2026 at 10:54 PM tison <[email protected]> wrote: > > > > > > > At the same time, I have already started familiarizing myself with the > > > > project on GitHub. > > > > > > Welcome! Feel free to ask anything on GitHub or following on the mailing > > > list. > > > > > > Although, I'd prefer to keep the focus on API, code quality, adoption, > > and > > > other development velocity things, rather than jump into concrete > > > free-standing style because I typically understand that contributors can > > > decide style adoption around the area they are actively working on. > > > Commenting on styles are cheap and if you're not living with those, it is > > > too cheap to suggest. > > > > > > Best, > > > tison. > > > > > > > > > mingcheng <[email protected]> 于2026年8月13日周四 22:18写道： > > > > > > > Hi, tison > > > > > > > > I agree with your careful consideration regarding the project version > > > > number strategy, and I also understand that we need to be mentally > > > > prepared for the long-term maintenance of this project. > > > > > > > > A clear plan shows that we already have many good ideas and roadmap > > > > which means a good start, I look forward to this project continuing to > > > > move forward within the incubation. > > > > > > > > At the same time, I have already started familiarizing myself with the > > > > project on GitHub. > > > > > > > > On Thu, Aug 13, 2026 at 10:01 PM tison <[email protected]> wrote: > > > > > > > > > > Hi mingcheng, > > > > > > > > > > > crates is currently 0.67, which doesn't seem very “mature,” so I'd > > > > > > suggest moving it to 1.0 when into the podling stage - that way > > looks > > > > > > more "mature" and production-ready :-) > > > > > > > > > > Thanks for your feedback :D > > > > > > > > > > A 1.0 release would typically associate with a stable promise. I'm > > going > > > > to > > > > > release a 0.7 version this month to include several breaking changes > > and > > > > > module structure rearrangement, and see if the state is in a good > > shape > > > > for > > > > > 1.0. > > > > > > > > > > That said, I'm a big fan of providing stable APIs that downstream > > > > projects > > > > > can rely on. But the version series should reflect the real stable > > > > status, > > > > > or else it would be meaning less. For example, a project release > > 100.0.1 > > > > > months after its 1.0.0 release, has noting different from staying in > > 0.x. > > > > > > > > > > Here is a meme site about ZeroVer [1] and you would find several ASF > > > > > (top-level) projects on list :D > > > > > > > > > > [1] https://0ver.org/ > > > > > > > > > > Back to Asyncband, the scope has been discussed as: > > > > > > > > > > * Asynchronous primitives like Semaphore, Mutex, WaitGroup, Latch, > > etc. > > > > > * Composited utilities like shutdown. > > > > > * Channels with multiple strategies. > > > > > * Concurrency control like admission, singleflight, and perhaps > > something > > > > > like select!/join! later. > > > > > > > > > > Non-goals contain: > > > > > > > > > > * IO reactor/proactor (fs, net, signal, timer, ...). We can continue > > > > > incubating that at fast/scorpio. > > > > > * Schedulers (tokio's scheduler, yatp, etc.). I have no idea about > > > > working > > > > > on these, yet. > > > > > * Future/Stream combinators. It is covered by rust-lang/futures and > > > > > actually with full async/await support this should be unnecessary. > > > > > > > > > > It's actually a big challenge to provide stable API promises. Or we > > can > > > > > keep the stable one documented while other stay behind an > > > > > "unstable-<feature-name>" feature flag. All of that are technical > > details > > > > > we can work together :D > > > > > > > > > > Best, > > > > > tison. > > > > > > > > > > > > > > > mingcheng <[email protected]> 于2026年8月13日周四 21:52写道： > > > > > > > > > > > Hi, tison > > > > > > > > > > > > Thanks for driving this work forward so efficiently. > > > > > > > > > > > > Here is one more small suggestion: I see the asyncband version on > > > > > > crates is currently 0.67, which doesn't seem very “mature,” so I'd > > > > > > suggest moving it to 1.0 when into the podling stage - that way > > looks > > > > > > more "mature" and production-ready :-) > > > > > > > > > > > > > > > > > > On Thu, Aug 13, 2026 at 8:52 PM tison <[email protected]> > > wrote: > > > > > > > > > > > > > > The rebrand has been done: > > > > > > > > > > > > > > * https://github.com/fast/asyncband > > > > > > > * https://crates.io/crates/asyncband > > > > > > > > > > > > > > The PODLINGNAMESEARCH ticket has been filed: > > > > > > > > > > > > > > * https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-257 > > > > > > > > > > > > > > Best, > > > > > > > tison. > > > > > > > > > > > > > > > > > > > > > Xuanwo <[email protected]> 于2026年8月12日周三 23:30写道： > > > > > > > > > > > > > > > Thank you for raising this! > > > > > > > > > > > > > > > > Learnt a lot about mea. I'm happy with the new name. > > > > > > > > > > > > > > > > On Wed, Aug 12, 2026, at 20:28, Twice wrote: > > > > > > > > > Hi IPMC, > > > > > > > > > > > > > > > > > > I would like to propose Asyncband [1] as a new Apache > > Incubator > > > > > > > > > project, you can find the proposal of Asyncband [2] for more > > > > details. > > > > > > > > > > > > > > > > > > The project was previously named MEA and was discussed in an > > > > > > Incubator > > > > > > > > > thread [3]. Based on community feedback, we decided to > > rename the > > > > > > > > > project Asyncband because MEA was too short and could be > > > > ambiguous in > > > > > > > > > some languages. > > > > > > > > > > > > > > > > > > I'm acting as the champion, and we currently have 4 mentors > > > > > > (including > > > > > > > > me). > > > > > > > > > > > > > > > > > > Full proposal inlined below for easy reading. > > > > > > > > > > > > > > > > > > [1] https://github.com/fast/mea > > > > > > > > > [2] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/spaces/INCUBATOR/pages/446071349/Asyncband+Proposal > > > > > > > > > [3] > > > > https://lists.apache.org/thread/5pb2rtzjmn1rzchfglokslgwwg293o47 > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Twice > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > Abstract > > > > > > > > > Asyncband is a runtime-agnostic Rust library of composable > > > > > > > > > synchronization, coordination, channel, and > > concurrency-control > > > > > > > > > primitives for asynchronous applications. > > > > > > > > > > > > > > > > > > Proposal > > > > > > > > > Asyncband 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. > > > > > > > > > Asyncband is intended to be a focused, commons-style > > foundation > > > > for > > > > > > > > > async synchronization and coordination in Rust rather than > > > > another > > > > > > > > > async runtime. > > > > > > > > > > > > > > > > > > Background > > > > > > > > > Asyncband 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 was previously named MEA and 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. > > > > > > > > > > > > > > > > > > Asyncband 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 Asyncband 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, > > Asyncband > > > > > > expects > > > > > > > > > to ensure its neutrality and further encourage and > > facilitate the > > > > > > > > > adoption of Asyncband 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 Asyncband and own different modules. > > > > > > > > > - Wider adoption: Asyncband 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 > > > > > > > > > Asyncband 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 Asyncband 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 > > > > > > > > > Asyncband 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. Asyncband can provide shared async coordination > > > > infrastructure > > > > > > > > > for Apache projects where appropriate while remaining useful > > to > > > > the > > > > > > > > > wider Rust community. > > > > > > > > > > > > > > > > > > Known Risks > > > > > > > > > Project Name > > > > > > > > > This project was previously named MEA, which stands for > > “Modular > > > > > > > > > Essentials for Async”. During previous discussions at the > > Apache > > > > > > > > > Incubator, we realized that MEA might be too short and > > ambiguous > > > > in > > > > > > > > > some languages, so it was renamed Asyncband. > > > > > > > > > > > > > > > > > > Orphan Products > > > > > > > > > Asyncband 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 > > > > > > > > > Asyncband 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 > > > > > > > > > Asyncband 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 Asyncband and uses it > > > > throughout > > > > > > > > > its Rust implementation. > > > > > > > > > - prek depends on Asyncband and is used in Apache Airflow’s > > > > > > > > > development workflows, creating an indirect relationship with > > > > Apache > > > > > > > > > Airflow. > > > > > > > > > - Asyncband 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 Asyncband is hosted at > > > > https://docs.rs/mea. > > > > > > > > > > > > > > > > > > If the proposal is accepted, the community may establish a > > > > project > > > > > > > > > website at asyncband.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 > > > > > > > > > - https://gitbox.apache.org/asf/repos/asyncband > > > > > > > > > - https://github.com/apache/asyncband > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > -- > > > > > > > > Xuanwo > > > > > > > > > > > > > > > > https://xuanwo.io/ > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
