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 status of the ignite-3 repo? вт, 15 дек. 2020 г. в 17:30, Carbone, Adam <adam.carb...@bottomline.com>: > 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 Carbone | Director of Innovation – Intelligent Platform Team | > Bottomline Technologies > Office: 603-501-6446 | Mobile: 603-570-8418 > www.bottomline.com > > > > On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <ilya.kasnach...@gmail.com> > wrote: > > 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 > got a > minor amount of complaints. > > Regards, > -- > Ilya Kasnacheev > > > пн, 14 дек. 2020 г. в 19:06, Carbone, Adam < > adam.carb...@bottomline.com>: > > > 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 > applications > > on Websphere, Weblogic, Redhat, etc... and the organizations that > use those > > platforms are slow to move... Most of them are still on Java8 > > > > So as a platform I think a strong consideration needs to be towards > having > > the broadest possible support profile until it becomes an impediment > to > > doing things that the platform needs. So far I haven't seen huge > things in > > the newer versions of java that are must haves ( a few exceptions are > > things that would be really nice to take advantage of ). > > > > I think that apache commons has taken the right approach by staying > on > > java 8 giving the largest possible user base. > > > > Even standardizing on java 11 would have to make us reconsider > Ignite as > > the platform we are using, we are not so invested in it as of now, > even > > though we have big plans to leverage it. Just because we aren't sure > when > > we are going to be able to upgrade from java8. It has support > through 2022, > > so I imagine that is when we will be discussing that. > > > > Regards > > > > ~Adam > > > > Adam Carbone | Director of Innovation – Intelligent Platform Team | > > Bottomline Technologies > > Office: 603-501-6446 | Mobile: 603-570-8418 > > www.bottomline.com > > > > > > > > On 11/24/20, 7:38 AM, "Alexey Zinoviev" <zaleslaw....@gmail.com> > wrote: > > > > 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 < > > andrey.mashen...@gmail.com>: > > > > > 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://urldefense.com/v3/__https://issues.apache.org/jira/browse/IGNITE-13751__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKAO2Ejs8$ > > > > > > On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko < > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > 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 > > steps > > > to > > > > make a change are described on the Wiki page [3]. > > > > > > > > Let me know if you have any questions. > > > > > > > > [1] > > > https://urldefense.com/v3/__https://github.com/apache/ignite-3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKIq24lxF$ > > > > [2] > > > https://urldefense.com/v3/__https://ci.ignite.apache.org/project/ignite3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKFGL_oJx$ > > > > [3] > > > > > > > > > > > > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0*ApacheIgnite3.0-DevelopmentProcess__;Kysj!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKNhWzQ0s$ > > > > > > > > -Val > > > > > > > > On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko < > > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > > > 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 these IEPs. I believe this might be > frustrating > > for the > > > > > folks who would like to commit code. > > > > > > > > > > The scope we agreed on is quite big, and it will surely > take > > > significant > > > > > time to implement all the changes and stabilize them. > Therefore, > > it's > > > > clear > > > > > to me that we will have to maintain 2.x and 3.x in > parallel for > > quite > > > > some > > > > > time - this needs to be addressed somehow. I'm convinced > that > > having a > > > > > separate repo is the ONLY way to do that, and so far, I > haven't > > heard > > > any > > > > > clear alternatives or reasons why we shouldn't do this. > > > > > > > > > > That said, I'm inclined to proceed with this in the next > few > > days - I > > > > will > > > > > create a repo and describe the process (which we, of > course, can > > > discuss > > > > > and modify going forward). Let's, at the very least, try > and see > > where > > > it > > > > > leads us. > > > > > > > > > > If someone has any concrete alternative options on how to > we can > > > maintain > > > > > two major versions in parallel, let's have another voice > > discussion > > > this > > > > > Friday. If we do the meeting, we should set it up with a > clear > > goal to > > > > make > > > > > a decision. Please let me know if there is interest in > this. > > > > > > > > > > -Val > > > > > > > > > > On Mon, Nov 16, 2020 at 6:31 AM Alexey Goncharuk < > > > > > alexey.goncha...@gmail.com> wrote: > > > > > > > > > >> 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 includes both functional targets and technical > debt > > issues > > > > >> pointed > > > > >> out by Sergey) > > > > >> - Who is planning to take an active part in each of the > > streams > > > (i.e. > > > > >> the 'design committee', as Sergey suggested) > > > > >> - What are the intermediate and final goals for each > of the > > streams > > > > >> - What are the cross-stream interactions and how we > > integrate them > > > > >> - How each of the streams will be integrated with the > current > > > > codebase > > > > >> based on the above (here is where we will see whether > > drop-in or > > > > >> incremental approaches make more sense) > > > > >> > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Andrey V. Mashenkov > > > > > > > > >
