Re: A new feedback has been added : 10

[Nikita Safonov]

Hi Ilya!

Currently we respond to users via the Bugyard.io reply form, which does not
support putting others on CC.
Nevertheless all the conversations are saved in Bugyard and can be reached
by all the Igniters.

Regarding our previous discussion:

As I mentioned before, I'm taking the first shift of maintaining the doc
feedback.
But since I'm not a committer, I cannot merge the changes and port them to
the latest branch (and, as a result, to have them deployed on the website).
For instance, several issues (#4
, #5
, #6
) were resolved a quiet
time ago, but they haven't been ported to the latest Ignite branch yet.

So can I kindly ask you to help me with this during the shift?

With best regards,
Nikita







чт, 23 сент. 2021 г. в 11:21, Ilya Kasnacheev :

> Hello!
>
> If we reply to users with emails, I suggest putting dev@ on CC.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 23 сент. 2021 г. в 03:54, Nikita Safonov :
>
> > Hi Ilya!
> >
> > That’s a good point. I’d like to highlight that Ignite Doc Feedback
> service
> > credentials are stored here
> >  >,
> > so anyone can see the user’s feedback on bugyard.io. As for now, only me
> > and Igor Gusev are managing this.
> > But I do believe that 3 months (or any other period) shifts can be
> useful,
> > as well as periodic reports.
> >
> > By the way, we do reply to the users’ feedback with emails. What is more,
> > the work on the feedback can be tracked via Apache Ignite Jira tickets.
> > Every doc feedback ticket’s title starts with «Bugyard feedback #...».
> >
> > I guess that I’m ready to take this role and to discuss the volunteers
> for
> > the upcoming shifts later.
> >
> > With best regards,
> > Nikita
> >
> > вт, 21 сент. 2021 г. в 21:56, Ilya Kasnacheev  >:
> >
> > > Hello!
> > >
> > > Dear developers, I suggest we should have someone responsible for
> > handling
> > > bugyard reports and writing about that on developers list.
> > >
> > > Feedback is hidden behind login and I have no idea what's there, much
> > less
> > > if it was fixed.
> > >
> > > I think we should have a reply to every Bugyard e-mail and maybe
> > > three-month long shifts of people responsible for that. Anybody wishing
> > to
> > > take this role?
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 20 сент. 2021 г. в 17:10, Bugyard :
> > >
> > > > A new feedback has been added, go to bugyard.io to see all the
> > > details...
> > > >
> > > > https://bugyard.io
> > > >
> > > > A new feedback has been added
> > > >
> > > > "Looks like  [Running Ignite with Java 11 or later] link is broken."
> >  by
> > > > tim239
> > > >
> > > > View feedback
> > > > https://app.bugyard.io/web/app/rycqZJDyY/f/61488444507c91001448c81c
> > >
> >
>

Re: Running TCBot across a PR

[Raymond Wilson]

Hi Pavel,

Thanks for the direction.

I created the account and have run the TCBot build and added the comment to
the Jira ticket.

There seem to be a lot of failing tests, though I suspect they are mostly
flapping/unstable tests rather than failures due to the change in the PR,
but the TCBot build has flagged four possible blockers. I'm not sure how to
evaluate those in the context of the change...

I have also noted you as a reviewer.

Thanks,
Raymond.


On Wed, Sep 29, 2021 at 7:35 PM Pavel Tupitsyn  wrote:

> Hi Raymond,
>
> 1. Please register an account on TeamCity (ci.ignite.apache.org), you'll
> be
> able to start builds right away.
> 2. Login with the same credentials to https://mtcga.gridgain.com/prs.html
> and schedule a build for your PR.
>
> See
>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot
> for more info.
>
> > I'm also not sure who to suggest for review in the Java K8s area.
> I can do the review once the tests pass.
>
> Thanks,
> Pavel
>
> On Wed, Sep 29, 2021 at 12:47 AM Raymond Wilson <
> raymond_wil...@trimble.com>
> wrote:
>
> > Hi,
> >
> > I have created and actioned a Jira ticket (
> > https://issues.apache.org/jira/browse/IGNITE-15602), and have a PR
> raised
> > from my fork to the main repo.
> >
> > I think I have checked all the boxes except for verifying TCBot is happy
> > (per instruction below)
> >
> >  - [ ] The pull request has been checked by the Teamcity Bot and
> >the `green visa` attached to the JIRA ticket (see [TC.Bot: Check PR](
> > https://mtcga.gridgain.com/prs.html))
> >
> > However, I don't (think I have) access to TeamCity, so I'm not sure how
> to
> > complete that step.
> >
> > I'm also not sure who to suggest for review in the Java K8s area.
> >
> > Thanks,
> > Raymond.
> >
> > --
> > 
> > Raymond Wilson
> > Trimble Distinguished Engineer, Civil Construction Software (CCS)
> > 11 Birmingham Drive | Christchurch, New Zealand
> > raymond_wil...@trimble.com
> >
> > <
> >
> https://worksos.trimble.com/?utm_source=Trimble_medium=emailsign_campaign=Launch
> > >
> >
>


-- 

Raymond Wilson
Trimble Distinguished Engineer, Civil Construction Software (CCS)
11 Birmingham Drive | Christchurch, New Zealand
raymond_wil...@trimble.com

A new feedback has been added : 17

[Bugyard]

A new feedback has been added, go to bugyard.io to see all the details...

https://bugyard.io

A new feedback has been added 

"https://ignite.apache.org/docs/latest/SQL/sql-api#inserting-updating-deleting-and-merging

why there are no .net instance?"   by fatihcandan52 

View feedback 
https://app.bugyard.io/web/app/rycqZJDyY/f/61545d20f3e99e001443d31e

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

I am watching how Apache Ignite does evolve for over a 3 years already and see 
that such hidden (almost no Open Source Community points could be achieved for 
refactoring and addressing something that is not directly project's source 
executable code) issues drown under constant pressure of new features and 
releases.

I have never created issues for Maven build refactoring (for instanced) because 
I understand that 1) it is almost impossible for current tech debt already 
accumulated and 2) to won't be welcomed by community because of indirect 
relationship to main project's goals.
Considering other parts, please, note [1], [2], [3], [4], [5], [6], [7], [8] 
and many many more issues that have no separate ticket.

My point — such technical debt is overwhelming and will be never ever 
approached.
That is one of the reasons why Ignite 3 being built from scratch, having in 
mind all mistakes we've already made and lots of errors we will never do just 
because there would be no legacy basic for that.



[1] https://issues.apache.org/jira/browse/IGNITE-7190
[2] https://issues.apache.org/jira/browse/IGNITE-7326
[3] https://issues.apache.org/jira/browse/IGNITE-7672
[4] https://issues.apache.org/jira/browse/IGNITE-8496
[5] https://issues.apache.org/jira/browse/IGNITE-9866
[6] https://issues.apache.org/jira/browse/IGNITE-10600
[7] https://issues.apache.org/jira/browse/IGNITE-10683
[8] https://issues.apache.org/jira/browse/IGNITE-10696





> On 29 Sep 2021, at 14:14, Nikolay Izhikov  wrote:
> 
>> — issues related to Maven build? possible Gradle upgrade?
> 
> I’m not aware of the issues.
> Can you, please, send a tickets or description of existing issues?
> Anyway, it seems change of build tool can be done at any time we want
> 
>> — issues related to run scripts?
>> — issues related to release and delivery processes and scripts?
> 
> I’m not aware of those too.
> Can you point to then, please?
> 
>> Are they going to be addressed during Apache Ignite evolution too?
> 
> Yes, from my point of view.
> 
>> 29 сент. 2021 г., в 14:03, Petr Ivanov  написал(а):
>> 
>> And what about:
>> — issues related to Maven build? possible Gradle upgrade?
>> — issues related to run scripts?
>> — issues related to release and delivery processes and scripts?
>> 
>> Are they going to be addressed during Apache Ignite evolution too?
>> 
>>> On 29 Sep 2021, at 13:47, Nikolay Izhikov  wrote:
>>> 
 Does you vision of evolutionary improvement involve technical debt 
 addressing
>>> 
>>> Yes, of course.
>>> 
>>> My vision was the following (from the bird eye):
>>> 
>>> - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User 
>>> API doesn’t change).
>>> - 2.30 - replace static XML configuration with the new dynamic approach.
>>> - 2.40 - replace H2 SQL engine with the Calcite
>>> 
>>> etc. 
>>> 
>>> Versions depends on feature readiness.
>>> 
>>> Anyway, I step back with the initial Ignite3 development, because, don’t 
>>> want to interfere the progress.
>>> 
>>> Respect to the developers who have courage to develop such complex things 
>>> from scratch.
>>> 
 29 сент. 2021 г., в 12:55, Petr Ivanov  написал(а):
 
 
> I believe that we should improve Ignite evolutionary and not 
> revolutionary.
> First of all, change user API with the slow improvements step by step.
 
 Nikolay,
 
 Does you vision of evolutionary improvement involve technical debt 
 addressing?
 
 
> 
> 
>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev  
>> написал(а):
>> 
>> Hello!
>> 
>> If we go the second route, we can call the field "Generation".
>> 
>> Generation: Ignite 2.x
>> Generation: Ignite 3
>> 
>> (no new tickets should ever be filed for Ignite 1.x but if they are, they
>> should go to the first Generation)
>> 
>> Regards.
>> -- 
>> Ilya Kasnacheev
>> 
>> 
>> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>> 
>>> As for the original topic, we need to come to a solution. Let me 
>>> summarize
>>> what we've discussed so far.
>>> 
>>> -PROBLEM-
>>> 
>>> Ignite 3 is the next major version of Apache Ignite. It targets the same
>>> use cases and provides a similar set of features as Ignite 2. At the 
>>> same
>>> time, Ignite 2 and Ignite 3 are *technically* separate projects. They 
>>> are
>>> developed in different repositories (and therefore are based on 
>>> different
>>> codebases) and implement different internal architectures. To achieve a
>>> more efficient development process, we need to create a clear separation
>>> between 2.x and 3.x within *development resources* (Jira and 
>>> Confluence).
>>> 
>>> -POSSIBLE SOLUTIONS-
>>> 
>>> 1. Create a separate Jira project and Confluence space for Ignite 3
>>> (initial suggestion).
>>> 2. Add a *mandatory* field in 

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Nikolay Izhikov]

> — issues related to Maven build? possible Gradle upgrade?

I’m not aware of the issues.
Can you, please, send a tickets or description of existing issues?
Anyway, it seems change of build tool can be done at any time we want

> — issues related to run scripts?
> — issues related to release and delivery processes and scripts?

I’m not aware of those too.
Can you point to then, please?

> Are they going to be addressed during Apache Ignite evolution too?

Yes, from my point of view.

> 29 сент. 2021 г., в 14:03, Petr Ivanov  написал(а):
> 
> And what about:
> — issues related to Maven build? possible Gradle upgrade?
> — issues related to run scripts?
> — issues related to release and delivery processes and scripts?
> 
> Are they going to be addressed during Apache Ignite evolution too?
> 
>> On 29 Sep 2021, at 13:47, Nikolay Izhikov  wrote:
>> 
>>> Does you vision of evolutionary improvement involve technical debt 
>>> addressing
>> 
>> Yes, of course.
>> 
>> My vision was the following (from the bird eye):
>> 
>> - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User 
>> API doesn’t change).
>> - 2.30 - replace static XML configuration with the new dynamic approach.
>> - 2.40 - replace H2 SQL engine with the Calcite
>> 
>> etc. 
>> 
>> Versions depends on feature readiness.
>> 
>> Anyway, I step back with the initial Ignite3 development, because, don’t 
>> want to interfere the progress.
>> 
>> Respect to the developers who have courage to develop such complex things 
>> from scratch.
>> 
>>> 29 сент. 2021 г., в 12:55, Petr Ivanov  написал(а):
>>> 
>>> 
 I believe that we should improve Ignite evolutionary and not revolutionary.
 First of all, change user API with the slow improvements step by step.
>>> 
>>> Nikolay,
>>> 
>>> Does you vision of evolutionary improvement involve technical debt 
>>> addressing?
>>> 
>>> 
 
 
> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev  
> написал(а):
> 
> Hello!
> 
> If we go the second route, we can call the field "Generation".
> 
> Generation: Ignite 2.x
> Generation: Ignite 3
> 
> (no new tickets should ever be filed for Ignite 1.x but if they are, they
> should go to the first Generation)
> 
> Regards.
> -- 
> Ilya Kasnacheev
> 
> 
> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
> 
>> As for the original topic, we need to come to a solution. Let me 
>> summarize
>> what we've discussed so far.
>> 
>> -PROBLEM-
>> 
>> Ignite 3 is the next major version of Apache Ignite. It targets the same
>> use cases and provides a similar set of features as Ignite 2. At the same
>> time, Ignite 2 and Ignite 3 are *technically* separate projects. They are
>> developed in different repositories (and therefore are based on different
>> codebases) and implement different internal architectures. To achieve a
>> more efficient development process, we need to create a clear separation
>> between 2.x and 3.x within *development resources* (Jira and Confluence).
>> 
>> -POSSIBLE SOLUTIONS-
>> 
>> 1. Create a separate Jira project and Confluence space for Ignite 3
>> (initial suggestion).
>> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs 
>> to
>> 2.x or 3.x.
>> 
>> If we go with #2, there are still several things to figure out:
>> 
>> - What is the name of this field? It needs to be intuitive to anyone who
>> joins the community.
>> - We need to make sure that Ignite 3 tickets are not mapped to 2.x
>> versions, and vice versa. Can we restrict this in Jira? Or we will have
>> to
>> monitor this manually?
>> - What do we do with Confluence?
>> 
>> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if 
>> you
>> still prefer the second option, could you please address the points 
>> above?
>> I don't think it can be treated as an actual suggestion until we cover
>> these details.
>> 
>> Let's discuss this until the end of the week. If there is no clear 
>> picture
>> on option #2 by then, I suggest we go with #1.
>> 
>> -Val
>> 
>> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>> 
>>> Folks,
>>> 
>>> Versioning is a separate topic. We agreed on the current scheme in March
>>> [1]. If someone thinks we need to change it, please create a new thread
>> and
>>> present your suggestions.
>>> 
>>> [1]
>>> 
>> https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E
>>> 
>>> -Val
>>> 
>>> On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov 
>> wrote:
>>> 
 Seems rational.
 
 
 But still 2.11.0 and 21.1.0 for 

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

And what about:
 — issues related to Maven build? possible Gradle upgrade?
 — issues related to run scripts?
 — issues related to release and delivery processes and scripts?

Are they going to be addressed during Apache Ignite evolution too?

> On 29 Sep 2021, at 13:47, Nikolay Izhikov  wrote:
> 
>> Does you vision of evolutionary improvement involve technical debt addressing
> 
> Yes, of course.
> 
> My vision was the following (from the bird eye):
> 
> - 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User 
> API doesn’t change).
> - 2.30 - replace static XML configuration with the new dynamic approach.
> - 2.40 - replace H2 SQL engine with the Calcite
> 
> etc. 
> 
> Versions depends on feature readiness.
> 
> Anyway, I step back with the initial Ignite3 development, because, don’t want 
> to interfere the progress.
> 
> Respect to the developers who have courage to develop such complex things 
> from scratch.
> 
>> 29 сент. 2021 г., в 12:55, Petr Ivanov  написал(а):
>> 
>> 
>>> I believe that we should improve Ignite evolutionary and not revolutionary.
>>> First of all, change user API with the slow improvements step by step.
>> 
>> Nikolay,
>> 
>> Does you vision of evolutionary improvement involve technical debt 
>> addressing?
>> 
>> 
>>> 
>>> 
 29 сент. 2021 г., в 11:43, Ilya Kasnacheev  
 написал(а):
 
 Hello!
 
 If we go the second route, we can call the field "Generation".
 
 Generation: Ignite 2.x
 Generation: Ignite 3
 
 (no new tickets should ever be filed for Ignite 1.x but if they are, they
 should go to the first Generation)
 
 Regards.
 -- 
 Ilya Kasnacheev
 
 
 ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko <
 valentin.kuliche...@gmail.com>:
 
> As for the original topic, we need to come to a solution. Let me summarize
> what we've discussed so far.
> 
> -PROBLEM-
> 
> Ignite 3 is the next major version of Apache Ignite. It targets the same
> use cases and provides a similar set of features as Ignite 2. At the same
> time, Ignite 2 and Ignite 3 are *technically* separate projects. They are
> developed in different repositories (and therefore are based on different
> codebases) and implement different internal architectures. To achieve a
> more efficient development process, we need to create a clear separation
> between 2.x and 3.x within *development resources* (Jira and Confluence).
> 
> -POSSIBLE SOLUTIONS-
> 
> 1. Create a separate Jira project and Confluence space for Ignite 3
> (initial suggestion).
> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to
> 2.x or 3.x.
> 
> If we go with #2, there are still several things to figure out:
> 
> - What is the name of this field? It needs to be intuitive to anyone who
> joins the community.
> - We need to make sure that Ignite 3 tickets are not mapped to 2.x
> versions, and vice versa. Can we restrict this in Jira? Or we will have
> to
> monitor this manually?
> - What do we do with Confluence?
> 
> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if 
> you
> still prefer the second option, could you please address the points above?
> I don't think it can be treated as an actual suggestion until we cover
> these details.
> 
> Let's discuss this until the end of the week. If there is no clear picture
> on option #2 by then, I suggest we go with #1.
> 
> -Val
> 
> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> 
>> Folks,
>> 
>> Versioning is a separate topic. We agreed on the current scheme in March
>> [1]. If someone thinks we need to change it, please create a new thread
> and
>> present your suggestions.
>> 
>> [1]
>> 
> https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E
>> 
>> -Val
>> 
>> On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov 
> wrote:
>> 
>>> Seems rational.
>>> 
>>> 
>>> But still 2.11.0 and 21.1.0 for the time being will look like similar or
>>> error in either version...
>>> 
>>> 
 On 27 Sep 2021, at 18:11, Ivan Pavlukhin  wrote:
 
 I mean that Ignite 2.x will continue to use old scheme and Ignite 3
 will be e.g. Ignite 21.1 and so on.
 
 2021-09-27 14:57 GMT+03:00, Petr Ivanov :
> How will not they clash if version is based only on date?
> 
>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin 
> wrote:
>> 
>> Today it is quite common to use calendar-based versioning scheme,
> e.g.
>> [1]. We can consider it for Ignite 3. Luckily versions will not
> clash.
>> 
>> [1] 

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Nikolay Izhikov]

> Does you vision of evolutionary improvement involve technical debt addressing

Yes, of course.

My vision was the following (from the bird eye):

- 2.20 - removals of LOCAL caches, MVCC and other abandoned features. (User API 
doesn’t change).
- 2.30 - replace static XML configuration with the new dynamic approach.
- 2.40 - replace H2 SQL engine with the Calcite

etc. 

Versions depends on feature readiness.

Anyway, I step back with the initial Ignite3 development, because, don’t want 
to interfere the progress.

Respect to the developers who have courage to develop such complex things from 
scratch.

> 29 сент. 2021 г., в 12:55, Petr Ivanov  написал(а):
> 
> 
>> I believe that we should improve Ignite evolutionary and not revolutionary.
>> First of all, change user API with the slow improvements step by step.
> 
> Nikolay,
> 
> Does you vision of evolutionary improvement involve technical debt addressing?
> 
> 
>> 
>> 
>>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev  
>>> написал(а):
>>> 
>>> Hello!
>>> 
>>> If we go the second route, we can call the field "Generation".
>>> 
>>> Generation: Ignite 2.x
>>> Generation: Ignite 3
>>> 
>>> (no new tickets should ever be filed for Ignite 1.x but if they are, they
>>> should go to the first Generation)
>>> 
>>> Regards.
>>> -- 
>>> Ilya Kasnacheev
>>> 
>>> 
>>> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com>:
>>> 
 As for the original topic, we need to come to a solution. Let me summarize
 what we've discussed so far.
 
 -PROBLEM-
 
 Ignite 3 is the next major version of Apache Ignite. It targets the same
 use cases and provides a similar set of features as Ignite 2. At the same
 time, Ignite 2 and Ignite 3 are *technically* separate projects. They are
 developed in different repositories (and therefore are based on different
 codebases) and implement different internal architectures. To achieve a
 more efficient development process, we need to create a clear separation
 between 2.x and 3.x within *development resources* (Jira and Confluence).
 
 -POSSIBLE SOLUTIONS-
 
 1. Create a separate Jira project and Confluence space for Ignite 3
 (initial suggestion).
 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to
 2.x or 3.x.
 
 If we go with #2, there are still several things to figure out:
 
 - What is the name of this field? It needs to be intuitive to anyone who
 joins the community.
 - We need to make sure that Ignite 3 tickets are not mapped to 2.x
 versions, and vice versa. Can we restrict this in Jira? Or we will have
 to
 monitor this manually?
 - What do we do with Confluence?
 
 Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if you
 still prefer the second option, could you please address the points above?
 I don't think it can be treated as an actual suggestion until we cover
 these details.
 
 Let's discuss this until the end of the week. If there is no clear picture
 on option #2 by then, I suggest we go with #1.
 
 -Val
 
 On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko <
 valentin.kuliche...@gmail.com> wrote:
 
> Folks,
> 
> Versioning is a separate topic. We agreed on the current scheme in March
> [1]. If someone thinks we need to change it, please create a new thread
 and
> present your suggestions.
> 
> [1]
> 
 https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E
> 
> -Val
> 
> On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov 
 wrote:
> 
>> Seems rational.
>> 
>> 
>> But still 2.11.0 and 21.1.0 for the time being will look like similar or
>> error in either version...
>> 
>> 
>>> On 27 Sep 2021, at 18:11, Ivan Pavlukhin  wrote:
>>> 
>>> I mean that Ignite 2.x will continue to use old scheme and Ignite 3
>>> will be e.g. Ignite 21.1 and so on.
>>> 
>>> 2021-09-27 14:57 GMT+03:00, Petr Ivanov :
 How will not they clash if version is based only on date?
 
> On 27 Sep 2021, at 14:33, Ivan Pavlukhin 
 wrote:
> 
> Today it is quite common to use calendar-based versioning scheme,
 e.g.
> [1]. We can consider it for Ignite 3. Luckily versions will not
 clash.
> 
> [1] https://www.cockroachlabs.com/docs/releases/index.html
> 
> 2021-09-27 10:49 GMT+03:00, Petr Ivanov :
>> That name will definitely confuse Jira users.
>> 
>> Let's stick to basic devision by 2.x and 3.x — it seems most
>> intuitive
>> and
>> has lots of examples inside ASF, look at the Tomcat for instance.
>> 
>>> On 25 Sep 2021, at 21:05, Saikat Maitra 
>>> wrote:
>>> 
>>> Hi,

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Petr Ivanov]

> I believe that we should improve Ignite evolutionary and not revolutionary.
> First of all, change user API with the slow improvements step by step.

Nikolay,

Does you vision of evolutionary improvement involve technical debt addressing?


> 
> 
>> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev  
>> написал(а):
>> 
>> Hello!
>> 
>> If we go the second route, we can call the field "Generation".
>> 
>> Generation: Ignite 2.x
>> Generation: Ignite 3
>> 
>> (no new tickets should ever be filed for Ignite 1.x but if they are, they
>> should go to the first Generation)
>> 
>> Regards.
>> -- 
>> Ilya Kasnacheev
>> 
>> 
>> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>> 
>>> As for the original topic, we need to come to a solution. Let me summarize
>>> what we've discussed so far.
>>> 
>>> -PROBLEM-
>>> 
>>> Ignite 3 is the next major version of Apache Ignite. It targets the same
>>> use cases and provides a similar set of features as Ignite 2. At the same
>>> time, Ignite 2 and Ignite 3 are *technically* separate projects. They are
>>> developed in different repositories (and therefore are based on different
>>> codebases) and implement different internal architectures. To achieve a
>>> more efficient development process, we need to create a clear separation
>>> between 2.x and 3.x within *development resources* (Jira and Confluence).
>>> 
>>> -POSSIBLE SOLUTIONS-
>>> 
>>> 1. Create a separate Jira project and Confluence space for Ignite 3
>>> (initial suggestion).
>>> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to
>>> 2.x or 3.x.
>>> 
>>> If we go with #2, there are still several things to figure out:
>>> 
>>>  - What is the name of this field? It needs to be intuitive to anyone who
>>>  joins the community.
>>>  - We need to make sure that Ignite 3 tickets are not mapped to 2.x
>>>  versions, and vice versa. Can we restrict this in Jira? Or we will have
>>> to
>>>  monitor this manually?
>>>  - What do we do with Confluence?
>>> 
>>> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if you
>>> still prefer the second option, could you please address the points above?
>>> I don't think it can be treated as an actual suggestion until we cover
>>> these details.
>>> 
>>> Let's discuss this until the end of the week. If there is no clear picture
>>> on option #2 by then, I suggest we go with #1.
>>> 
>>> -Val
>>> 
>>> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>> 
 Folks,
 
 Versioning is a separate topic. We agreed on the current scheme in March
 [1]. If someone thinks we need to change it, please create a new thread
>>> and
 present your suggestions.
 
 [1]
 
>>> https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E
 
 -Val
 
 On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov 
>>> wrote:
 
> Seems rational.
> 
> 
> But still 2.11.0 and 21.1.0 for the time being will look like similar or
> error in either version...
> 
> 
>> On 27 Sep 2021, at 18:11, Ivan Pavlukhin  wrote:
>> 
>> I mean that Ignite 2.x will continue to use old scheme and Ignite 3
>> will be e.g. Ignite 21.1 and so on.
>> 
>> 2021-09-27 14:57 GMT+03:00, Petr Ivanov :
>>> How will not they clash if version is based only on date?
>>> 
 On 27 Sep 2021, at 14:33, Ivan Pavlukhin 
>>> wrote:
 
 Today it is quite common to use calendar-based versioning scheme,
>>> e.g.
 [1]. We can consider it for Ignite 3. Luckily versions will not
>>> clash.
 
 [1] https://www.cockroachlabs.com/docs/releases/index.html
 
 2021-09-27 10:49 GMT+03:00, Petr Ivanov :
> That name will definitely confuse Jira users.
> 
> Let's stick to basic devision by 2.x and 3.x — it seems most
> intuitive
> and
> has lots of examples inside ASF, look at the Tomcat for instance.
> 
>> On 25 Sep 2021, at 21:05, Saikat Maitra 
>> wrote:
>> 
>> Hi,
>> 
>> I like the major version update like Ignite 3.0 but if we were to
> come
>> up
>> with a name my other suggestion would be
>> 
>> Ignite-kernel
>> 
>> kernel - for the central or most important part of something
>> 
>> Also taken references from Compute kernel - a routine compiled for
> high
>> throughput accelerators
>> 
>> https://en.wikipedia.org/wiki/Compute_kernel
>> 
>> Regards,
>> Saikat
>> 
>> 
>> On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>> 
>>> Kafka and Spark didn't split codebases (at least to my
>>> knowledge).
>>> Separating 

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Nikolay Izhikov]

Hello, Valentin.

> Nikolay, Ilya, Denis, and others who opposed the initial suggestion

It seems I don’t write my point clear.
I’m +1 to have another jira project for Ignite3.

My point is - Ignite3 is not Ignite - it just another database engine.

> Ignite 2 and Ignite 3 are *technically* separate projects

You definition of «technically» is unclear for me.

> It targets the same use cases and provides a similar set of features as 
> Ignite 2

I don’t believe it’s true.

I believe that we should improve Ignite evolutionary and not revolutionary.
First of all, change user API with the slow improvements step by step.

Kafka3, you mentioned, AFAIK doesn’t change user API at all, except removing 
deprecated methods. [1]

[1] 
https://www.confluent.io/blog/apache-kafka-3-0-major-improvements-and-new-features/

> 29 сент. 2021 г., в 11:43, Ilya Kasnacheev  
> написал(а):
> 
> Hello!
> 
> If we go the second route, we can call the field "Generation".
> 
> Generation: Ignite 2.x
> Generation: Ignite 3
> 
> (no new tickets should ever be filed for Ignite 1.x but if they are, they
> should go to the first Generation)
> 
> Regards.
> -- 
> Ilya Kasnacheev
> 
> 
> ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
> 
>> As for the original topic, we need to come to a solution. Let me summarize
>> what we've discussed so far.
>> 
>> -PROBLEM-
>> 
>> Ignite 3 is the next major version of Apache Ignite. It targets the same
>> use cases and provides a similar set of features as Ignite 2. At the same
>> time, Ignite 2 and Ignite 3 are *technically* separate projects. They are
>> developed in different repositories (and therefore are based on different
>> codebases) and implement different internal architectures. To achieve a
>> more efficient development process, we need to create a clear separation
>> between 2.x and 3.x within *development resources* (Jira and Confluence).
>> 
>> -POSSIBLE SOLUTIONS-
>> 
>> 1. Create a separate Jira project and Confluence space for Ignite 3
>> (initial suggestion).
>> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to
>> 2.x or 3.x.
>> 
>> If we go with #2, there are still several things to figure out:
>> 
>>   - What is the name of this field? It needs to be intuitive to anyone who
>>   joins the community.
>>   - We need to make sure that Ignite 3 tickets are not mapped to 2.x
>>   versions, and vice versa. Can we restrict this in Jira? Or we will have
>> to
>>   monitor this manually?
>>   - What do we do with Confluence?
>> 
>> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if you
>> still prefer the second option, could you please address the points above?
>> I don't think it can be treated as an actual suggestion until we cover
>> these details.
>> 
>> Let's discuss this until the end of the week. If there is no clear picture
>> on option #2 by then, I suggest we go with #1.
>> 
>> -Val
>> 
>> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>> 
>>> Folks,
>>> 
>>> Versioning is a separate topic. We agreed on the current scheme in March
>>> [1]. If someone thinks we need to change it, please create a new thread
>> and
>>> present your suggestions.
>>> 
>>> [1]
>>> 
>> https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E
>>> 
>>> -Val
>>> 
>>> On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov 
>> wrote:
>>> 
 Seems rational.
 
 
 But still 2.11.0 and 21.1.0 for the time being will look like similar or
 error in either version...
 
 
> On 27 Sep 2021, at 18:11, Ivan Pavlukhin  wrote:
> 
> I mean that Ignite 2.x will continue to use old scheme and Ignite 3
> will be e.g. Ignite 21.1 and so on.
> 
> 2021-09-27 14:57 GMT+03:00, Petr Ivanov :
>> How will not they clash if version is based only on date?
>> 
>>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin 
>> wrote:
>>> 
>>> Today it is quite common to use calendar-based versioning scheme,
>> e.g.
>>> [1]. We can consider it for Ignite 3. Luckily versions will not
>> clash.
>>> 
>>> [1] https://www.cockroachlabs.com/docs/releases/index.html
>>> 
>>> 2021-09-27 10:49 GMT+03:00, Petr Ivanov :
 That name will definitely confuse Jira users.
 
 Let's stick to basic devision by 2.x and 3.x — it seems most
 intuitive
 and
 has lots of examples inside ASF, look at the Tomcat for instance.
 
> On 25 Sep 2021, at 21:05, Saikat Maitra 
> wrote:
> 
> Hi,
> 
> I like the major version update like Ignite 3.0 but if we were to
 come
> up
> with a name my other suggestion would be
> 
> Ignite-kernel
> 
> kernel - for the central or most important part of something
> 
> Also taken references from Compute 

Re: [DISCUSSION] Separate Jira project and Confluence space for Ignite 3

[Ilya Kasnacheev]

Hello!

If we go the second route, we can call the field "Generation".

Generation: Ignite 2.x
Generation: Ignite 3

(no new tickets should ever be filed for Ignite 1.x but if they are, they
should go to the first Generation)

Regards.
-- 
Ilya Kasnacheev


ср, 29 сент. 2021 г. в 00:33, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> As for the original topic, we need to come to a solution. Let me summarize
> what we've discussed so far.
>
> -PROBLEM-
>
> Ignite 3 is the next major version of Apache Ignite. It targets the same
> use cases and provides a similar set of features as Ignite 2. At the same
> time, Ignite 2 and Ignite 3 are *technically* separate projects. They are
> developed in different repositories (and therefore are based on different
> codebases) and implement different internal architectures. To achieve a
> more efficient development process, we need to create a clear separation
> between 2.x and 3.x within *development resources* (Jira and Confluence).
>
> -POSSIBLE SOLUTIONS-
>
> 1. Create a separate Jira project and Confluence space for Ignite 3
> (initial suggestion).
> 2. Add a *mandatory* field in Jira to identify whether a ticket belongs to
> 2.x or 3.x.
>
> If we go with #2, there are still several things to figure out:
>
>- What is the name of this field? It needs to be intuitive to anyone who
>joins the community.
>- We need to make sure that Ignite 3 tickets are not mapped to 2.x
>versions, and vice versa. Can we restrict this in Jira? Or we will have
> to
>monitor this manually?
>- What do we do with Confluence?
>
> Nikolay, Ilya, Denis, and others who opposed the initial suggestion: if you
> still prefer the second option, could you please address the points above?
> I don't think it can be treated as an actual suggestion until we cover
> these details.
>
> Let's discuss this until the end of the week. If there is no clear picture
> on option #2 by then, I suggest we go with #1.
>
> -Val
>
> On Tue, Sep 28, 2021 at 11:22 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Folks,
> >
> > Versioning is a separate topic. We agreed on the current scheme in March
> > [1]. If someone thinks we need to change it, please create a new thread
> and
> > present your suggestions.
> >
> > [1]
> >
> https://lists.apache.org/thread.html/r17ebaad35ca2bd70e716e67683ae7fec9bd97372b6cc57a7e9c81f9d%40%3Cdev.ignite.apache.org%3E
> >
> > -Val
> >
> > On Tue, Sep 28, 2021 at 12:37 PM Petr Ivanov 
> wrote:
> >
> >> Seems rational.
> >>
> >>
> >> But still 2.11.0 and 21.1.0 for the time being will look like similar or
> >> error in either version...
> >>
> >>
> >> > On 27 Sep 2021, at 18:11, Ivan Pavlukhin  wrote:
> >> >
> >> > I mean that Ignite 2.x will continue to use old scheme and Ignite 3
> >> > will be e.g. Ignite 21.1 and so on.
> >> >
> >> > 2021-09-27 14:57 GMT+03:00, Petr Ivanov :
> >> >> How will not they clash if version is based only on date?
> >> >>
> >> >>> On 27 Sep 2021, at 14:33, Ivan Pavlukhin 
> wrote:
> >> >>>
> >> >>> Today it is quite common to use calendar-based versioning scheme,
> e.g.
> >> >>> [1]. We can consider it for Ignite 3. Luckily versions will not
> clash.
> >> >>>
> >> >>> [1] https://www.cockroachlabs.com/docs/releases/index.html
> >> >>>
> >> >>> 2021-09-27 10:49 GMT+03:00, Petr Ivanov :
> >>  That name will definitely confuse Jira users.
> >> 
> >>  Let's stick to basic devision by 2.x and 3.x — it seems most
> >> intuitive
> >>  and
> >>  has lots of examples inside ASF, look at the Tomcat for instance.
> >> 
> >> > On 25 Sep 2021, at 21:05, Saikat Maitra 
> >> > wrote:
> >> >
> >> > Hi,
> >> >
> >> > I like the major version update like Ignite 3.0 but if we were to
> >> come
> >> > up
> >> > with a name my other suggestion would be
> >> >
> >> > Ignite-kernel
> >> >
> >> > kernel - for the central or most important part of something
> >> >
> >> > Also taken references from Compute kernel - a routine compiled for
> >> high
> >> > throughput accelerators
> >> >
> >> > https://en.wikipedia.org/wiki/Compute_kernel
> >> >
> >> > Regards,
> >> > Saikat
> >> >
> >> >
> >> > On Sat, Sep 25, 2021 at 3:12 AM Valentin Kulichenko <
> >> > valentin.kuliche...@gmail.com> wrote:
> >> >
> >> >> Kafka and Spark didn't split codebases (at least to my
> knowledge).
> >> >> Separating codebases was the fundamental step, everything else
> is a
> >> >> technicality.
> >> >>
> >> >> Having said that, I will be OK with your suggestion as I don't
> >> really
> >> >> see
> >> >> a
> >> >> difference, although I'm not sure we will be able to come up
> with a
> >> >> name
> >> >> that is more intuitive than a separate project :)
> >> >>
> >> >> Let's see what others think.
> >> >>
> >> >> -Val
> >> >>
> >> >> On Sat, Sep 25, 2021 at 12:23 AM Denis 

Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]

[Ivan Daschinsky]

Created issues related building ODBC module, running C++ suites and
removing VS project files

1. https://issues.apache.org/jira/browse/IGNITE-15637
2.https://issues.apache.org/jira/browse/IGNITE-15636

вс, 26 сент. 2021 г. в 19:50, Ivan Daschinsky :

> +1
>
> Let's consider building odbc driver using Visual C++ 2017?
>
> 2015, 2017 and 2019 share the same redistributable package and it is the
> default one in Windows 10.
>
> Also, let's remove vs project files, since the most of you all agree that
> it is redundant.
>
> If both suggestions are ok, I will create ticketa soon.
>
> вс, 26 сент. 2021 г., 17:10 Pavel Tupitsyn :
>
>> +1
>>
>> On Fri, Sep 24, 2021 at 8:04 PM Maxim Muzafarov 
>> wrote:
>>
>> > Hello Nikita,
>> >
>> > +1 if you will lead this release.
>> >
>> >
>> > I'd suggest including into the release scope this one issue too:
>> >
>> > Snapshot restore must support restoring with indexes rebuild
>> > https://issues.apache.org/jira/browse/IGNITE-14744
>> >
>> > Hopefully, it will be completed by the end of October.
>> >
>> > On Fri, 24 Sept 2021 at 19:48, Nikita Amelchev 
>> > wrote:
>> > >
>> > > Dear Ignite Community!
>> > >
>> > > I suggest starting Apache Ignite 2.12 release activities.
>> > >
>> > > For now, we've accumulated a hundred resolved issues with new features
>> > > and bug fixes which are waiting for their release date. For example,
>> > >
>> > > CDC Application
>> > > Index Query API
>> > > Utility for analyzing indexes
>> > > Java compute tasks for C++
>> > > SQL commands statistics
>> > > etc.
>> > >
>> > > I want to propose myself to be the release manager of the planning
>> > release.
>> > >
>> > > I propose the following timeline:
>> > >
>> > > Scope Freeze: October 15, 2021
>> > > Code Freeze: October 29, 2021
>> > > Voting Date: November 15, 2021
>> > > Release Date: November 22, 2021
>> > >
>> > > WDYT?
>> > >
>> > > --
>> > > Best wishes,
>> > > Amelchev Nikita
>> >
>>
>

-- 
Sincerely yours, Ivan Daschinskiy

Re: Running TCBot across a PR

[Pavel Tupitsyn]

Hi Raymond,

1. Please register an account on TeamCity (ci.ignite.apache.org), you'll be
able to start builds right away.
2. Login with the same credentials to https://mtcga.gridgain.com/prs.html
and schedule a build for your PR.

See
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot
for more info.

> I'm also not sure who to suggest for review in the Java K8s area.
I can do the review once the tests pass.

Thanks,
Pavel

On Wed, Sep 29, 2021 at 12:47 AM Raymond Wilson 
wrote:

> Hi,
>
> I have created and actioned a Jira ticket (
> https://issues.apache.org/jira/browse/IGNITE-15602), and have a PR raised
> from my fork to the main repo.
>
> I think I have checked all the boxes except for verifying TCBot is happy
> (per instruction below)
>
>  - [ ] The pull request has been checked by the Teamcity Bot and
>the `green visa` attached to the JIRA ticket (see [TC.Bot: Check PR](
> https://mtcga.gridgain.com/prs.html))
>
> However, I don't (think I have) access to TeamCity, so I'm not sure how to
> complete that step.
>
> I'm also not sure who to suggest for review in the Java K8s area.
>
> Thanks,
> Raymond.
>
> --
> 
> Raymond Wilson
> Trimble Distinguished Engineer, Civil Construction Software (CCS)
> 11 Birmingham Drive | Christchurch, New Zealand
> raymond_wil...@trimble.com
>
> <
> https://worksos.trimble.com/?utm_source=Trimble_medium=emailsign_campaign=Launch
> >
>