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:38:16 GMT
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
View raw message