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 <willem.ji...@gmail.com> 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 <mo.sado...@expolab.org> > 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 <willem.ji...@gmail.com> > 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 俊平堵 <junping...@apache.org> wrote: > > > > > > > > +1. > > > > btw, I assume we will have an official vote thread (start with > [VOTE]) > > > > later? > > > > > > > > Thanks, > > > > > > > > JP > > > > > > > > Atri Sharma <a...@apache.org> 于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 <junping_du at apache com org> > > > > > > > > > > Calvin Kirs <kirs at apache com org> > > > > > > > > > > Kevin Ratnasekera <djkevincr at apache com org> > > > > > > > > > > Roman Shaposhnik <rvs at apache com org> > > > > > > > > > > Christian Grobmeier <grobmeier at apache dot org> > > > > > > > > > > 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 > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
