If no further concerns, I wish to start the vote thread tomorrow. On Wed, 11 Oct 2023 at 12:16 AM, Christian Grobmeier <grobme...@apache.org> wrote:
> I agree too. > > However, I am also concerned the titel is [DISCUSS] - shouldn't this be a > vote already? > > > On Tue, Oct 10, 2023, at 13:42, 俊平堵 wrote: > > 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 > >> > > >> > > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
