Agree with Roman and Dave that we can keep the original list. I think Willem is just curious on the mismatch between commits and committers, and the explanation here make sense to me.
Thanks, JP Mohammad Sadoghi <mo.sado...@expolab.org> 于2023年10月10日周二 11:50写道： > Dear all, > > *Question on Initial Committers:* > As was mentioned earlier. The criteria that I used was to credit anyone who > has worked on the ResilientDB project since 2018, acknowledging their > contributions. Below is the detailed breakdown of our contributors. So we > can reduce the list as needed in accordance with ASF guidelines. As for the > broader contributors, these are the folks who have supported ResilientDB, > e.g., formalization of the research ideas, discussion of how to tackle a > particular algorithm or its implementation, testing, and analysis. However, > these broader members have not contributed to the codebase. So this is why > they were tagged differently.*ResilientDB Core *[all have signed ICLA] > Mohammad Sadoghi <msadoghi at ucdavis dot edu> > Junchao Chen <juccchen at ucdavis dot edu> > Dakai Kang <dakang at ucdavis dot edu> > Suyash Gupta <suyash.gupta at berkeley dot> [Now at UC Berkeley] > Sajjad Rahnama <srahnama at ucdavis dot edu> [Now at Oracle] > Wayne Wang <wjawang at ucdavis dot edu> [Now at Hesai Technology] > Julieta Duarte <juduarte at ucdavis dot edu> > Glenn Chen <gjjchen at ucdavis dot edu> > *Tooling/SDK/Wallet/Applications *[all have signed ICLA] > Thamir Qadah <tmqadah at uqu dot edu dot sa> [Umm Al-Qura University] > Jinxiao Yu <jnxyu at ucdavis dot edu> [Now at Amazon AWS] > Arindaam Roy <aroy at ucdavis dot edu> [Now at Square] > Divjeet Singh Jas <djas at ucdavis dot edu> > Apratim Shukla <aprshukla at ucdavis dot edu> > Priyal Soni <pdsoni at ucdavis dot edu> [Now at Amazon AWS] > Rohan Sogani <rmsogani at ucdavis dot edu> [Now at Oracle] > Kaustubh Shete <kshete at ucdavis dot edu> > Gopal Nambiar <gnambiar at ucdavis dot edu> > Saipranav Kotamreddy <saikotamreddy at ucdavis dot edu> > Haskell Lark Macaraig <hbmacaraig at ucdavis dot edu> > > *Deprecated/Obsolete Features *[have been rewritten or removed] > Jelle Hellings <jhellings at mcmaster dot ca> [Now at McMaster University] > Shesha Vishnu Prasad <sdharanaiah at ucdavis dot edu> [Now at Path] > Dhruv Krishnan <dkrishnan at ucdavis dot edu > [Now at Amazon AWS] > Shubham Pandey <shupandey at ucdavis dot edu> [Now at Cisco] > Steve Chen <sstchen at ucdavis dot edu> > Priya Holani <pmholani at ucdavis dot edu > [Now at Amazon AWS] > Haojun (Howard) Zhu <hajzhu at ucdavis dot edu> > Robert HE <mjhe at ucdavis dot edu> [Now at Amazon AWS] > Shreenath Iyer <shriyer at ucdavis dot edu> [Now at Amazon AWS] > Domenic Cianfichi <djcianfichi at ucdavis dot edu> [Now at Amazon AWS] > Erik Linsenmayer <ehlinsenmayer at ucdavis dot edu> [Now at General > Atomics] > Shreyan Mohanty <shmohanty at ucdavis dot edu> [Now at General Atomics] > Xinyuan Sun <sxysun at ucdavis dot edu> [Now at CertiK] > Patrick Liao <pjliao at ucdavis dot edu> [Now at Juniper Networks] > Tim Huang <timhwang at ucdavis dot edu> > Jared Givens <jcgivens at ucdavis dot edu> > Aditya Bej <akbej at ucdavis dot edu> > Seongwoo Choi <shjchoi at ucdavis dot edu > > > *Question on Private Development:* > As per request, we have transitioned away from local/private development. > We have forked our public ResilientDB, and we began the process of moving > all experimental features into this repo. All these ongoing features are > available in this repo but are still under development and not yet ready to > be released to the main repository.*Our New Development Repo: * > https://github.com/msadoghi/resilientdb/*Notable Branches (Active > Projects)* > Speculative Consensus: https://github.com/msadoghi/resilientdb/tree/poe > Rotating Leader (lightweight recovery): > https://github.com/msadoghi/resilientdb/tree/hs > Queue-Oriented Concurrency Control (concurrent execution): > https://github.com/msadoghi/resilientdb/tree/QueccBranch > Smart Contract Concurrency: > https://github.com/msadoghi/resilientdb/tree/smartcontract_cc > > --- > Best Regards, > Mohammad Sadoghi, PhD > Associate Professor > Exploratory Systems Lab (ExpoLab) > Department of Computer Science > University of California, Davis > > ExpoLab: https://expolab.org/ > ResilientDB: https://resilientdb.com/ > Phone: 914-319-7937 > > > On Mon, Oct 9, 2023 at 6:18 PM Dave Fisher <wave4d...@comcast.net> wrote: > > > > > > > Sent from my iPhone > > > > > On Oct 9, 2023, at 7:51 PM, Suyash Gupta <suyash.gu...@berkeley.edu > .invalid> > > wrote: > > > > > > Hello All > > > > > > Let me try to add to Mohammad's response. We defined an initial > committer > > > list of 40+ members as we wanted to give credit to everyone who has > > > collaborated with us on projects/papers that were built around > > ResilientDB. > > > But, the 20 contributors visible on github are the ones who worked on > the > > > actual codebase, which we are trying to bring to ASF. The projects that > > > other folks worked on are independent from the ResilientDB codebase and > > > have no correlation with this release. > > > > > > So, following ASF guidelines, we are fine with reducing the initial > > > committer list to the 20 members. Please let us know your thoughts. > > > > One way to consider is that initial committers should be those who plan > to > > participate in the Apache ResilientDB community. ASF committers need to > > sign an ICLA and that will determine how many committers. Nothing > prevents > > any of those who don’t sign from contributing. > > > > Early in incubation you will need to create a website and you can discuss > > the history of the project and if they agree those contributors you wish > to > > honor. > > > > Best wishes, > > Dave > > > > > > > > > > >> On Sun, Oct 8, 2023 at 9:47 AM Mohammad Sadoghi < > mo.sado...@expolab.org > > > > > >> wrote: > > >> > > >> 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 > > >>> > > >>> > > >> > > > > > > > > > -- > > > *- Regards* > > > > > > *Suyash Gupta, PhD * > > > *SkyLab* > > > *Dept. of Computer Science* > > > *University of California Berkeley* > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
