On Tue, Oct 10, 2023, at 20:49, Atri Sharma wrote:
> If no further concerns, I wish to start the vote thread tomorrow.
>
Awesome. Since you have allowed plenty of "complain time," it's safe to go by
tomorrow.
Thanks for taking care of this!
> 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
