Dear all, Could we move the [VOTE] phase after removing the broad contributors (as it was suggested)?
The last [Discuss] thread was sent 10 days ago with +8(binding). --- 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 Thu, Oct 12, 2023 at 12:03 AM Mohammad Sadoghi <mo.sado...@expolab.org> wrote: > Sure, please remove them [I do not have write access to the wiki]. Thank > you kindly. > > --- > 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 Thu, Oct 12, 2023 at 12:02 AM Atri Sharma <a...@apache.org> wrote: > >> I suggest removing them since it is leading to confusion. >> >> On Thu, Oct 12, 2023 at 12:27 PM Mohammad Sadoghi >> <mo.sado...@expolab.org> wrote: >> > >> > Dear all, >> > >> > As for the question of the “Broader Contributing Members”, they do not >> > qualify as initial committers as they have provided feedback / >> contributed >> > on the broader scope of ResilientDB, so we suggest either removing them >> or >> > keeping them in a separate category. I prefer keeping them as a separate >> > category, but of course, we will follow the ASF recommendation.We are in >> > the process of improving and upgrading our website, and we will add all >> the >> > initial committers to the website. Currently, from our website, we have >> > also linked to our Apache proposal, which includes the complete list of >> > initial committers.With regards to the question of forked repo vs. >> branch, >> > we are fine with either option. We have made our development public (no >> > longer private), and we can work on the either public repo (main vs. >> > forked), whichever mode is preferred by ASF.With regards to PR, moving >> > forward, we will ensure PR reviews and issue discussions are all done on >> > the public repo with complete visibility. >> > >> > --- >> > 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 Wed, Oct 11, 2023 at 7:49 PM Willem Jiang <willem.ji...@gmail.com> >> wrote: >> > >> > > Unlike the Linux kernel, we use the dev or main branch from the >> > > official upstream repo to accept the PRs from the developer; we do the >> > > release work on the other branch in the same repo. We don't use >> > > another forked repo to keep those changes first. It will confuse the >> > > contributor in finding the right developing branch on the project repo >> > > to work on. >> > > >> > > I barely find the repo's PR reviews and issue discussions[1]. Without >> > > sharing these development contexts, it is hard for the new contributor >> > > to know the story behind the code change. We can improve the >> > > situation during the incubation process. You can take the issue and >> > > PRs of OpenDaL[2] as a polling example. >> > > >> > > BTW, the license header on the source code[3] is not the ASL >> > > request[4]. We can address this kind of problem during the code >> > > transfer. >> > > >> > > [1]https://github.com/resilientdb/resilientdb >> > > [2]https://github.com/apache/incubator-opendal/ >> > > [3] >> > > >> https://github.com/resilientdb/resilientdb/blob/master/executor/common/transaction_manager.cpp#L1 >> > > [4]https://github.com/msadoghi/resilientdb/blob/hs/LICENSE#L189 >> > > >> > > Willem Jiang >> > > >> > > Twitter: willemjiang >> > > Weibo: 姜宁willem >> > > >> > > On Tue, Oct 10, 2023 at 11:50 AM Mohammad Sadoghi >> > > <mo.sado...@expolab.org> wrote: >> > > > >> > > > 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 >> > > >> > > >> >> -- >> Regards, >> >> Atri >> Apache Concerted >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >>
