[DISCUSS] Ignite 3.0 development approach

[Andrew 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 <[hidden email]>
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 <[hidden email]
> >:
>
> > 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-13751
> >
> > On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko <
> > [hidden email]> 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://github.com/apache/ignite-3
> > > [2] https://ci.ignite.apache.org/project/ignite3
> > > [3]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-DevelopmentProcess
> > >
> > > -Val
> > >
> > > On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
> > > [hidden email]> 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 <
> > > > [hidden email]> 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
> >
>

--
Best regards,
Andrey V. Mashenkov

[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 <[hidden email]>
wrote:

> 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 <[hidden email]>
> 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 <
> [hidden email]
> > >:
> >
> > > 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-13751
> > >
> > > On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko <
> > > [hidden email]> 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://github.com/apache/ignite-3
> > > > [2] https://ci.ignite.apache.org/project/ignite3
> > > > [3]
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-DevelopmentProcess
> > > >
> > > > -Val
> > > >
> > > > On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
> > > > [hidden email]> 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 <
> > > > > [hidden email]> 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
> > >
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

[vveider]

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 of efforts should be made to enforce Apache Ignite be built on JDK 11 alone, not to mention 15th version...



Also, If we are going to introduce such major changes, I'd like to purpose maven project refactoring as well:
1. Full revision of all ant-calling tasks with javascript functions and alike — the complexity of those are overwhelming, something new should be at least researched.
2. Full revisions of profiles (for both root and modules) as there are some obsolete ones, and some that do ambiguous or, even worse, totally unknown tasks.
3. Introduce plugin and dependency management sections to control over and concrete versions of software we are relying in our project. Additionally — add BOM with all Ignite modules and their dependencies, which should help our users to better embed Ignite to their projects.
4. Up all versions of plugins and dependencies where possible to there current production versions (for plugins — it should be a must if we are ever going to build project under latest JDK versions).
5. Prepare project for parallel building, testing and assembling where possible for faster development process, with possible additional enhancement like incremental rebuild.
6. Possibly — research alternate builders, like Gradle (thought there are a lot of questions to its race condition issues during multimodule builds).



And last, but not least — think of migrating to 'CI/CD as a Code' approach for our main instrument TeamCity.
Whole project (both test and release build configurations) can be described using DSL (Kotlin in case of TC) and stored in VCS, forcing infrastructure changes to go through the same development processes including discussions, review, change history and etc.

Only I am not sure for now about where should the code be stored — in separate repository (secure, but disables testing of code with TC settings both in single PR), or alongside project's code (can be possible security hole).
That would require additional dev thread I think.



WDYT?

> On 24 Nov 2020, at 20:04, Pavel Tupitsyn <[hidden email]> wrote:
>
> 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 <[hidden email]>
> wrote:
>
>> 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 <[hidden email]>
>> 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 <
>> [hidden email]
>>>> :
>>>
>>>> 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-13751
>>>>
>>>> On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko <
>>>> [hidden email]> 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://github.com/apache/ignite-3
>>>>> [2] https://ci.ignite.apache.org/project/ignite3
>>>>> [3]
>>>>>
>>>>>
>>>>
>>>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-DevelopmentProcess
>>>>>
>>>>> -Val
>>>>>
>>>>> On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
>>>>> [hidden email]> 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 <
>>>>>> [hidden email]> 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
>>>>
>>>
>>
>>
>> --
>> Best regards,
>> Andrey V. Mashenkov
>>

[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 separately (e.g. GitHub secrets), TeamCity probably has
a similar feature.


On Fri, Nov 27, 2020 at 3:28 PM Petr Ivanov <[hidden email]> 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 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 of
> efforts should be made to enforce Apache Ignite be built on JDK 11 alone,
> not to mention 15th version...
>
>
>
> Also, If we are going to introduce such major changes, I'd like to purpose
> maven project refactoring as well:
> 1. Full revision of all ant-calling tasks with javascript functions and
> alike — the complexity of those are overwhelming, something new should be
> at least researched.
> 2. Full revisions of profiles (for both root and modules) as there are
> some obsolete ones, and some that do ambiguous or, even worse, totally
> unknown tasks.
> 3. Introduce plugin and dependency management sections to control over and
> concrete versions of software we are relying in our project. Additionally —
> add BOM with all Ignite modules and their dependencies, which should help
> our users to better embed Ignite to their projects.
> 4. Up all versions of plugins and dependencies where possible to there
> current production versions (for plugins — it should be a must if we are
> ever going to build project under latest JDK versions).
> 5. Prepare project for parallel building, testing and assembling where
> possible for faster development process, with possible additional
> enhancement like incremental rebuild.
> 6. Possibly — research alternate builders, like Gradle (thought there are
> a lot of questions to its race condition issues during multimodule builds).
>
>
>
> And last, but not least — think of migrating to 'CI/CD as a Code' approach
> for our main instrument TeamCity.
> Whole project (both test and release build configurations) can be
> described using DSL (Kotlin in case of TC) and stored in VCS, forcing
> infrastructure changes to go through the same development processes
> including discussions, review, change history and etc.
>
> Only I am not sure for now about where should the code be stored — in
> separate repository (secure, but disables testing of code with TC settings
> both in single PR), or alongside project's code (can be possible security
> hole).
> That would require additional dev thread I think.
>
>
>
> WDYT?
>
> > On 24 Nov 2020, at 20:04, Pavel Tupitsyn <[hidden email]> wrote:
> >
> > 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 <
> [hidden email]>
> > wrote:
> >
> >> 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 <[hidden email]
> >
> >> 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 <
> >> [hidden email]
> >>>> :
> >>>
> >>>> 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-13751
> >>>>
> >>>> On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko <
> >>>> [hidden email]> 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://github.com/apache/ignite-3
> >>>>> [2] https://ci.ignite.apache.org/project/ignite3
> >>>>> [3]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-DevelopmentProcess
> >>>>>
> >>>>> -Val
> >>>>>
> >>>>> On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
> >>>>> [hidden email]> 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 <
> >>>>>> [hidden email]> 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
> >>>>
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >> Andrey V. Mashenkov
> >>
>
>

[vveider]

> 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 even committer permissions can modify build configuration in such a way that it will be doing something not intend to do (bitcoin mining for instance) or even something harmful (like trying to attack underlying TC infrastructure). If we are to store CI/CD configuration alongside code, some restrictions are required.

> On 27 Nov 2020, at 15:59, Pavel Tupitsyn <[hidden email]> wrote:
>
>> 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 separately (e.g. GitHub secrets), TeamCity probably has
> a similar feature.
>
>
> On Fri, Nov 27, 2020 at 3:28 PM Petr Ivanov <[hidden email]> 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 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 of
>> efforts should be made to enforce Apache Ignite be built on JDK 11 alone,
>> not to mention 15th version...
>>
>>
>>
>> Also, If we are going to introduce such major changes, I'd like to purpose
>> maven project refactoring as well:
>> 1. Full revision of all ant-calling tasks with javascript functions and
>> alike — the complexity of those are overwhelming, something new should be
>> at least researched.
>> 2. Full revisions of profiles (for both root and modules) as there are
>> some obsolete ones, and some that do ambiguous or, even worse, totally
>> unknown tasks.
>> 3. Introduce plugin and dependency management sections to control over and
>> concrete versions of software we are relying in our project. Additionally —
>> add BOM with all Ignite modules and their dependencies, which should help
>> our users to better embed Ignite to their projects.
>> 4. Up all versions of plugins and dependencies where possible to there
>> current production versions (for plugins — it should be a must if we are
>> ever going to build project under latest JDK versions).
>> 5. Prepare project for parallel building, testing and assembling where
>> possible for faster development process, with possible additional
>> enhancement like incremental rebuild.
>> 6. Possibly — research alternate builders, like Gradle (thought there are
>> a lot of questions to its race condition issues during multimodule builds).
>>
>>
>>
>> And last, but not least — think of migrating to 'CI/CD as a Code' approach
>> for our main instrument TeamCity.
>> Whole project (both test and release build configurations) can be
>> described using DSL (Kotlin in case of TC) and stored in VCS, forcing
>> infrastructure changes to go through the same development processes
>> including discussions, review, change history and etc.
>>
>> Only I am not sure for now about where should the code be stored — in
>> separate repository (secure, but disables testing of code with TC settings
>> both in single PR), or alongside project's code (can be possible security
>> hole).
>> That would require additional dev thread I think.
>>
>>
>>
>> WDYT?
>>
>>> On 24 Nov 2020, at 20:04, Pavel Tupitsyn <[hidden email]> wrote:
>>>
>>> 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 <
>> [hidden email]>
>>> wrote:
>>>
>>>> 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 <[hidden email]
>>>
>>>> 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 <
>>>> [hidden email]
>>>>>> :
>>>>>
>>>>>> 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-13751
>>>>>>
>>>>>> On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko <
>>>>>> [hidden email]> 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://github.com/apache/ignite-3
>>>>>>> [2] https://ci.ignite.apache.org/project/ignite3
>>>>>>> [3]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-DevelopmentProcess
>>>>>>>
>>>>>>> -Val
>>>>>>>
>>>>>>> On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
>>>>>>> [hidden email]> 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 <
>>>>>>>> [hidden email]> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Andrey V. Mashenkov
>>>>
>>
>>

[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 <[hidden email]>:

> > 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
> even committer permissions can modify build configuration in such a way
> that it will be doing something not intend to do (bitcoin mining for
> instance) or even something harmful (like trying to attack underlying TC
> infrastructure). If we are to store CI/CD configuration alongside code,
> some restrictions are required.
>
>
>
> > On 27 Nov 2020, at 15:59, Pavel Tupitsyn <[hidden email]> wrote:
> >
> >> 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 separately (e.g. GitHub secrets), TeamCity probably
> has
> > a similar feature.
> >
> >
> > On Fri, Nov 27, 2020 at 3:28 PM Petr Ivanov <[hidden email]> 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 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
> of
> >> efforts should be made to enforce Apache Ignite be built on JDK 11
> alone,
> >> not to mention 15th version...
> >>
> >>
> >>
> >> Also, If we are going to introduce such major changes, I'd like to
> purpose
> >> maven project refactoring as well:
> >> 1. Full revision of all ant-calling tasks with javascript functions and
> >> alike — the complexity of those are overwhelming, something new should
> be
> >> at least researched.
> >> 2. Full revisions of profiles (for both root and modules) as there are
> >> some obsolete ones, and some that do ambiguous or, even worse, totally
> >> unknown tasks.
> >> 3. Introduce plugin and dependency management sections to control over
> and
> >> concrete versions of software we are relying in our project.
> Additionally —
> >> add BOM with all Ignite modules and their dependencies, which should
> help
> >> our users to better embed Ignite to their projects.
> >> 4. Up all versions of plugins and dependencies where possible to there
> >> current production versions (for plugins — it should be a must if we are
> >> ever going to build project under latest JDK versions).
> >> 5. Prepare project for parallel building, testing and assembling where
> >> possible for faster development process, with possible additional
> >> enhancement like incremental rebuild.
> >> 6. Possibly — research alternate builders, like Gradle (thought there
> are
> >> a lot of questions to its race condition issues during multimodule
> builds).
> >>
> >>
> >>
> >> And last, but not least — think of migrating to 'CI/CD as a Code'
> approach
> >> for our main instrument TeamCity.
> >> Whole project (both test and release build configurations) can be
> >> described using DSL (Kotlin in case of TC) and stored in VCS, forcing
> >> infrastructure changes to go through the same development processes
> >> including discussions, review, change history and etc.
> >>
> >> Only I am not sure for now about where should the code be stored — in
> >> separate repository (secure, but disables testing of code with TC
> settings
> >> both in single PR), or alongside project's code (can be possible
> security
> >> hole).
> >> That would require additional dev thread I think.
> >>
> >>
> >>
> >> WDYT?
> >>
> >>> On 24 Nov 2020, at 20:04, Pavel Tupitsyn <[hidden email]> wrote:
> >>>
> >>> 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 <
> >> [hidden email]>
> >>> wrote:
> >>>
> >>>> 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 <
> [hidden email]
> >>>
> >>>> 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 <
> >>>> [hidden email]
> >>>>>> :
> >>>>>
> >>>>>> 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-13751
> >>>>>>
> >>>>>> On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko <
> >>>>>> [hidden email]> 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://github.com/apache/ignite-3
> >>>>>>> [2] https://ci.ignite.apache.org/project/ignite3
> >>>>>>> [3]
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-DevelopmentProcess
> >>>>>>>
> >>>>>>> -Val
> >>>>>>>
> >>>>>>> On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
> >>>>>>> [hidden email]> 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 <
> >>>>>>>> [hidden email]> 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
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best regards,
> >>>> Andrey V. Mashenkov
> >>>>
> >>
> >>
>
>

[Valentin Kulichenko]

Petr,

You have some great points! My comments are below.

-Val

On Fri, Nov 27, 2020 at 4:28 AM Petr Ivanov <[hidden email]> 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 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 of
> efforts should be made to enforce Apache Ignite be built on JDK 11 alone,
> not to mention 15th version...
>

[Val] I think we will have to stick with Java 11, simply because it's the
current LTS. If we go with 15, almost no one will be able to use Ignite in
production :) We can switch to 17 in the future in case there is any value.


> Also, If we are going to introduce such major changes, I'd like to purpose
> maven project refactoring as well:
> 1. Full revision of all ant-calling tasks with javascript functions and
> alike — the complexity of those are overwhelming, something new should be
> at least researched.
>

[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?


> 2. Full revisions of profiles (for both root and modules) as there are
> some obsolete ones, and some that do ambiguous or, even worse, totally
> unknown tasks.
>

[Val] Agree - the number of profiles should be at least minimized. In the
best case, we should not have any profiles at all. They are non-intuitive
for developers, and also often confuse IDEs.


> 3. Introduce plugin and dependency management sections to control over and
> concrete versions of software we are relying in our project. Additionally —
> add BOM with all Ignite modules and their dependencies, which should help
> our users to better embed Ignite to their projects.
> 4. Up all versions of plugins and dependencies where possible to there
> current production versions (for plugins — it should be a must if we are
> ever going to build project under latest JDK versions).
>

[Val] Agree with both.


> 5. Prepare project for parallel building, testing and assembling where
> possible for faster development process, with possible additional
> enhancement like incremental rebuild.
>

[Val] Could you elaborate on this? What should be parallelized in your
view, and how exactly it will speed up the process?


> 6. Possibly — research alternate builders, like Gradle (thought there are
> a lot of questions to its race condition issues during multimodule builds).
>

[Val] I'm not sure we need this. Gradle does seem to be nicer than Maven in
many aspects, but this will be a big transition for the community. The
value of such a transition is not clear. We also seem to have much more
experience in Maven than in Gradle.


> And last, but not least — think of migrating to 'CI/CD as a Code' approach
> for our main instrument TeamCity.
> Whole project (both test and release build configurations) can be
> described using DSL (Kotlin in case of TC) and stored in VCS, forcing
> infrastructure changes to go through the same development processes
> including discussions, review, change history and etc.
>

[Val] Huge +1.

>
> Only I am not sure for now about where should the code be stored — in
> separate repository (secure, but disables testing of code with TC settings
> both in single PR), or alongside project's code (can be possible security
> hole).
> That would require additional dev thread I think.
>
>
>
> WDYT?
>
> > On 24 Nov 2020, at 20:04, Pavel Tupitsyn <[hidden email]> wrote:
> >
> > 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 <
> [hidden email]>
> > wrote:
> >
> >> 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 <[hidden email]
> >
> >> 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 <
> >> [hidden email]
> >>>> :
> >>>
> >>>> 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-13751
> >>>>
> >>>> On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko <
> >>>> [hidden email]> 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://github.com/apache/ignite-3
> >>>>> [2] https://ci.ignite.apache.org/project/ignite3
> >>>>> [3]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-DevelopmentProcess
> >>>>>
> >>>>> -Val
> >>>>>
> >>>>> On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
> >>>>> [hidden email]> 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 <
> >>>>>> [hidden email]> 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
> >>>>
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >> Andrey V. Mashenkov
> >>
>
>

[vveider]

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 (including calling Javascript via ant), assembling, javadoc modification and so on.
There are at least 11 modules with maven-antrun-plugin, plus core and parent pom.

I suggest some revision is required and a) removing of obsolete ones and b) trying to replace ant call with more native maven plugin (or at least redesign approach to be more clear what it does and why).



> [Val] Could you elaborate on this? What should be parallelized in your
> view, and how exactly it will speed up the process?

I was talking about stable parallel build (current it is not stable, producing different results from build to build and having race condition issues) and parallel tests (we have no unit tests for now, but when we will have, forkCount=1 should be the default behaviour).
For both — correct set of plugins and their version should be introduced and tests.

That is not in high priority, more "nice to have" feature.



> [Val] I'm not sure we need this. Gradle does seem to be nicer than Maven in
> many aspects, but this will be a big transition for the community. The
> value of such a transition is not clear. We also seem to have much more
> experience in Maven than in Gradle.

Agree. I was thinking of Gradle only as a possible alternative if we will face impossible to solve with maven issues.

> On 28 Nov 2020, at 07:31, Valentin Kulichenko <[hidden email]> wrote:
>
> Petr,
>
> You have some great points! My comments are below.
>
> -Val
>
> On Fri, Nov 27, 2020 at 4:28 AM Petr Ivanov <[hidden email]> 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 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 of
>> efforts should be made to enforce Apache Ignite be built on JDK 11 alone,
>> not to mention 15th version...
>>
>
> [Val] I think we will have to stick with Java 11, simply because it's the
> current LTS. If we go with 15, almost no one will be able to use Ignite in
> production :) We can switch to 17 in the future in case there is any value.
>
>
>> Also, If we are going to introduce such major changes, I'd like to purpose
>> maven project refactoring as well:
>> 1. Full revision of all ant-calling tasks with javascript functions and
>> alike — the complexity of those are overwhelming, something new should be
>> at least researched.
>>
>
> [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?
>
>
>> 2. Full revisions of profiles (for both root and modules) as there are
>> some obsolete ones, and some that do ambiguous or, even worse, totally
>> unknown tasks.
>>
>
> [Val] Agree - the number of profiles should be at least minimized. In the
> best case, we should not have any profiles at all. They are non-intuitive
> for developers, and also often confuse IDEs.
>
>
>> 3. Introduce plugin and dependency management sections to control over and
>> concrete versions of software we are relying in our project. Additionally —
>> add BOM with all Ignite modules and their dependencies, which should help
>> our users to better embed Ignite to their projects.
>> 4. Up all versions of plugins and dependencies where possible to there
>> current production versions (for plugins — it should be a must if we are
>> ever going to build project under latest JDK versions).
>>
>
> [Val] Agree with both.
>
>
>> 5. Prepare project for parallel building, testing and assembling where
>> possible for faster development process, with possible additional
>> enhancement like incremental rebuild.
>>
>
> [Val] Could you elaborate on this? What should be parallelized in your
> view, and how exactly it will speed up the process?
>
>
>> 6. Possibly — research alternate builders, like Gradle (thought there are
>> a lot of questions to its race condition issues during multimodule builds).
>>
>
> [Val] I'm not sure we need this. Gradle does seem to be nicer than Maven in
> many aspects, but this will be a big transition for the community. The
> value of such a transition is not clear. We also seem to have much more
> experience in Maven than in Gradle.
>
>
>> And last, but not least — think of migrating to 'CI/CD as a Code' approach
>> for our main instrument TeamCity.
>> Whole project (both test and release build configurations) can be
>> described using DSL (Kotlin in case of TC) and stored in VCS, forcing
>> infrastructure changes to go through the same development processes
>> including discussions, review, change history and etc.
>>
>
> [Val] Huge +1.
>
>
>>
>> Only I am not sure for now about where should the code be stored — in
>> separate repository (secure, but disables testing of code with TC settings
>> both in single PR), or alongside project's code (can be possible security
>> hole).
>> That would require additional dev thread I think.
>>
>>
>>
>> WDYT?
>>
>>> On 24 Nov 2020, at 20:04, Pavel Tupitsyn <[hidden email]> wrote:
>>>
>>> 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 <
>> [hidden email]>
>>> wrote:
>>>
>>>> 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 <[hidden email]
>>>
>>>> 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 <
>>>> [hidden email]
>>>>>> :
>>>>>
>>>>>> 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-13751
>>>>>>
>>>>>> On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko <
>>>>>> [hidden email]> 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://github.com/apache/ignite-3
>>>>>>> [2] https://ci.ignite.apache.org/project/ignite3
>>>>>>> [3]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-DevelopmentProcess
>>>>>>>
>>>>>>> -Val
>>>>>>>
>>>>>>> On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
>>>>>>> [hidden email]> 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 <
>>>>>>>> [hidden email]> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Andrey V. Mashenkov
>>>>
>>
>>

[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 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: [phone]
www.bottomline.com
 
 

On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]> 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 <[hidden email]>:

    > 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 <
    > [hidden email]> 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 <
    > > [hidden email]> 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 <
    > > > [hidden email]> 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
    >

[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 got a
minor amount of complaints.

Regards,
--
Ilya Kasnacheev


пн, 14 дек. 2020 г. в 19:06, Carbone, Adam <[hidden email]>:

> 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: [phone]
> www.bottomline.com
>
>
>
> On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]> 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 <
> [hidden email]>:
>
>     > 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 <
>     > [hidden email]> 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 <
>     > > [hidden email]> 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 <
>     > > > [hidden email]> 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
>     >
>
>

[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 Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: [phone]
www.bottomline.com
 
 

On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <[hidden email]> 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 <[hidden email]>:

    > 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: [phone]
    > www.bottomline.com
    >
    >
    >
    > On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]> 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 <
    > [hidden email]>:
    >
    >     > 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 <
    >     > [hidden email]> 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 <
    >     > > [hidden email]> 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 <
    >     > > > [hidden email]> 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
    >     >
    >
    >

[Dmitry 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 status of the ignite-3 repo?

вт, 15 дек. 2020 г. в 17:30, Carbone, Adam <[hidden email]>:

> 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: [phone]
> www.bottomline.com
>
>
>
> On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <[hidden email]>
> 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 <
> [hidden email]>:
>
>     > 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: [phone]
>     > www.bottomline.com
>     >
>     >
>     >
>     > On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]>
> 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 <
>     > [hidden email]>:
>     >
>     >     > 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 <
>     >     > [hidden email]> 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 <
>     >     > > [hidden email]> 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 <
>     >     > > > [hidden email]> 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
>     >     >
>     >
>     >
>
>

[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 where we can
merge the code for 3.x. Thus, I've created this new repo. We already have
multiple IEPs, as well as several contributors who are actively involved in
development. Some of the first PRs were merged today.

I didn't hear any objections since the repo was created.

-Val

On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov <[hidden email]> wrote:

> 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 <[hidden email]>:
>
> > 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: [phone]
> > www.bottomline.com
> >
> >
> >
> > On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <[hidden email]>
> > 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 <
> > [hidden email]>:
> >
> >     > 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: [phone]
> >     > www.bottomline.com
> >     >
> >     >
> >     >
> >     > On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]>
> > 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 <
> >     > [hidden email]>:
> >     >
> >     >     > 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 <
> >     >     > [hidden email]> 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 <
> >     >     > > [hidden email]> 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 <
> >     >     > > > [hidden email]> 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
> >     >     >
> >     >
> >     >
> >
> >
>

[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 Kulichenko <[hidden email]>:

> 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 where we can
> merge the code for 3.x. Thus, I've created this new repo. We already have
> multiple IEPs, as well as several contributors who are actively involved in
> development. Some of the first PRs were merged today.
>
> I didn't hear any objections since the repo was created.
>
> -Val
>
> On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov <[hidden email]> wrote:
>
>> 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 <[hidden email]>:
>>
>> > 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: [phone]
>> > www.bottomline.com
>> >
>> >
>> >
>> > On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <[hidden email]>
>> > 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 <
>> > [hidden email]>:
>> >
>> >     > 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: [phone]
>> >     > www.bottomline.com
>> >     >
>> >     >
>> >     >
>> >     > On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]>
>> > 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 <
>> >     > [hidden email]>:
>> >     >
>> >     >     > 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 <
>> >     >     > [hidden email]> 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 <
>> >     >     > > [hidden email]> 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 <
>> >     >     > > > [hidden email]> 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
>> >     >     >
>> >     >
>> >     >
>> >
>> >
>>
>

--

Best regards,
Ivan Pavlukhin

[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
debatable at this point -- please feel free to share your thoughts on this.

-Val

On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin <[hidden email]> wrote:

> 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 Kulichenko <
> [hidden email]>:
> > 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 where we
> can
> > merge the code for 3.x. Thus, I've created this new repo. We already have
> > multiple IEPs, as well as several contributors who are actively involved
> in
> > development. Some of the first PRs were merged today.
> >
> > I didn't hear any objections since the repo was created.
> >
> > -Val
> >
> > On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov <[hidden email]>
> wrote:
> >
> >> 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 <[hidden email]
> >:
> >>
> >> > 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: [phone]
> >> > www.bottomline.com
> >> >
> >> >
> >> >
> >> > On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <[hidden email]>
> >> > 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 <
> >> > [hidden email]>:
> >> >
> >> >     > 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: [phone]
> >> >     > www.bottomline.com
> >> >     >
> >> >     >
> >> >     >
> >> >     > On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]
> >
> >> > 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 <
> >> >     > [hidden email]>:
> >> >     >
> >> >     >     > 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 <
> >> >     >     > [hidden email]> 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 <
> >> >     >     > > [hidden email]> 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 <
> >> >     >     > > > [hidden email]> 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
> >> >     >     >
> >> >     >
> >> >     >
> >> >
> >> >
> >>
> >
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>

[vveider]

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 even introduce some kind of switch — so that we can test old and new build approaches and provide seamless transition if we agree on that.

> On 19 Dec 2020, at 01:00, Valentin Kulichenko <[hidden email]> wrote:
>
> 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
> debatable at this point -- please feel free to share your thoughts on this.
>
> -Val
>
> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin <[hidden email]> wrote:
>
>> 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 Kulichenko <
>> [hidden email]>:
>>> 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 where we
>> can
>>> merge the code for 3.x. Thus, I've created this new repo. We already have
>>> multiple IEPs, as well as several contributors who are actively involved
>> in
>>> development. Some of the first PRs were merged today.
>>>
>>> I didn't hear any objections since the repo was created.
>>>
>>> -Val
>>>
>>> On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov <[hidden email]>
>> wrote:
>>>
>>>> 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 <[hidden email]
>>> :
>>>>
>>>>> 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: [phone]
>>>>> www.bottomline.com
>>>>>
>>>>>
>>>>>
>>>>> On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <[hidden email]>
>>>>> 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 <
>>>>> [hidden email]>:
>>>>>
>>>>>> 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: [phone]
>>>>>> www.bottomline.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]
>>>
>>>>> 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 <
>>>>>> [hidden email]>:
>>>>>>
>>>>>>> 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 <
>>>>>>> [hidden email]> 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 <
>>>>>>>> [hidden email]> 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 <
>>>>>>>>> [hidden email]> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Best regards,
>> Ivan Pavlukhin
>>

[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 <[hidden email]>:

> 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 even introduce some kind of switch — so that we can test old and new
> build approaches and provide seamless transition if we agree on that.
>
>> On 19 Dec 2020, at 01:00, Valentin Kulichenko
>> <[hidden email]> wrote:
>>
>> 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
>> debatable at this point -- please feel free to share your thoughts on
>> this.
>>
>> -Val
>>
>> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin <[hidden email]>
>> wrote:
>>
>>> 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 Kulichenko <
>>> [hidden email]>:
>>>> 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 where we
>>> can
>>>> merge the code for 3.x. Thus, I've created this new repo. We already
>>>> have
>>>> multiple IEPs, as well as several contributors who are actively
>>>> involved
>>> in
>>>> development. Some of the first PRs were merged today.
>>>>
>>>> I didn't hear any objections since the repo was created.
>>>>
>>>> -Val
>>>>
>>>> On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov <[hidden email]>
>>> wrote:
>>>>
>>>>> 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
>>>>> <[hidden email]
>>>> :
>>>>>
>>>>>> 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: [phone]
>>>>>> www.bottomline.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <[hidden email]>
>>>>>> 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 <
>>>>>> [hidden email]>:
>>>>>>
>>>>>>> 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: [phone]
>>>>>>> www.bottomline.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]
>>>>
>>>>>> 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 <
>>>>>>> [hidden email]>:
>>>>>>>
>>>>>>>> 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 <
>>>>>>>> [hidden email]> 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 <
>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>> [hidden email]> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Ivan Pavlukhin
>>>
>
>

--

Best regards,
Ivan Pavlukhin

[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 <[hidden email]>:

> 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 <[hidden email]>:
>> 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 even introduce some kind of switch — so that we can test old and new
>> build approaches and provide seamless transition if we agree on that.
>>
>>> On 19 Dec 2020, at 01:00, Valentin Kulichenko
>>> <[hidden email]> wrote:
>>>
>>> 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
>>> debatable at this point -- please feel free to share your thoughts on
>>> this.
>>>
>>> -Val
>>>
>>> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin <[hidden email]>
>>> wrote:
>>>
>>>> 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 Kulichenko <
>>>> [hidden email]>:
>>>>> 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 where we
>>>> can
>>>>> merge the code for 3.x. Thus, I've created this new repo. We already
>>>>> have
>>>>> multiple IEPs, as well as several contributors who are actively
>>>>> involved
>>>> in
>>>>> development. Some of the first PRs were merged today.
>>>>>
>>>>> I didn't hear any objections since the repo was created.
>>>>>
>>>>> -Val
>>>>>
>>>>> On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> 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
>>>>>> <[hidden email]
>>>>> :
>>>>>>
>>>>>>> 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: [phone]
>>>>>>> www.bottomline.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <[hidden email]>
>>>>>>> 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 <
>>>>>>> [hidden email]>:
>>>>>>>
>>>>>>>> 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: [phone]
>>>>>>>> www.bottomline.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]
>>>>>
>>>>>>> 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 <
>>>>>>>> [hidden email]>:
>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>> [hidden email]> 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 <
>>>>>>>>>>> [hidden email]> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>> Ivan Pavlukhin
>>>>
>>
>>
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>

--

Best regards,
Ivan Pavlukhin

[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 <[hidden email]> wrote:

> 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 <[hidden email]>:
> > 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 <[hidden email]>:
> >> 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 even introduce some kind of switch — so that we can test old and new
> >> build approaches and provide seamless transition if we agree on that.
> >>
> >>> On 19 Dec 2020, at 01:00, Valentin Kulichenko
> >>> <[hidden email]> wrote:
> >>>
> >>> 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
> >>> debatable at this point -- please feel free to share your thoughts on
> >>> this.
> >>>
> >>> -Val
> >>>
> >>> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin <[hidden email]>
> >>> wrote:
> >>>
> >>>> 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 Kulichenko <
> >>>> [hidden email]>:
> >>>>> 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 where
> we
> >>>> can
> >>>>> merge the code for 3.x. Thus, I've created this new repo. We already
> >>>>> have
> >>>>> multiple IEPs, as well as several contributors who are actively
> >>>>> involved
> >>>> in
> >>>>> development. Some of the first PRs were merged today.
> >>>>>
> >>>>> I didn't hear any objections since the repo was created.
> >>>>>
> >>>>> -Val
> >>>>>
> >>>>> On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov <[hidden email]>
> >>>> wrote:
> >>>>>
> >>>>>> 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
> >>>>>> <[hidden email]
> >>>>> :
> >>>>>>
> >>>>>>> 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: [phone]
> >>>>>>> www.bottomline.com
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <
> [hidden email]>
> >>>>>>> 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 <
> >>>>>>> [hidden email]>:
> >>>>>>>
> >>>>>>>> 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: [phone]
> >>>>>>>> www.bottomline.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]
> >>>>>
> >>>>>>> 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 <
> >>>>>>>> [hidden email]>:
> >>>>>>>>
> >>>>>>>>> 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 <
> >>>>>>>>> [hidden email]> 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 <
> >>>>>>>>>> [hidden email]> 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 <
> >>>>>>>>>>> [hidden email]> 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
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Best regards,
> >>>> Ivan Pavlukhin
> >>>>
> >>
> >>
> >
> >
> > --
> >
> > Best regards,
> > Ivan Pavlukhin
> >
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>

[Ivan Pavlukhin]

Pavel, thanks for explanation!

2020-12-22 13:34 GMT+03:00, Pavel Tupitsyn <[hidden email]>:

> 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 <[hidden email]> wrote:
>
>> 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 <[hidden email]>:
>> > 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 <[hidden email]>:
>> >> 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 even introduce some kind of switch — so that we can test old and
>> >> new
>> >> build approaches and provide seamless transition if we agree on that.
>> >>
>> >>> On 19 Dec 2020, at 01:00, Valentin Kulichenko
>> >>> <[hidden email]> wrote:
>> >>>
>> >>> 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
>> >>> debatable at this point -- please feel free to share your thoughts on
>> >>> this.
>> >>>
>> >>> -Val
>> >>>
>> >>> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin <[hidden email]>
>> >>> wrote:
>> >>>
>> >>>> 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 Kulichenko <
>> >>>> [hidden email]>:
>> >>>>> 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 where
>> we
>> >>>> can
>> >>>>> merge the code for 3.x. Thus, I've created this new repo. We
>> >>>>> already
>> >>>>> have
>> >>>>> multiple IEPs, as well as several contributors who are actively
>> >>>>> involved
>> >>>> in
>> >>>>> development. Some of the first PRs were merged today.
>> >>>>>
>> >>>>> I didn't hear any objections since the repo was created.
>> >>>>>
>> >>>>> -Val
>> >>>>>
>> >>>>> On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov <[hidden email]>
>> >>>> wrote:
>> >>>>>
>> >>>>>> 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
>> >>>>>> <[hidden email]
>> >>>>> :
>> >>>>>>
>> >>>>>>> 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: [phone]
>> >>>>>>> www.bottomline.com
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <
>> [hidden email]>
>> >>>>>>> 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 <
>> >>>>>>> [hidden email]>:
>> >>>>>>>
>> >>>>>>>> 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: [phone]
>> >>>>>>>> www.bottomline.com
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On 11/24/20, 7:38 AM, "Alexey Zinoviev" <[hidden email]
>> >>>>>
>> >>>>>>> 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 <
>> >>>>>>>> [hidden email]>:
>> >>>>>>>>
>> >>>>>>>>> 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 <
>> >>>>>>>>> [hidden email]> 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 <
>> >>>>>>>>>> [hidden email]> 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 <
>> >>>>>>>>>>> [hidden email]> 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
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>> Best regards,
>> >>>> Ivan Pavlukhin
>> >>>>
>> >>
>> >>
>> >
>> >
>> > --
>> >
>> > Best regards,
>> > Ivan Pavlukhin
>> >
>>
>>
>> --
>>
>> Best regards,
>> Ivan Pavlukhin
>>
>

--

Best regards,
Ivan Pavlukhin