ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Vinogradov ...@apache.org>
Subject Re: [DISCUSS] Ignite 3.0 development approach
Date Mon, 02 Nov 2020 11:09:36 GMT
Alexey,

Do we have any estimates of how fast we'll be able to gain production-ready
AI 3.0 in case of a "new repo" choice?

On Mon, Nov 2, 2020 at 2:01 PM Alexey Goncharuk <alexey.goncharuk@gmail.com>
wrote:

> Nikolay,
>
> What new features are we planning to implement for Ignite 2.x? I think once
> we commence working on Ignite 3.0, we should gradually cease the activity
> on Ignite 2.x to mere bugfixes because such parallel development will be
> overwhelming regardless of how we choose to proceed.
>
> пн, 2 нояб. 2020 г. в 13:38, Nikolay Izhikov <nizhikov@apache.org>:
>
> > To be clear:
> >
> > > I would suggest creating a new repository for Ignite 3.0 (perhaps, a
> new
> > clean branch, but a new repo looks nicer to me) and a new Ignite 3.0
> > TeamCity project.
> >
> > +1 for new Team City project.
> > +1 for new branch for Ignite3.
> > -1 for new repo.
> >
> >
> > > 2 нояб. 2020 г., в 13:35, Nikolay Izhikov <NIzhikov.dev@gmail.com>
> > написал(а):
> > >
> > > Hello, Alexey.
> > >
> > > I think it will hurt our project more than help.
> > > Developing new features for 2 separate branches with the different APIs
> > and internal structure is overwhelming
> > >
> > > Maybe we should relax a bit requirements for Ignite3?
> > > Maybe we should move step by step and make Ignite3 with new
> > configuration than Ignite4 with new transactions, etc?
> > >
> > >> 2 нояб. 2020 г., в 13:14, Alexey Goncharuk <
> alexey.goncharuk@gmail.com>
> > написал(а):
> > >>
> > >> Igniters,
> > >>
> > >> I wanted to pitch a rather radical idea regarding the Ignite 3.0
> > >> development which has occurred to me some time ago.
> > >>
> > >> We already have several IEPs targeted to Ignite 3.0 which imply major
> > >> changes to the codebase (the change in replication protocol and thus
> > >> transactions, change in binary format, updated metastorage, etc). We
> > also
> > >> planned significant changes in public APIs: configuration format
> change,
> > >> improvements in cache APIs, SQL APIs, transaction mode rework. The
> > wishlist
> > >> of changes for Ignite 3.0 is huge.
> > >>
> > >> So, I was wondering whether it makes sense to try to change the old
> > >> codebase, or start with a new baseline and move old pieces of code
> that
> > do
> > >> not require significant rework. Personally, I would go with the second
> > >> option for the following reasons:
> > >>
> > >>  - We have a chance to shift the development paradigm in the project
> and
> > >>  introduce the practice of true unit-tests. In the new baseline at the
> > >>  beginning there will be no ability to run an end-to-end scenario,
> thus
> > we
> > >>  will be forced to write unit-tests. So far, such practice was hard to
> > >>  implement because of tight coupling between Ignite components and
> > inability
> > >>  to instantiate components without an instance of KernalContext. For
> > >>  example, we should be able to thoroughly test internal primitives,
> > such as
> > >>  replication protocol (without actual communication), distributed
> > >>  metastorage contracts, persistence layer, etc.
> > >>  - We will significantly reduce the development cycle in the beginning
> > >>  (right now the RunAll takes two hours of astronomical time with empty
> > TC;
> > >>  in the new approach developer will be able to run ALL tests locally
> in
> > a
> > >>  matter of minutes)
> > >>  - We can get rid of TC bot and enforce green TC by integrating TC
> build
> > >>  results with GitHub PRs (the same way Travis is currently integrated
> > to PR
> > >>  check). We should restrict PR merge without a TC check
> > >>  - We will still have to re-write all tests, but only once. If we try
> to
> > >>  modify the old codebase, we would need to modify all the tests for
> > every
> > >>  major change (public API change, configuration change)
> > >>  - We will have fewer conflicts when working together. For example, I
> > >>  cannot imagine how one would merge two changes of getting rid of
> > >>  IgniteFuture and changes in replication protocol, for example
> > >>
> > >> Technically, I would suggest creating a new repository for Ignite 3.0
> > >> (perhaps, a new clean branch, but a new repo looks nicer to me) and a
> > new
> > >> Ignite 3.0 TeamCity project.
> > >>
> > >> While it may seem quite radical, I do believe that this approach will
> > give
> > >> us more benefits than trying to make such major changes in the
> existing
> > >> codebase. If needed, let's schedule a discord chat like before to
> > discuss
> > >> this.
> > >>
> > >> WDYT?
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message