ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Izhikov <nizhi...@apache.org>
Subject Re: [DISCUSS] Ignite 3.0 development approach
Date Mon, 02 Nov 2020 10:35:46 GMT
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.

View raw message