Sergey. > pay our (already huge) technical debt,
Can you, please, make your statement more specific? What specific points of technical debt do we have? I think we should write it down and solve the issues step by step. > 16 нояб. 2020 г., в 14:28, Sergey Chugunov <sergey.chugu...@gmail.com> > написал(а): > > Igniters, > > I agree that create or not create is not a question, rephrasing > Shakespeare. > > My main point is that developing new features on top of old 2.x-style > architecture is a bad idea. We will write the code and spend some time > stabilizing it (which is expected and fine). But then, when we finally > decide to fix our architecture and pay our (already huge) technical debt, > we will have to rewrite this code again and spend time stabilizing it again. > > Creating new components on top of 2.x (which is actually 1.x, nothing > fundamentally new was introduced in terms of architecture) is equal to > wasting time now and creating more worthless work for the future. > > Earlier I suggested to rank all new features according to their criticality > and amount of breaking changes and shape 3.0 scope based on this analysis. > Let's get back to this idea and prepare a scope based on publicly shared > arguments. > > One more thing I would add here. Our users are smart people and make > decisions about upgrading or not upgrading to a new version based on > cost/value balance. Incremental approach keeps cost (public API breaking > changes) high but brings questionable amounts of value with each iteration. > If we add more valuable features to 3.0 and force users to pay the cost > only once they will be happier than if we split really needed changes to > several major releases and send our users to hell of endless rewriting > their codebases. In the latter case we'll see users to be much more > reluctant to upgrade to newer versions. > > Hope this makes sense. > > On Mon, Nov 16, 2020 at 2:24 PM Nikolay Izhikov <nizhi...@apache.org> wrote: > >>> 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 >>>>> >>>> >> >> >>
