Re: [DISCUSS] Ignite 3.0 development approach

2020-12-25 Thread Petr Ivanov
Rather strange, cause the repository on GitHub is only a mirror of Apache's GitBox. Although — I guess Apache applied the same policy to its repositories, if not was it's author... > On 22 Dec 2020, at 13:34, Pavel Tupitsyn wrote: > > Ivan, it is the new GitHub default > > "On Oct. 1, 2020,

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-22 Thread Ivan Pavlukhin
Pavel, thanks for explanation! 2020-12-22 13:34 GMT+03:00, Pavel Tupitsyn : > Ivan, it is the new GitHub default > > "On Oct. 1, 2020, any new repositories you create will use main as the > default branch, instead of master" [1] > > [1] > https://www.zdnet.com/article/github-to-replace-master-with

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-22 Thread Pavel Tupitsyn
Ivan, it is the new GitHub default "On Oct. 1, 2020, any new repositories you create will use main as the default branch, instead of master" [1] [1] https://www.zdnet.com/article/github-to-replace-master-with-main-starting-next-month/ On Tue, Dec 22, 2020 at 1:12 PM Ivan Pavlukhin wrote: > Als

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-22 Thread Ivan Pavlukhin
Also I noticed that ignite-3 repository has "main" but not "master" branch. Who can shed light on this? Did not find an explanation in this thread. 2020-12-22 13:09 GMT+03:00, Ivan Pavlukhin : > I noticed some free-from commit messages in ignite-3 repository. I > think we should use ticket-based w

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-22 Thread Ivan Pavlukhin
I noticed some free-from commit messages in ignite-3 repository. I think we should use ticket-based workflow and commit messages as usual. [1] https://github.com/apache/ignite-3/commits/main 2020-12-21 10:55 GMT+03:00, Petr Ivanov : > There is no problem to have both in new repository, if skilled

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-20 Thread Petr Ivanov
There is no problem to have both in new repository, if skilled enthusiast will take over that job. I guess we will stick to Maven for time being but development of Gradle-based building system can be done in parallel. I can even add corresponding development build configurations for TeamCity, or

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-18 Thread Valentin Kulichenko
Hi Ivan, There was a very brief discussion around this. Basically, it looks like switching from Maven to something else is not going to bring much value, but at the same time will be quite demanding because the community has much more experience with Maven. However, I would say that it is still de

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-17 Thread Ivan Pavlukhin
Hi Igniters, Forgive me that I am not reading dev list carefully these days. Was it explicitly decided that Maven should be used as a build system for Ignite 3? As there is a new repository we possibly can update our build tools as well. What do you think? 2020-12-17 22:45 GMT+03:00, Valentin Kul

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-17 Thread Valentin Kulichenko
Hi Dmitriy, I don't think there is any reason for concern at this point. The community agreed on the scope of the changes for 3.0 - it is described on Wiki. The scope is quite big, so it is clear that 2.x and 3.x will have to exist in parallel for a significant amount of time, so we need a place w

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-16 Thread Dmitriy Pavlov
Folks, I'm a little bit concerned about the simultaneous - existence of the repo https://github.com/apache/ignite-3 and PRs for that repo - and a couple of downvotes from PMC members. Is it all fine here? Was there any vote /discussion where it was discussed and consensus approved? What is the sta

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-15 Thread Carbone, Adam
I don't believe Java 7 was LTS, and I hope that others will have upgraded long before that. If that is the release timeframe for 3.0, then I suppose that would makes sense, I would still doubt that people would be going newer than java 11, just my opinion of what I'm seeing. Regards ~adam Adam

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-15 Thread Ilya Kasnacheev
Hello! I guess Ignite 3.0 will be ready for production use somewhere in 2022, realistically. By that time, Java 8 will be long enough out of support so that most companies will actually forbid its use, WRT vulnerabilities et all. After all we have managed to upgrade from Java 7 to Java 8 and only

Re: [DISCUSS] Ignite 3.0 development approach

2020-12-14 Thread Carbone, Adam
So just one bit to consider... Are there features that you need to use in these newer versions of java? Or are we just updating to stay current? The reason I ask is that there are still lots of people in an enterprise space that are beholden to having to support legacy JAVAEE supported applicati

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-30 Thread Petr Ivanov
Hi, Val. Thanks for comments. Let me explain some ambiguous points. > [Val] What do we use Ant tasks for? I'm sure we do use them a lot for > release packaging, but it will apparently be significantly simplified. Are > there any other cases? We have ant tasks for C++ / .NET version changing (i

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-27 Thread Valentin Kulichenko
Petr, You have some great points! My comments are below. -Val On Fri, Nov 27, 2020 at 4:28 AM Petr Ivanov wrote: > More or less, unless we specifically forbid that, I guess > > However there is bigger concern: JDK 15 is STS, so after half of a year it > will be out of support and no major prod

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-27 Thread Ilya Kasnacheev
Hello! One can still submit a PR which mines bitcoin and run tests on it. CI/CD configuration alongside code does not solve the issue that any user may run code on TC. Regards, -- Ilya Kasnacheev пт, 27 нояб. 2020 г. в 16:48, Petr Ivanov : > > Storing CI/CD code (yaml definitions for Travis/A

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-27 Thread Petr Ivanov
> Storing CI/CD code (yaml definitions for Travis/Azure/GH Actions, Jenkins > pipelines, etc) in the same repo is very common. > Secrets are stored separately (e.g. GitHub secrets), TeamCity probably has > a similar feature. My main security concern — anyone, including third-party person without

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-27 Thread Pavel Tupitsyn
> migrating to 'CI/CD as a Code' Huge +1 for this. > where should the code be stored .. > alongside project's code (can be possible security hole) Storing CI/CD code (yaml definitions for Travis/Azure/GH Actions, Jenkins pipelines, etc) in the same repo is very common. Secrets are stored separa

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-27 Thread Petr Ivanov
More or less, unless we specifically forbid that, I guess However there is bigger concern: JDK 15 is STS, so after half of a year it will be out of support and no major production team will use that JDK in their environment. I would stick to JDK 11 as it is LTS at least until JDK17, plus — a lot

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-24 Thread Pavel Tupitsyn
If we use Java15 for development, can the resulting package be used from a Java11 app (the latest LTS)? On Tue, Nov 24, 2020 at 7:51 PM Andrey Mashenkov wrote: > Jave15 looks awesome. > > * Hidden classes [1] can be used by codegenerators. > * Records [2] can replace boilerplate code like Ignite

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-24 Thread Andrey Mashenkov
Jave15 looks awesome. * Hidden classes [1] can be used by codegenerators. * Records [2] can replace boilerplate code like IgniteBiTuple, GridTupleX. [1] https://openjdk.java.net/jeps/371 [2] https://openjdk.java.net/jeps/384 On Tue, Nov 24, 2020 at 3:38 PM Alexey Zinoviev wrote: > Java 15 is b

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-24 Thread Alexey Zinoviev
Java 15 is better, VarHandles, ForeignMemory access and so on. In both cases, I support the Java version 11 and higher for the development! вт, 24 нояб. 2020 г. в 15:21, Andrey Mashenkov : > Let's add maven plugins for sanity checks at the early stage. > I've created a ticket for this [1]. > >

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-24 Thread Andrey Mashenkov
Let's add maven plugins for sanity checks at the early stage. I've created a ticket for this [1]. Also, I've found initial pom.xml has a target version Java 8. Do we intend to move to Java 11 (or may be next LTS) and drop Java 8 in Ignite 3.0? [1] https://issues.apache.org/jira/browse/IGNITE-137

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-23 Thread Valentin Kulichenko
Folks, I went ahead and created the repository [1]. I also configured a TeamCity project [2] that runs all available JUnit tests on every PR creation or update. It also sends the status update to GitHub so that it's reflected in the PR itself so that we can do merges directly from GitHub. Basic st

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-18 Thread Valentin Kulichenko
Thanks, guys. It looks like we are much closer to the consensus now. I totally on board with the plan, but I would also like to address the short-term needs. As I've already mentioned earlier, there are several active IEPs, but we still don't have even a preliminary technical process for working on

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-16 Thread Alexey Goncharuk
Good, I think we have an intermediate agreement on the scope and significance of the changes we want to make. I suggest creating separate discussion streams and calls for each of the suggested topics so that: - It is clear for the community what is the motivation of the stream (this include

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-16 Thread Nikolay Izhikov
Sergey. > pay our (already huge) technical debt, Can you, please, make your statement more specific? What specific points of technical debt do we have? I think we should write it down and solve the issues step by step. > 16 нояб. 2020 г., в 14:28, Sergey Chugunov > написал(а): > > Igniters,

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-16 Thread Sergey Chugunov
Igniters, I agree that create or not create is not a question, rephrasing Shakespeare. My main point is that developing new features on top of old 2.x-style architecture is a bad idea. We will write the code and spend some time stabilizing it (which is expected and fine). But then, when we finall

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-16 Thread Nikolay Izhikov
> Let's indeed focus on Sergey's suggestions on the design->development > approach. +1 > - API & configuration cleanup > - New management tool > - Schema-first approach > - New replication infrastructure +1. > 16 нояб. 2020 г., в 13:40, Alexey Goncharuk > написал(а): > > Folks, > >

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-16 Thread Alexey Goncharuk
Folks, I think we are overly driven away by the phrase 'new repo' rather than the essence of my suggestion. We can keep developing in the same repo, we can even keep developing in the master branch. My point is that Ignite 3.0 is a chance to move on with the architecture, so if we really want to m

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-13 Thread Alexey Zinoviev
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 Serg

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-13 Thread 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. I

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-13 Thread Ivan Daschinsky
>> 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. R

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-13 Thread 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 discussio

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-12 Thread 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 wou

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-12 Thread 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 tec

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-10 Thread Valentin Kulichenko
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 s

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-10 Thread Maxim Muzafarov
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 dev

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-10 Thread Alexei Scherbakov
Makes sense to me. вт, 10 нояб. 2020 г. в 18:47, Sergey Chugunov : > Igniters, > > I thought over Friday meeting ideas and concerns and summarized them in > these three points: > > >1. *Components design unification approach.* New proposed components >will be developed by different contri

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-10 Thread Sergey Chugunov
Igniters, I thought over Friday meeting ideas and concerns and summarized them in these three points: 1. *Components design unification approach.* New proposed components will be developed by different contributors, but they need to be unified and should integrate with each other easily

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-06 Thread Kseniya Romanova
Here are the slides from Alexey Goncharuk. Let's think this over and continue on Monday: https://go.gridgain.com/rs/491-TWR-806/images/Ignite_3_Plans_and_development_process.pdf чт, 5 нояб. 2020 г. в 11:13, Anton Vinogradov : > Folks, > > Should we perform cleanup work before (r)evolutional chang

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-05 Thread Anton Vinogradov
Folks, Should we perform cleanup work before (r)evolutional changes? My huge proposal is to get rid of things which we don't need anyway - local caches, - strange tx modes, - code overcomplexity because of RollingUpgrade feature never attended at AI, - etc, before choosing the way. On Tue, Nov 3,

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-03 Thread Valentin Kulichenko
Ksenia, thanks for scheduling this on such short notice! As for the original topic, I do support Alexey's idea. We're not going to rewrite anything from scratch, as most of the components are going to be moved as-is or with minimal modifications. However, the changes that are proposed imply seriou

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-03 Thread Kseniya Romanova
Pavel, all the interesting points will be anyway published here in English (as the principal "if it's not on devlist it doesn't happened" is still relevant). This is just a quick call for a group of developers. Later we can do a separate presentation of idea and discussion in English as we did for

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-03 Thread Pavel Tupitsyn
Kseniya, Thanks for scheduling this call. Do you think we can switch to English if non-Russian speaking community members decide to join? On Tue, Nov 3, 2020 at 1:32 PM Kseniya Romanova wrote: > Let's do this community discussion open. Here's the link on zoom call in > Russian for Friday 6 PM:

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-03 Thread Kseniya Romanova
Let's do this community discussion open. Here's the link on zoom call in Russian for Friday 6 PM: https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/274360378/ вт, 3 нояб. 2020 г. в 12:49, Nikolay Izhikov : > Time works for me. > > > 3 нояб. 2020 г., в 12:40, Alexey Goncharuk > написал(а)

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-03 Thread Nikolay Izhikov
Time works for me. > 3 нояб. 2020 г., в 12:40, Alexey Goncharuk > написал(а): > > Nikolay, > > I am up for the call. I will try to explain my reasoning in greater detail > and will be glad to hear the concerns. Will this Friday, Nov 6th, work? > > вт, 3 нояб. 2020 г. в 10:09, Nikolay Izhikov

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-03 Thread Alexey Goncharuk
Nikolay, I am up for the call. I will try to explain my reasoning in greater detail and will be glad to hear the concerns. Will this Friday, Nov 6th, work? вт, 3 нояб. 2020 г. в 10:09, Nikolay Izhikov : > Igniters, should we have a call for this topic? > > > 2 нояб. 2020 г., в 18:53, Pavel Tupit

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Nikita Ivanov
+1 on having a separate repo. Make the work cleaner and more effective. -- Nikita Ivanov On Mon, Nov 2, 2020 at 11:09 PM Nikolay Izhikov wrote: > Igniters, should we have a call for this topic? > > > 2 нояб. 2020 г., в 18:53, Pavel Tupitsyn > написал(а): > > > >> not intend to rewrite everyt

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Nikolay Izhikov
Igniters, should we have a call for this topic? > 2 нояб. 2020 г., в 18:53, Pavel Tupitsyn написал(а): > >> not intend to rewrite everything from scratch > >> Every single test from Ignite 2.x should be moved to Ignite 3 >> regardless of how we choose to proceed. > > Alexey, thank you for the

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Pavel Tupitsyn
> not intend to rewrite everything from scratch > Every single test from Ignite 2.x should be moved to Ignite 3 > regardless of how we choose to proceed. Alexey, thank you for the explanation, this addresses all of my concerns. On Mon, Nov 2, 2020 at 6:43 PM Andrey Mashenkov wrote: > Hi, I

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Andrey Mashenkov
Hi, Igniters. * AFAIU, we need a new repo if we want to apply different restrictions to pull requests, otherwise I see no difference for myself. E.g. make static analysis (do we have?), compile, styles, and javadoc checks mandatory. I think that relaxed requirements here will lead to bad product

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Ilya Kasnacheev
Hello! In my opinion, what you are actually proposing is writing a new IMDG/distributed database. I'm not sure why one would assume that this new product will be particularly successful with users. We have some very good developers out there now, but some of the people who actually wrote Ignite 2

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Alexey Goncharuk
Nikolay, Pavel, Thanks for the feedback! First of all, I wanted to stress that I do not intend to rewrite everything from scratch (I never used this phrase). There are significant parts of code that would be moved with minimal modifications. Second, I never said that we will get rid of the old tes

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Pavel Tupitsyn
1. Rewriting from scratch is never a good idea. We don't want to follow the path of Netscape and lose all our users by the time we have a working 3.0 [1] 2. Not sure about new repo - seems like some pain and no gain, what's the problem with a branch? 3. We should keep existing integration tests w

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Nikolay Izhikov
Hello, Alexey. I think that «rewriting from scratch» approach has a high risk to make new features unusable. At the time Ignite2 was started no-one wants to do bad UX or bad features. Nevertheless, it happen. I think we can avoid it with the Ignite3 and successors if we will move step by step

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Anton Vinogradov
Alexey, Do we have any estimates of how fast we'll be able to gain production-ready AI 3.0 in case of a "new repo" choice? On Mon, Nov 2, 2020 at 2:01 PM Alexey Goncharuk wrote: > Nikolay, > > What new features are we planning to implement for Ignite 2.x? I think once > we commence working on I

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Alexey Goncharuk
Nikolay, What new features are we planning to implement for Ignite 2.x? I think once we commence working on Ignite 3.0, we should gradually cease the activity on Ignite 2.x to mere bugfixes because such parallel development will be overwhelming regardless of how we choose to proceed. пн, 2 нояб.

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Nikolay Izhikov
To be clear: > I would suggest creating a new repository for Ignite 3.0 (perhaps, a new > clean branch, but a new repo looks nicer to me) and a new Ignite 3.0 TeamCity > project. +1 for new Team City project. +1 for new branch for Ignite3. -1 for new repo. > 2 нояб. 2020 г., в 13:35, Nikolay

Re: [DISCUSS] Ignite 3.0 development approach

2020-11-02 Thread Nikolay Izhikov
Hello, Alexey. I think it will hurt our project more than help. Developing new features for 2 separate branches with the different APIs and internal structure is overwhelming Maybe we should relax a bit requirements for Ignite3? Maybe we should move step by step and make Ignite3 with new configu