I still have a question for the “Broader Contributing Members”: do we treat them as initial committers?
It makes sense that we keep track of all the contributors on the project website so that no one will be surprised by the long list of initial committers. An extensive initial committer list doesn't mean we have a healthy, diverse community. It is incredibly challenging to bring those graduated students back to the project from my experience with IoTDB. When we consider the community-building work during the polling graduation evaluation, we just track the new committers we have during the incubation process. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Oct 10, 2023 at 7:43 PM 俊平堵 <junping...@apache.org> 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
