Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Generation is a good one. Also we can use variant from DEB packaging versioning — EPOCH. > On 17 Oct 2021, at 02:52, Valentin Kulichenko > wrote: > > Folks, > > Since there are controversial opinions regarding the topic, I've cancelled > the vote and would like to resurrect the discussion. > > There are a couple of items that I would like to hear your opinions on. > > 1. I still propose to have a separate Confluence space for Ignite 3. This > makes total sense to me - Ignite 2 and 3 have such different architectures, > that mixing their internal documentations is really confusing. The same > goes for IEPs. > 2. If we create a mandatory field to Jira as we discussed, what should be > the name? Current suggestions are "Architecture" and "Generation". Are > there any other ideas? > > Please let me know your thoughts. > > -Val > > On Tue, Oct 5, 2021 at 1:34 AM Ivan Pavlukhin wrote: > >> Sorry, If I missed something in the thread but in case of a separate >> JIRA project how are users supposed to create e.g. bug tickets? How >> can we make sure that users will not use a wrong JIRA project often? >> >> 2021-10-05 2:50 GMT+03:00, Valentin Kulichenko < >> valentin.kuliche...@gmail.com>: >>> Ivan, >>> >>> I'm not pushing, I'm trying to apply the lazy consensus. It soon will be >> a >>> whole month since I've started the discussion - more than enough to >> express >>> concerns and provide alternative suggestions. Please keep in mind that we >>> are trying to address a very specific technical problem that influences >> the >>> development. "Do nothing" is not really an option here. >>> >>> Either way, I will put the initial suggestion for the vote. >>> >>> -Val >>> >>> On Thu, Sep 30, 2021 at 12:24 AM Ivan Pavlukhin >>> wrote: >>> Val, > Let's discuss this until the end of the week. If there is no clear picture on option #2 by then, I suggest we go with #1. For a moment I felt that the proposal is pushed. Let's not do so. The subject is very important, years impact I suppose. And the best way here is to reach absolute consensus. Without tight timelines so far. In case if we fail with consensus we can arrange formal voting. 2021-09-29 14:34 GMT+03:00, Petr Ivanov : > I am watching how Apache Ignite does evolve for over a 3 years already and > see that such hidden (almost no Open Source Community points could be > achieved for refactoring and addressing something that is not directly > project's source executable code) issues drown under constant pressure > of > new features and releases. > > I have never created issues for Maven build refactoring (for >> instanced) > because I understand that 1) it is almost impossible for current tech debt > already accumulated and 2) to won't be welcomed by community because >> of > indirect relationship to main project's goals. > Considering other parts, please, note [1], [2], [3], [4], [5], [6], > [7], [8] > and many many more issues that have no separate ticket. > > My point — such technical debt is overwhelming and will be never ever > approached. > That is one of the reasons why Ignite 3 being built from scratch, > having in > mind all mistakes we've already made and lots of errors we will never > do > just because there would be no legacy basic for that. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-7190 > [2] https://issues.apache.org/jira/browse/IGNITE-7326 > [3] https://issues.apache.org/jira/browse/IGNITE-7672 > [4] https://issues.apache.org/jira/browse/IGNITE-8496 > [5] https://issues.apache.org/jira/browse/IGNITE-9866 > [6] https://issues.apache.org/jira/browse/IGNITE-10600 > [7] https://issues.apache.org/jira/browse/IGNITE-10683 > [8] https://issues.apache.org/jira/browse/IGNITE-10696 > > > > > >> On 29 Sep 2021, at 14:14, Nikolay Izhikov >> wrote: >> >>> — issues related to Maven build? possible Gradle upgrade? >> >> I’m not aware of the issues. >> Can you, please, send a tickets or description of existing issues? >> Anyway, it seems change of build tool can be done at any time we want >> >>> — issues related to run scripts? >>> — issues related to release and delivery processes and scripts? >> >> I’m not aware of those too. >> Can you point to then, please? >> >>> Are they going to be addressed during Apache Ignite evolution too? >> >> Yes, from my point of view. >> >>> 29 сент. 2021 г., в 14:03, Petr Ivanov написал(а): >>> >>> And what about: >>> — issues related to Maven build? possible Gradle upgrade? >>> — issues related to run scripts? >>> — issues related to release and delivery processes and scripts? >>> >>> Are they going to be addressed during Apache Ignite evolution too?
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Folks, Since there are controversial opinions regarding the topic, I've cancelled the vote and would like to resurrect the discussion. There are a couple of items that I would like to hear your opinions on. 1. I still propose to have a separate Confluence space for Ignite 3. This makes total sense to me - Ignite 2 and 3 have such different architectures, that mixing their internal documentations is really confusing. The same goes for IEPs. 2. If we create a mandatory field to Jira as we discussed, what should be the name? Current suggestions are "Architecture" and "Generation". Are there any other ideas? Please let me know your thoughts. -Val On Tue, Oct 5, 2021 at 1:34 AM Ivan Pavlukhin wrote: > Sorry, If I missed something in the thread but in case of a separate > JIRA project how are users supposed to create e.g. bug tickets? How > can we make sure that users will not use a wrong JIRA project often? > > 2021-10-05 2:50 GMT+03:00, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > Ivan, > > > > I'm not pushing, I'm trying to apply the lazy consensus. It soon will be > a > > whole month since I've started the discussion - more than enough to > express > > concerns and provide alternative suggestions. Please keep in mind that we > > are trying to address a very specific technical problem that influences > the > > development. "Do nothing" is not really an option here. > > > > Either way, I will put the initial suggestion for the vote. > > > > -Val > > > > On Thu, Sep 30, 2021 at 12:24 AM Ivan Pavlukhin > > wrote: > > > >> Val, > >> > >> > Let's discuss this until the end of the week. If there is no clear > >> picture on option #2 by then, I suggest we go with #1. > >> > >> For a moment I felt that the proposal is pushed. Let's not do so. The > >> subject is very important, years impact I suppose. And the best way > >> here is to reach absolute consensus. Without tight timelines so far. > >> In case if we fail with consensus we can arrange formal voting. > >> > >> 2021-09-29 14:34 GMT+03:00, Petr Ivanov : > >> > I am watching how Apache Ignite does evolve for over a 3 years already > >> and > >> > see that such hidden (almost no Open Source Community points could be > >> > achieved for refactoring and addressing something that is not directly > >> > project's source executable code) issues drown under constant pressure > >> > of > >> > new features and releases. > >> > > >> > I have never created issues for Maven build refactoring (for > instanced) > >> > because I understand that 1) it is almost impossible for current tech > >> debt > >> > already accumulated and 2) to won't be welcomed by community because > of > >> > indirect relationship to main project's goals. > >> > Considering other parts, please, note [1], [2], [3], [4], [5], [6], > >> > [7], > >> [8] > >> > and many many more issues that have no separate ticket. > >> > > >> > My point — such technical debt is overwhelming and will be never ever > >> > approached. > >> > That is one of the reasons why Ignite 3 being built from scratch, > >> > having > >> in > >> > mind all mistakes we've already made and lots of errors we will never > >> > do > >> > just because there would be no legacy basic for that. > >> > > >> > > >> > > >> > [1] https://issues.apache.org/jira/browse/IGNITE-7190 > >> > [2] https://issues.apache.org/jira/browse/IGNITE-7326 > >> > [3] https://issues.apache.org/jira/browse/IGNITE-7672 > >> > [4] https://issues.apache.org/jira/browse/IGNITE-8496 > >> > [5] https://issues.apache.org/jira/browse/IGNITE-9866 > >> > [6] https://issues.apache.org/jira/browse/IGNITE-10600 > >> > [7] https://issues.apache.org/jira/browse/IGNITE-10683 > >> > [8] https://issues.apache.org/jira/browse/IGNITE-10696 > >> > > >> > > >> > > >> > > >> > > >> >> On 29 Sep 2021, at 14:14, Nikolay Izhikov > wrote: > >> >> > >> >>> — issues related to Maven build? possible Gradle upgrade? > >> >> > >> >> I’m not aware of the issues. > >> >> Can you, please, send a tickets or description of existing issues? > >> >> Anyway, it seems change of build tool can be done at any time we want > >> >> > >> >>> — issues related to run scripts? > >> >>> — issues related to release and delivery processes and scripts? > >> >> > >> >> I’m not aware of those too. > >> >> Can you point to then, please? > >> >> > >> >>> Are they going to be addressed during Apache Ignite evolution too? > >> >> > >> >> Yes, from my point of view. > >> >> > >> >>> 29 сент. 2021 г., в 14:03, Petr Ivanov > >> написал(а): > >> >>> > >> >>> And what about: > >> >>> — issues related to Maven build? possible Gradle upgrade? > >> >>> — issues related to run scripts? > >> >>> — issues related to release and delivery processes and scripts? > >> >>> > >> >>> Are they going to be addressed during Apache Ignite evolution too? > >> >>> > >> On 29 Sep 2021, at 13:47, Nikolay Izhikov > >> wrote: > >> > >> > Does you vision of evolutionary improvement involve technical debt > >> >
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Sorry, If I missed something in the thread but in case of a separate JIRA project how are users supposed to create e.g. bug tickets? How can we make sure that users will not use a wrong JIRA project often? 2021-10-05 2:50 GMT+03:00, Valentin Kulichenko : > Ivan, > > I'm not pushing, I'm trying to apply the lazy consensus. It soon will be a > whole month since I've started the discussion - more than enough to express > concerns and provide alternative suggestions. Please keep in mind that we > are trying to address a very specific technical problem that influences the > development. "Do nothing" is not really an option here. > > Either way, I will put the initial suggestion for the vote. > > -Val > > On Thu, Sep 30, 2021 at 12:24 AM Ivan Pavlukhin > wrote: > >> Val, >> >> > Let's discuss this until the end of the week. If there is no clear >> picture on option #2 by then, I suggest we go with #1. >> >> For a moment I felt that the proposal is pushed. Let's not do so. The >> subject is very important, years impact I suppose. And the best way >> here is to reach absolute consensus. Without tight timelines so far. >> In case if we fail with consensus we can arrange formal voting. >> >> 2021-09-29 14:34 GMT+03:00, Petr Ivanov : >> > I am watching how Apache Ignite does evolve for over a 3 years already >> and >> > see that such hidden (almost no Open Source Community points could be >> > achieved for refactoring and addressing something that is not directly >> > project's source executable code) issues drown under constant pressure >> > of >> > new features and releases. >> > >> > I have never created issues for Maven build refactoring (for instanced) >> > because I understand that 1) it is almost impossible for current tech >> debt >> > already accumulated and 2) to won't be welcomed by community because of >> > indirect relationship to main project's goals. >> > Considering other parts, please, note [1], [2], [3], [4], [5], [6], >> > [7], >> [8] >> > and many many more issues that have no separate ticket. >> > >> > My point — such technical debt is overwhelming and will be never ever >> > approached. >> > That is one of the reasons why Ignite 3 being built from scratch, >> > having >> in >> > mind all mistakes we've already made and lots of errors we will never >> > do >> > just because there would be no legacy basic for that. >> > >> > >> > >> > [1] https://issues.apache.org/jira/browse/IGNITE-7190 >> > [2] https://issues.apache.org/jira/browse/IGNITE-7326 >> > [3] https://issues.apache.org/jira/browse/IGNITE-7672 >> > [4] https://issues.apache.org/jira/browse/IGNITE-8496 >> > [5] https://issues.apache.org/jira/browse/IGNITE-9866 >> > [6] https://issues.apache.org/jira/browse/IGNITE-10600 >> > [7] https://issues.apache.org/jira/browse/IGNITE-10683 >> > [8] https://issues.apache.org/jira/browse/IGNITE-10696 >> > >> > >> > >> > >> > >> >> On 29 Sep 2021, at 14:14, Nikolay Izhikov wrote: >> >> >> >>> — issues related to Maven build? possible Gradle upgrade? >> >> >> >> I’m not aware of the issues. >> >> Can you, please, send a tickets or description of existing issues? >> >> Anyway, it seems change of build tool can be done at any time we want >> >> >> >>> — issues related to run scripts? >> >>> — issues related to release and delivery processes and scripts? >> >> >> >> I’m not aware of those too. >> >> Can you point to then, please? >> >> >> >>> Are they going to be addressed during Apache Ignite evolution too? >> >> >> >> Yes, from my point of view. >> >> >> >>> 29 сент. 2021 г., в 14:03, Petr Ivanov >> написал(а): >> >>> >> >>> And what about: >> >>> — issues related to Maven build? possible Gradle upgrade? >> >>> — issues related to run scripts? >> >>> — issues related to release and delivery processes and scripts? >> >>> >> >>> Are they going to be addressed during Apache Ignite evolution too? >> >>> >> On 29 Sep 2021, at 13:47, Nikolay Izhikov >> wrote: >> >> > Does you vision of evolutionary improvement involve technical debt >> > addressing >> >> Yes, of course. >> >> My vision was the following (from the bird eye): >> >> - 2.20 - removals of LOCAL caches, MVCC and other abandoned >> features. >> (User API doesn’t change). >> - 2.30 - replace static XML configuration with the new dynamic >> approach. >> - 2.40 - replace H2 SQL engine with the Calcite >> >> etc. >> >> Versions depends on feature readiness. >> >> Anyway, I step back with the initial Ignite3 development, because, >> don’t >> want to interfere the progress. >> >> Respect to the developers who have courage to develop such complex >> things from scratch. >> >> > 29 сент. 2021 г., в 12:55, Petr Ivanov >> > написал(а): >> > >> > >> >> I believe that we should improve Ignite evolutionary and not >> >> revolutionary. >> >> First of all, change user API with the slow improvements step by
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Ivan, I'm not pushing, I'm trying to apply the lazy consensus. It soon will be a whole month since I've started the discussion - more than enough to express concerns and provide alternative suggestions. Please keep in mind that we are trying to address a very specific technical problem that influences the development. "Do nothing" is not really an option here. Either way, I will put the initial suggestion for the vote. -Val On Thu, Sep 30, 2021 at 12:24 AM Ivan Pavlukhin wrote: > Val, > > > Let's discuss this until the end of the week. If there is no clear > picture on option #2 by then, I suggest we go with #1. > > For a moment I felt that the proposal is pushed. Let's not do so. The > subject is very important, years impact I suppose. And the best way > here is to reach absolute consensus. Without tight timelines so far. > In case if we fail with consensus we can arrange formal voting. > > 2021-09-29 14:34 GMT+03:00, Petr Ivanov : > > I am watching how Apache Ignite does evolve for over a 3 years already > and > > see that such hidden (almost no Open Source Community points could be > > achieved for refactoring and addressing something that is not directly > > project's source executable code) issues drown under constant pressure of > > new features and releases. > > > > I have never created issues for Maven build refactoring (for instanced) > > because I understand that 1) it is almost impossible for current tech > debt > > already accumulated and 2) to won't be welcomed by community because of > > indirect relationship to main project's goals. > > Considering other parts, please, note [1], [2], [3], [4], [5], [6], [7], > [8] > > and many many more issues that have no separate ticket. > > > > My point — such technical debt is overwhelming and will be never ever > > approached. > > That is one of the reasons why Ignite 3 being built from scratch, having > in > > mind all mistakes we've already made and lots of errors we will never do > > just because there would be no legacy basic for that. > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-7190 > > [2] https://issues.apache.org/jira/browse/IGNITE-7326 > > [3] https://issues.apache.org/jira/browse/IGNITE-7672 > > [4] https://issues.apache.org/jira/browse/IGNITE-8496 > > [5] https://issues.apache.org/jira/browse/IGNITE-9866 > > [6] https://issues.apache.org/jira/browse/IGNITE-10600 > > [7] https://issues.apache.org/jira/browse/IGNITE-10683 > > [8] https://issues.apache.org/jira/browse/IGNITE-10696 > > > > > > > > > > > >> On 29 Sep 2021, at 14:14, Nikolay Izhikov wrote: > >> > >>> — issues related to Maven build? possible Gradle upgrade? > >> > >> I’m not aware of the issues. > >> Can you, please, send a tickets or description of existing issues? > >> Anyway, it seems change of build tool can be done at any time we want > >> > >>> — issues related to run scripts? > >>> — issues related to release and delivery processes and scripts? > >> > >> I’m not aware of those too. > >> Can you point to then, please? > >> > >>> Are they going to be addressed during Apache Ignite evolution too? > >> > >> Yes, from my point of view. > >> > >>> 29 сент. 2021 г., в 14:03, Petr Ivanov > написал(а): > >>> > >>> And what about: > >>> — issues related to Maven build? possible Gradle upgrade? > >>> — issues related to run scripts? > >>> — issues related to release and delivery processes and scripts? > >>> > >>> Are they going to be addressed during Apache Ignite evolution too? > >>> > On 29 Sep 2021, at 13:47, Nikolay Izhikov > wrote: > > > Does you vision of evolutionary improvement involve technical debt > > addressing > > Yes, of course. > > My vision was the following (from the bird eye): > > - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. > (User API doesn’t change). > - 2.30 - replace static XML configuration with the new dynamic > approach. > - 2.40 - replace H2 SQL engine with the Calcite > > etc. > > Versions depends on feature readiness. > > Anyway, I step back with the initial Ignite3 development, because, > don’t > want to interfere the progress. > > Respect to the developers who have courage to develop such complex > things from scratch. > > > 29 сент. 2021 г., в 12:55, Petr Ivanov > > написал(а): > > > > > >> I believe that we should improve Ignite evolutionary and not > >> revolutionary. > >> First of all, change user API with the slow improvements step by > >> step. > > > > Nikolay, > > > > Does you vision of evolutionary improvement involve technical debt > > addressing? > > > > > >> > >> > >>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev > >>> написал(а): > >>> > >>> Hello! > >>> > >>> If we go the second route, we can call the field "Generation". > >>> > >>> Generation: Ignite 2.x > >>> Gene
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Val, > Let's discuss this until the end of the week. If there is no clear picture on > option #2 by then, I suggest we go with #1. For a moment I felt that the proposal is pushed. Let's not do so. The subject is very important, years impact I suppose. And the best way here is to reach absolute consensus. Without tight timelines so far. In case if we fail with consensus we can arrange formal voting. 2021-09-29 14:34 GMT+03:00, Petr Ivanov : > I am watching how Apache Ignite does evolve for over a 3 years already and > see that such hidden (almost no Open Source Community points could be > achieved for refactoring and addressing something that is not directly > project's source executable code) issues drown under constant pressure of > new features and releases. > > I have never created issues for Maven build refactoring (for instanced) > because I understand that 1) it is almost impossible for current tech debt > already accumulated and 2) to won't be welcomed by community because of > indirect relationship to main project's goals. > Considering other parts, please, note [1], [2], [3], [4], [5], [6], [7], [8] > and many many more issues that have no separate ticket. > > My point — such technical debt is overwhelming and will be never ever > approached. > That is one of the reasons why Ignite 3 being built from scratch, having in > mind all mistakes we've already made and lots of errors we will never do > just because there would be no legacy basic for that. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-7190 > [2] https://issues.apache.org/jira/browse/IGNITE-7326 > [3] https://issues.apache.org/jira/browse/IGNITE-7672 > [4] https://issues.apache.org/jira/browse/IGNITE-8496 > [5] https://issues.apache.org/jira/browse/IGNITE-9866 > [6] https://issues.apache.org/jira/browse/IGNITE-10600 > [7] https://issues.apache.org/jira/browse/IGNITE-10683 > [8] https://issues.apache.org/jira/browse/IGNITE-10696 > > > > > >> On 29 Sep 2021, at 14:14, Nikolay Izhikov wrote: >> >>> — issues related to Maven build? possible Gradle upgrade? >> >> I’m not aware of the issues. >> Can you, please, send a tickets or description of existing issues? >> Anyway, it seems change of build tool can be done at any time we want >> >>> — issues related to run scripts? >>> — issues related to release and delivery processes and scripts? >> >> I’m not aware of those too. >> Can you point to then, please? >> >>> Are they going to be addressed during Apache Ignite evolution too? >> >> Yes, from my point of view. >> >>> 29 сент. 2021 г., в 14:03, Petr Ivanov написал(а): >>> >>> And what about: >>> — issues related to Maven build? possible Gradle upgrade? >>> — issues related to run scripts? >>> — issues related to release and delivery processes and scripts? >>> >>> Are they going to be addressed during Apache Ignite evolution too? >>> On 29 Sep 2021, at 13:47, Nikolay Izhikov wrote: > Does you vision of evolutionary improvement involve technical debt > addressing Yes, of course. My vision was the following (from the bird eye): - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User API doesn’t change). - 2.30 - replace static XML configuration with the new dynamic approach. - 2.40 - replace H2 SQL engine with the Calcite etc. Versions depends on feature readiness. Anyway, I step back with the initial Ignite3 development, because, don’t want to interfere the progress. Respect to the developers who have courage to develop such complex things from scratch. > 29 сент. 2021 г., в 12:55, Petr Ivanov > написал(а): > > >> I believe that we should improve Ignite evolutionary and not >> revolutionary. >> First of all, change user API with the slow improvements step by >> step. > > Nikolay, > > Does you vision of evolutionary improvement involve technical debt > addressing? > > >> >> >>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev >>> написал(а): >>> >>> Hello! >>> >>> If we go the second route, we can call the field "Generation". >>> >>> Generation: Ignite 2.x >>> Generation: Ignite 3 >>> >>> (no new tickets should ever be filed for Ignite 1.x but if they are, >>> they >>> should go to the first Generation) >>> >>> Regards. >>> -- >>> Ilya Kasnacheev >>> >>> >>> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko < >>> valentin.kuliche...@gmail.com>: >>> As for the original topic, we need to come to a solution. Let me summarize what we've discussed so far. -PROBLEM- Ignite 3 is the next major version of Apache Ignite. It targets the same use cases and provides a similar set of features as Ignite 2. At the same time, Ignite 2 and Ignite 3 are *technica
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
I am watching how Apache Ignite does evolve for over a 3 years already and see that such hidden (almost no Open Source Community points could be achieved for refactoring and addressing something that is not directly project's source executable code) issues drown under constant pressure of new features and releases. I have never created issues for Maven build refactoring (for instanced) because I understand that 1) it is almost impossible for current tech debt already accumulated and 2) to won't be welcomed by community because of indirect relationship to main project's goals. Considering other parts, please, note [1], [2], [3], [4], [5], [6], [7], [8] and many many more issues that have no separate ticket. My point — such technical debt is overwhelming and will be never ever approached. That is one of the reasons why Ignite 3 being built from scratch, having in mind all mistakes we've already made and lots of errors we will never do just because there would be no legacy basic for that. [1] https://issues.apache.org/jira/browse/IGNITE-7190 [2] https://issues.apache.org/jira/browse/IGNITE-7326 [3] https://issues.apache.org/jira/browse/IGNITE-7672 [4] https://issues.apache.org/jira/browse/IGNITE-8496 [5] https://issues.apache.org/jira/browse/IGNITE-9866 [6] https://issues.apache.org/jira/browse/IGNITE-10600 [7] https://issues.apache.org/jira/browse/IGNITE-10683 [8] https://issues.apache.org/jira/browse/IGNITE-10696 > On 29 Sep 2021, at 14:14, Nikolay Izhikov wrote: > >> — issues related to Maven build? possible Gradle upgrade? > > I’m not aware of the issues. > Can you, please, send a tickets or description of existing issues? > Anyway, it seems change of build tool can be done at any time we want > >> — issues related to run scripts? >> — issues related to release and delivery processes and scripts? > > I’m not aware of those too. > Can you point to then, please? > >> Are they going to be addressed during Apache Ignite evolution too? > > Yes, from my point of view. > >> 29 сент. 2021 г., в 14:03, Petr Ivanov написал(а): >> >> And what about: >> — issues related to Maven build? possible Gradle upgrade? >> — issues related to run scripts? >> — issues related to release and delivery processes and scripts? >> >> Are they going to be addressed during Apache Ignite evolution too? >> >>> On 29 Sep 2021, at 13:47, Nikolay Izhikov wrote: >>> Does you vision of evolutionary improvement involve technical debt addressing >>> >>> Yes, of course. >>> >>> My vision was the following (from the bird eye): >>> >>> - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User >>> API doesn’t change). >>> - 2.30 - replace static XML configuration with the new dynamic approach. >>> - 2.40 - replace H2 SQL engine with the Calcite >>> >>> etc. >>> >>> Versions depends on feature readiness. >>> >>> Anyway, I step back with the initial Ignite3 development, because, don’t >>> want to interfere the progress. >>> >>> Respect to the developers who have courage to develop such complex things >>> from scratch. >>> 29 сент. 2021 г., в 12:55, Petr Ivanov написал(а): > I believe that we should improve Ignite evolutionary and not > revolutionary. > First of all, change user API with the slow improvements step by step. Nikolay, Does you vision of evolutionary improvement involve technical debt addressing? > > >> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev >> написал(а): >> >> Hello! >> >> If we go the second route, we can call the field "Generation". >> >> Generation: Ignite 2.x >> Generation: Ignite 3 >> >> (no new tickets should ever be filed for Ignite 1.x but if they are, they >> should go to the first Generation) >> >> Regards. >> -- >> Ilya Kasnacheev >> >> >> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko < >> valentin.kuliche...@gmail.com>: >> >>> As for the original topic, we need to come to a solution. Let me >>> summarize >>> what we've discussed so far. >>> >>> -PROBLEM- >>> >>> Ignite 3 is the next major version of Apache Ignite. It targets the same >>> use cases and provides a similar set of features as Ignite 2. At the >>> same >>> time, Ignite 2 and Ignite 3 are *technically* separate projects. They >>> are >>> developed in different repositories (and therefore are based on >>> different >>> codebases) and implement different internal architectures. To achieve a >>> more efficient development process, we need to create a clear separation >>> between 2.x and 3.x within *development resources* (Jira and >>> Confluence). >>> >>> -POSSIBLE SOLUTIONS- >>> >>> 1. Create a separate Jira project and Confluence space for Ignite 3 >>> (initial suggestion). >>> 2. Add a *mandatory* field in Jir
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
> — issues related to Maven build? possible Gradle upgrade? I’m not aware of the issues. Can you, please, send a tickets or description of existing issues? Anyway, it seems change of build tool can be done at any time we want > — issues related to run scripts? > — issues related to release and delivery processes and scripts? I’m not aware of those too. Can you point to then, please? > Are they going to be addressed during Apache Ignite evolution too? Yes, from my point of view. > 29 сент. 2021 г., в 14:03, Petr Ivanov написал(а): > > And what about: > — issues related to Maven build? possible Gradle upgrade? > — issues related to run scripts? > — issues related to release and delivery processes and scripts? > > Are they going to be addressed during Apache Ignite evolution too? > >> On 29 Sep 2021, at 13:47, Nikolay Izhikov wrote: >> >>> Does you vision of evolutionary improvement involve technical debt >>> addressing >> >> Yes, of course. >> >> My vision was the following (from the bird eye): >> >> - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User >> API doesn’t change). >> - 2.30 - replace static XML configuration with the new dynamic approach. >> - 2.40 - replace H2 SQL engine with the Calcite >> >> etc. >> >> Versions depends on feature readiness. >> >> Anyway, I step back with the initial Ignite3 development, because, don’t >> want to interfere the progress. >> >> Respect to the developers who have courage to develop such complex things >> from scratch. >> >>> 29 сент. 2021 г., в 12:55, Petr Ivanov написал(а): >>> >>> I believe that we should improve Ignite evolutionary and not revolutionary. First of all, change user API with the slow improvements step by step. >>> >>> Nikolay, >>> >>> Does you vision of evolutionary improvement involve technical debt >>> addressing? >>> >>> > 29 сент. 2021 г., в 11:43, Ilya Kasnacheev > написал(а): > > Hello! > > If we go the second route, we can call the field "Generation". > > Generation: Ignite 2.x > Generation: Ignite 3 > > (no new tickets should ever be filed for Ignite 1.x but if they are, they > should go to the first Generation) > > Regards. > -- > Ilya Kasnacheev > > > ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > >> As for the original topic, we need to come to a solution. Let me >> summarize >> what we've discussed so far. >> >> -PROBLEM- >> >> Ignite 3 is the next major version of Apache Ignite. It targets the same >> use cases and provides a similar set of features as Ignite 2. At the same >> time, Ignite 2 and Ignite 3 are *technically* separate projects. They are >> developed in different repositories (and therefore are based on different >> codebases) and implement different internal architectures. To achieve a >> more efficient development process, we need to create a clear separation >> between 2.x and 3.x within *development resources* (Jira and Confluence). >> >> -POSSIBLE SOLUTIONS- >> >> 1. Create a separate Jira project and Confluence space for Ignite 3 >> (initial suggestion). >> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs >> to >> 2.x or 3.x. >> >> If we go with #2, there are still several things to figure out: >> >> - What is the name of this field? It needs to be intuitive to anyone who >> joins the community. >> - We need to make sure that Ignite 3 tickets are not mapped to 2.x >> versions, and vice versa. Can we restrict this in Jira? Or we will have >> to >> monitor this manually? >> - What do we do with Confluence? >> >> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if >> you >> still prefer the second option, could you please address the points >> above? >> I don't think it can be treated as an actual suggestion until we cover >> these details. >> >> Let's discuss this until the end of the week. If there is no clear >> picture >> on option #2 by then, I suggest we go with #1. >> >> -Val >> >> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko < >> valentin.kuliche...@gmail.com> wrote: >> >>> Folks, >>> >>> Versioning is a separate topic. We agreed on the current scheme in March >>> [1]. If someone thinks we need to change it, please create a new thread >> and >>> present your suggestions. >>> >>> [1] >>> >> https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E >>> >>> -Val >>> >>> On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov >> wrote: >>> Seems rational. But still 2.11.0 and 21.1.0 for the
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
And what about: — issues related to Maven build? possible Gradle upgrade? — issues related to run scripts? — issues related to release and delivery processes and scripts? Are they going to be addressed during Apache Ignite evolution too? > On 29 Sep 2021, at 13:47, Nikolay Izhikov wrote: > >> Does you vision of evolutionary improvement involve technical debt addressing > > Yes, of course. > > My vision was the following (from the bird eye): > > - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User > API doesn’t change). > - 2.30 - replace static XML configuration with the new dynamic approach. > - 2.40 - replace H2 SQL engine with the Calcite > > etc. > > Versions depends on feature readiness. > > Anyway, I step back with the initial Ignite3 development, because, don’t want > to interfere the progress. > > Respect to the developers who have courage to develop such complex things > from scratch. > >> 29 сент. 2021 г., в 12:55, Petr Ivanov написал(а): >> >> >>> I believe that we should improve Ignite evolutionary and not revolutionary. >>> First of all, change user API with the slow improvements step by step. >> >> Nikolay, >> >> Does you vision of evolutionary improvement involve technical debt >> addressing? >> >> >>> >>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev написал(а): Hello! If we go the second route, we can call the field "Generation". Generation: Ignite 2.x Generation: Ignite 3 (no new tickets should ever be filed for Ignite 1.x but if they are, they should go to the first Generation) Regards. -- Ilya Kasnacheev ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > As for the original topic, we need to come to a solution. Let me summarize > what we've discussed so far. > > -PROBLEM- > > Ignite 3 is the next major version of Apache Ignite. It targets the same > use cases and provides a similar set of features as Ignite 2. At the same > time, Ignite 2 and Ignite 3 are *technically* separate projects. They are > developed in different repositories (and therefore are based on different > codebases) and implement different internal architectures. To achieve a > more efficient development process, we need to create a clear separation > between 2.x and 3.x within *development resources* (Jira and Confluence). > > -POSSIBLE SOLUTIONS- > > 1. Create a separate Jira project and Confluence space for Ignite 3 > (initial suggestion). > 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to > 2.x or 3.x. > > If we go with #2, there are still several things to figure out: > > - What is the name of this field? It needs to be intuitive to anyone who > joins the community. > - We need to make sure that Ignite 3 tickets are not mapped to 2.x > versions, and vice versa. Can we restrict this in Jira? Or we will have > to > monitor this manually? > - What do we do with Confluence? > > Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if > you > still prefer the second option, could you please address the points above? > I don't think it can be treated as an actual suggestion until we cover > these details. > > Let's discuss this until the end of the week. If there is no clear picture > on option #2 by then, I suggest we go with #1. > > -Val > > On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> Folks, >> >> Versioning is a separate topic. We agreed on the current scheme in March >> [1]. If someone thinks we need to change it, please create a new thread > and >> present your suggestions. >> >> [1] >> > https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E >> >> -Val >> >> On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov > wrote: >> >>> Seems rational. >>> >>> >>> But still 2.11.0 and 21.1.0 for the time being will look like similar or >>> error in either version... >>> >>> On 27 Sep 2021, at 18:11, Ivan Pavlukhin wrote: I mean that Ignite 2.x will continue to use old scheme and Ignite 3 will be e.g. Ignite 21.1 and so on. 2021-09-27 14:57 GMT+03:00, Petr Ivanov : > How will not they clash if version is based only on date? > >> On 27 Sep 2021, at 14:33, Ivan Pavlukhin > wrote: >> >> Today it is quite common to use calendar-based versioning scheme, > e.g. >> [1]. We can consider it for Ignite 3. Luckily versions will not > clash. >> >> [1] https://www.co
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
> Does you vision of evolutionary improvement involve technical debt addressing Yes, of course. My vision was the following (from the bird eye): - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User API doesn’t change). - 2.30 - replace static XML configuration with the new dynamic approach. - 2.40 - replace H2 SQL engine with the Calcite etc. Versions depends on feature readiness. Anyway, I step back with the initial Ignite3 development, because, don’t want to interfere the progress. Respect to the developers who have courage to develop such complex things from scratch. > 29 сент. 2021 г., в 12:55, Petr Ivanov написал(а): > > >> I believe that we should improve Ignite evolutionary and not revolutionary. >> First of all, change user API with the slow improvements step by step. > > Nikolay, > > Does you vision of evolutionary improvement involve technical debt addressing? > > >> >> >>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev >>> написал(а): >>> >>> Hello! >>> >>> If we go the second route, we can call the field "Generation". >>> >>> Generation: Ignite 2.x >>> Generation: Ignite 3 >>> >>> (no new tickets should ever be filed for Ignite 1.x but if they are, they >>> should go to the first Generation) >>> >>> Regards. >>> -- >>> Ilya Kasnacheev >>> >>> >>> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko < >>> valentin.kuliche...@gmail.com>: >>> As for the original topic, we need to come to a solution. Let me summarize what we've discussed so far. -PROBLEM- Ignite 3 is the next major version of Apache Ignite. It targets the same use cases and provides a similar set of features as Ignite 2. At the same time, Ignite 2 and Ignite 3 are *technically* separate projects. They are developed in different repositories (and therefore are based on different codebases) and implement different internal architectures. To achieve a more efficient development process, we need to create a clear separation between 2.x and 3.x within *development resources* (Jira and Confluence). -POSSIBLE SOLUTIONS- 1. Create a separate Jira project and Confluence space for Ignite 3 (initial suggestion). 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to 2.x or 3.x. If we go with #2, there are still several things to figure out: - What is the name of this field? It needs to be intuitive to anyone who joins the community. - We need to make sure that Ignite 3 tickets are not mapped to 2.x versions, and vice versa. Can we restrict this in Jira? Or we will have to monitor this manually? - What do we do with Confluence? Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if you still prefer the second option, could you please address the points above? I don't think it can be treated as an actual suggestion until we cover these details. Let's discuss this until the end of the week. If there is no clear picture on option #2 by then, I suggest we go with #1. -Val On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Folks, > > Versioning is a separate topic. We agreed on the current scheme in March > [1]. If someone thinks we need to change it, please create a new thread and > present your suggestions. > > [1] > https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E > > -Val > > On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov wrote: > >> Seems rational. >> >> >> But still 2.11.0 and 21.1.0 for the time being will look like similar or >> error in either version... >> >> >>> On 27 Sep 2021, at 18:11, Ivan Pavlukhin wrote: >>> >>> I mean that Ignite 2.x will continue to use old scheme and Ignite 3 >>> will be e.g. Ignite 21.1 and so on. >>> >>> 2021-09-27 14:57 GMT+03:00, Petr Ivanov : How will not they clash if version is based only on date? > On 27 Sep 2021, at 14:33, Ivan Pavlukhin wrote: > > Today it is quite common to use calendar-based versioning scheme, e.g. > [1]. We can consider it for Ignite 3. Luckily versions will not clash. > > [1] https://www.cockroachlabs.com/docs/releases/index.html > > 2021-09-27 10:49 GMT+03:00, Petr Ivanov : >> That name will definitely confuse Jira users. >> >> Let's stick to basic devision by 2.x and 3.x — it seems most >> intuitive >> and >> has lots of examples inside ASF, look at the Tomcat for instance. >> >>> On 25 Sep 2021, at 21:05, Saikat Maitra >>> wrote: >>> >>> Hi,
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
> I believe that we should improve Ignite evolutionary and not revolutionary. > First of all, change user API with the slow improvements step by step. Nikolay, Does you vision of evolutionary improvement involve technical debt addressing? > > >> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev >> написал(а): >> >> Hello! >> >> If we go the second route, we can call the field "Generation". >> >> Generation: Ignite 2.x >> Generation: Ignite 3 >> >> (no new tickets should ever be filed for Ignite 1.x but if they are, they >> should go to the first Generation) >> >> Regards. >> -- >> Ilya Kasnacheev >> >> >> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko < >> valentin.kuliche...@gmail.com>: >> >>> As for the original topic, we need to come to a solution. Let me summarize >>> what we've discussed so far. >>> >>> -PROBLEM- >>> >>> Ignite 3 is the next major version of Apache Ignite. It targets the same >>> use cases and provides a similar set of features as Ignite 2. At the same >>> time, Ignite 2 and Ignite 3 are *technically* separate projects. They are >>> developed in different repositories (and therefore are based on different >>> codebases) and implement different internal architectures. To achieve a >>> more efficient development process, we need to create a clear separation >>> between 2.x and 3.x within *development resources* (Jira and Confluence). >>> >>> -POSSIBLE SOLUTIONS- >>> >>> 1. Create a separate Jira project and Confluence space for Ignite 3 >>> (initial suggestion). >>> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to >>> 2.x or 3.x. >>> >>> If we go with #2, there are still several things to figure out: >>> >>> - What is the name of this field? It needs to be intuitive to anyone who >>> joins the community. >>> - We need to make sure that Ignite 3 tickets are not mapped to 2.x >>> versions, and vice versa. Can we restrict this in Jira? Or we will have >>> to >>> monitor this manually? >>> - What do we do with Confluence? >>> >>> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if you >>> still prefer the second option, could you please address the points above? >>> I don't think it can be treated as an actual suggestion until we cover >>> these details. >>> >>> Let's discuss this until the end of the week. If there is no clear picture >>> on option #2 by then, I suggest we go with #1. >>> >>> -Val >>> >>> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko < >>> valentin.kuliche...@gmail.com> wrote: >>> Folks, Versioning is a separate topic. We agreed on the current scheme in March [1]. If someone thinks we need to change it, please create a new thread >>> and present your suggestions. [1] >>> https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E -Val On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov >>> wrote: > Seems rational. > > > But still 2.11.0 and 21.1.0 for the time being will look like similar or > error in either version... > > >> On 27 Sep 2021, at 18:11, Ivan Pavlukhin wrote: >> >> I mean that Ignite 2.x will continue to use old scheme and Ignite 3 >> will be e.g. Ignite 21.1 and so on. >> >> 2021-09-27 14:57 GMT+03:00, Petr Ivanov : >>> How will not they clash if version is based only on date? >>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin >>> wrote: Today it is quite common to use calendar-based versioning scheme, >>> e.g. [1]. We can consider it for Ignite 3. Luckily versions will not >>> clash. [1] https://www.cockroachlabs.com/docs/releases/index.html 2021-09-27 10:49 GMT+03:00, Petr Ivanov : > That name will definitely confuse Jira users. > > Let's stick to basic devision by 2.x and 3.x — it seems most > intuitive > and > has lots of examples inside ASF, look at the Tomcat for instance. > >> On 25 Sep 2021, at 21:05, Saikat Maitra >> wrote: >> >> Hi, >> >> I like the major version update like Ignite 3.0 but if we were to > come >> up >> with a name my other suggestion would be >> >> Ignite-kernel >> >> kernel - for the central or most important part of something >> >> Also taken references from Compute kernel - a routine compiled for > high >> throughput accelerators >> >> https://en.wikipedia.org/wiki/Compute_kernel >> >> Regards, >> Saikat >> >> >> On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko < >> valentin.kuliche...@gmail.com> wrote: >> >>> Kafka and Spark didn't split codebases (at least to my >>> knowledge). >>> Separating
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Hello, Valentin. > Nikolay, Ilya, Denis, and others who opposed the initial suggestion It seems I don’t write my point clear. I’m +1 to have another jira project for Ignite3. My point is - Ignite3 is not Ignite - it just another database engine. > Ignite 2 and Ignite 3 are *technically* separate projects You definition of «technically» is unclear for me. > It targets the same use cases and provides a similar set of features as > Ignite 2 I don’t believe it’s true. I believe that we should improve Ignite evolutionary and not revolutionary. First of all, change user API with the slow improvements step by step. Kafka3, you mentioned, AFAIK doesn’t change user API at all, except removing deprecated methods. [1] [1] https://www.confluent.io/blog/apache-kafka-3-0-major-improvements-and-new-features/ > 29 сент. 2021 г., в 11:43, Ilya Kasnacheev > написал(а): > > Hello! > > If we go the second route, we can call the field "Generation". > > Generation: Ignite 2.x > Generation: Ignite 3 > > (no new tickets should ever be filed for Ignite 1.x but if they are, they > should go to the first Generation) > > Regards. > -- > Ilya Kasnacheev > > > ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > >> As for the original topic, we need to come to a solution. Let me summarize >> what we've discussed so far. >> >> -PROBLEM- >> >> Ignite 3 is the next major version of Apache Ignite. It targets the same >> use cases and provides a similar set of features as Ignite 2. At the same >> time, Ignite 2 and Ignite 3 are *technically* separate projects. They are >> developed in different repositories (and therefore are based on different >> codebases) and implement different internal architectures. To achieve a >> more efficient development process, we need to create a clear separation >> between 2.x and 3.x within *development resources* (Jira and Confluence). >> >> -POSSIBLE SOLUTIONS- >> >> 1. Create a separate Jira project and Confluence space for Ignite 3 >> (initial suggestion). >> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to >> 2.x or 3.x. >> >> If we go with #2, there are still several things to figure out: >> >> - What is the name of this field? It needs to be intuitive to anyone who >> joins the community. >> - We need to make sure that Ignite 3 tickets are not mapped to 2.x >> versions, and vice versa. Can we restrict this in Jira? Or we will have >> to >> monitor this manually? >> - What do we do with Confluence? >> >> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if you >> still prefer the second option, could you please address the points above? >> I don't think it can be treated as an actual suggestion until we cover >> these details. >> >> Let's discuss this until the end of the week. If there is no clear picture >> on option #2 by then, I suggest we go with #1. >> >> -Val >> >> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko < >> valentin.kuliche...@gmail.com> wrote: >> >>> Folks, >>> >>> Versioning is a separate topic. We agreed on the current scheme in March >>> [1]. If someone thinks we need to change it, please create a new thread >> and >>> present your suggestions. >>> >>> [1] >>> >> https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E >>> >>> -Val >>> >>> On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov >> wrote: >>> Seems rational. But still 2.11.0 and 21.1.0 for the time being will look like similar or error in either version... > On 27 Sep 2021, at 18:11, Ivan Pavlukhin wrote: > > I mean that Ignite 2.x will continue to use old scheme and Ignite 3 > will be e.g. Ignite 21.1 and so on. > > 2021-09-27 14:57 GMT+03:00, Petr Ivanov : >> How will not they clash if version is based only on date? >> >>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin >> wrote: >>> >>> Today it is quite common to use calendar-based versioning scheme, >> e.g. >>> [1]. We can consider it for Ignite 3. Luckily versions will not >> clash. >>> >>> [1] https://www.cockroachlabs.com/docs/releases/index.html >>> >>> 2021-09-27 10:49 GMT+03:00, Petr Ivanov : That name will definitely confuse Jira users. Let's stick to basic devision by 2.x and 3.x — it seems most intuitive and has lots of examples inside ASF, look at the Tomcat for instance. > On 25 Sep 2021, at 21:05, Saikat Maitra > wrote: > > Hi, > > I like the major version update like Ignite 3.0 but if we were to come > up > with a name my other suggestion would be > > Ignite-kernel > > kernel - for the central or most important part of something > > Also taken references from Compute kernel
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Hello! If we go the second route, we can call the field "Generation". Generation: Ignite 2.x Generation: Ignite 3 (no new tickets should ever be filed for Ignite 1.x but if they are, they should go to the first Generation) Regards. -- Ilya Kasnacheev ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > As for the original topic, we need to come to a solution. Let me summarize > what we've discussed so far. > > -PROBLEM- > > Ignite 3 is the next major version of Apache Ignite. It targets the same > use cases and provides a similar set of features as Ignite 2. At the same > time, Ignite 2 and Ignite 3 are *technically* separate projects. They are > developed in different repositories (and therefore are based on different > codebases) and implement different internal architectures. To achieve a > more efficient development process, we need to create a clear separation > between 2.x and 3.x within *development resources* (Jira and Confluence). > > -POSSIBLE SOLUTIONS- > > 1. Create a separate Jira project and Confluence space for Ignite 3 > (initial suggestion). > 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to > 2.x or 3.x. > > If we go with #2, there are still several things to figure out: > >- What is the name of this field? It needs to be intuitive to anyone who >joins the community. >- We need to make sure that Ignite 3 tickets are not mapped to 2.x >versions, and vice versa. Can we restrict this in Jira? Or we will have > to >monitor this manually? >- What do we do with Confluence? > > Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if you > still prefer the second option, could you please address the points above? > I don't think it can be treated as an actual suggestion until we cover > these details. > > Let's discuss this until the end of the week. If there is no clear picture > on option #2 by then, I suggest we go with #1. > > -Val > > On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Folks, > > > > Versioning is a separate topic. We agreed on the current scheme in March > > [1]. If someone thinks we need to change it, please create a new thread > and > > present your suggestions. > > > > [1] > > > https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E > > > > -Val > > > > On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov > wrote: > > > >> Seems rational. > >> > >> > >> But still 2.11.0 and 21.1.0 for the time being will look like similar or > >> error in either version... > >> > >> > >> > On 27 Sep 2021, at 18:11, Ivan Pavlukhin wrote: > >> > > >> > I mean that Ignite 2.x will continue to use old scheme and Ignite 3 > >> > will be e.g. Ignite 21.1 and so on. > >> > > >> > 2021-09-27 14:57 GMT+03:00, Petr Ivanov : > >> >> How will not they clash if version is based only on date? > >> >> > >> >>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin > wrote: > >> >>> > >> >>> Today it is quite common to use calendar-based versioning scheme, > e.g. > >> >>> [1]. We can consider it for Ignite 3. Luckily versions will not > clash. > >> >>> > >> >>> [1] https://www.cockroachlabs.com/docs/releases/index.html > >> >>> > >> >>> 2021-09-27 10:49 GMT+03:00, Petr Ivanov : > >> That name will definitely confuse Jira users. > >> > >> Let's stick to basic devision by 2.x and 3.x — it seems most > >> intuitive > >> and > >> has lots of examples inside ASF, look at the Tomcat for instance. > >> > >> > On 25 Sep 2021, at 21:05, Saikat Maitra > >> > wrote: > >> > > >> > Hi, > >> > > >> > I like the major version update like Ignite 3.0 but if we were to > >> come > >> > up > >> > with a name my other suggestion would be > >> > > >> > Ignite-kernel > >> > > >> > kernel - for the central or most important part of something > >> > > >> > Also taken references from Compute kernel - a routine compiled for > >> high > >> > throughput accelerators > >> > > >> > https://en.wikipedia.org/wiki/Compute_kernel > >> > > >> > Regards, > >> > Saikat > >> > > >> > > >> > On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko < > >> > valentin.kuliche...@gmail.com> wrote: > >> > > >> >> Kafka and Spark didn't split codebases (at least to my > knowledge). > >> >> Separating codebases was the fundamental step, everything else > is a > >> >> technicality. > >> >> > >> >> Having said that, I will be OK with your suggestion as I don't > >> really > >> >> see > >> >> a > >> >> difference, although I'm not sure we will be able to come up > with a > >> >> name > >> >> that is more intuitive than a separate project :) > >> >> > >> >> Let's see what others think. > >> >> > >> >> -Val > >> >> > >> >> On Sat, Sep 25, 2021 at 12:23 AM Denis Ma
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
As for the original topic, we need to come to a solution. Let me summarize what we've discussed so far. -PROBLEM- Ignite 3 is the next major version of Apache Ignite. It targets the same use cases and provides a similar set of features as Ignite 2. At the same time, Ignite 2 and Ignite 3 are *technically* separate projects. They are developed in different repositories (and therefore are based on different codebases) and implement different internal architectures. To achieve a more efficient development process, we need to create a clear separation between 2.x and 3.x within *development resources* (Jira and Confluence). -POSSIBLE SOLUTIONS- 1. Create a separate Jira project and Confluence space for Ignite 3 (initial suggestion). 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to 2.x or 3.x. If we go with #2, there are still several things to figure out: - What is the name of this field? It needs to be intuitive to anyone who joins the community. - We need to make sure that Ignite 3 tickets are not mapped to 2.x versions, and vice versa. Can we restrict this in Jira? Or we will have to monitor this manually? - What do we do with Confluence? Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if you still prefer the second option, could you please address the points above? I don't think it can be treated as an actual suggestion until we cover these details. Let's discuss this until the end of the week. If there is no clear picture on option #2 by then, I suggest we go with #1. -Val On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Folks, > > Versioning is a separate topic. We agreed on the current scheme in March > [1]. If someone thinks we need to change it, please create a new thread and > present your suggestions. > > [1] > https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E > > -Val > > On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov wrote: > >> Seems rational. >> >> >> But still 2.11.0 and 21.1.0 for the time being will look like similar or >> error in either version... >> >> >> > On 27 Sep 2021, at 18:11, Ivan Pavlukhin wrote: >> > >> > I mean that Ignite 2.x will continue to use old scheme and Ignite 3 >> > will be e.g. Ignite 21.1 and so on. >> > >> > 2021-09-27 14:57 GMT+03:00, Petr Ivanov : >> >> How will not they clash if version is based only on date? >> >> >> >>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin wrote: >> >>> >> >>> Today it is quite common to use calendar-based versioning scheme, e.g. >> >>> [1]. We can consider it for Ignite 3. Luckily versions will not clash. >> >>> >> >>> [1] https://www.cockroachlabs.com/docs/releases/index.html >> >>> >> >>> 2021-09-27 10:49 GMT+03:00, Petr Ivanov : >> That name will definitely confuse Jira users. >> >> Let's stick to basic devision by 2.x and 3.x — it seems most >> intuitive >> and >> has lots of examples inside ASF, look at the Tomcat for instance. >> >> > On 25 Sep 2021, at 21:05, Saikat Maitra >> > wrote: >> > >> > Hi, >> > >> > I like the major version update like Ignite 3.0 but if we were to >> come >> > up >> > with a name my other suggestion would be >> > >> > Ignite-kernel >> > >> > kernel - for the central or most important part of something >> > >> > Also taken references from Compute kernel - a routine compiled for >> high >> > throughput accelerators >> > >> > https://en.wikipedia.org/wiki/Compute_kernel >> > >> > Regards, >> > Saikat >> > >> > >> > On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko < >> > valentin.kuliche...@gmail.com> wrote: >> > >> >> Kafka and Spark didn't split codebases (at least to my knowledge). >> >> Separating codebases was the fundamental step, everything else is a >> >> technicality. >> >> >> >> Having said that, I will be OK with your suggestion as I don't >> really >> >> see >> >> a >> >> difference, although I'm not sure we will be able to come up with a >> >> name >> >> that is more intuitive than a separate project :) >> >> >> >> Let's see what others think. >> >> >> >> -Val >> >> >> >> On Sat, Sep 25, 2021 at 12:23 AM Denis Magda >> >> wrote: >> >> >> >>> Moving the discussion back to the dev list. >> >>> >> >>> Val, Andrey, for that purpose we can ask INFRA to create a >> >>> special mandatory field such as "Architecture" with two predefined >> >> values - >> >>> "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it >> needs >> >>> to >> >>> be >> >>> intuitive enough even for users who submit issues. What disturbs >> me >> >>> is >> >> that >> >>> neither Kafka nor Spark have a different project for the recently >> >> released >> >>> versions 3. A dif
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Folks, Versioning is a separate topic. We agreed on the current scheme in March [1]. If someone thinks we need to change it, please create a new thread and present your suggestions. [1] https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E -Val On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov wrote: > Seems rational. > > > But still 2.11.0 and 21.1.0 for the time being will look like similar or > error in either version... > > > > On 27 Sep 2021, at 18:11, Ivan Pavlukhin wrote: > > > > I mean that Ignite 2.x will continue to use old scheme and Ignite 3 > > will be e.g. Ignite 21.1 and so on. > > > > 2021-09-27 14:57 GMT+03:00, Petr Ivanov : > >> How will not they clash if version is based only on date? > >> > >>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin wrote: > >>> > >>> Today it is quite common to use calendar-based versioning scheme, e.g. > >>> [1]. We can consider it for Ignite 3. Luckily versions will not clash. > >>> > >>> [1] https://www.cockroachlabs.com/docs/releases/index.html > >>> > >>> 2021-09-27 10:49 GMT+03:00, Petr Ivanov : > That name will definitely confuse Jira users. > > Let's stick to basic devision by 2.x and 3.x — it seems most intuitive > and > has lots of examples inside ASF, look at the Tomcat for instance. > > > On 25 Sep 2021, at 21:05, Saikat Maitra > > wrote: > > > > Hi, > > > > I like the major version update like Ignite 3.0 but if we were to > come > > up > > with a name my other suggestion would be > > > > Ignite-kernel > > > > kernel - for the central or most important part of something > > > > Also taken references from Compute kernel - a routine compiled for > high > > throughput accelerators > > > > https://en.wikipedia.org/wiki/Compute_kernel > > > > Regards, > > Saikat > > > > > > On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > >> Kafka and Spark didn't split codebases (at least to my knowledge). > >> Separating codebases was the fundamental step, everything else is a > >> technicality. > >> > >> Having said that, I will be OK with your suggestion as I don't > really > >> see > >> a > >> difference, although I'm not sure we will be able to come up with a > >> name > >> that is more intuitive than a separate project :) > >> > >> Let's see what others think. > >> > >> -Val > >> > >> On Sat, Sep 25, 2021 at 12:23 AM Denis Magda > >> wrote: > >> > >>> Moving the discussion back to the dev list. > >>> > >>> Val, Andrey, for that purpose we can ask INFRA to create a > >>> special mandatory field such as "Architecture" with two predefined > >> values - > >>> "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs > >>> to > >>> be > >>> intuitive enough even for users who submit issues. What disturbs me > >>> is > >> that > >>> neither Kafka nor Spark have a different project for the recently > >> released > >>> versions 3. A different GitHub project is not that disturbing. > >>> > >>> - > >>> Denis > >>> > >>> > >>> On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko < > >>> valentin.kuliche...@gmail.com> wrote: > >>> > Denis, > > From a purely technical perspective, these are indeed two separate > projects, because they are based on different codebases. The split > >> you're > talking about happened a year ago, when we created the repo for > Ignite > >> 3. > This significantly differs from the 1.x->2.x transition, as these > two > shared the codebase. > > For the same reason, a bug filed for 2.x can't be just > transitioned > to > 3.x. It will either not exist in 3.x in the first place, or will > >> require > >>> a > completely different fix, which will mean two different tickets. > > That said, I still believe that Ignite 2 and Ignite 3 are just > >> different > versions of the same product, because, as you correctly mentioned, > they > target "same users, community, use cases". At the same time, they > are > developed as different projects on the technical level. Let's not > >> confuse > these two aspects with each other - they are largely orthogonal. > > At this point, creating a Jira project doesn't change anything > fundamentally. It's only about ease of use of our tooling and > efficient > ticket management. > > -Val > > On Thu, Sep 23, 2021 at 10:15 PM Denis Magda > >> wrote: > > > Folks, you confuse me. I've never treated
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Seems rational. But still 2.11.0 and 21.1.0 for the time being will look like similar or error in either version... > On 27 Sep 2021, at 18:11, Ivan Pavlukhin wrote: > > I mean that Ignite 2.x will continue to use old scheme and Ignite 3 > will be e.g. Ignite 21.1 and so on. > > 2021-09-27 14:57 GMT+03:00, Petr Ivanov : >> How will not they clash if version is based only on date? >> >>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin wrote: >>> >>> Today it is quite common to use calendar-based versioning scheme, e.g. >>> [1]. We can consider it for Ignite 3. Luckily versions will not clash. >>> >>> [1] https://www.cockroachlabs.com/docs/releases/index.html >>> >>> 2021-09-27 10:49 GMT+03:00, Petr Ivanov : That name will definitely confuse Jira users. Let's stick to basic devision by 2.x and 3.x — it seems most intuitive and has lots of examples inside ASF, look at the Tomcat for instance. > On 25 Sep 2021, at 21:05, Saikat Maitra > wrote: > > Hi, > > I like the major version update like Ignite 3.0 but if we were to come > up > with a name my other suggestion would be > > Ignite-kernel > > kernel - for the central or most important part of something > > Also taken references from Compute kernel - a routine compiled for high > throughput accelerators > > https://en.wikipedia.org/wiki/Compute_kernel > > Regards, > Saikat > > > On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> Kafka and Spark didn't split codebases (at least to my knowledge). >> Separating codebases was the fundamental step, everything else is a >> technicality. >> >> Having said that, I will be OK with your suggestion as I don't really >> see >> a >> difference, although I'm not sure we will be able to come up with a >> name >> that is more intuitive than a separate project :) >> >> Let's see what others think. >> >> -Val >> >> On Sat, Sep 25, 2021 at 12:23 AM Denis Magda >> wrote: >> >>> Moving the discussion back to the dev list. >>> >>> Val, Andrey, for that purpose we can ask INFRA to create a >>> special mandatory field such as "Architecture" with two predefined >> values - >>> "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs >>> to >>> be >>> intuitive enough even for users who submit issues. What disturbs me >>> is >> that >>> neither Kafka nor Spark have a different project for the recently >> released >>> versions 3. A different GitHub project is not that disturbing. >>> >>> - >>> Denis >>> >>> >>> On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko < >>> valentin.kuliche...@gmail.com> wrote: >>> Denis, From a purely technical perspective, these are indeed two separate projects, because they are based on different codebases. The split >> you're talking about happened a year ago, when we created the repo for Ignite >> 3. This significantly differs from the 1.x->2.x transition, as these two shared the codebase. For the same reason, a bug filed for 2.x can't be just transitioned to 3.x. It will either not exist in 3.x in the first place, or will >> require >>> a completely different fix, which will mean two different tickets. That said, I still believe that Ignite 2 and Ignite 3 are just >> different versions of the same product, because, as you correctly mentioned, they target "same users, community, use cases". At the same time, they are developed as different projects on the technical level. Let's not >> confuse these two aspects with each other - they are largely orthogonal. At this point, creating a Jira project doesn't change anything fundamentally. It's only about ease of use of our tooling and efficient ticket management. -Val On Thu, Sep 23, 2021 at 10:15 PM Denis Magda >> wrote: > Folks, you confuse me. I've never treated Ignite 3 as a different > project. It's the same Ignite (distributed database for >> high-performance > computing...) but on a modernized architecture and APIs - thus, a >> major > version. Same users, community, use cases. > > But, I'm against separate JIRA or Confluence projects. This is how >>> you're > truly stepping on a project-split path. When we used to work on > Ignite >>> 2 we > could live within the same JIRA space with Ignite 1. Moreover, many >>> tickets > that are filed against Ignite 2 can be fix
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
I mean that Ignite 2.x will continue to use old scheme and Ignite 3 will be e.g. Ignite 21.1 and so on. 2021-09-27 14:57 GMT+03:00, Petr Ivanov : > How will not they clash if version is based only on date? > >> On 27 Sep 2021, at 14:33, Ivan Pavlukhin wrote: >> >> Today it is quite common to use calendar-based versioning scheme, e.g. >> [1]. We can consider it for Ignite 3. Luckily versions will not clash. >> >> [1] https://www.cockroachlabs.com/docs/releases/index.html >> >> 2021-09-27 10:49 GMT+03:00, Petr Ivanov : >>> That name will definitely confuse Jira users. >>> >>> Let's stick to basic devision by 2.x and 3.x — it seems most intuitive >>> and >>> has lots of examples inside ASF, look at the Tomcat for instance. >>> On 25 Sep 2021, at 21:05, Saikat Maitra wrote: Hi, I like the major version update like Ignite 3.0 but if we were to come up with a name my other suggestion would be Ignite-kernel kernel - for the central or most important part of something Also taken references from Compute kernel - a routine compiled for high throughput accelerators https://en.wikipedia.org/wiki/Compute_kernel Regards, Saikat On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Kafka and Spark didn't split codebases (at least to my knowledge). > Separating codebases was the fundamental step, everything else is a > technicality. > > Having said that, I will be OK with your suggestion as I don't really > see > a > difference, although I'm not sure we will be able to come up with a > name > that is more intuitive than a separate project :) > > Let's see what others think. > > -Val > > On Sat, Sep 25, 2021 at 12:23 AM Denis Magda > wrote: > >> Moving the discussion back to the dev list. >> >> Val, Andrey, for that purpose we can ask INFRA to create a >> special mandatory field such as "Architecture" with two predefined > values - >> "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs >> to >> be >> intuitive enough even for users who submit issues. What disturbs me >> is > that >> neither Kafka nor Spark have a different project for the recently > released >> versions 3. A different GitHub project is not that disturbing. >> >> - >> Denis >> >> >> On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko < >> valentin.kuliche...@gmail.com> wrote: >> >>> Denis, >>> >>> From a purely technical perspective, these are indeed two separate >>> projects, because they are based on different codebases. The split > you're >>> talking about happened a year ago, when we created the repo for >>> Ignite > 3. >>> This significantly differs from the 1.x->2.x transition, as these >>> two >>> shared the codebase. >>> >>> For the same reason, a bug filed for 2.x can't be just transitioned >>> to >>> 3.x. It will either not exist in 3.x in the first place, or will > require >> a >>> completely different fix, which will mean two different tickets. >>> >>> That said, I still believe that Ignite 2 and Ignite 3 are just > different >>> versions of the same product, because, as you correctly mentioned, >>> they >>> target "same users, community, use cases". At the same time, they >>> are >>> developed as different projects on the technical level. Let's not > confuse >>> these two aspects with each other - they are largely orthogonal. >>> >>> At this point, creating a Jira project doesn't change anything >>> fundamentally. It's only about ease of use of our tooling and >>> efficient >>> ticket management. >>> >>> -Val >>> >>> On Thu, Sep 23, 2021 at 10:15 PM Denis Magda > wrote: >>> Folks, you confuse me. I've never treated Ignite 3 as a different project. It's the same Ignite (distributed database for > high-performance computing...) but on a modernized architecture and APIs - thus, a > major version. Same users, community, use cases. But, I'm against separate JIRA or Confluence projects. This is how >> you're truly stepping on a project-split path. When we used to work on Ignite >> 2 we could live within the same JIRA space with Ignite 1. Moreover, many >> tickets that are filed against Ignite 2 can be fixed in Ignite 3 only - which >> is a version change in our JIRA. So, -1 from me for the separate JIRA proposal. - Denis On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov wrote: > Val, > > I don't see any issues having
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
How will not they clash if version is based only on date? > On 27 Sep 2021, at 14:33, Ivan Pavlukhin wrote: > > Today it is quite common to use calendar-based versioning scheme, e.g. > [1]. We can consider it for Ignite 3. Luckily versions will not clash. > > [1] https://www.cockroachlabs.com/docs/releases/index.html > > 2021-09-27 10:49 GMT+03:00, Petr Ivanov : >> That name will definitely confuse Jira users. >> >> Let's stick to basic devision by 2.x and 3.x — it seems most intuitive and >> has lots of examples inside ASF, look at the Tomcat for instance. >> >>> On 25 Sep 2021, at 21:05, Saikat Maitra wrote: >>> >>> Hi, >>> >>> I like the major version update like Ignite 3.0 but if we were to come up >>> with a name my other suggestion would be >>> >>> Ignite-kernel >>> >>> kernel - for the central or most important part of something >>> >>> Also taken references from Compute kernel - a routine compiled for high >>> throughput accelerators >>> >>> https://en.wikipedia.org/wiki/Compute_kernel >>> >>> Regards, >>> Saikat >>> >>> >>> On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko < >>> valentin.kuliche...@gmail.com> wrote: >>> Kafka and Spark didn't split codebases (at least to my knowledge). Separating codebases was the fundamental step, everything else is a technicality. Having said that, I will be OK with your suggestion as I don't really see a difference, although I'm not sure we will be able to come up with a name that is more intuitive than a separate project :) Let's see what others think. -Val On Sat, Sep 25, 2021 at 12:23 AM Denis Magda wrote: > Moving the discussion back to the dev list. > > Val, Andrey, for that purpose we can ask INFRA to create a > special mandatory field such as "Architecture" with two predefined values - > "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs to > be > intuitive enough even for users who submit issues. What disturbs me is that > neither Kafka nor Spark have a different project for the recently released > versions 3. A different GitHub project is not that disturbing. > > - > Denis > > > On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> Denis, >> >> From a purely technical perspective, these are indeed two separate >> projects, because they are based on different codebases. The split you're >> talking about happened a year ago, when we created the repo for Ignite 3. >> This significantly differs from the 1.x->2.x transition, as these two >> shared the codebase. >> >> For the same reason, a bug filed for 2.x can't be just transitioned to >> 3.x. It will either not exist in 3.x in the first place, or will require > a >> completely different fix, which will mean two different tickets. >> >> That said, I still believe that Ignite 2 and Ignite 3 are just different >> versions of the same product, because, as you correctly mentioned, >> they >> target "same users, community, use cases". At the same time, they are >> developed as different projects on the technical level. Let's not confuse >> these two aspects with each other - they are largely orthogonal. >> >> At this point, creating a Jira project doesn't change anything >> fundamentally. It's only about ease of use of our tooling and >> efficient >> ticket management. >> >> -Val >> >> On Thu, Sep 23, 2021 at 10:15 PM Denis Magda wrote: >> >>> Folks, you confuse me. I've never treated Ignite 3 as a different >>> project. It's the same Ignite (distributed database for high-performance >>> computing...) but on a modernized architecture and APIs - thus, a major >>> version. Same users, community, use cases. >>> >>> But, I'm against separate JIRA or Confluence projects. This is how > you're >>> truly stepping on a project-split path. When we used to work on >>> Ignite > 2 we >>> could live within the same JIRA space with Ignite 1. Moreover, many > tickets >>> that are filed against Ignite 2 can be fixed in Ignite 3 only - which > is a >>> version change in our JIRA. >>> >>> So, -1 from me for the separate JIRA proposal. >>> >>> - >>> Denis >>> >>> >>> On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov >>> wrote: >>> Val, I don't see any issues having different projects under Ignite's brand from the developer's side except the versioning issue. This is a bad case when two different projects must have dependent versions and even worse when some marketing things affect the development and release processes. I agre
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Today it is quite common to use calendar-based versioning scheme, e.g. [1]. We can consider it for Ignite 3. Luckily versions will not clash. [1] https://www.cockroachlabs.com/docs/releases/index.html 2021-09-27 10:49 GMT+03:00, Petr Ivanov : > That name will definitely confuse Jira users. > > Let's stick to basic devision by 2.x and 3.x — it seems most intuitive and > has lots of examples inside ASF, look at the Tomcat for instance. > >> On 25 Sep 2021, at 21:05, Saikat Maitra wrote: >> >> Hi, >> >> I like the major version update like Ignite 3.0 but if we were to come up >> with a name my other suggestion would be >> >> Ignite-kernel >> >> kernel - for the central or most important part of something >> >> Also taken references from Compute kernel - a routine compiled for high >> throughput accelerators >> >> https://en.wikipedia.org/wiki/Compute_kernel >> >> Regards, >> Saikat >> >> >> On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko < >> valentin.kuliche...@gmail.com> wrote: >> >>> Kafka and Spark didn't split codebases (at least to my knowledge). >>> Separating codebases was the fundamental step, everything else is a >>> technicality. >>> >>> Having said that, I will be OK with your suggestion as I don't really see >>> a >>> difference, although I'm not sure we will be able to come up with a name >>> that is more intuitive than a separate project :) >>> >>> Let's see what others think. >>> >>> -Val >>> >>> On Sat, Sep 25, 2021 at 12:23 AM Denis Magda wrote: >>> Moving the discussion back to the dev list. Val, Andrey, for that purpose we can ask INFRA to create a special mandatory field such as "Architecture" with two predefined >>> values - "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs to be intuitive enough even for users who submit issues. What disturbs me is >>> that neither Kafka nor Spark have a different project for the recently >>> released versions 3. A different GitHub project is not that disturbing. - Denis On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Denis, > > From a purely technical perspective, these are indeed two separate > projects, because they are based on different codebases. The split >>> you're > talking about happened a year ago, when we created the repo for Ignite >>> 3. > This significantly differs from the 1.x->2.x transition, as these two > shared the codebase. > > For the same reason, a bug filed for 2.x can't be just transitioned to > 3.x. It will either not exist in 3.x in the first place, or will >>> require a > completely different fix, which will mean two different tickets. > > That said, I still believe that Ignite 2 and Ignite 3 are just >>> different > versions of the same product, because, as you correctly mentioned, > they > target "same users, community, use cases". At the same time, they are > developed as different projects on the technical level. Let's not >>> confuse > these two aspects with each other - they are largely orthogonal. > > At this point, creating a Jira project doesn't change anything > fundamentally. It's only about ease of use of our tooling and > efficient > ticket management. > > -Val > > On Thu, Sep 23, 2021 at 10:15 PM Denis Magda >>> wrote: > >> Folks, you confuse me. I've never treated Ignite 3 as a different >> project. It's the same Ignite (distributed database for >>> high-performance >> computing...) but on a modernized architecture and APIs - thus, a >>> major >> version. Same users, community, use cases. >> >> But, I'm against separate JIRA or Confluence projects. This is how you're >> truly stepping on a project-split path. When we used to work on >> Ignite 2 we >> could live within the same JIRA space with Ignite 1. Moreover, many tickets >> that are filed against Ignite 2 can be fixed in Ignite 3 only - which is a >> version change in our JIRA. >> >> So, -1 from me for the separate JIRA proposal. >> >> - >> Denis >> >> >> On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov >> wrote: >> >>> Val, >>> >>> I don't see any issues having different projects under Ignite's >>> brand >>> from the developer's side except the versioning issue. This is a bad >>> case when two different projects must have dependent versions and >>> even >>> worse when some marketing things affect the development and release >>> processes. >>> >>> I agree with Nikolay and Ilya - the right way here is having >>> "Ignite" and versioning started from zero. However, >>> both >>> of Ignite's can easily co-exist. >>> >>> On Tue, 21 Sept 2021 at 22:13, Valentin Kulichenko >>> wrote: Ilya, What exa
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
That name will definitely confuse Jira users. Let's stick to basic devision by 2.x and 3.x — it seems most intuitive and has lots of examples inside ASF, look at the Tomcat for instance. > On 25 Sep 2021, at 21:05, Saikat Maitra wrote: > > Hi, > > I like the major version update like Ignite 3.0 but if we were to come up > with a name my other suggestion would be > > Ignite-kernel > > kernel - for the central or most important part of something > > Also taken references from Compute kernel - a routine compiled for high > throughput accelerators > > https://en.wikipedia.org/wiki/Compute_kernel > > Regards, > Saikat > > > On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> Kafka and Spark didn't split codebases (at least to my knowledge). >> Separating codebases was the fundamental step, everything else is a >> technicality. >> >> Having said that, I will be OK with your suggestion as I don't really see a >> difference, although I'm not sure we will be able to come up with a name >> that is more intuitive than a separate project :) >> >> Let's see what others think. >> >> -Val >> >> On Sat, Sep 25, 2021 at 12:23 AM Denis Magda wrote: >> >>> Moving the discussion back to the dev list. >>> >>> Val, Andrey, for that purpose we can ask INFRA to create a >>> special mandatory field such as "Architecture" with two predefined >> values - >>> "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs to be >>> intuitive enough even for users who submit issues. What disturbs me is >> that >>> neither Kafka nor Spark have a different project for the recently >> released >>> versions 3. A different GitHub project is not that disturbing. >>> >>> - >>> Denis >>> >>> >>> On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko < >>> valentin.kuliche...@gmail.com> wrote: >>> Denis, From a purely technical perspective, these are indeed two separate projects, because they are based on different codebases. The split >> you're talking about happened a year ago, when we created the repo for Ignite >> 3. This significantly differs from the 1.x->2.x transition, as these two shared the codebase. For the same reason, a bug filed for 2.x can't be just transitioned to 3.x. It will either not exist in 3.x in the first place, or will >> require >>> a completely different fix, which will mean two different tickets. That said, I still believe that Ignite 2 and Ignite 3 are just >> different versions of the same product, because, as you correctly mentioned, they target "same users, community, use cases". At the same time, they are developed as different projects on the technical level. Let's not >> confuse these two aspects with each other - they are largely orthogonal. At this point, creating a Jira project doesn't change anything fundamentally. It's only about ease of use of our tooling and efficient ticket management. -Val On Thu, Sep 23, 2021 at 10:15 PM Denis Magda >> wrote: > Folks, you confuse me. I've never treated Ignite 3 as a different > project. It's the same Ignite (distributed database for >> high-performance > computing...) but on a modernized architecture and APIs - thus, a >> major > version. Same users, community, use cases. > > But, I'm against separate JIRA or Confluence projects. This is how >>> you're > truly stepping on a project-split path. When we used to work on Ignite >>> 2 we > could live within the same JIRA space with Ignite 1. Moreover, many >>> tickets > that are filed against Ignite 2 can be fixed in Ignite 3 only - which >>> is a > version change in our JIRA. > > So, -1 from me for the separate JIRA proposal. > > - > Denis > > > On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov > wrote: > >> Val, >> >> I don't see any issues having different projects under Ignite's brand >> from the developer's side except the versioning issue. This is a bad >> case when two different projects must have dependent versions and >> even >> worse when some marketing things affect the development and release >> processes. >> >> I agree with Nikolay and Ilya - the right way here is having >> "Ignite" and versioning started from zero. However, >> both >> of Ignite's can easily co-exist. >> >> On Tue, 21 Sept 2021 at 22:13, Valentin Kulichenko >> wrote: >>> >>> Ilya, >>> >>> What exactly is this different focus and different values? Why >>> exactly >> do you think Ignite 3 will never cover all the current features? And >>> why is >> this the criteria in the first place? I work on both Ignite 2 and >>> Ignite 3 >> almost every day and I simply don't think all this is true. I >> honestly >> can't understand what this fuss is all about. >>> >>
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Hi, I like the major version update like Ignite 3.0 but if we were to come up with a name my other suggestion would be Ignite-kernel kernel - for the central or most important part of something Also taken references from Compute kernel - a routine compiled for high throughput accelerators https://en.wikipedia.org/wiki/Compute_kernel Regards, Saikat On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Kafka and Spark didn't split codebases (at least to my knowledge). > Separating codebases was the fundamental step, everything else is a > technicality. > > Having said that, I will be OK with your suggestion as I don't really see a > difference, although I'm not sure we will be able to come up with a name > that is more intuitive than a separate project :) > > Let's see what others think. > > -Val > > On Sat, Sep 25, 2021 at 12:23 AM Denis Magda wrote: > > > Moving the discussion back to the dev list. > > > > Val, Andrey, for that purpose we can ask INFRA to create a > > special mandatory field such as "Architecture" with two predefined > values - > > "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs to be > > intuitive enough even for users who submit issues. What disturbs me is > that > > neither Kafka nor Spark have a different project for the recently > released > > versions 3. A different GitHub project is not that disturbing. > > > > - > > Denis > > > > > > On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Denis, > > > > > > From a purely technical perspective, these are indeed two separate > > > projects, because they are based on different codebases. The split > you're > > > talking about happened a year ago, when we created the repo for Ignite > 3. > > > This significantly differs from the 1.x->2.x transition, as these two > > > shared the codebase. > > > > > > For the same reason, a bug filed for 2.x can't be just transitioned to > > > 3.x. It will either not exist in 3.x in the first place, or will > require > > a > > > completely different fix, which will mean two different tickets. > > > > > > That said, I still believe that Ignite 2 and Ignite 3 are just > different > > > versions of the same product, because, as you correctly mentioned, they > > > target "same users, community, use cases". At the same time, they are > > > developed as different projects on the technical level. Let's not > confuse > > > these two aspects with each other - they are largely orthogonal. > > > > > > At this point, creating a Jira project doesn't change anything > > > fundamentally. It's only about ease of use of our tooling and efficient > > > ticket management. > > > > > > -Val > > > > > > On Thu, Sep 23, 2021 at 10:15 PM Denis Magda > wrote: > > > > > >> Folks, you confuse me. I've never treated Ignite 3 as a different > > >> project. It's the same Ignite (distributed database for > high-performance > > >> computing...) but on a modernized architecture and APIs - thus, a > major > > >> version. Same users, community, use cases. > > >> > > >> But, I'm against separate JIRA or Confluence projects. This is how > > you're > > >> truly stepping on a project-split path. When we used to work on Ignite > > 2 we > > >> could live within the same JIRA space with Ignite 1. Moreover, many > > tickets > > >> that are filed against Ignite 2 can be fixed in Ignite 3 only - which > > is a > > >> version change in our JIRA. > > >> > > >> So, -1 from me for the separate JIRA proposal. > > >> > > >> - > > >> Denis > > >> > > >> > > >> On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov > > >> wrote: > > >> > > >>> Val, > > >>> > > >>> I don't see any issues having different projects under Ignite's brand > > >>> from the developer's side except the versioning issue. This is a bad > > >>> case when two different projects must have dependent versions and > even > > >>> worse when some marketing things affect the development and release > > >>> processes. > > >>> > > >>> I agree with Nikolay and Ilya - the right way here is having > > >>> "Ignite" and versioning started from zero. However, > both > > >>> of Ignite's can easily co-exist. > > >>> > > >>> On Tue, 21 Sept 2021 at 22:13, Valentin Kulichenko > > >>> wrote: > > >>> > > > >>> > Ilya, > > >>> > > > >>> > What exactly is this different focus and different values? Why > > exactly > > >>> do you think Ignite 3 will never cover all the current features? And > > why is > > >>> this the criteria in the first place? I work on both Ignite 2 and > > Ignite 3 > > >>> almost every day and I simply don't think all this is true. I > honestly > > >>> can't understand what this fuss is all about. > > >>> > > > >>> > Folks, quite frankly, this discussion seems counterproductive at > this > > >>> point. Are there any particular suggestions? If so, let's discuss > them. > > >>> Otherwise, let's just do some coding - isn't that why we are all > here? > > :) > > >>> > > > >>>
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Kafka and Spark didn't split codebases (at least to my knowledge). Separating codebases was the fundamental step, everything else is a technicality. Having said that, I will be OK with your suggestion as I don't really see a difference, although I'm not sure we will be able to come up with a name that is more intuitive than a separate project :) Let's see what others think. -Val On Sat, Sep 25, 2021 at 12:23 AM Denis Magda wrote: > Moving the discussion back to the dev list. > > Val, Andrey, for that purpose we can ask INFRA to create a > special mandatory field such as "Architecture" with two predefined values - > "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs to be > intuitive enough even for users who submit issues. What disturbs me is that > neither Kafka nor Spark have a different project for the recently released > versions 3. A different GitHub project is not that disturbing. > > - > Denis > > > On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Denis, > > > > From a purely technical perspective, these are indeed two separate > > projects, because they are based on different codebases. The split you're > > talking about happened a year ago, when we created the repo for Ignite 3. > > This significantly differs from the 1.x->2.x transition, as these two > > shared the codebase. > > > > For the same reason, a bug filed for 2.x can't be just transitioned to > > 3.x. It will either not exist in 3.x in the first place, or will require > a > > completely different fix, which will mean two different tickets. > > > > That said, I still believe that Ignite 2 and Ignite 3 are just different > > versions of the same product, because, as you correctly mentioned, they > > target "same users, community, use cases". At the same time, they are > > developed as different projects on the technical level. Let's not confuse > > these two aspects with each other - they are largely orthogonal. > > > > At this point, creating a Jira project doesn't change anything > > fundamentally. It's only about ease of use of our tooling and efficient > > ticket management. > > > > -Val > > > > On Thu, Sep 23, 2021 at 10:15 PM Denis Magda wrote: > > > >> Folks, you confuse me. I've never treated Ignite 3 as a different > >> project. It's the same Ignite (distributed database for high-performance > >> computing...) but on a modernized architecture and APIs - thus, a major > >> version. Same users, community, use cases. > >> > >> But, I'm against separate JIRA or Confluence projects. This is how > you're > >> truly stepping on a project-split path. When we used to work on Ignite > 2 we > >> could live within the same JIRA space with Ignite 1. Moreover, many > tickets > >> that are filed against Ignite 2 can be fixed in Ignite 3 only - which > is a > >> version change in our JIRA. > >> > >> So, -1 from me for the separate JIRA proposal. > >> > >> - > >> Denis > >> > >> > >> On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov > >> wrote: > >> > >>> Val, > >>> > >>> I don't see any issues having different projects under Ignite's brand > >>> from the developer's side except the versioning issue. This is a bad > >>> case when two different projects must have dependent versions and even > >>> worse when some marketing things affect the development and release > >>> processes. > >>> > >>> I agree with Nikolay and Ilya - the right way here is having > >>> "Ignite" and versioning started from zero. However, both > >>> of Ignite's can easily co-exist. > >>> > >>> On Tue, 21 Sept 2021 at 22:13, Valentin Kulichenko > >>> wrote: > >>> > > >>> > Ilya, > >>> > > >>> > What exactly is this different focus and different values? Why > exactly > >>> do you think Ignite 3 will never cover all the current features? And > why is > >>> this the criteria in the first place? I work on both Ignite 2 and > Ignite 3 > >>> almost every day and I simply don't think all this is true. I honestly > >>> can't understand what this fuss is all about. > >>> > > >>> > Folks, quite frankly, this discussion seems counterproductive at this > >>> point. Are there any particular suggestions? If so, let's discuss them. > >>> Otherwise, let's just do some coding - isn't that why we are all here? > :) > >>> > > >>> > -Val > >>> > > >>> > On Tue, Sep 21, 2021 at 9:52 PM Ilya Kasnacheev < > >>> ilya.kasnach...@gmail.com> wrote: > >>> >> > >>> >> Hello! > >>> >> > >>> >> I concur with Nikolay. Maybe Ignite 3 should be called "Ignite >>> adverb>" because it is a product with a different focus and values > which > >>> has no plans to cover the entirety of Ignite's features. > >>> >> > >>> >> Regards, > >>> >> -- > >>> >> Ilya Kasnacheev > >>> >> > >>> >> > >>> >> вт, 21 сент. 2021 г. в 17:56, Nikolay Izhikov >: > >>> >>> > >>> >>> Hello, Ignite PMC. > >>> >>> > >>> >>> Is there any reason to keep calling Ignite3 as "Ignite"? > >>> >>> > >>> >>> It seems to me that from the very beginning Ignite3 is a new > >>> d
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Moving the discussion back to the dev list. Val, Andrey, for that purpose we can ask INFRA to create a special mandatory field such as "Architecture" with two predefined values - "Ignite 2.x" and "Ignite 3.x". Come up with a better name, it needs to be intuitive enough even for users who submit issues. What disturbs me is that neither Kafka nor Spark have a different project for the recently released versions 3. A different GitHub project is not that disturbing. - Denis On Fri, Sep 24, 2021 at 4:09 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Denis, > > From a purely technical perspective, these are indeed two separate > projects, because they are based on different codebases. The split you're > talking about happened a year ago, when we created the repo for Ignite 3. > This significantly differs from the 1.x->2.x transition, as these two > shared the codebase. > > For the same reason, a bug filed for 2.x can't be just transitioned to > 3.x. It will either not exist in 3.x in the first place, or will require a > completely different fix, which will mean two different tickets. > > That said, I still believe that Ignite 2 and Ignite 3 are just different > versions of the same product, because, as you correctly mentioned, they > target "same users, community, use cases". At the same time, they are > developed as different projects on the technical level. Let's not confuse > these two aspects with each other - they are largely orthogonal. > > At this point, creating a Jira project doesn't change anything > fundamentally. It's only about ease of use of our tooling and efficient > ticket management. > > -Val > > On Thu, Sep 23, 2021 at 10:15 PM Denis Magda wrote: > >> Folks, you confuse me. I've never treated Ignite 3 as a different >> project. It's the same Ignite (distributed database for high-performance >> computing...) but on a modernized architecture and APIs - thus, a major >> version. Same users, community, use cases. >> >> But, I'm against separate JIRA or Confluence projects. This is how you're >> truly stepping on a project-split path. When we used to work on Ignite 2 we >> could live within the same JIRA space with Ignite 1. Moreover, many tickets >> that are filed against Ignite 2 can be fixed in Ignite 3 only - which is a >> version change in our JIRA. >> >> So, -1 from me for the separate JIRA proposal. >> >> - >> Denis >> >> >> On Wed, Sep 22, 2021 at 8:23 AM Maxim Muzafarov >> wrote: >> >>> Val, >>> >>> I don't see any issues having different projects under Ignite's brand >>> from the developer's side except the versioning issue. This is a bad >>> case when two different projects must have dependent versions and even >>> worse when some marketing things affect the development and release >>> processes. >>> >>> I agree with Nikolay and Ilya - the right way here is having >>> "Ignite" and versioning started from zero. However, both >>> of Ignite's can easily co-exist. >>> >>> On Tue, 21 Sept 2021 at 22:13, Valentin Kulichenko >>> wrote: >>> > >>> > Ilya, >>> > >>> > What exactly is this different focus and different values? Why exactly >>> do you think Ignite 3 will never cover all the current features? And why is >>> this the criteria in the first place? I work on both Ignite 2 and Ignite 3 >>> almost every day and I simply don't think all this is true. I honestly >>> can't understand what this fuss is all about. >>> > >>> > Folks, quite frankly, this discussion seems counterproductive at this >>> point. Are there any particular suggestions? If so, let's discuss them. >>> Otherwise, let's just do some coding - isn't that why we are all here? :) >>> > >>> > -Val >>> > >>> > On Tue, Sep 21, 2021 at 9:52 PM Ilya Kasnacheev < >>> ilya.kasnach...@gmail.com> wrote: >>> >> >>> >> Hello! >>> >> >>> >> I concur with Nikolay. Maybe Ignite 3 should be called "Ignite >> adverb>" because it is a product with a different focus and values which >>> has no plans to cover the entirety of Ignite's features. >>> >> >>> >> Regards, >>> >> -- >>> >> Ilya Kasnacheev >>> >> >>> >> >>> >> вт, 21 сент. 2021 г. в 17:56, Nikolay Izhikov : >>> >>> >>> >>> Hello, Ignite PMC. >>> >>> >>> >>> Is there any reason to keep calling Ignite3 as "Ignite"? >>> >>> >>> >>> It seems to me that from the very beginning Ignite3 is a new >>> database engine built on completely new architecture. >>> >>> Ignite2 and Ignite3 has nothing similar except the name. All is >>> different >>> >>> - source code. >>> >>> - repository. >>> >>> - features. >>> >>> - API. >>> >>> - road map. >>> >>> - contributors. >>> >>> - contribution rules. >>> >>> - release cycle. >>> >>> *** you are here *** >>> >>> - jira >>> >>> - confluence >>> >>> >>> >>> Should we accept the fact that thing we calling as "Ignite3" is just >>> another project? >>> >>> Can you, please, share your vision on how Ignite and Ignite3 should >>> coexists? >>> >>> >>> >>> вт, 21 сент. 2021 г. в 17:13, Dmitry Pavlov : >>> >>> Ok, if nobody minds, I'l
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Dmitry, Thanks! Sure, this is not super urgent. Please let us know when this is ready. And feel free to ask me any questions if you have any. -Val On Tue, Sep 21, 2021 at 5:13 PM Dmitry Pavlov wrote: > Ok, if nobody minds, I'll create spaces a bit later. > > I hope it is not too urgent. > > Sincerely, > Dmitriy Pavlov > > On 2021/09/21 10:37:42, Valentin Kulichenko > wrote: > > Hi Dmitry, > > > > According to Infra, this has to be done through > http://selfserve.apache.org/, > > but only PMC chairs have access. > > > > Could you please assist with the creation of the Jira project and > > Confluence space? > > > > -Val > > > > On Tue, Sep 21, 2021 at 10:46 AM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Infra requests created: > > > > > >- https://issues.apache.org/jira/browse/INFRA-22349 > > >- https://issues.apache.org/jira/browse/INFRA-22350 > > > > > > -Val > > > > > > On Mon, Sep 20, 2021 at 10:50 AM Petr Ivanov > wrote: > > > > > >> +1 > > >> > > >> Since we've agreed that there are two projects (that are Ignite2 and > > >> Ignite3), separate development environments seem to be logical and > natural > > >> course of things. > > >> > > >> > On 18 Sep 2021, at 12:42, Alexander Polovtcev < > alexpolovt...@gmail.com> > > >> wrote: > > >> > > > >> > +1 > > >> > This is a welcome proposal, because we already have some pending > Ignite > > >> 3 > > >> > specific documents, and it is not clear where to put them at the > moment. > > >> > > > >> > On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko < > > >> > valentin.kuliche...@gmail.com> wrote: > > >> > > > >> >> Igniters, > > >> >> > > >> >> I think it's clear to all of us that Ignite 2.x and 3.x will > coexist > > >> for a > > >> >> while. They are developed in separate Git repos, but we still > > >> accumulate > > >> >> the tickets for both versions in the same Jira project, which > seems to > > >> >> complicate the ticket management. > > >> >> > > >> >> For example, we use the "ignite-3" label for 3.x tickets, but this > > >> approach > > >> >> is fragile. If someone forgets to add the label to a new ticket, > it's > > >> >> likely to be lost. We need a better separation. > > >> >> > > >> >> All the above is true for Wiki as well - we use a single Confluence > > >> space. > > >> >> > > >> >> I suggest creating a new Jira project and a new Confluence space > for > > >> Ignite > > >> >> 3 and moving all the relevant tickets and pages there. > > >> >> > > >> >> Any thoughts or objections? > > >> >> > > >> >> -Val > > >> >> > > >> > > > >> > > > >> > -- > > >> > With regards, > > >> > Aleksandr Polovtcev > > >> > > >> > > >
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Ok, if nobody minds, I'll create spaces a bit later. I hope it is not too urgent. Sincerely, Dmitriy Pavlov On 2021/09/21 10:37:42, Valentin Kulichenko wrote: > Hi Dmitry, > > According to Infra, this has to be done through http://selfserve.apache.org/, > but only PMC chairs have access. > > Could you please assist with the creation of the Jira project and > Confluence space? > > -Val > > On Tue, Sep 21, 2021 at 10:46 AM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Infra requests created: > > > >- https://issues.apache.org/jira/browse/INFRA-22349 > >- https://issues.apache.org/jira/browse/INFRA-22350 > > > > -Val > > > > On Mon, Sep 20, 2021 at 10:50 AM Petr Ivanov wrote: > > > >> +1 > >> > >> Since we've agreed that there are two projects (that are Ignite2 and > >> Ignite3), separate development environments seem to be logical and natural > >> course of things. > >> > >> > On 18 Sep 2021, at 12:42, Alexander Polovtcev > >> wrote: > >> > > >> > +1 > >> > This is a welcome proposal, because we already have some pending Ignite > >> 3 > >> > specific documents, and it is not clear where to put them at the moment. > >> > > >> > On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko < > >> > valentin.kuliche...@gmail.com> wrote: > >> > > >> >> Igniters, > >> >> > >> >> I think it's clear to all of us that Ignite 2.x and 3.x will coexist > >> for a > >> >> while. They are developed in separate Git repos, but we still > >> accumulate > >> >> the tickets for both versions in the same Jira project, which seems to > >> >> complicate the ticket management. > >> >> > >> >> For example, we use the "ignite-3" label for 3.x tickets, but this > >> approach > >> >> is fragile. If someone forgets to add the label to a new ticket, it's > >> >> likely to be lost. We need a better separation. > >> >> > >> >> All the above is true for Wiki as well - we use a single Confluence > >> space. > >> >> > >> >> I suggest creating a new Jira project and a new Confluence space for > >> Ignite > >> >> 3 and moving all the relevant tickets and pages there. > >> >> > >> >> Any thoughts or objections? > >> >> > >> >> -Val > >> >> > >> > > >> > > >> > -- > >> > With regards, > >> > Aleksandr Polovtcev > >> > >> >
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Hi Dmitry, According to Infra, this has to be done through http://selfserve.apache.org/, but only PMC chairs have access. Could you please assist with the creation of the Jira project and Confluence space? -Val On Tue, Sep 21, 2021 at 10:46 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Infra requests created: > >- https://issues.apache.org/jira/browse/INFRA-22349 >- https://issues.apache.org/jira/browse/INFRA-22350 > > -Val > > On Mon, Sep 20, 2021 at 10:50 AM Petr Ivanov wrote: > >> +1 >> >> Since we've agreed that there are two projects (that are Ignite2 and >> Ignite3), separate development environments seem to be logical and natural >> course of things. >> >> > On 18 Sep 2021, at 12:42, Alexander Polovtcev >> wrote: >> > >> > +1 >> > This is a welcome proposal, because we already have some pending Ignite >> 3 >> > specific documents, and it is not clear where to put them at the moment. >> > >> > On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko < >> > valentin.kuliche...@gmail.com> wrote: >> > >> >> Igniters, >> >> >> >> I think it's clear to all of us that Ignite 2.x and 3.x will coexist >> for a >> >> while. They are developed in separate Git repos, but we still >> accumulate >> >> the tickets for both versions in the same Jira project, which seems to >> >> complicate the ticket management. >> >> >> >> For example, we use the "ignite-3" label for 3.x tickets, but this >> approach >> >> is fragile. If someone forgets to add the label to a new ticket, it's >> >> likely to be lost. We need a better separation. >> >> >> >> All the above is true for Wiki as well - we use a single Confluence >> space. >> >> >> >> I suggest creating a new Jira project and a new Confluence space for >> Ignite >> >> 3 and moving all the relevant tickets and pages there. >> >> >> >> Any thoughts or objections? >> >> >> >> -Val >> >> >> > >> > >> > -- >> > With regards, >> > Aleksandr Polovtcev >> >>
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Infra requests created: - https://issues.apache.org/jira/browse/INFRA-22349 - https://issues.apache.org/jira/browse/INFRA-22350 -Val On Mon, Sep 20, 2021 at 10:50 AM Petr Ivanov wrote: > +1 > > Since we've agreed that there are two projects (that are Ignite2 and > Ignite3), separate development environments seem to be logical and natural > course of things. > > > On 18 Sep 2021, at 12:42, Alexander Polovtcev > wrote: > > > > +1 > > This is a welcome proposal, because we already have some pending Ignite 3 > > specific documents, and it is not clear where to put them at the moment. > > > > On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > >> Igniters, > >> > >> I think it's clear to all of us that Ignite 2.x and 3.x will coexist > for a > >> while. They are developed in separate Git repos, but we still accumulate > >> the tickets for both versions in the same Jira project, which seems to > >> complicate the ticket management. > >> > >> For example, we use the "ignite-3" label for 3.x tickets, but this > approach > >> is fragile. If someone forgets to add the label to a new ticket, it's > >> likely to be lost. We need a better separation. > >> > >> All the above is true for Wiki as well - we use a single Confluence > space. > >> > >> I suggest creating a new Jira project and a new Confluence space for > Ignite > >> 3 and moving all the relevant tickets and pages there. > >> > >> Any thoughts or objections? > >> > >> -Val > >> > > > > > > -- > > With regards, > > Aleksandr Polovtcev > >
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
+1 Since we've agreed that there are two projects (that are Ignite2 and Ignite3), separate development environments seem to be logical and natural course of things. > On 18 Sep 2021, at 12:42, Alexander Polovtcev wrote: > > +1 > This is a welcome proposal, because we already have some pending Ignite 3 > specific documents, and it is not clear where to put them at the moment. > > On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> Igniters, >> >> I think it's clear to all of us that Ignite 2.x and 3.x will coexist for a >> while. They are developed in separate Git repos, but we still accumulate >> the tickets for both versions in the same Jira project, which seems to >> complicate the ticket management. >> >> For example, we use the "ignite-3" label for 3.x tickets, but this approach >> is fragile. If someone forgets to add the label to a new ticket, it's >> likely to be lost. We need a better separation. >> >> All the above is true for Wiki as well - we use a single Confluence space. >> >> I suggest creating a new Jira project and a new Confluence space for Ignite >> 3 and moving all the relevant tickets and pages there. >> >> Any thoughts or objections? >> >> -Val >> > > > -- > With regards, > Aleksandr Polovtcev
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
+1 This is a welcome proposal, because we already have some pending Ignite 3 specific documents, and it is not clear where to put them at the moment. On Sat, Sep 18, 2021 at 4:22 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Igniters, > > I think it's clear to all of us that Ignite 2.x and 3.x will coexist for a > while. They are developed in separate Git repos, but we still accumulate > the tickets for both versions in the same Jira project, which seems to > complicate the ticket management. > > For example, we use the "ignite-3" label for 3.x tickets, but this approach > is fragile. If someone forgets to add the label to a new ticket, it's > likely to be lost. We need a better separation. > > All the above is true for Wiki as well - we use a single Confluence space. > > I suggest creating a new Jira project and a new Confluence space for Ignite > 3 and moving all the relevant tickets and pages there. > > Any thoughts or objections? > > -Val > -- With regards, Aleksandr Polovtcev
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
Huge +1. сб, 18 сент. 2021 г., 04:22 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Igniters, > > I think it's clear to all of us that Ignite 2.x and 3.x will coexist for a > while. They are developed in separate Git repos, but we still accumulate > the tickets for both versions in the same Jira project, which seems to > complicate the ticket management. > > For example, we use the "ignite-3" label for 3.x tickets, but this approach > is fragile. If someone forgets to add the label to a new ticket, it's > likely to be lost. We need a better separation. > > All the above is true for Wiki as well - we use a single Confluence space. > > I suggest creating a new Jira project and a new Confluence space for Ignite > 3 and moving all the relevant tickets and pages there. > > Any thoughts or objections? > > -Val >
Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3
+1 -- Nikita Ivanov On Fri, Sep 17, 2021 at 6:22 PM Valentin Kulichenko wrote: > > Igniters, > > I think it's clear to all of us that Ignite 2.x and 3.x will coexist for a > while. They are developed in separate Git repos, but we still accumulate > the tickets for both versions in the same Jira project, which seems to > complicate the ticket management. > > For example, we use the "ignite-3" label for 3.x tickets, but this approach > is fragile. If someone forgets to add the label to a new ticket, it's > likely to be lost. We need a better separation. > > All the above is true for Wiki as well - we use a single Confluence space. > > I suggest creating a new Jira project and a new Confluence space for Ignite > 3 and moving all the relevant tickets and pages there. > > Any thoughts or objections? > > -Val
