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
>
>

Reply via email to