RE: Final draft of the Incubator Board Report - April 2016
Hi, John I think our mentors are busy during the day. Patrick was on vacation last week. I'd suggest give them a few more hours to signoff the report. Thanks, Yanping -Original Message- From: John D. Ament [mailto:johndam...@apache.org] Sent: Tuesday, April 12, 2016 4:32 PM To: general@incubator.apache.org Subject: Re: Final draft of the Incubator Board Report - April 2016 I'm a bit curious about how we should handle Mnemonic. I've received no response thus far from the podling. I'd rather not kick them out of the monthly report. John On Mon, Apr 11, 2016 at 11:28 PM Marvin Humphreywrote: > On Mon, Apr 11, 2016 at 3:56 AM, John D. Ament > wrote: > > > Below is the final draft of the board report. > > The report looks good to me! Comments inline. > > > - Airflow > > - Gearpump > > - Mnemonic > > - Omid > > - Tephra > > > > * Graduations > > > > The board has motions for the following: > > > > - Apex > > - Johnzon > > - TinkerPop > > - AsterixDB > > What turnover! I see that with the addition of Quickstep that's *six* new > podlings in one month, which has to be a record. > > Congrats to all the entrants and graduates! > > > * Credits > > > > - Report Manager: > > I added the credit for this month's erstwhile Report Manager. :) > > > * Did not report, expected next month > > > > - Concerted > > - OpenAz > > - Tephra > > The OpenAZ report was due in January and is thus 4 months late, which I > have > now noted on the wiki. OpenAZ's status has been raised on > private@incubator > and we just have to keep raising it each month until a report gets filed. > > > > > Fineract > > > > Fineract is an open source system for core banking as a platform. > > > > Fineract has been incubating since 2015-12-15. > > > > Three most important issues to address in the move towards graduation: > > > > 1. Finalising the initial release > > 2. Improve the communication around the differences between the > previous > > MifosX project and the new Fineract project, especially in the > MifosX > > community, website etc. > > 3. With the first initial release, encourage the community to use the > > proper infastructure (mailing lists, issue tracker) for the ongoing > > collaboration within the community. > > 4. Change management towards less 'key-man' dependency on previous > > tech/community leaders from MifosX, more towards community driven > > consensus. > > 5. Reduce clutter on mailinglist from JIRA updates etc. > > > > Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be > > aware of? > > > > On the mailinglist there have been discussions around the lack of > traffic > > on it. This is part of the switchover from the current MifosX community > > and mailinglists towards the new Fineract lists. At the same time the > > recent meet-up of Mifosx and Fineract devs and people interested in it > > (see community development), has also triggered a lot of offline > > interaction. > > > > How has the community developed since the last report? > > > > While activity on the mailinglist has been pretty low, we've had a > great > > meet-up in Amsterdam where a nice mix of existing MifosX community > members > > and a group of new interested people was present. This has boosted > > interest in Fineract. > > > > We have a high level of interest from new contributors throughout > Africa - > > we are working to properly engage them and guide them to the correct > > collaboration channels in our Fineract community. > > > > How has the project developed since the last report? > > > > Individual members of the leading partner organizations building > solutions > > using the Fineract platform have begun to effectively use the Fineract > > issue tracker to communicate and track the requirements and > enhancements > > they're building and contributing to Fineract. These individuals are > > setting a good example that other individuals from our partner > community > > should follow. > > > > Date of last release: > > > > N/A > > > > When were the last committers or PMC members elected? > > > > N/A > > > > Signed-off-by: > > > > [ ](fineract) Ross Gardler > > [ ](fineract) Greg Stein > > [X](fineract) Roman Shaposhnik > > This report provides excellent insight into the challenges and > opportunities > before the Fineract community. Thank you for a good read, and good luck! > > > > > FreeMarker > > > How has the project developed since the last report? > > > > FreeMarker had two public releases: A Release Candidate (so that users > can > > test it), and one final release. Apart from the new features and > fixes, we > > have adjusted the source code and build process to follow Apache best > > practices more closely, and to be more appealing for contributors > > (switching to Java 5, fixing formatting
RE: [DISCUSS] Mnemonic incubator proposal
In general, Mnemonic can be integrated into many projects. First, projects can use Mnemonic to take data off Java heap so GC can be much reduced, and use GET/SET to access data fields so serdes can be eliminated. Later we can expand Mnemonic to excise persistent/non-volatile programming on large scaled distributed systems with TB sized fast persistent memory devices. Regarding solving Hadoop Namenode pressure of large scale of cluster scenarios. This issue is due to HDFS. Last year we found the use of FileInputStream in HDFS causes unpredicted long Garbage Collection pauses due to the overhead of finalizers and significantly impacted HDFS performance and its scalability. We recorded the issue in https://issues.apache.org/jira/browse/HDFS-8562 Uma explained what we can do for using Mnemonic to improve HDFS performance and scalability. One big advantage is Mnemonic does not need to hold File System cache for random access, which will benefit large scale of clusters. Thanks yanping -Original Message- From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com] Sent: Tuesday, February 23, 2016 8:06 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Mnemonic incubator proposal Hi Liang, Thank you for your interest. Sure we would consider you adding in interested contributors list. >Mnemonic is trying to solve performance issues associated with serialization/deserialization of java object when dealing with JVM & disk directly as well as GC pressure caused by caching ? Yes. >whether Mnemonic could solve Hadoop Namenode pressure of large scale of cluster scenaros, or not? Yeah, we are thinking on some aspects considering memory and GC overheads in Namenode too. Example couple of JIRAs already there in HDFS to move some of data structure to off heap. So, we had plans to get the standard data structures from this library and can make use of them push. Also we could make advantage if persistence here. @Yanping/Gary, may be you could add more points if you have? [Gary] Thanks Uma, in addition, you can plug-in your special allocators that could be optimized for namenode usage patterns, by this way, the performance could be better and more predictable. Thanks. Regards, Uma On 2/23/16, 6:48 PM, "Liang Chen"wrote: >Interesting, would love to become the contributor > >My understanding: Mnemonic is trying to solve performance issues >associated with serialization/deserialization of java object when >dealing with JVM & disk directly as well as GC pressure caused by >caching ? > >one question: whether Mnemonic could solve Hadoop Namenode pressure of >large scale of cluster scenaros, or not? > > > >-- >View this message in context: >http://apache-incubator-general.996316.n3.nabble.com/DISCUSS-Mnemonic-i >ncu >bator-proposal-tp48502p48533.html >Sent from the Apache Incubator - General mailing list archive at >Nabble.com. > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Mnemonic incubator proposal
Hi, All I uploaded a PDF presentation that describes Project Mnemonic with some nice pictures. Click Attachment link below to see the presentation. Attachment name: Project_Mnemonic_Pub1.0.pdf Attachment size: 1493317 Attachment link: https://wiki.apache.org/incubator/MnemonicProposal?action=AttachFile=get=Project_Mnemonic_Pub1.0.pdf Page link: https://wiki.apache.org/incubator/MnemonicProposal Thanks Yanping -Original Message- From: Wang, Yanping [mailto:yanping.w...@intel.com] Sent: Sunday, February 21, 2016 11:47 AM To: general@incubator.apache.org Subject: [DISCUSS] Mnemonic incubator proposal Hi all We'd like to start a discussion regarding a proposal to submit Mnemonic to the Apache Incubator. The proposal text is available on the Wiki here: https://wiki.apache.org/incubator/MnemonicProposal and pasted below for convenience. We are excited to make this proposal, and look forward to the community's input! Best, Yanping = Mnemonic Proposal = === Abstract === Mnemonic is a Java based non-volatile memory library for in-place structured data processing and computing. It is a solution for generic object and block persistence on heterogeneous block and byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD, and cloud network storage. === Proposal === Mnemonic is a structured data persistence in-memory in-place library for Java-based applications and frameworks. It provides unified interfaces for data manipulation on heterogeneous block/byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD, and cloud network devices. The design motivation for this project is to create a non-volatile programming paradigm for in-memory data object persistence, in-memory data objects caching, and JNI-less IPC. Mnemonic simplifies the usage of data object caching, persistence, and JNI-less IPC for massive object oriented structural datasets. Mnemonic defines Non-Volatile Java objects that store data fields in persistent memory and storage. During the program runtime, only methods and volatile fields are instantiated in Java heap, Non-Volatile data fields are directly accessed via GET/SET operation to and from persistent memory and storage. Mnemonic avoids SerDes and significantly reduces amount of garbage in Java heap. Major features of Mnemonic: * Provides an abstract level of viewpoint to utilize heterogeneous block/byte-addressable device as a whole (e.g., DRAM, persistent memory, NVMe, SSD, HD, cloud network Storage). * Provides seamless support object oriented design and programming without adding burden to transfer object data to different form. * Avoids the object data serialization/de-serialization for data retrieval, caching and storage. * Reduces the consumption of on-heap memory and in turn to reduce and stabilize Java Garbage Collection (GC) pauses for latency sensitive applications. * Overcomes current limitations of Java GC to manage much larger memory resources for massive dataset processing and computing. * Supports the migration data usage model from traditional NVMe/SSD/HD to non-volatile memory with ease. * Uses lazy loading mechanism to avoid unnecessary memory consumption if some data does not need to use for computing immediately. * Bypasses JNI call for the interaction between Java runtime application and its native code. * Provides an allocation aware auto-reclaim mechanism to prevent external memory resource leaking. === Background === Big Data and Cloud applications increasingly require both high throughput and low latency processing. Java-based applications targeting the Big Data and Cloud space should be tuned for better throughput, lower latency, and more predictable response time. Typically, there are some issues that impact BigData applications' performance and scalability: 1) The Complexity of Data Transformation/Organization: In most cases, during data processing, applications use their own complicated data caching mechanism for SerDes data objects, spilling to different storage and eviction large amount of data. Some data objects contains complex values and structure that will make it much more difficulty for data organization. To load and then parse/decode its datasets from storage consumes high system resource and computation power. 2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes Frequent Long GC Pauses: Big Data computing/syntax generates large amount of temporary objects during processing, e.g. lambda, SerDes, copying and etc. This will trigger frequent long Java GC pause to scan references, to update references lists, and to copy live objects from one memory location to another blindly. 3) The Unpredictable GC Pause: For latency sensitive applications, such as database, search engine, web query, real-time/streaming computing, require latency/request-response under control. But current Java GC does not provide predictable GC activities with large on-heap
RE: [DISCUSS] Mnemonic incubator proposal
Yes, Jacques, it is exciting to see Arrow and Mnemonic can leverage each other. I looked at Apache Drill today. I think Drill can use Mnemonic to optimize scalable data sources. So the idea is, Mnemonic takes Arrow as a columnar data construct or collection that optimized from memory to CPU cache. Then Drill can use Arrow integrated Mnemonic to access cross distributed systems storage media for scalable data sources. Drill + (Mnemonic (Arrow)) Integration => Optimize entire data access chains from distributed storage media to CPU cache. Definitely looking forward to working together. Best, Yanping -Original Message- From: Jacques Nadeau [mailto:jacq...@apache.org] Sent: Monday, February 22, 2016 4:43 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Mnemonic incubator proposal Hey YanPing, This addition is nice to see. I agree that there is great opportunity for the Arrow and Mnemonic communities to collaborate. I look forward to working together. Jacques On Mon, Feb 22, 2016 at 3:01 PM, Wang, Yanping <yanping.w...@intel.com> wrote: > Hi, All > > Based on feedback, we added following into Mnemonic proposal: > > Relationships with Other Apache Product > + Relationship with Apache™ Arrow: > + Arrow's columnar data layout allows great use of CPU caches & SIMD. It > places all data that relevant to a column operation in a compact format in > memory. > + > + Mnemonic directly puts the whole business object graphs on external > heterogeneous storage media, e.g. off-heap, SSD. It is not necessary to > normalize the structures of object graphs for caching, checkpoint or > storing. It doesn’t require developers to normalize their data object > graphs. Mnemonic applications can avoid indexing & join datasets compared > to traditional approaches. > + > + Mnemonic can leverage Arrow to transparently re-layout qualified data > objects or create special containers that is able to efficiently hold those > data records in columnar form as one of major performance optimization > constructs. > + > > Thanks > Yanping > > -Original Message- > From: Wang, Yanping [mailto:yanping.w...@intel.com] > Sent: Sunday, February 21, 2016 11:47 AM > To: general@incubator.apache.org > Subject: [DISCUSS] Mnemonic incubator proposal > > Hi all > > We'd like to start a discussion regarding a proposal to submit Mnemonic to > the Apache Incubator. > > The proposal text is available on the Wiki here: > https://wiki.apache.org/incubator/MnemonicProposal > > and pasted below for convenience. > > We are excited to make this proposal, and look forward to the community's > input! > > Best, > Yanping > > > = Mnemonic Proposal = > === Abstract === > Mnemonic is a Java based non-volatile memory library for in-place > structured data processing and computing. It is a solution for generic > object and block persistence on heterogeneous block and byte-addressable > devices, such as DRAM, persistent memory, NVMe, SSD, and cloud network > storage. > > === Proposal === > Mnemonic is a structured data persistence in-memory in-place library for > Java-based applications and frameworks. It provides unified interfaces for > data manipulation on heterogeneous block/byte-addressable devices, such as > DRAM, persistent memory, NVMe, SSD, and cloud network devices. > > The design motivation for this project is to create a non-volatile > programming paradigm for in-memory data object persistence, in-memory data > objects caching, and JNI-less IPC. > Mnemonic simplifies the usage of data object caching, persistence, and > JNI-less IPC for massive object oriented structural datasets. > > Mnemonic defines Non-Volatile Java objects that store data fields in > persistent memory and storage. During the program runtime, only methods and > volatile fields are instantiated in Java heap, Non-Volatile data fields are > directly accessed via GET/SET operation to and from persistent memory and > storage. Mnemonic avoids SerDes and significantly reduces amount of garbage > in Java heap. > > Major features of Mnemonic: > * Provides an abstract level of viewpoint to utilize heterogeneous > block/byte-addressable device as a whole (e.g., DRAM, persistent memory, > NVMe, SSD, HD, cloud network Storage). > * Provides seamless support object oriented design and programming without > adding burden to transfer object data to different form. > * Avoids the object data serialization/de-serialization for data > retrieval, caching and storage. > * Reduces the consumption of on-heap memory and in turn to reduce and > stabilize Java Garbage Collection (GC) pauses for latency sensitive > applications. > * Overcomes current limitations of Java GC to manage much
RE: [DISCUSS] Mnemonic incubator proposal
Hi, All Based on feedback, we added following into Mnemonic proposal: Relationships with Other Apache Product + Relationship with Apache™ Arrow: + Arrow's columnar data layout allows great use of CPU caches & SIMD. It places all data that relevant to a column operation in a compact format in memory. + + Mnemonic directly puts the whole business object graphs on external heterogeneous storage media, e.g. off-heap, SSD. It is not necessary to normalize the structures of object graphs for caching, checkpoint or storing. It doesn’t require developers to normalize their data object graphs. Mnemonic applications can avoid indexing & join datasets compared to traditional approaches. + + Mnemonic can leverage Arrow to transparently re-layout qualified data objects or create special containers that is able to efficiently hold those data records in columnar form as one of major performance optimization constructs. + Thanks Yanping -Original Message- From: Wang, Yanping [mailto:yanping.w...@intel.com] Sent: Sunday, February 21, 2016 11:47 AM To: general@incubator.apache.org Subject: [DISCUSS] Mnemonic incubator proposal Hi all We'd like to start a discussion regarding a proposal to submit Mnemonic to the Apache Incubator. The proposal text is available on the Wiki here: https://wiki.apache.org/incubator/MnemonicProposal and pasted below for convenience. We are excited to make this proposal, and look forward to the community's input! Best, Yanping = Mnemonic Proposal = === Abstract === Mnemonic is a Java based non-volatile memory library for in-place structured data processing and computing. It is a solution for generic object and block persistence on heterogeneous block and byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD, and cloud network storage. === Proposal === Mnemonic is a structured data persistence in-memory in-place library for Java-based applications and frameworks. It provides unified interfaces for data manipulation on heterogeneous block/byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD, and cloud network devices. The design motivation for this project is to create a non-volatile programming paradigm for in-memory data object persistence, in-memory data objects caching, and JNI-less IPC. Mnemonic simplifies the usage of data object caching, persistence, and JNI-less IPC for massive object oriented structural datasets. Mnemonic defines Non-Volatile Java objects that store data fields in persistent memory and storage. During the program runtime, only methods and volatile fields are instantiated in Java heap, Non-Volatile data fields are directly accessed via GET/SET operation to and from persistent memory and storage. Mnemonic avoids SerDes and significantly reduces amount of garbage in Java heap. Major features of Mnemonic: * Provides an abstract level of viewpoint to utilize heterogeneous block/byte-addressable device as a whole (e.g., DRAM, persistent memory, NVMe, SSD, HD, cloud network Storage). * Provides seamless support object oriented design and programming without adding burden to transfer object data to different form. * Avoids the object data serialization/de-serialization for data retrieval, caching and storage. * Reduces the consumption of on-heap memory and in turn to reduce and stabilize Java Garbage Collection (GC) pauses for latency sensitive applications. * Overcomes current limitations of Java GC to manage much larger memory resources for massive dataset processing and computing. * Supports the migration data usage model from traditional NVMe/SSD/HD to non-volatile memory with ease. * Uses lazy loading mechanism to avoid unnecessary memory consumption if some data does not need to use for computing immediately. * Bypasses JNI call for the interaction between Java runtime application and its native code. * Provides an allocation aware auto-reclaim mechanism to prevent external memory resource leaking. === Background === Big Data and Cloud applications increasingly require both high throughput and low latency processing. Java-based applications targeting the Big Data and Cloud space should be tuned for better throughput, lower latency, and more predictable response time. Typically, there are some issues that impact BigData applications' performance and scalability: 1) The Complexity of Data Transformation/Organization: In most cases, during data processing, applications use their own complicated data caching mechanism for SerDes data objects, spilling to different storage and eviction large amount of data. Some data objects contains complex values and structure that will make it much more difficulty for data organization. To load and then parse/decode its datasets from storage consumes high system resource and computation power. 2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes Frequent Long GC Pauses: Big Data computing/syntax g
RE: [DISCUSS] Mnemonic incubator proposal
That's great, thanks Debo, I will add you as additional interested contributors. Thanks Yanping -Original Message- From: Debo Dutta (dedutta) [mailto:dedu...@cisco.com] Sent: Sunday, February 21, 2016 3:26 PM To: general@incubator.apache.org Subject: Re: [DISCUSS] Mnemonic incubator proposal Hi Yanping This is very interesting and timely. Would love to contribute, participate etc. thx debo On 2/21/16, 11:47 AM, "Wang, Yanping" <yanping.w...@intel.com> wrote: >Hi all > >We'd like to start a discussion regarding a proposal to submit Mnemonic >to the Apache Incubator. > >The proposal text is available on the Wiki here: >https://wiki.apache.org/incubator/MnemonicProposal > >and pasted below for convenience. > >We are excited to make this proposal, and look forward to the community's >input! > >Best, >Yanping > > >= Mnemonic Proposal = >=== Abstract === >Mnemonic is a Java based non-volatile memory library for in-place >structured data processing and computing. It is a solution for generic >object and block persistence on heterogeneous block and byte-addressable >devices, such as DRAM, persistent memory, NVMe, SSD, and cloud network >storage. > >=== Proposal === >Mnemonic is a structured data persistence in-memory in-place library for >Java-based applications and frameworks. It provides unified interfaces >for data manipulation on heterogeneous block/byte-addressable devices, >such as DRAM, persistent memory, NVMe, SSD, and cloud network devices. > >The design motivation for this project is to create a non-volatile >programming paradigm for in-memory data object persistence, in-memory >data objects caching, and JNI-less IPC. >Mnemonic simplifies the usage of data object caching, persistence, and >JNI-less IPC for massive object oriented structural datasets. > >Mnemonic defines Non-Volatile Java objects that store data fields in >persistent memory and storage. During the program runtime, only methods >and volatile fields are instantiated in Java heap, Non-Volatile data >fields are directly accessed via GET/SET operation to and from persistent >memory and storage. Mnemonic avoids SerDes and significantly reduces >amount of garbage in Java heap. > >Major features of Mnemonic: >* Provides an abstract level of viewpoint to utilize heterogeneous >block/byte-addressable device as a whole (e.g., DRAM, persistent memory, >NVMe, SSD, HD, cloud network Storage). >* Provides seamless support object oriented design and programming >without adding burden to transfer object data to different form. >* Avoids the object data serialization/de-serialization for data >retrieval, caching and storage. >* Reduces the consumption of on-heap memory and in turn to reduce and >stabilize Java Garbage Collection (GC) pauses for latency sensitive >applications. >* Overcomes current limitations of Java GC to manage much larger memory >resources for massive dataset processing and computing. >* Supports the migration data usage model from traditional NVMe/SSD/HD to >non-volatile memory with ease. >* Uses lazy loading mechanism to avoid unnecessary memory consumption if >some data does not need to use for computing immediately. >* Bypasses JNI call for the interaction between Java runtime application >and its native code. >* Provides an allocation aware auto-reclaim mechanism to prevent external >memory resource leaking. > > >=== Background === >Big Data and Cloud applications increasingly require both high throughput >and low latency processing. Java-based applications targeting the Big >Data and Cloud space should be tuned for better throughput, lower >latency, and more predictable response time. >Typically, there are some issues that impact BigData applications' >performance and scalability: > >1) The Complexity of Data Transformation/Organization: In most cases, >during data processing, applications use their own complicated data >caching mechanism for SerDes data objects, spilling to different storage >and eviction large amount of data. Some data objects contains complex >values and structure that will make it much more difficulty for data >organization. To load and then parse/decode its datasets from storage >consumes high system resource and computation power. > >2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes >Frequent Long GC Pauses: Big Data computing/syntax generates large amount >of temporary objects during processing, e.g. lambda, SerDes, copying and >etc. This will trigger frequent long Java GC pause to scan references, to >update references lists, and to copy live objects from one memory >location to another blindly. > >3) The Unpredictable GC Pause: For latency sensitive applications, such >as datab
[DISCUSS] Mnemonic incubator proposal
tible Licenses Note: The runtime dependent licenses of Mnemonic are all declared as Apache 2.0, the GNU licensed components are used for Mnemonic build and deployment. The Mnemonic JNI libraries are built using the GNU tools. maven and its plugins (http://maven.apache.org/ ) [Apache 2.0] JDK8 or OpenJDK 8 (http://java.com/) [Oracle or Openjdk JDK License] Nvml (http://pmem.io ) [optional] [Open Source] PMalloc (https://github.com/bigdata-memory/pmalloc ) [optional] [Apache 2.0] Build and test dependencies: org.testng.testng v6.8.17 (http://testng.org) [Apache 2.0] org.flowcomputing.commons.commons-resgc v0.8.7 [Apache 2.0] org.flowcomputing.commons.commons-primitives v.0.6.0 [Apache 2.0] com.squareup.javapoet v1.3.1-SNAPSHOT [Apache 2.0] JDK8 or OpenJDK 8 (http://java.com/) [Oracle or Openjdk JDK License] === Cryptography === Project Mnemonic does not use cryptography itself, however, Hadoop projects use standard APIs and tools for SSH and SSL communication where necessary. === Required Resources === We request that following resources be created for the project to use Mailing lists priv...@mnemonic.incubator.apache.org (moderated subscriptions) comm...@mnemonic.incubator.apache.org d...@mnemonic.incubator.apache.org Git repository https://github.com/apache/incubator-mnemonic Documentation https://mnemonic.incubator.apache.org/docs/ JIRA instance https://issues.apache.org/jira/browse/mnemonic === Initial Committers === * Gang (Gary) Wang (gang1 dot wang at intel dot com) * Yanping Wang (yanping dot wang at intel dot com) * Uma Maheswara Rao G (umamahesh at apache dot org) * Kai Zheng (drankye at apache dot org) * Rakesh Radhakrishnan Potty (rakeshr at apache dot org) * Sean Zhong (seanzhong at apache dot org) * Henry Saputra (hsaputra at apache dot org) * Hao Cheng (hao dot cheng at intel dot com) === Affiliations === * Gang (Gary) Wang, Intel * Yanping Wang, Intel * Uma Maheswara Rao G, Intel * Kai Zheng, Intel * Rakesh Radhakrishnan Potty, Intel * Sean Zhong, Intel * Henry Saputra, Independent * Hao Cheng, Intel === Sponsors === Champion Patrick Hunt Nominated Mentors * Patrick Hunt - Apache IPMC member * Andrew Purtell - Apache IPMC member * James Taylor - Apache IPMC member * Henry Saputra - Apache IPMC member Sponsoring Entity Apache Incubator PMC
Wiki write access request
Hi - I'd like to request write access to the incubator wiki. My username is YanpingWang1 I'm intending to create/update a project proposal. Thanks! Yanping - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org