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.goncha...@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 <nizhi...@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....@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.goncha...@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? > > > > > > > >
