> Let's indeed focus on Sergey's suggestions on the design->development > approach.
+1 > - API & configuration cleanup > - New management tool > - Schema-first approach > - New replication infrastructure +1. > 16 нояб. 2020 г., в 13:40, Alexey Goncharuk <alexey.goncha...@gmail.com> > написал(а): > > Folks, > > I think we are overly driven away by the phrase 'new repo' rather than the > essence of my suggestion. We can keep developing in the same repo, we can > even keep developing in the master branch. My point is that Ignite 3.0 is a > chance to move on with the architecture, so if we really want to make > architectural improvements, we should not strive for incremental changes > for *some parts of the code*. > > Maxim, > > To comment on your examples: I think that the huge effort that is currently > required to make any significant change in Ignite is the perfect example of > how we lack structure in the codebase. Yes, theoretically we can introduce > incremental changes in the code that will improve the structure, but my > question is: we did not do it before, what will enforce us to make these > changes now? With the current approach, adding a new feature increases the > test time non-linearly because without proper decoupling you have to test > all possible combinations of features together. We can move faster than > that. > > I also do not agree that we should reduce the scope of Ignite 3.0 that > much. I do not see how the schema-first approach can be properly and > reliably implemented without a reliable HA metastorage, which in turn > requires a reliable replication protocol to be implemented. Besides, if a > number of people want to work on some Ignite feature, why should they wait > because not all community members have time to review the changes? > > Let's indeed focus on Sergey's suggestions on the design->development > approach. I back both Nikolay's and Maxim's scope, but I think we should > unite them, not intersect, and the minimal list of changes to be included > to Ignite 3.0 is: > > - API & configuration cleanup > - New management tool > - Schema-first approach > - New replication infrastructure > > Any smaller subset of changes will leave Ignite 3.0 in a transient state > with people being too afraid to move to it because there are more major > breaking changes scheduled. > > пт, 13 нояб. 2020 г. в 18:28, Alexey Zinoviev <zaleslaw....@gmail.com>: > >> I'm -1 for creating a new repo. >> Also I support Maxim's plan for 3.0 >> >> пт, 13 нояб. 2020 г. в 15:50, Maxim Muzafarov <mmu...@apache.org>: >> >>> Val, >>> >>> >>> Why *creating a new repo* is the main point we faced with? Would it be >>> better to discuss the components design approach and scope management >>> first suggested by Sergey Chugunov? I doubt that new repo will solve >>> move us forward. >>> >>> Currently, I'm -1 to create a new repo with the inputs above. >>> >>> In addition to Nikolay's answer I see the following drawbacks of >>> creating new repo: >>> - we have very few positive examples of finalizing really huge >>> improvements to *production-ready* states the others remains >>> incomplete (MVCC, Calcite, Zookeeper, Tracing, Thread per Partition, >>> etc) >>> - AFAIK, the Native Persistence took a very long period of >>> stabilization even after it has been developed (we must take it into >>> account for developing new features like IEP-61) >>> - feature development for a long period of time (like 3.0) without any >>> releases will lead to all these changes became obsolete at the moment >>> of release (AFAIK the 2.8 which released a year ago still has no big >>> deployments) >>> - human resources -- some of the Igniters may lose their interest for >>> 3.0 during development, some of them may switch to different projects, >>> etc. >>> - do we all estimating the scope of 3.0 correct? The 2.8 release took 1.5 >>> years. >>> >>> Have I missed something? >>> >>> >>> I suggest the following plan: >>> >>> - initiate 3.0 development in the master branch (after 2.10 release >>> change version to 3.0-SNAPSHOT instead of 2.11-SNAPSHOT) >>> - cleanup and collapse all the current APIs (see To Be Removed List >>> For Discussion on Apache Ignite 3.0 Wishlist) >>> - reduce the scope for 3.0 even more. I suggest focusing on two >>> things: Calcite + Schema-first approach >>> - create feature branches for proposed IEPs (for 3.0 only) >>> - create the release road map (allocate e.g. IEP-61 to 4.0 etc.) >>> >>> On Fri, 13 Nov 2020 at 14:03, Ivan Daschinsky <ivanda...@gmail.com> >> wrote: >>>> >>>>>> b. Implement IEP-61 - Common Replication Infrastructure >>>> I suppose, that this is the main cause of the current discussion. >>>> I hardly believe that this activity can be done without at least >>> creating a >>>> completely new branch. >>>> >>>> пт, 13 нояб. 2020 г. в 11:12, Nikolay Izhikov <nizhi...@apache.org>: >>>> >>>>> My suggestion: >>>>> >>>>> 1. Reduce Ignite3 scope to the following: >>>>> a. Delete all deprecated API and support of obsolete internal >>>>> protocols. >>>>> b. Implement IEP-61 - Common Replication Infrastructure >>>>> c. Implement new Ignite management tool ignitectl as >> suggested >>>>> during Ignite3 discussion. >>>>> >>>>> 2. Implement and release following improvements like transactions, >>> Calcite >>>>> based SQL, etc in the ongoing releases - Ignite 4, 5, 6 >>>>> >>>>> My concern against separate Ignite 3 repo is the following: >>>>> >>>>> 1. We spread community to the two very separated part - Ignite3 >>> developers >>>>> and Ignite2 maintainers. believe it’s bad for our community. >>>>> That can lead to the situation when we don’t fix critical or >>>>> blocker issueds «because they will not exists in Ignite3» >>>>> That will lead to the solutions never reviewed or reviewed >>> poorly. >>>>> >>>>> 2. It seems for me that current scope of Ignite3 is too big to be >>>>> implemented in any reasonable time. >>>>> >>>>> >>>>>> 13 нояб. 2020 г., в 10:57, Nikolay Izhikov <nizhikov....@gmail.com >>> >>>>> написал(а): >>>>>> >>>>>> Hello, Valentin. >>>>>> >>>>>>> Nikolay, Maxim, are you OK with this route? >>>>>> >>>>>> -1 to have another repo for Ignite3 development. >>>>>> >>>>>>> 13 нояб. 2020 г., в 03:04, Valentin Kulichenko < >>>>> valentin.kuliche...@gmail.com> написал(а): >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> We already have multiple IEPs for Ignite 3.0, and as far as I >> know, >>>>> there are contributors that would like to work on them (or probably >>> already >>>>> started). That said, we should make a decision as soon as possible. >>>>>>> >>>>>>> At this point, it doesn't seem that there are any strong >> objections >>> to >>>>> the technical side of things. So I would suggest the following: >>>>>>> >>>>>>> 1. Proceed with Alexey's approach to the development process, as >> it >>>>> seems to be the best (in my opinion - the only) way to address all >> the >>>>> technical concerns and issues expressed in the thread. We'll start by >>>>> creating a new repo and a new TC project. >>>>>>> 2. Start a separate discussion around transparency. If there are >> any >>>>> changes we need to make to our contributor guidelines, I am happy to >>> talk >>>>> them through, but I don't think it's reasonable to delay feature >>>>> development because of this. In the short term, I will make sure that >>>>> everything that happens within the new repo is as open to the >>> community as >>>>> possible. >>>>>>> >>>>>>> Nikolay, Maxim, are you OK with this route? >>>>>>> >>>>>>> -Val >>>>>>> >>>>>>> On Tue, Nov 10, 2020 at 4:55 PM Valentin Kulichenko < >>>>> valentin.kuliche...@gmail.com> wrote: >>>>>>> Maxim, >>>>>>> >>>>>>> 2.x and 3.x will have to coexist for some time - I don't see how >> we >>> can >>>>> avoid this considering the set of proposed changes. That said, we >>>>> effectively will need to have two "masters" - one for each major >>> version. >>>>> Master for 3.x can technically be a branch in the existing repo, but >>> having >>>>> a separate repo seems cleaner, simply because it will not be a >>> "branch" in >>>>> the traditional sense. >>>>>>> >>>>>>> Note that the new repo will still be under the Apache org, with >> the >>>>> same set of committers, managed by the community, etc. All the >>> development >>>>> happening for 3.0 must follow the rules that we currently have (if >>>>> anything, it's an opportunity to improve those rules). >>>>>>> >>>>>>> As I said during the call on Friday, I strongly believe that if >>> there >>>>> is a transparency issue, it will exist regardless of the approach we >>> choose >>>>> for 3.0. If community members develop without IEPs or public >>> discussions, >>>>> this will happen for both 2.x and 3.x unless we address this >>> separately. I >>>>> don't see how this is related to Alexey's suggestion, which targets >>>>> *technical* issues with the product more than anything else. This a >>> way to >>>>> achieve better modularity, introduce better coverage with unit tests, >>>>> reduce conflicts during development, etc. >>>>>>> >>>>>>> Coming back to transparency, let's identify the issues and fix >>> them. It >>>>> probably makes sense to have a separate discussion on this topic. >>>>>>> >>>>>>> -Val >>>>>>> >>>>>>> On Tue, Nov 10, 2020 at 1:05 PM Maxim Muzafarov < >> mmu...@apache.org> >>>>> wrote: >>>>>>> Sergey, >>>>>>> >>>>>>> >>>>>>> Your summary makes sense to me. >>>>>>> >>>>>>> However, how we come up from *Development transparency* to >> *create a >>>>>>> separate public repository dedicated for 3.0*? For me *development >>>>>>> transparency* is about making changes in the master branch. These >>>>>>> changes will definitely be seen by all the Ignite developers. >>>>>>> >>>>>>> A dedicated public repository is technically public and visible >> for >>>>>>> everyone, but it allows development without IEPs, without public >>>>>>> discussion (since all the code changes are not related to the >> master >>>>>>> branch) it also allows a large number of assumptions and >> deviations >>>>>>> (like code-style violations). It also not about *development >>>>>>> transparency* since developers which are working on 3.0 is only a >>>>>>> subset of all Ignite developers which may continue working on 2.x. >>> For >>>>>>> me, this would be a huge step backwards. >>>>>>> >>>>>>> Ignite veterans should remember how long the branch stabilization >>> took >>>>>>> for the 2.x version with the PDS. >>>>>>> >>>>>>> >>>>>>> I think each breaking change should be passed through the master >>> branch. >>>>>>> >>>>>>> On Tue, 10 Nov 2020 at 22:18, Alexei Scherbakov >>>>>>> <alexey.scherbak...@gmail.com> wrote: >>>>>>>> >>>>>>>> Makes sense to me. >>>>>>>> >>>>>>>> вт, 10 нояб. 2020 г. в 18:47, Sergey Chugunov < >>>>> sergey.chugu...@gmail.com>: >>>>>>>> >>>>>>>>> Igniters, >>>>>>>>> >>>>>>>>> I thought over Friday meeting ideas and concerns and summarized >>> them >>>>> in >>>>>>>>> these three points: >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. *Components design unification approach.* New proposed >>> components >>>>>>>>> will be developed by different contributors, but they need to >> be >>>>> unified >>>>>>>>> and should integrate with each other easily. To ensure that I >>>>> suggest >>>>>>>>> calling an architecture group that will create design >> guidelines >>>>> for all >>>>>>>>> components and high-level overview of overall architecture. >> How >>>>> code is >>>>>>>>> split into components, what are component boundaries, how >>> component >>>>>>>>> lifecycle works and what are its interfaces - all these and >>> other >>>>>>>>> questions >>>>>>>>> should be covered. >>>>>>>>> >>>>>>>>> 2. *Scope management.* Apache 3.0 should be implemented >> within a >>>>>>>>> reasonable time, so we need some procedure to decide whether a >>>>>>>>> particular >>>>>>>>> feature should be dropped from the scope of 3.0 and postponed >>> to 3.1 >>>>>>>>> release. To do so I suggest to range all features by two >>> parameters: >>>>>>>>> criticality for 3.0 and amount of breaking changes. 3.0 scope >>> should >>>>>>>>> include features of high criticality AND features with a big >>> amount >>>>> of >>>>>>>>> breaking changes. All other features can be made optional. >>>>>>>>> >>>>>>>>> 3. *Development transparency.* Development of all components >>> should >>>>> be >>>>>>>>> made as transparent for everyone as possible. Any contributor >>>>> should be >>>>>>>>> able to look over any component at any stage of development. >> To >>>>> achieve >>>>>>>>> this I suggest to create a separate public repository >> dedicated >>> for >>>>> 3.0 >>>>>>>>> development. It will make the code available for everyone but >>> when >>>>>>>>> development of 3.0 is done we won't loose any stars of our >>> current >>>>>>>>> repository as we merge dev repo into main one and drop dev. >>>>>>>>> >>>>>>>>> Do these ideas make sense to you? Are there any concerns not >>> covered >>>>> by >>>>>>>>> these suggestions? >>>>>>>>> >>>>>>>>> On Fri, Nov 6, 2020 at 7:36 PM Kseniya Romanova < >>>>> romanova.ks....@gmail.com >>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Here are the slides from Alexey Goncharuk. Let's think this >> over >>> and >>>>>>>>>> continue on Monday: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>> >>> >> https://go.gridgain.com/rs/491-TWR-806/images/Ignite_3_Plans_and_development_process.pdf >>>>>>>>>> >>>>>>>>>> чт, 5 нояб. 2020 г. в 11:13, Anton Vinogradov <a...@apache.org>: >>>>>>>>>> >>>>>>>>>>> Folks, >>>>>>>>>>> >>>>>>>>>>> Should we perform cleanup work before (r)evolutional changes? >>>>>>>>>>> My huge proposal is to get rid of things which we don't need >>> anyway >>>>>>>>>>> - local caches, >>>>>>>>>>> - strange tx modes, >>>>>>>>>>> - code overcomplexity because of RollingUpgrade feature never >>>>> attended >>>>>>>>> at >>>>>>>>>>> AI, >>>>>>>>>>> - etc, >>>>>>>>>>> before choosing the way. >>>>>>>>>>> >>>>>>>>>>> On Tue, Nov 3, 2020 at 3:31 PM Valentin Kulichenko < >>>>>>>>>>> valentin.kuliche...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Ksenia, thanks for scheduling this on such short notice! >>>>>>>>>>>> >>>>>>>>>>>> As for the original topic, I do support Alexey's idea. We're >>> not >>>>>>>>> going >>>>>>>>>> to >>>>>>>>>>>> rewrite anything from scratch, as most of the components are >>> going >>>>> to >>>>>>>>>> be >>>>>>>>>>>> moved as-is or with minimal modifications. However, the >> changes >>>>> that >>>>>>>>>> are >>>>>>>>>>>> proposed imply serious rework of the core parts of the code, >>> which >>>>>>>>> are >>>>>>>>>>> not >>>>>>>>>>>> properly decoupled from each other and from other parts. This >>> makes >>>>>>>>> the >>>>>>>>>>>> incremental approach borderline impossible. Developing in a >> new >>>>> repo, >>>>>>>>>>>> however, addresses this concern. As a bonus, we can also >>> refactor >>>>> the >>>>>>>>>>> code, >>>>>>>>>>>> introduce better decoupling, get rid of kernel context, and >>> develop >>>>>>>>>> unit >>>>>>>>>>>> tests (finally!). >>>>>>>>>>>> >>>>>>>>>>>> Basically, this proposal only affects the *process*, not the >>> set of >>>>>>>>>>> changes >>>>>>>>>>>> we had discussed before. Ignite 3.0 is our unique chance to >>> make >>>>>>>>> things >>>>>>>>>>>> right. >>>>>>>>>>>> >>>>>>>>>>>> -Val >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 3, 2020 at 3:06 AM Kseniya Romanova < >>>>>>>>>>> romanova.ks....@gmail.com >>>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Pavel, all the interesting points will be anyway published >>> here in >>>>>>>>>>>> English >>>>>>>>>>>>> (as the principal "if it's not on devlist it doesn't >>> happened" is >>>>>>>>>> still >>>>>>>>>>>>> relevant). This is just a quick call for a group of >>> developers. >>>>>>>>> Later >>>>>>>>>>> we >>>>>>>>>>>>> can do a separate presentation of idea and discussion in >>> English >>>>> as >>>>>>>>>> we >>>>>>>>>>>> did >>>>>>>>>>>>> for the Ignite 3.0 draft of changes. >>>>>>>>>>>>> >>>>>>>>>>>>> вт, 3 нояб. 2020 г. в 13:52, Pavel Tupitsyn < >>> ptupit...@apache.org >>>>>>>>>> : >>>>>>>>>>>>> >>>>>>>>>>>>>> Kseniya, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for scheduling this call. >>>>>>>>>>>>>> Do you think we can switch to English if non-Russian >> speaking >>>>>>>>>>> community >>>>>>>>>>>>>> members decide to join? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Nov 3, 2020 at 1:32 PM Kseniya Romanova < >>>>>>>>>>>>> romanova.ks....@gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Let's do this community discussion open. Here's the link >> on >>>>>>>>> zoom >>>>>>>>>>> call >>>>>>>>>>>>> in >>>>>>>>>>>>>>> Russian for Friday 6 PM: >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>> https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/274360378/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> вт, 3 нояб. 2020 г. в 12:49, Nikolay Izhikov < >>>>>>>>>> nizhi...@apache.org >>>>>>>>>>>> : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Time works for me. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 3 нояб. 2020 г., в 12:40, Alexey Goncharuk < >>>>>>>>>>>>>> alexey.goncha...@gmail.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> написал(а): >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Nikolay, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am up for the call. I will try to explain my reasoning >>> in >>>>>>>>>>>> greater >>>>>>>>>>>>>>>> detail >>>>>>>>>>>>>>>>> and will be glad to hear the concerns. Will this Friday, >>>>>>>>> Nov >>>>>>>>>>> 6th, >>>>>>>>>>>>>> work? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> вт, 3 нояб. 2020 г. в 10:09, Nikolay Izhikov < >>>>>>>>>>>> nizhi...@apache.org >>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Igniters, should we have a call for this topic? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2 нояб. 2020 г., в 18:53, Pavel Tupitsyn < >>>>>>>>>>> ptupit...@apache.org >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> написал(а): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> not intend to rewrite everything from scratch >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Every single test from Ignite 2.x should be moved to >>>>>>>>>> Ignite >>>>>>>>>>> 3 >>>>>>>>>>>>>>>>>>>> regardless of how we choose to proceed. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Alexey, thank you for the explanation, this addresses >>> all >>>>>>>>>> of >>>>>>>>>>> my >>>>>>>>>>>>>>>> concerns. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Nov 2, 2020 at 6:43 PM Andrey Mashenkov < >>>>>>>>>>>>>>>>>> andrey.mashen...@gmail.com> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi, Igniters. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> * AFAIU, we need a new repo if we want to apply >>>>>>>>> different >>>>>>>>>>>>>>> restrictions >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> pull requests, >>>>>>>>>>>>>>>>>>>> otherwise I see no difference for myself. >>>>>>>>>>>>>>>>>>>> E.g. make static analysis (do we have?), compile, >>>>>>>>> styles, >>>>>>>>>>> and >>>>>>>>>>>>>>> javadoc >>>>>>>>>>>>>>>>>>>> checks mandatory. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I think that relaxed requirements here will lead to >> bad >>>>>>>>>>>> product >>>>>>>>>>>>>>>> quality. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> * Agree with Pavel, we should 'keep' integrations >> tests >>>>>>>>>>>> somehow. >>>>>>>>>>>>>>>>>>>> During active development tests will be broken most >> of >>>>>>>>>> time, >>>>>>>>>>>> so, >>>>>>>>>>>>>>>>>>>> I'd port them e.g. suite-by-suite once we will have a >>>>>>>>>> stable >>>>>>>>>>>> and >>>>>>>>>>>>>>>>>> featured >>>>>>>>>>>>>>>>>>>> environment to run them and of course make test's >> code >>>>>>>>>> clear >>>>>>>>>>>> and >>>>>>>>>>>>>>> avoid >>>>>>>>>>>>>>>>>>>> bad/non-relevant ones. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> * I like bottom-up approach. >>>>>>>>>>>>>>>>>>>> With it we could make a better framework. I mean >> clear >>>>>>>>>>>> component >>>>>>>>>>>>>>>>>> lifecycle, >>>>>>>>>>>>>>>>>>>> component wiring mechanics, general methods to >> approach >>>>>>>>>> core >>>>>>>>>>>>>>>> components >>>>>>>>>>>>>>>>>>>> such as exchange/communication >>>>>>>>>>>>>>>>>>>> to avoid code mess like we have in ExchangeFuture >> with >>>>>>>>> all >>>>>>>>>>>> these >>>>>>>>>>>>>>>> custom >>>>>>>>>>>>>>>>>>>> callbacks for each component, interfaces like >>>>>>>>>>>>>>>>>>>> PartitionsExchangeAware, >> IgniteChangeGlobalStateSupport >>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> a pack of >>>>>>>>>>>>>>>>>> >>>>>>>>>>> >> start/stop/onKernalStart/onPluginStart/onActivate/onDisconnected >>>>>>>>>>>>>>>>>>>> and so on in various unexpected places. >>>>>>>>>>>>>>>>>>>> Hope, we will be able to port most of the good code >> to >>>>>>>>> the >>>>>>>>>>> new >>>>>>>>>>>>>>>> framework >>>>>>>>>>>>>>>>>>>> version. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Nov 2, 2020 at 6:18 PM Alexey Goncharuk < >>>>>>>>>>>>>>>>>>>> alexey.goncha...@gmail.com> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Nikolay, Pavel, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks for the feedback! First of all, I wanted to >>>>>>>>> stress >>>>>>>>>>>> that >>>>>>>>>>>>> I >>>>>>>>>>>>>> do >>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>> intend to rewrite everything from scratch (I never >>> used >>>>>>>>>>> this >>>>>>>>>>>>>>> phrase). >>>>>>>>>>>>>>>>>>>> There >>>>>>>>>>>>>>>>>>>>> are significant parts of code that would be moved >> with >>>>>>>>>>>> minimal >>>>>>>>>>>>>>>>>>>>> modifications. Second, I never said that we will get >>>>>>>>> rid >>>>>>>>>> of >>>>>>>>>>>> the >>>>>>>>>>>>>> old >>>>>>>>>>>>>>>>>> tests >>>>>>>>>>>>>>>>>>>>> codebase. Every single test from Ignite 2.x should >> be >>>>>>>>>> moved >>>>>>>>>>>> to >>>>>>>>>>>>>>>> Ignite 3 >>>>>>>>>>>>>>>>>>>>> regardless of how we choose to proceed. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> My point is that for some parts of the code a clean >>>>>>>>>>> bottom-up >>>>>>>>>>>>>>>>>>>>> implementation will be cheaper in many ways. Let me >>>>>>>>> give >>>>>>>>>>> you >>>>>>>>>>>> a >>>>>>>>>>>>>> few >>>>>>>>>>>>>>>>>>>> concrete >>>>>>>>>>>>>>>>>>>>> examples: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> - I think no one can object that we need a cleanly >>>>>>>>>>> separated >>>>>>>>>>>>>>>>>>>> persistence >>>>>>>>>>>>>>>>>>>>> layer for Ignite. There is a very raw draft IEP for >>>>>>>>> this >>>>>>>>>>>>>> already. >>>>>>>>>>>>>>> On >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> other hand, I think we also can agree that we need a >>>>>>>>>>>>> split-brain >>>>>>>>>>>>>>>>>>>>> resistant >>>>>>>>>>>>>>>>>>>>> replication protocol for caches. There is also an >> IEP >>>>>>>>>> for >>>>>>>>>>>>> this. >>>>>>>>>>>>>>>>>>>> Neither >>>>>>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>>>>> the changes is a good fit for 2.x because they are >>>>>>>>>> likely >>>>>>>>>>> to >>>>>>>>>>>>>>>>>> introduce >>>>>>>>>>>>>>>>>>>>> breaking changes in the persistence layer, >>>>>>>>> configuration >>>>>>>>>>> and >>>>>>>>>>>>>>>>>> behavior. >>>>>>>>>>>>>>>>>>>>> Additionally, these components are now tightly >>>>>>>>> coupled, >>>>>>>>>> so >>>>>>>>>>>>> there >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>> no >>>>>>>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>>>>> these two changes can be implemented in parallel and >>>>>>>>>> then >>>>>>>>>>>>> merged >>>>>>>>>>>>>>>>>>>>> together >>>>>>>>>>>>>>>>>>>>> easily. So what we will end up with is having to >>>>>>>>>> implement >>>>>>>>>>>>> these >>>>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>>>>> sequentially, fixing all existing tests twice, and >>>>>>>>>>>> essentially >>>>>>>>>>>>>>>>>>>> throwing >>>>>>>>>>>>>>>>>>>>> away half of the work done because the other part of >>>>>>>>> the >>>>>>>>>>>>> change >>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>> re-implemented >>>>>>>>>>>>>>>>>>>>> - Similar example goes with getting rid of >>>>>>>>>>>>> IgniteInternalFuture >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> replacing it with CompletableFuture, and any other >>>>>>>>>> change >>>>>>>>>>>> that >>>>>>>>>>>>>>>>>> touches >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> asynchronous part of the code. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Third, I do not see how this choice affects the UX >> of >>>>>>>>>>> Ignite. >>>>>>>>>>>>> The >>>>>>>>>>>>>>> end >>>>>>>>>>>>>>>>>>>> user >>>>>>>>>>>>>>>>>>>>> experience must be fixed in the IEP regardless of >> the >>>>>>>>>>>>> development >>>>>>>>>>>>>>>>>> process >>>>>>>>>>>>>>>>>>>>> and the fact that we have gaps in this area in >> Ignite >>>>>>>>> 2.x >>>>>>>>>>>> just >>>>>>>>>>>>>>>> confirms >>>>>>>>>>>>>>>>>>>>> that. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Pavel, agree that a repo/branch is a technicality, I >>>>>>>>>> guess >>>>>>>>>>> if >>>>>>>>>>>>>>>>>>>> reformulate, >>>>>>>>>>>>>>>>>>>>> my point is that we might agree to have a single >>>>>>>>>>> development >>>>>>>>>>>>>> master >>>>>>>>>>>>>>>>>>>> branch >>>>>>>>>>>>>>>>>>>>> with 'disassembled' end-to-end functionality for >> some >>>>>>>>>>> period >>>>>>>>>>>> of >>>>>>>>>>>>>>> time >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> speed up development, and re-assemble the core >>> features >>>>>>>>>>> after >>>>>>>>>>>>>>> having >>>>>>>>>>>>>>>>>>>>> submodules tested independently. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Nikolay, >>>>>>>>>>>>>>>>>>>>>> We have many features that have to evolve. >>>>>>>>>>>>>>>>>>>>>> Snapshots, rebalance, tooling, tracing, zookeeper >>>>>>>>>> support, >>>>>>>>>>>>> etc. >>>>>>>>>>>>>>>>>>>>> This is not very specific. In the end, resources are >>>>>>>>>>> limited >>>>>>>>>>>>> and >>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>>> not be able to drive both tracks simultaneously, >>>>>>>>>> especially >>>>>>>>>>>>>> after a >>>>>>>>>>>>>>>>>>>> couple >>>>>>>>>>>>>>>>>>>>> of features having been implemented for Ignite 3.0. >> If >>>>>>>>>>> there >>>>>>>>>>>>> are >>>>>>>>>>>>>>>> indeed >>>>>>>>>>>>>>>>>>>>> some major changes that we want to do in Ignite 2.x >>>>>>>>>> instead >>>>>>>>>>>> of >>>>>>>>>>>>>>>> putting >>>>>>>>>>>>>>>>>>>>> effort into 3.0 - let's discuss them. I am just not >>>>>>>>> aware >>>>>>>>>>> of >>>>>>>>>>>>> any, >>>>>>>>>>>>>>>>>> that's >>>>>>>>>>>>>>>>>>>>> why I am eager to move forward with Ignite 3.0. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> We have bugs and issues that can be fixed in 2.x >>>>>>>>> without >>>>>>>>>>>>>> breaking >>>>>>>>>>>>>>>>>>>> backward >>>>>>>>>>>>>>>>>>>>> compatibility. >>>>>>>>>>>>>>>>>>>>>> We have many users who are happy with the 2.x with >>> all >>>>>>>>>>> it’s >>>>>>>>>>>>>>> issues. >>>>>>>>>>>>>>>>>>>>> These changes will be covered by end-to-end tests >> and >>>>>>>>>>>> migrated >>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> Ignite >>>>>>>>>>>>>>>>>>>>> 3.0, so I see no issues here. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Finally, Anton & Nikolay >>>>>>>>>>>>>>>>>>>>> I do not have an estimate for this simply because >> the >>>>>>>>>>>> activity >>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>> community-driven and it depends on the number of >>> people >>>>>>>>>>>> willing >>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> contribute. With the current pace, I would hope to >>> have >>>>>>>>>> an >>>>>>>>>>> RC >>>>>>>>>>>>> of >>>>>>>>>>>>>>>> Ignite >>>>>>>>>>>>>>>>>>>> 3.0 >>>>>>>>>>>>>>>>>>>>> to be ready by the end of 2021. My gut feeling is >> that >>>>>>>>> by >>>>>>>>>>>>> moving >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>> incremental changes, we will not be able to >> implement >>>>>>>>>> even >>>>>>>>>>>> half >>>>>>>>>>>>>> of >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> wishlist by that time. >>>>>>>>>>>>>>>>>>>>> I doubt that releasing several major releases with >>>>>>>>>> breaking >>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>>> make Ignite users happy either because each upgrade >>>>>>>>> will >>>>>>>>>>> cost >>>>>>>>>>>>>>> Ignite >>>>>>>>>>>>>>>>>>>> users >>>>>>>>>>>>>>>>>>>>> money, so the fewer major versions we release, the >>>>>>>>>> better. >>>>>>>>>>>> Thus >>>>>>>>>>>>>> my >>>>>>>>>>>>>>>> wish >>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> include all breaking changes in one release. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'll be now quiet for a while, let's see what other >>>>>>>>>>> community >>>>>>>>>>>>>>> members >>>>>>>>>>>>>>>>>>>>> think. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> пн, 2 нояб. 2020 г. в 15:52, Pavel Tupitsyn < >>>>>>>>>>>>>> ptupit...@apache.org >>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 1. Rewriting from scratch is never a good idea. >>>>>>>>>>>>>>>>>>>>>> We don't want to follow the path of Netscape and >> lose >>>>>>>>>> all >>>>>>>>>>>> our >>>>>>>>>>>>>>> users >>>>>>>>>>>>>>>>>>>>>> by the time we have a working 3.0 [1] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 2. Not sure about new repo - seems like some pain >> and >>>>>>>>> no >>>>>>>>>>>> gain, >>>>>>>>>>>>>>>> what's >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> problem with a branch? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 3. We should keep existing integration tests when >>>>>>>>>>> possible. >>>>>>>>>>>>>>>>>>>>>> We have accumulated a lot of edge case knowledge >> over >>>>>>>>>> the >>>>>>>>>>>>> years, >>>>>>>>>>>>>>>>>>>>>> it is not a good idea to send all of that down the >>>>>>>>>> drain. >>>>>>>>>>>>>>>>>>>>>> Yes, integration tests are slow, but they are the >>> most >>>>>>>>>>>>> valuable. >>>>>>>>>>>>>>>>>>>>>> I think we can move more stuff into nightly runs >> and >>>>>>>>>> have >>>>>>>>>>> a >>>>>>>>>>>>> fast >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> modern >>>>>>>>>>>>>>>>>>>>>> basic suite. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Alexey, you are much more familiar with the Ignite >>>>>>>>> core >>>>>>>>>>>>> codebase >>>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>>>>>>> most >>>>>>>>>>>>>>>>>>>>>> of us, >>>>>>>>>>>>>>>>>>>>>> can you please explain in more detail which >>> particular >>>>>>>>>>>>> feature, >>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> your >>>>>>>>>>>>>>>>>>>>>> opinion, >>>>>>>>>>>>>>>>>>>>>> mandates this "start from scratch" approach? >>>>>>>>>>>>>>>>>>>>>> Is it really not possible at all to follow a less >>>>>>>>>> radical >>>>>>>>>>>> way? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>> >>> >> https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Nov 2, 2020 at 2:25 PM Nikolay Izhikov < >>>>>>>>>>>>>>> nizhi...@apache.org >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hello, Alexey. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think that «rewriting from scratch» approach >> has a >>>>>>>>>> high >>>>>>>>>>>>> risk >>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> make >>>>>>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>>>>>> features unusable. >>>>>>>>>>>>>>>>>>>>>>> At the time Ignite2 was started no-one wants to do >>>>>>>>> bad >>>>>>>>>> UX >>>>>>>>>>>> or >>>>>>>>>>>>>> bad >>>>>>>>>>>>>>>>>>>>>> features. >>>>>>>>>>>>>>>>>>>>>>> Nevertheless, it happen. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think we can avoid it with the Ignite3 and >>>>>>>>> successors >>>>>>>>>>> if >>>>>>>>>>>> we >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>> move >>>>>>>>>>>>>>>>>>>>>>> step by step without keeping backward >> compatibility >>>>>>>>>>>>>>>>>>>>>>> With the step by step approach, we can focus on >> each >>>>>>>>>>>>> component >>>>>>>>>>>>>>>>>>>>>> separately. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> What new features are we planning to implement >> for >>>>>>>>>>> Ignite >>>>>>>>>>>>> 2.x? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> We have many features that have to evolve. >>>>>>>>>>>>>>>>>>>>>>> Snapshots, rebalance, tooling, tracing, zookeeper >>>>>>>>>>> support, >>>>>>>>>>>>> etc. >>>>>>>>>>>>>>>>>>>>>>> We have bugs and issues that can be fixed in 2.x >>>>>>>>>> without >>>>>>>>>>>>>> breaking >>>>>>>>>>>>>>>>>>>>>> backward >>>>>>>>>>>>>>>>>>>>>>> compatibility. >>>>>>>>>>>>>>>>>>>>>>> We have many users who are happy with the 2.x with >>>>>>>>> all >>>>>>>>>>> it’s >>>>>>>>>>>>>>> issues. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 2 нояб. 2020 г., в 14:09, Anton Vinogradov < >>>>>>>>>>> a...@apache.org >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> написал(а): >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>>> Andrey V. Mashenkov >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Alexei Scherbakov >>>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Sincerely yours, Ivan Daschinskiy >>> >>
