[MTCGA]: new failures in builds [5733487] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New Critical Failure in master MVCC Cache 8 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MvccCache8?branch=%3Cdefault%3E Changes may lead to failure were done by - vladsz83 https://ci.ignite.apache.org/viewModification.html?modId=909777 - denis magda https://ci.ignite.apache.org/viewModification.html?modId=909778 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 10:52:43 14-11-2020
[MTCGA]: new failures in builds [5728476] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *Test with high flaky rate in master CacheMvccPartitionedSqlQueriesTest.testJoinTransactional_DistributedJoins_ClientServer https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6466081321439161948=%3Cdefault%3E=testDetails *Test with high flaky rate in master MvccDeadlockDetectionTest.randomizedPuts https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6926945939778768712=%3Cdefault%3E=testDetails *Test with high flaky rate in master CacheMvccPartitionedSqlQueriesTest.testJoinTransactional_DistributedJoins_ClientServer2 https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4195797906313250275=%3Cdefault%3E=testDetails Changes may lead to failure were done by - igor sapego https://ci.ignite.apache.org/viewModification.html?modId=909652 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 03:07:39 14-11-2020
[MTCGA]: new failures in builds [5731930, 5731771] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New Critical Failure in master MVCC Cache 7 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MvccCache7?branch=%3Cdefault%3E No changes in the build *New test failure in master-nightly IgniteRebalanceScheduleResendPartitionsTest.test https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=249563339269496287=%3Cdefault%3E=testDetails Changes may lead to failure were done by - igor sapego https://ci.ignite.apache.org/viewModification.html?modId=909734 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 01:37:40 14-11-2020
[MTCGA]: new failures in builds [5731709] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New Critical Failure in master Cache (Restarts) 1 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CacheRestarts1?branch=%3Cdefault%3E Changes may lead to failure were done by - igor sapego https://ci.ignite.apache.org/viewModification.html?modId=909734 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 22:52:40 13-11-2020
Re: [DISCUSS] Ignite 3.0 development approach
I'm -1 for creating a new repo. Also I support Maxim's plan for 3.0 пт, 13 нояб. 2020 г. в 15:50, Maxim Muzafarov : > Val, > > > Why *creating a new repo* is the main point we faced with? Would it be > better to discuss the components design approach and scope management > first suggested by Sergey Chugunov? I doubt that new repo will solve > move us forward. > > Currently, I'm -1 to create a new repo with the inputs above. > > In addition to Nikolay's answer I see the following drawbacks of > creating new repo: > - we have very few positive examples of finalizing really huge > improvements to *production-ready* states the others remains > incomplete (MVCC, Calcite, Zookeeper, Tracing, Thread per Partition, > etc) > - AFAIK, the Native Persistence took a very long period of > stabilization even after it has been developed (we must take it into > account for developing new features like IEP-61) > - feature development for a long period of time (like 3.0) without any > releases will lead to all these changes became obsolete at the moment > of release (AFAIK the 2.8 which released a year ago still has no big > deployments) > - human resources -- some of the Igniters may lose their interest for > 3.0 during development, some of them may switch to different projects, > etc. > - do we all estimating the scope of 3.0 correct? The 2.8 release took 1.5 > years. > > Have I missed something? > > > I suggest the following plan: > > - initiate 3.0 development in the master branch (after 2.10 release > change version to 3.0-SNAPSHOT instead of 2.11-SNAPSHOT) > - cleanup and collapse all the current APIs (see To Be Removed List > For Discussion on Apache Ignite 3.0 Wishlist) > - reduce the scope for 3.0 even more. I suggest focusing on two > things: Calcite + Schema-first approach > - create feature branches for proposed IEPs (for 3.0 only) > - create the release road map (allocate e.g. IEP-61 to 4.0 etc.) > > On Fri, 13 Nov 2020 at 14:03, Ivan Daschinsky wrote: > > > > >> b. Implement IEP-61 - Common Replication Infrastructure > > I suppose, that this is the main cause of the current discussion. > > I hardly believe that this activity can be done without at least > creating a > > completely new branch. > > > > пт, 13 нояб. 2020 г. в 11:12, Nikolay Izhikov : > > > > > My suggestion: > > > > > > 1. Reduce Ignite3 scope to the following: > > > a. Delete all deprecated API and support of obsolete internal > > > protocols. > > > b. Implement IEP-61 - Common Replication Infrastructure > > > c. Implement new Ignite management tool ignitectl as suggested > > > during Ignite3 discussion. > > > > > > 2. Implement and release following improvements like transactions, > Calcite > > > based SQL, etc in the ongoing releases - Ignite 4, 5, 6 > > > > > > My concern against separate Ignite 3 repo is the following: > > > > > > 1. We spread community to the two very separated part - Ignite3 > developers > > > and Ignite2 maintainers. believe it’s bad for our community. > > > That can lead to the situation when we don’t fix critical or > > > blocker issueds «because they will not exists in Ignite3» > > > That will lead to the solutions never reviewed or reviewed > poorly. > > > > > > 2. It seems for me that current scope of Ignite3 is too big to be > > > implemented in any reasonable time. > > > > > > > > > > 13 нояб. 2020 г., в 10:57, Nikolay Izhikov > > > написал(а): > > > > > > > > Hello, Valentin. > > > > > > > >> Nikolay, Maxim, are you OK with this route? > > > > > > > > -1 to have another repo for Ignite3 development. > > > > > > > >> 13 нояб. 2020 г., в 03:04, Valentin Kulichenko < > > > valentin.kuliche...@gmail.com> написал(а): > > > >> > > > >> Folks, > > > >> > > > >> We already have multiple IEPs for Ignite 3.0, and as far as I know, > > > there are contributors that would like to work on them (or probably > already > > > started). That said, we should make a decision as soon as possible. > > > >> > > > >> At this point, it doesn't seem that there are any strong objections > to > > > the technical side of things. So I would suggest the following: > > > >> > > > >> 1. Proceed with Alexey's approach to the development process, as it > > > seems to be the best (in my opinion - the only) way to address all the > > > technical concerns and issues expressed in the thread. We'll start by > > > creating a new repo and a new TC project. > > > >> 2. Start a separate discussion around transparency. If there are any > > > changes we need to make to our contributor guidelines, I am happy to > talk > > > them through, but I don't think it's reasonable to delay feature > > > development because of this. In the short term, I will make sure that > > > everything that happens within the new repo is as open to the > community as > > > possible. > > > >> > > > >> Nikolay, Maxim, are you OK with this route? > > > >> > > > >> -Val > > > >> > > > >> On Tue, Nov 10, 2020 at 4:55 PM Valentin Kulichenko < >
[jira] [Created] (IGNITE-13706) Thin Client Put_All uses LinkedHashMap, causes warning and may deadlock
Ilya Kasnacheev created IGNITE-13706: Summary: Thin Client Put_All uses LinkedHashMap, causes warning and may deadlock Key: IGNITE-13706 URL: https://issues.apache.org/jira/browse/IGNITE-13706 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 2.9 Reporter: Ilya Kasnacheev Thin client protocol handler for Put_All (1004) operation will create a linked hash map and then invoke putAll on this map. This leads to couple of issues: * Thin client may easily deadlock the cluster by issuing parallel transactional putAlls with different order of keys. * "Unordered map with putAll" warning is printed to log, causing user confusion, even if client actually uses SortedMap with putAll(). What we really need is BinaryObject-aware SortedMap / making sure that keys/KeyCacheObjects are always comparable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Live coding session next week
Hi Ilya! You can see the meeting link after RVSP on meetup.com https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/273935662/ This mailing list is open and to announce the zoom link is not the best thing to do. I can not understand why it's fun to interrupt zoom calls, but some people (and bots) do that all the time. Just this week Reactive Summit had to change the platform for Q because of this. BTW I fixed several timezones in the event description, sorry if I mislead someone. Just forgot about changing summertime back. пт, 13 нояб. 2020 г. в 05:31, Ilya Kazakov : > Hello Valentin! > > Could you provide a link for a meeting, please? > > - > Ilya Kazakov > > пт, 13 нояб. 2020 г. в 07:07, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > > Igniters, > > > > On Tuesday next week (Nov 17), Denis Magda and I will conduct a live > > coding session, where we will implement a primitive Ignite-like > distributed > > database from scratch. We will demonstrate major components required for > > such a system, show how they interact with each other and how they can be > > implemented in Java. > > > > Join if you would like to better understand how distributed systems work > > under the hood, or if you simply want to have some fun :) > > > > RSVP and all the details here: Tuesday, November 17, 2020 > > 8:00 AM to 10:00 AM PST > > > > -Val > > >
Re: [DISCUSS] Ignite 3.0 development approach
Val, Why *creating a new repo* is the main point we faced with? Would it be better to discuss the components design approach and scope management first suggested by Sergey Chugunov? I doubt that new repo will solve move us forward. Currently, I'm -1 to create a new repo with the inputs above. In addition to Nikolay's answer I see the following drawbacks of creating new repo: - we have very few positive examples of finalizing really huge improvements to *production-ready* states the others remains incomplete (MVCC, Calcite, Zookeeper, Tracing, Thread per Partition, etc) - AFAIK, the Native Persistence took a very long period of stabilization even after it has been developed (we must take it into account for developing new features like IEP-61) - feature development for a long period of time (like 3.0) without any releases will lead to all these changes became obsolete at the moment of release (AFAIK the 2.8 which released a year ago still has no big deployments) - human resources -- some of the Igniters may lose their interest for 3.0 during development, some of them may switch to different projects, etc. - do we all estimating the scope of 3.0 correct? The 2.8 release took 1.5 years. Have I missed something? I suggest the following plan: - initiate 3.0 development in the master branch (after 2.10 release change version to 3.0-SNAPSHOT instead of 2.11-SNAPSHOT) - cleanup and collapse all the current APIs (see To Be Removed List For Discussion on Apache Ignite 3.0 Wishlist) - reduce the scope for 3.0 even more. I suggest focusing on two things: Calcite + Schema-first approach - create feature branches for proposed IEPs (for 3.0 only) - create the release road map (allocate e.g. IEP-61 to 4.0 etc.) On Fri, 13 Nov 2020 at 14:03, Ivan Daschinsky wrote: > > >> b. Implement IEP-61 - Common Replication Infrastructure > I suppose, that this is the main cause of the current discussion. > I hardly believe that this activity can be done without at least creating a > completely new branch. > > пт, 13 нояб. 2020 г. в 11:12, Nikolay Izhikov : > > > My suggestion: > > > > 1. Reduce Ignite3 scope to the following: > > a. Delete all deprecated API and support of obsolete internal > > protocols. > > b. Implement IEP-61 - Common Replication Infrastructure > > c. Implement new Ignite management tool ignitectl as suggested > > during Ignite3 discussion. > > > > 2. Implement and release following improvements like transactions, Calcite > > based SQL, etc in the ongoing releases - Ignite 4, 5, 6 > > > > My concern against separate Ignite 3 repo is the following: > > > > 1. We spread community to the two very separated part - Ignite3 developers > > and Ignite2 maintainers. believe it’s bad for our community. > > That can lead to the situation when we don’t fix critical or > > blocker issueds «because they will not exists in Ignite3» > > That will lead to the solutions never reviewed or reviewed poorly. > > > > 2. It seems for me that current scope of Ignite3 is too big to be > > implemented in any reasonable time. > > > > > > > 13 нояб. 2020 г., в 10:57, Nikolay Izhikov > > написал(а): > > > > > > Hello, Valentin. > > > > > >> Nikolay, Maxim, are you OK with this route? > > > > > > -1 to have another repo for Ignite3 development. > > > > > >> 13 нояб. 2020 г., в 03:04, Valentin Kulichenko < > > valentin.kuliche...@gmail.com> написал(а): > > >> > > >> Folks, > > >> > > >> We already have multiple IEPs for Ignite 3.0, and as far as I know, > > there are contributors that would like to work on them (or probably already > > started). That said, we should make a decision as soon as possible. > > >> > > >> At this point, it doesn't seem that there are any strong objections to > > the technical side of things. So I would suggest the following: > > >> > > >> 1. Proceed with Alexey's approach to the development process, as it > > seems to be the best (in my opinion - the only) way to address all the > > technical concerns and issues expressed in the thread. We'll start by > > creating a new repo and a new TC project. > > >> 2. Start a separate discussion around transparency. If there are any > > changes we need to make to our contributor guidelines, I am happy to talk > > them through, but I don't think it's reasonable to delay feature > > development because of this. In the short term, I will make sure that > > everything that happens within the new repo is as open to the community as > > possible. > > >> > > >> Nikolay, Maxim, are you OK with this route? > > >> > > >> -Val > > >> > > >> On Tue, Nov 10, 2020 at 4:55 PM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > >> Maxim, > > >> > > >> 2.x and 3.x will have to coexist for some time - I don't see how we can > > avoid this considering the set of proposed changes. That said, we > > effectively will need to have two "masters" - one for each major version. > > Master for 3.x can technically be a branch in the existing
[jira] [Created] (IGNITE-13705) Fix middle node failed when failed next node and previous.
Vladimir Steshin created IGNITE-13705: - Summary: Fix middle node failed when failed next node and previous. Key: IGNITE-13705 URL: https://issues.apache.org/jira/browse/IGNITE-13705 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin Assignee: Vladimir Steshin The discovery ducktape test has detected failure of third node in the middle of 2 simulateously failed nodes. First research shows the trouble in backward connection checking: next node has checked itself: [2020-11-13 14:50:44,463][INFO ][tcp-disco-sock-reader-[47cc6f70 10.53.125.224:35381]-#7-#79][org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi1] Connection check done [liveAddr=tkles-pprb00188.vm.esrt.cloud.sbrf.ru/10.53.125.160:47500, previousNode=TcpDiscoveryNode [id=8331a61c-ea93-4bf5-bc8c-b24c032068d0, consistentId=tkles-pprb00188.vm.esrt.cloud.sbrf.ru, addrs=ArrayList [10.53.125.160], sockAddrs=HashSet [tkles-pprb00188.vm.esrt.cloud.sbrf.ru/10.53.125.160:47500], discPort=47500, order=1, intOrder=1, lastExchangeTime=1605268203598, loc=false, ver=2.10.0#20201113-sha1:, isClient=false], addressesToCheck=[tkles-pprb00188.vm.esrt.cloud.sbrf.ru/10.53.125.160:47500], connectingNodeId=47cc6f70-9fe4-437d-b183-826f2687aac8] -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: 2.9.1 release scope and dates
Igniters, hello! I think the scope of 2.9.1 is finalized. > On 9 Nov 2020, at 12:04, Yaroslav Molochkov wrote: > > Ivan, thanks! > > Added it to the list. > >> On 8 Nov 2020, at 14:13, Ivan Daschinsky wrote: >> >> Yaroslav, there is another bug for 2.9.1 release >> https://issues.apache.org/jira/browse/IGNITE-13572 >> >> чт, 5 нояб. 2020 г., 19:23 Yaroslav Molochkov : >> >>> Ivan, hi! >>> Sure. >>> >>> UPD: i am the release manager and will be doing this with Maxim's help >>> (since i don't have some user permissions) >>> On Thu, Nov 5, 2020 at 6:24 PM Ivan Daschinsky wrote: Hi. I'd suggest to add this issue. This is a usability improvement for zk discovery, and also this patch incorporates fixes for JMX metrics concurrency issues [1] -- https://issues.apache.org/jira/browse/IGNITE-13577 чт, 5 нояб. 2020 г., 16:20 Yaroslav Molochkov : > Igniters! > > I'd like to help with the 2.9.1 release. The scope of this release includes > following issues: > > >>> https://issues.apache.org/jira/browse/IGNITE-13676?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1 > > Maxim Muzafarov agreed to help me with the process and he will be the > release manager. > > Scope freeze: Nov. 12th > Code freeze: Nov. 19th > Voting date: Nov. 26th > Release date: Nov. 31st > > Tickets that were added (or to be added) to the scope don't bring new > features but various bug fixes. > >>>
[jira] [Created] (IGNITE-13704) Try failuredetectionTimeout==500 in ducktape integration test.
Vladimir Steshin created IGNITE-13704: - Summary: Try failuredetectionTimeout==500 in ducktape integration test. Key: IGNITE-13704 URL: https://issues.apache.org/jira/browse/IGNITE-13704 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin Try failuredetectionTimeout==500 in ducktape integration test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Ignite 3.0 development approach
>> b. Implement IEP-61 - Common Replication Infrastructure I suppose, that this is the main cause of the current discussion. I hardly believe that this activity can be done without at least creating a completely new branch. пт, 13 нояб. 2020 г. в 11:12, Nikolay Izhikov : > My suggestion: > > 1. Reduce Ignite3 scope to the following: > a. Delete all deprecated API and support of obsolete internal > protocols. > b. Implement IEP-61 - Common Replication Infrastructure > c. Implement new Ignite management tool ignitectl as suggested > during Ignite3 discussion. > > 2. Implement and release following improvements like transactions, Calcite > based SQL, etc in the ongoing releases - Ignite 4, 5, 6 > > My concern against separate Ignite 3 repo is the following: > > 1. We spread community to the two very separated part - Ignite3 developers > and Ignite2 maintainers. believe it’s bad for our community. > That can lead to the situation when we don’t fix critical or > blocker issueds «because they will not exists in Ignite3» > That will lead to the solutions never reviewed or reviewed poorly. > > 2. It seems for me that current scope of Ignite3 is too big to be > implemented in any reasonable time. > > > > 13 нояб. 2020 г., в 10:57, Nikolay Izhikov > написал(а): > > > > Hello, Valentin. > > > >> Nikolay, Maxim, are you OK with this route? > > > > -1 to have another repo for Ignite3 development. > > > >> 13 нояб. 2020 г., в 03:04, Valentin Kulichenko < > valentin.kuliche...@gmail.com> написал(а): > >> > >> Folks, > >> > >> We already have multiple IEPs for Ignite 3.0, and as far as I know, > there are contributors that would like to work on them (or probably already > started). That said, we should make a decision as soon as possible. > >> > >> At this point, it doesn't seem that there are any strong objections to > the technical side of things. So I would suggest the following: > >> > >> 1. Proceed with Alexey's approach to the development process, as it > seems to be the best (in my opinion - the only) way to address all the > technical concerns and issues expressed in the thread. We'll start by > creating a new repo and a new TC project. > >> 2. Start a separate discussion around transparency. If there are any > changes we need to make to our contributor guidelines, I am happy to talk > them through, but I don't think it's reasonable to delay feature > development because of this. In the short term, I will make sure that > everything that happens within the new repo is as open to the community as > possible. > >> > >> Nikolay, Maxim, are you OK with this route? > >> > >> -Val > >> > >> On Tue, Nov 10, 2020 at 4:55 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> Maxim, > >> > >> 2.x and 3.x will have to coexist for some time - I don't see how we can > avoid this considering the set of proposed changes. That said, we > effectively will need to have two "masters" - one for each major version. > Master for 3.x can technically be a branch in the existing repo, but having > a separate repo seems cleaner, simply because it will not be a "branch" in > the traditional sense. > >> > >> Note that the new repo will still be under the Apache org, with the > same set of committers, managed by the community, etc. All the development > happening for 3.0 must follow the rules that we currently have (if > anything, it's an opportunity to improve those rules). > >> > >> As I said during the call on Friday, I strongly believe that if there > is a transparency issue, it will exist regardless of the approach we choose > for 3.0. If community members develop without IEPs or public discussions, > this will happen for both 2.x and 3.x unless we address this separately. I > don't see how this is related to Alexey's suggestion, which targets > *technical* issues with the product more than anything else. This a way to > achieve better modularity, introduce better coverage with unit tests, > reduce conflicts during development, etc. > >> > >> Coming back to transparency, let's identify the issues and fix them. It > probably makes sense to have a separate discussion on this topic. > >> > >> -Val > >> > >> On Tue, Nov 10, 2020 at 1:05 PM Maxim Muzafarov > wrote: > >> Sergey, > >> > >> > >> Your summary makes sense to me. > >> > >> However, how we come up from *Development transparency* to *create a > >> separate public repository dedicated for 3.0*? For me *development > >> transparency* is about making changes in the master branch. These > >> changes will definitely be seen by all the Ignite developers. > >> > >> A dedicated public repository is technically public and visible for > >> everyone, but it allows development without IEPs, without public > >> discussion (since all the code changes are not related to the master > >> branch) it also allows a large number of assumptions and deviations > >> (like code-style violations). It also not about *development > >> transparency*
[jira] [Created] (IGNITE-13703) Check difference between TcpDiscovery and ZookeeperDiscovery at Cellular switch
Anton Vinogradov created IGNITE-13703: - Summary: Check difference between TcpDiscovery and ZookeeperDiscovery at Cellular switch Key: IGNITE-13703 URL: https://issues.apache.org/jira/browse/IGNITE-13703 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Ignite 3.0 development approach
My suggestion: 1. Reduce Ignite3 scope to the following: a. Delete all deprecated API and support of obsolete internal protocols. b. Implement IEP-61 - Common Replication Infrastructure c. Implement new Ignite management tool ignitectl as suggested during Ignite3 discussion. 2. Implement and release following improvements like transactions, Calcite based SQL, etc in the ongoing releases - Ignite 4, 5, 6 My concern against separate Ignite 3 repo is the following: 1. We spread community to the two very separated part - Ignite3 developers and Ignite2 maintainers. believe it’s bad for our community. That can lead to the situation when we don’t fix critical or blocker issueds «because they will not exists in Ignite3» That will lead to the solutions never reviewed or reviewed poorly. 2. It seems for me that current scope of Ignite3 is too big to be implemented in any reasonable time. > 13 нояб. 2020 г., в 10:57, Nikolay Izhikov > написал(а): > > Hello, Valentin. > >> Nikolay, Maxim, are you OK with this route? > > -1 to have another repo for Ignite3 development. > >> 13 нояб. 2020 г., в 03:04, Valentin Kulichenko >> написал(а): >> >> Folks, >> >> We already have multiple IEPs for Ignite 3.0, and as far as I know, there >> are contributors that would like to work on them (or probably already >> started). That said, we should make a decision as soon as possible. >> >> At this point, it doesn't seem that there are any strong objections to the >> technical side of things. So I would suggest the following: >> >> 1. Proceed with Alexey's approach to the development process, as it seems to >> be the best (in my opinion - the only) way to address all the technical >> concerns and issues expressed in the thread. We'll start by creating a new >> repo and a new TC project. >> 2. Start a separate discussion around transparency. If there are any changes >> we need to make to our contributor guidelines, I am happy to talk them >> through, but I don't think it's reasonable to delay feature development >> because of this. In the short term, I will make sure that everything that >> happens within the new repo is as open to the community as possible. >> >> Nikolay, Maxim, are you OK with this route? >> >> -Val >> >> On Tue, Nov 10, 2020 at 4:55 PM Valentin Kulichenko >> wrote: >> Maxim, >> >> 2.x and 3.x will have to coexist for some time - I don't see how we can >> avoid this considering the set of proposed changes. That said, we >> effectively will need to have two "masters" - one for each major version. >> Master for 3.x can technically be a branch in the existing repo, but having >> a separate repo seems cleaner, simply because it will not be a "branch" in >> the traditional sense. >> >> Note that the new repo will still be under the Apache org, with the same set >> of committers, managed by the community, etc. All the development happening >> for 3.0 must follow the rules that we currently have (if anything, it's an >> opportunity to improve those rules). >> >> As I said during the call on Friday, I strongly believe that if there is a >> transparency issue, it will exist regardless of the approach we choose for >> 3.0. If community members develop without IEPs or public discussions, this >> will happen for both 2.x and 3.x unless we address this separately. I don't >> see how this is related to Alexey's suggestion, which targets *technical* >> issues with the product more than anything else. This a way to achieve >> better modularity, introduce better coverage with unit tests, reduce >> conflicts during development, etc. >> >> Coming back to transparency, let's identify the issues and fix them. It >> probably makes sense to have a separate discussion on this topic. >> >> -Val >> >> On Tue, Nov 10, 2020 at 1:05 PM Maxim Muzafarov wrote: >> Sergey, >> >> >> Your summary makes sense to me. >> >> However, how we come up from *Development transparency* to *create a >> separate public repository dedicated for 3.0*? For me *development >> transparency* is about making changes in the master branch. These >> changes will definitely be seen by all the Ignite developers. >> >> A dedicated public repository is technically public and visible for >> everyone, but it allows development without IEPs, without public >> discussion (since all the code changes are not related to the master >> branch) it also allows a large number of assumptions and deviations >> (like code-style violations). It also not about *development >> transparency* since developers which are working on 3.0 is only a >> subset of all Ignite developers which may continue working on 2.x. For >> me, this would be a huge step backwards. >> >> Ignite veterans should remember how long the branch stabilization took >> for the 2.x version with the PDS. >> >> >> I think each breaking change should be passed through the master branch. >> >> On Tue, 10 Nov 2020 at 22:18,
