Re: [DISCUSS] Incubating Proposal of ResilientDB
Everything we have done including research/papers and outcome of development have been open for years. We simply wanted to keep the public repo cleaner and we only released when we were certain that the new feature is well tested and stable. We will switch our development completely to our public repo effective immediately. That is not issue at all. Best Regards, Mohammad Sadoghi, PhD Associate Professor Exploratory Systems Lab (ExpoLab) Department of Computer Science University of California, Davis On Sun, Oct 8, 2023 at 3:08 AM Willem Jiang wrote: > I just checked the GitHub issue and PRs of ResilientDB. There is > little discussion on the GitHub issue and review comments on GitHub > PRs. > Please keep Open Communications[1] in mind. We value transparency in > the ASF way. Internal development could block the contributions > outside of the organization and cause us some trouble in building the > community. > > Once the development switches to the public repo, the project could be > ready to enter the incubation process. > > [1] > https://www.apache.org/theapacheway/#what-makes-the-apache-way-so-hard-to-define > > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Sun, Oct 8, 2023 at 3:33 PM Mohammad Sadoghi > wrote: > > > > Thank you for your question. > > > > With regards to the initial committers, over the years we had much larger > > set of contributors who worked on the private repo of ResilientDB which > > derives the research. Only when features are stable and well tested over > > time, they have been advanced and promoted to our public repo. Our > private > > repo has many more experimental features that as part of our roadmap will > > be released once they reach the same level of maturity. > > > > Best Regards, > > Mohammad Sadoghi, PhD > > Associate Professor > > Exploratory Systems Lab (ExpoLab) > > Department of Computer Science > > University of California, Davis > > > > > > On Sun, Oct 8, 2023 at 12:23 AM Willem Jiang > wrote: > > > > > Hi, > > > > > > I have a quick question about the initial committers. > > > There are about 40+ initial committers, but I can only find about 20 > > > contributors in the GitHub group[1] contributor list. > > > Could you explain the initial committer criteria? > > > There is a section of "Broader Contributing Members" in the > > > proposal[2] after the initial committer, if we treat them as initial > > > committers, why do we need to separate them with the initial > > > committer? > > > > > > Thanks, > > > > > > [1]https://github.com/resilientdb > > > [2] > > > > https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Sun, Oct 8, 2023 at 1:38 PM 俊平堵 wrote: > > > > > > > > +1. > > > > btw, I assume we will have an official vote thread (start with > [VOTE]) > > > > later? > > > > > > > > Thanks, > > > > > > > > JP > > > > > > > > Atri Sharma 于2023年10月3日周二 19:24写道： > > > > > > > > > We want to propose ResilientDB as a new Apache Incubator project. > > > > > > > > > > ResilientDB[1] is a distributed blockchain framework that is > written > > > > > in C++ and integrates with Byzantine Fault-Tolerant (BFT) and Crash > > > > > Fault-Tolerant (CFT) consensus protocols. Code is present at [2]. > > > > > > > > > > Key features: > > > > > > > > > > Provides a scalable client-server architecture. Each developer can > use > > > > > the ResilientDB framework to deploy a replicated service acting as > a > > > > > service. The developer can choose the desired number of replicas > and > > > > > the number of clients its system should tolerate. > > > > > > > > > > Provides native integration with PBFT consensus protocol – arguably > > > > > the most popular BFT consensus protocol. PBFT helps replicas reach > an > > > > > agreement for ordering the client's requests. > > > > > > > > > > Provides a mechanism to simulate the failure of different replicas > > > > > (including the leader). > > > > > > > > > > Provides a correct implementation of the view-change protocol that > > > > > replaces a faulty (or malicious) leader and moves all replicas to > the > > > > > new view. > > > > > > > > > > Provides checkpoint and recovery protocols to facilitate garbage > > > > > collection, recovery of failed replicas, and durably logging of the > > > > > blockchain state. > > > > > > > > > > Eases development and testing of newer and optimized BFT and CFT > > > > > consensus protocols. > > > > > Provides clients with support for three different application > > > interfaces: > > > > > > > > > > Key-Value Stores - where client transactions include key-value > pairs. > > > > > > > > > > Smart Contracts - where clients issue smart contracts in Solidity > for > > > > > processing. > > > > > > > > > > UTXO - where clients issue unspent transactions similar to ones in > > > Bitcoin. > > > > > > > > > > Facilitates benchmarking system/protocol performance with the
Re: [DISCUSS] Incubating Proposal of Answer
Dear Incubator Members, I hope this message finds you well. We've noticed discussions about the project name and would love to spread our voice here. We've used "Answer" since the project's inception, and have attached to it over the past year. Some of our users are also very familiar with this name. According to feedback from the Apache trademarks team: 'It is possible to use such a name on the understanding that obtaining a trademark for it is likely to be a more difficult (and longer) process.' We understand it may be a longer process, but we believe using "Answer" shouldn't pose significant issues. Therefore, we propose that we maintain "Answer" as the project name during the current voting phase. The name 'Answer' is currently not trademarked, and we will assist ASF in registering the trademark in the future. Additionally, we want to clarify that, as of now, we haven't developed any commercial products or online services under the "Answer" project name. Once again, thank you for your discussions and interest in the project. Best Regards, Anne Sheng Wu 于2023年9月29日周五 18:16写道： > I think it is good to go. > > Sheng Wu 吴晟 > > Apache SkyWalking > Twitter, wusheng1108 > > > tison 于2023年9月29日 周五15:48写道： > > > This proposal should be good to go :D > > > > Best, > > tison. > > > > > > Willem Jiang 于2023年9月28日周四 18:34写道： > > > > > Hi, > > > > > > After talking with the Answer development team about the brand name > > > issue, there is some feedback from the team. > > > They still want to use the answer as the project name, and they don't > > > plan to provide commercial products or online services based on this > > > project so far. > > > > > > Please let me know if there are any other concerns about this project. > > > I will start a vote next week if there are no other objections. > > > > > > Best regards, > > > > > > Willem Jiang > > > > > > Twitter: willemjiang > > > Weibo: 姜宁willem > > > > > > On Thu, Sep 21, 2023 at 11:14 PM tison wrote: > > > > > > > > Hi, > > > > > > > > About the project name and trademark, according to the trademarks@ > > > reply, > > > > > > > > > It is possible to use such a name on the understanding that > > obtaining a > > > > > trademark for it is likely to be a more difficult (and longer) > > process. > > > > > > > > So it's viable and I also inform the initial committers to think of > the > > > > pros and cons. > > > > > > > > Let's say we don't have a blocker here but potential trade-offs. > Apache > > > > Arrow can be > > > > a compare whose name is also a common word, and the community built > up > > > the > > > > brand recognition so the name is associated with the project. > > > > > > > > Best, > > > > tison. > > > > > > > > > > > > Willem Jiang 于2023年9月21日周四 23:00写道： > > > > > > > > > Hi PJ, > > > > > > > > > > Thanks for the reply, I will talk to the team and find out if we > can > > > > > figure out a better name for it. > > > > > I raised the same question when I first heard about the name, but > > it's > > > > > hard for the team to give up the product word they already have > > > > > without a solid objection. > > > > > > > > > > Willem Jiang > > > > > > > > > > Twitter: willemjiang > > > > > Weibo: 姜宁willem > > > > > On Thu, Sep 21, 2023 at 9:36 PM PJ Fanning > > > wrote: > > > > > > > > > > > > For me, Answer is a problematic name. We're trying to move away > > from > > > > > > relying on the Apache brand name so project names ideally should > > work > > > > > > with or without the Apache name. Answer does not work as a brand > on > > > > > > its own, it depends on being Apache Answer to make it seem like a > > > > > > brand. I'm not saying that we should stop calling our projects > > Apache > > > > > > XYZ yet but I just think the XYZ needs to work as a standalone > > > project > > > > > > name too. Even something like 'Answer Platform' and 'Apache > Answer > > > > > > Platform' might make the name more specific. Imagine trying to > > search > > > > > > online for 'Answer'. There are more than 14 billion matches on > > > Google. > > > > > > > > > > > > On Thu, 21 Sept 2023 at 13:51, Sheng Wu < > wu.sheng.841...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > I have a question for the mentors, do you check whether this > > > general > > > > > > > word, `Answer` is an acceptable project name for the > foundation? > > > > > > > > > > > > > > Sheng Wu 吴晟 > > > > > > > Twitter, wusheng1108 > > > > > > > > > > > > > > Jean-Baptiste Onofré 于2023年9月21日周四 20:39写道： > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > It looks interesting at first glance. I will do a new pass on > > the > > > > > > > > proposal (in more details). > > > > > > > > > > > > > > > > Regards > > > > > > > > JB > > > > > > > > > > > > > > > > On Thu, Sep 21, 2023 at 2:00 PM Willem Jiang < > > > willem.ji...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > > > > > > We want to propose Answer as a new Apache Incubator >
Re: [DISCUSS] Incubating Proposal of ResilientDB
I just checked the GitHub issue and PRs of ResilientDB. There is little discussion on the GitHub issue and review comments on GitHub PRs. Please keep Open Communications[1] in mind. We value transparency in the ASF way. Internal development could block the contributions outside of the organization and cause us some trouble in building the community. Once the development switches to the public repo, the project could be ready to enter the incubation process. [1]https://www.apache.org/theapacheway/#what-makes-the-apache-way-so-hard-to-define Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Sun, Oct 8, 2023 at 3:33 PM Mohammad Sadoghi wrote: > > Thank you for your question. > > With regards to the initial committers, over the years we had much larger > set of contributors who worked on the private repo of ResilientDB which > derives the research. Only when features are stable and well tested over > time, they have been advanced and promoted to our public repo. Our private > repo has many more experimental features that as part of our roadmap will > be released once they reach the same level of maturity. > > Best Regards, > Mohammad Sadoghi, PhD > Associate Professor > Exploratory Systems Lab (ExpoLab) > Department of Computer Science > University of California, Davis > > > On Sun, Oct 8, 2023 at 12:23 AM Willem Jiang wrote: > > > Hi, > > > > I have a quick question about the initial committers. > > There are about 40+ initial committers, but I can only find about 20 > > contributors in the GitHub group[1] contributor list. > > Could you explain the initial committer criteria? > > There is a section of "Broader Contributing Members" in the > > proposal[2] after the initial committer, if we treat them as initial > > committers, why do we need to separate them with the initial > > committer? > > > > Thanks, > > > > [1]https://github.com/resilientdb > > [2] > > https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal > > > > Willem Jiang > > > > Twitter: willemjiang > > Weibo: 姜宁willem > > > > On Sun, Oct 8, 2023 at 1:38 PM 俊平堵 wrote: > > > > > > +1. > > > btw, I assume we will have an official vote thread (start with [VOTE]) > > > later? > > > > > > Thanks, > > > > > > JP > > > > > > Atri Sharma 于2023年10月3日周二 19:24写道： > > > > > > > We want to propose ResilientDB as a new Apache Incubator project. > > > > > > > > ResilientDB[1] is a distributed blockchain framework that is written > > > > in C++ and integrates with Byzantine Fault-Tolerant (BFT) and Crash > > > > Fault-Tolerant (CFT) consensus protocols. Code is present at [2]. > > > > > > > > Key features: > > > > > > > > Provides a scalable client-server architecture. Each developer can use > > > > the ResilientDB framework to deploy a replicated service acting as a > > > > service. The developer can choose the desired number of replicas and > > > > the number of clients its system should tolerate. > > > > > > > > Provides native integration with PBFT consensus protocol – arguably > > > > the most popular BFT consensus protocol. PBFT helps replicas reach an > > > > agreement for ordering the client's requests. > > > > > > > > Provides a mechanism to simulate the failure of different replicas > > > > (including the leader). > > > > > > > > Provides a correct implementation of the view-change protocol that > > > > replaces a faulty (or malicious) leader and moves all replicas to the > > > > new view. > > > > > > > > Provides checkpoint and recovery protocols to facilitate garbage > > > > collection, recovery of failed replicas, and durably logging of the > > > > blockchain state. > > > > > > > > Eases development and testing of newer and optimized BFT and CFT > > > > consensus protocols. > > > > Provides clients with support for three different application > > interfaces: > > > > > > > > Key-Value Stores - where client transactions include key-value pairs. > > > > > > > > Smart Contracts - where clients issue smart contracts in Solidity for > > > > processing. > > > > > > > > UTXO - where clients issue unspent transactions similar to ones in > > Bitcoin. > > > > > > > > Facilitates benchmarking system/protocol performance with the help of > > > > existing benchmarks, such as YCSB [SoCC’10] and Diablo [EuroSys’23]. > > > > > > > > Stores non-volatile ledger (blockchain) in memory and for further > > > > durability, provides APIs to store both client data and blockchain in > > > > LevelDB and RocksDB. > > > > > > > > > > > > The serving mentors would be: > > > > > > > > Junping Du > > > > > > > > Calvin Kirs > > > > > > > > Kevin Ratnasekera > > > > > > > > Roman Shaposhnik > > > > > > > > Christian Grobmeier > > > > > > > > and I shall be serving as the Champion. > > > > > > > > We have not done a trademark check yet for the name but that can be > > > > pursued independently. > > > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal > > > > [2]
Re: [DISCUSS] Incubating Proposal of ResilientDB
Thank you for your question. With regards to the initial committers, over the years we had much larger set of contributors who worked on the private repo of ResilientDB which derives the research. Only when features are stable and well tested over time, they have been advanced and promoted to our public repo. Our private repo has many more experimental features that as part of our roadmap will be released once they reach the same level of maturity. Best Regards, Mohammad Sadoghi, PhD Associate Professor Exploratory Systems Lab (ExpoLab) Department of Computer Science University of California, Davis On Sun, Oct 8, 2023 at 12:23 AM Willem Jiang wrote: > Hi, > > I have a quick question about the initial committers. > There are about 40+ initial committers, but I can only find about 20 > contributors in the GitHub group[1] contributor list. > Could you explain the initial committer criteria? > There is a section of "Broader Contributing Members" in the > proposal[2] after the initial committer, if we treat them as initial > committers, why do we need to separate them with the initial > committer? > > Thanks, > > [1]https://github.com/resilientdb > [2] > https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Sun, Oct 8, 2023 at 1:38 PM 俊平堵 wrote: > > > > +1. > > btw, I assume we will have an official vote thread (start with [VOTE]) > > later? > > > > Thanks, > > > > JP > > > > Atri Sharma 于2023年10月3日周二 19:24写道： > > > > > We want to propose ResilientDB as a new Apache Incubator project. > > > > > > ResilientDB[1] is a distributed blockchain framework that is written > > > in C++ and integrates with Byzantine Fault-Tolerant (BFT) and Crash > > > Fault-Tolerant (CFT) consensus protocols. Code is present at [2]. > > > > > > Key features: > > > > > > Provides a scalable client-server architecture. Each developer can use > > > the ResilientDB framework to deploy a replicated service acting as a > > > service. The developer can choose the desired number of replicas and > > > the number of clients its system should tolerate. > > > > > > Provides native integration with PBFT consensus protocol – arguably > > > the most popular BFT consensus protocol. PBFT helps replicas reach an > > > agreement for ordering the client's requests. > > > > > > Provides a mechanism to simulate the failure of different replicas > > > (including the leader). > > > > > > Provides a correct implementation of the view-change protocol that > > > replaces a faulty (or malicious) leader and moves all replicas to the > > > new view. > > > > > > Provides checkpoint and recovery protocols to facilitate garbage > > > collection, recovery of failed replicas, and durably logging of the > > > blockchain state. > > > > > > Eases development and testing of newer and optimized BFT and CFT > > > consensus protocols. > > > Provides clients with support for three different application > interfaces: > > > > > > Key-Value Stores - where client transactions include key-value pairs. > > > > > > Smart Contracts - where clients issue smart contracts in Solidity for > > > processing. > > > > > > UTXO - where clients issue unspent transactions similar to ones in > Bitcoin. > > > > > > Facilitates benchmarking system/protocol performance with the help of > > > existing benchmarks, such as YCSB [SoCC’10] and Diablo [EuroSys’23]. > > > > > > Stores non-volatile ledger (blockchain) in memory and for further > > > durability, provides APIs to store both client data and blockchain in > > > LevelDB and RocksDB. > > > > > > > > > The serving mentors would be: > > > > > > Junping Du > > > > > > Calvin Kirs > > > > > > Kevin Ratnasekera > > > > > > Roman Shaposhnik > > > > > > Christian Grobmeier > > > > > > and I shall be serving as the Champion. > > > > > > We have not done a trademark check yet for the name but that can be > > > pursued independently. > > > > > > [1] > > > > https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal > > > [2] https://github.com/resilientdb/resilientdb > > > > > > Atri > > > > > > - > > > 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] Incubating Proposal of ResilientDB
Hi, I have a quick question about the initial committers. There are about 40+ initial committers, but I can only find about 20 contributors in the GitHub group[1] contributor list. Could you explain the initial committer criteria? There is a section of "Broader Contributing Members" in the proposal[2] after the initial committer, if we treat them as initial committers, why do we need to separate them with the initial committer? Thanks, [1]https://github.com/resilientdb [2]https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Sun, Oct 8, 2023 at 1:38 PM 俊平堵 wrote: > > +1. > btw, I assume we will have an official vote thread (start with [VOTE]) > later? > > Thanks, > > JP > > Atri Sharma 于2023年10月3日周二 19:24写道： > > > We want to propose ResilientDB as a new Apache Incubator project. > > > > ResilientDB[1] is a distributed blockchain framework that is written > > in C++ and integrates with Byzantine Fault-Tolerant (BFT) and Crash > > Fault-Tolerant (CFT) consensus protocols. Code is present at [2]. > > > > Key features: > > > > Provides a scalable client-server architecture. Each developer can use > > the ResilientDB framework to deploy a replicated service acting as a > > service. The developer can choose the desired number of replicas and > > the number of clients its system should tolerate. > > > > Provides native integration with PBFT consensus protocol – arguably > > the most popular BFT consensus protocol. PBFT helps replicas reach an > > agreement for ordering the client's requests. > > > > Provides a mechanism to simulate the failure of different replicas > > (including the leader). > > > > Provides a correct implementation of the view-change protocol that > > replaces a faulty (or malicious) leader and moves all replicas to the > > new view. > > > > Provides checkpoint and recovery protocols to facilitate garbage > > collection, recovery of failed replicas, and durably logging of the > > blockchain state. > > > > Eases development and testing of newer and optimized BFT and CFT > > consensus protocols. > > Provides clients with support for three different application interfaces: > > > > Key-Value Stores - where client transactions include key-value pairs. > > > > Smart Contracts - where clients issue smart contracts in Solidity for > > processing. > > > > UTXO - where clients issue unspent transactions similar to ones in Bitcoin. > > > > Facilitates benchmarking system/protocol performance with the help of > > existing benchmarks, such as YCSB [SoCC’10] and Diablo [EuroSys’23]. > > > > Stores non-volatile ledger (blockchain) in memory and for further > > durability, provides APIs to store both client data and blockchain in > > LevelDB and RocksDB. > > > > > > The serving mentors would be: > > > > Junping Du > > > > Calvin Kirs > > > > Kevin Ratnasekera > > > > Roman Shaposhnik > > > > Christian Grobmeier > > > > and I shall be serving as the Champion. > > > > We have not done a trademark check yet for the name but that can be > > pursued independently. > > > > [1] > > https://cwiki.apache.org/confluence/display/INCUBATOR/ResilientDBProposal > > [2] https://github.com/resilientdb/resilientdb > > > > Atri > > > > - > > 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: Re:[VOTE] Accept Answer into the Apache Incubator
Hi KimmKing, We had the project name discussion in the discussion thread[1]. Currently the project doesn't have plans to rename the project name.[2] [1]https://lists.apache.org/thread/42tvz3rqfy4w5poqgslh71sm1o1td7zn [2]https://lists.apache.org/thread/68n5kz5c3bm3fm5nckj1zwl3xf2vwcvh Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Thu, Oct 5, 2023 at 2:59 PM KimmKing wrote: > > There will be some preferred names for discussion or not? My Suggestion is > OpenAnswer/Openswer. > > > > > -- > > Kimm King(kimmk...@apache.org/kimmk...@163.com) > Apache Dubbo PMC Member > github: kimmking > > > > > > At 2023-10-05 14:55:27, "KimmKing" wrote: > >+1， nobinding > > > > > > > > > >-- > > > >Kimm King(kimmk...@apache.org/kimmk...@163.com) > >Apache Dubbo PMC Member > >github: kimmking > > > > > > > > > > > >At 2023-10-03 08:17:16, "Willem Jiang" wrote: > >>Following up the [DISCUSS] thread on Answer [1] I would like to call a > >>VOTE to accept into the Apache Incubator. > >> > >>Answer is a question-and-answer (Q) platform software for teams at > >>any scale to build a help center, knowledge base, community forum, > >>etc. > >> > >>Please cast your vote: > >> > >> [ ] +1, bring into the Incubator > >> [ ] +0, I don't care either way > >> [ ] -1, do not bring Answer into the Incubator, because... > >> > >>The vote will open at least for 72 hours and only votes from the > >>Incubator PMC are binding, but votes from everyone are welcome. > >> > >>Please check out the Answer Proposal from the incubator wiki[2]. > >> > >>[1]https://lists.apache.org/thread/42tvz3rqfy4w5poqgslh71sm1o1td7zn > >>[2]https://cwiki.apache.org/confluence/display/INCUBATOR/Answer+Proposal > >> > >>Best Regards, > >> > >>Willem Jiang > >> > >>Twitter: willemjiang > >>Weibo: 姜宁willem > >> > >>- > >>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: [VOTE] Accept Answer into the Apache Incubator
+1 （binding） Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Oct 3, 2023 at 8:17 AM Willem Jiang wrote: > > Following up the [DISCUSS] thread on Answer [1] I would like to call a > VOTE to accept into the Apache Incubator. > > Answer is a question-and-answer (Q) platform software for teams at > any scale to build a help center, knowledge base, community forum, > etc. > > Please cast your vote: > > [ ] +1, bring into the Incubator > [ ] +0, I don't care either way > [ ] -1, do not bring Answer into the Incubator, because... > > The vote will open at least for 72 hours and only votes from the > Incubator PMC are binding, but votes from everyone are welcome. > > Please check out the Answer Proposal from the incubator wiki[2]. > > [1]https://lists.apache.org/thread/42tvz3rqfy4w5poqgslh71sm1o1td7zn > [2]https://cwiki.apache.org/confluence/display/INCUBATOR/Answer+Proposal > > Best Regards, > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
