Sergey Chernolyas created IGNITE-12582:
--
Summary: It is needed to set used cache for Spring Data by
property
Key: IGNITE-12582
URL: https://issues.apache.org/jira/browse/IGNITE-12582
Project: I
Got it, sounds good!
Should we consider the list of modules included in the slim package
finalized?
чт, 16 янв. 2020 г. в 13:13, Igor Sapego :
> Alexey, if I understand correctly, Ilya does not suggest to pre-built
> binaries, just to ship it with configure script pre-generated, which
> is a comm
Hi,
I suppose you can.
Nikolay possibly may help with it.
If you have the telegram, join to Russian channel: https://t.me/RU_Ignite
вс, 26 янв. 2020 г. в 19:21, Vladimir Steshin :
> Hi everyone.
>
> How do you think, can I start this task:
> https://issues.apache.org/jira/projects/IGNITE/issues/
Hello!
If you have the telegram, join to Russian channel: https://t.me/RU_Ignite
чт, 23 янв. 2020 г. в 16:07, Ilya Kasnacheev :
> Hello!
>
> I have added you to Contributors of our project, you can now assign issues
> to yourself.
>
> Please read
> https://cwiki.apache.org/confluence/display/IGN
Maksim, folks,
Actually I am curious what kind of communication channel is mentioned
telegram channel? Should we add a link to it on official "community
resources" page?
пн, 27 янв. 2020 г. в 11:40, Maksim Stepachev :
>
> Hello!
>
> If you have the telegram, join to Russian channel: https://t.me/
And dont forget asf slack with a few channel about Apache ignite
пн, 27 янв. 2020 г., 12:20 Ivan Pavlukhin :
> Maksim, folks,
>
> Actually I am curious what kind of communication channel is mentioned
> telegram channel? Should we add a link to it on official "community
> resources" page?
>
> пн,
Congratulations, Igor.
Well deserved!
> On 27 Jan 2020, at 08:57, Ivan Pavlukhin wrote:
>
> Hello Ignite Community,
>
> The Project Management Committee (PMC) for Apache Ignite has invited
> Igor Sapego to join the PMC as a new member and we are pleased to
> announce that he has accepted.
>
Hello, Alexey Kuznetsov.
I have two approvals from Saikat Maitra and Maxim Stepachov.
I have plans to merge spring-boot autoconfigure modules to
ignite-extensions. [1]
Do you want to perform additional review?
[1] https://github.com/apache/ignite-extensions/pull/6
пт, 24 янв. 2020 г. в 07:41, Sa
Ok. Forgot to explain the ticket. I'm going to bring some refactoring to
the test, replace inheritance with parametrization. Many tests use
extending to handle params like
public class JdbcThinBulkLoadAtomicReplicatedSelfTest extends
JdbcThinBulkLoadAbstractSelfTest {
/** {@inheritDoc} */
Vladimir Steshin created IGNITE-12583:
-
Summary: Parametrization of JdbcThinBulkLoadAbstractSelfTest
Key: IGNITE-12583
URL: https://issues.apache.org/jira/browse/IGNITE-12583
Project: Ignite
Aditya created IGNITE-12584:
---
Summary: Query execution is too long issue!
Key: IGNITE-12584
URL: https://issues.apache.org/jira/browse/IGNITE-12584
Project: Ignite
Issue Type: Bug
Repor
Today I opened for myself a possibility to merge PR via GitHub. And
GitHub allows 3 usual options to do a merge (merge commit, rebase,
squash). And "merge commit" is a default option but an illegal one
according to Apache Ignite usual practices.
So, I wonder is it somehow possible to configure it
Hello!
I implore everybody to use scripts/apply-pull-request.sh, I never had any
problems with it. The only downside is that cherry-peek needs to be clean.
Regards,
--
Ilya Kasnacheev
пн, 27 янв. 2020 г. в 14:22, Ivan Pavlukhin :
> Today I opened for myself a possibility to merge PR via GitHu
Iliya,
How well does this script work under non-linux operations systems?
> On 27 Jan 2020, at 14:24, Ilya Kasnacheev wrote:
>
> Hello!
>
> I implore everybody to use scripts/apply-pull-request.sh, I never had any
> problems with it. The only downside is that cherry-peek needs to be clean.
>
Merging from GitHub is very convenient indeed, much faster and safer than
anything else.
And yes, GitHub provides a way to disable Merge and Rebase, leaving only
Squash option:
https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests
However, I
Hi Igor,
congrats with new role.
Sincerely,
Dmitriy Pavlov
пн, 27 янв. 2020 г. в 12:51, Petr Ivanov :
> Congratulations, Igor.
>
> Well deserved!
>
>
> > On 27 Jan 2020, at 08:57, Ivan Pavlukhin wrote:
> >
> > Hello Ignite Community,
> >
> > The Project Management Committee (PMC) for Apache Ig
Hi Igniters,
I would name dev list as the only one official channel. Other options are
supplementary channels just for convenience (Slack for voice calls & chats,
Russian local resources for easier communication without foreign language
barrier). But still, I hope we're on the same page that
_If i
+1 to keep only "squash" merge option
On Mon, 27 Jan 2020 at 14:39, Pavel Tupitsyn wrote:
>
> Merging from GitHub is very convenient indeed, much faster and safer than
> anything else.
>
> And yes, GitHub provides a way to disable Merge and Rebase, leaving only
> Squash option:
> https://help.git
I always merge PRs from GitHub when possible. By doing it I can keep my
Git's local state unmodified.
So I suggest using squash and merge.
пн, 27 янв. 2020 г. в 14:59, Maxim Muzafarov :
> +1 to keep only "squash" merge option
>
> On Mon, 27 Jan 2020 at 14:39, Pavel Tupitsyn wrote:
> >
> > Mergi
Hi Denis,
yes, sorry for late reply, I just did double check that I can access
answers. Additionally, Ksenia R. have access to proposals.
Anyone from PMC who would like to volunteer and being PMC Representative
for Apache Ignite Local meetups are always welcomed (according
https://www.apache.org/
I beleive that dev list should be the only mean of (technical)
decision making for the project.
But other resources can show better productivity and especially for
newcomers. And I am little bit worried that means of communication
seems a little bit scattered. I will try telegram =)
пн, 27 янв. 2
But there is still the question how to configure it. Petr, can you
help here? Or somebody else? Or INFRA ticket should be created?
пн, 27 янв. 2020 г. в 15:05, Dmitriy Pavlov :
>
> I always merge PRs from GitHub when possible. By doing it I can keep my
> Git's local state unmodified.
>
> So I sugg
Ok, if no one have objections, I will restrict a map by strings only.
чт, 23 янв. 2020 г., 17:20 Pavel Tupitsyn :
> > Well, my understanding was a binary object with compact footer = false
> is totally standalone entity and can be read without any external metadata
> Not exactly: type name and f
Unfortunately, I have no power at Apache's GitHub repositories.
Ticket for INFRA maybe the best way to solve the issue.
> On 27 Jan 2020, at 15:23, Ivan Pavlukhin wrote:
>
> But there is still the question how to configure it. Petr, can you
> help here? Or somebody else? Or INFRA ticket should
Petr Ivanov
The script works great for me under windows.
пн, 27 янв. 2020 г. в 15:33, Petr Ivanov :
> Unfortunately, I have no power at Apache's GitHub repositories.
> Ticket for INFRA maybe the best way to solve the issue.
>
>
> > On 27 Jan 2020, at 15:23, Ivan Pavlukhin wrote:
> >
> > But the
Folks,
I'm sorry for not being too attentive to the whole thread discussion
and maybe missing some details.
But... who will perform the review of [1] issue?
Will we merge it to 2.8? (hope so)
[1] https://issues.apache.org/jira/browse/IGNITE-12553
[IEP-35] public Java metric API
On Sat, 25 Jan
Nikolay,
I've reviewed your changes and I tend to agree with Andrey, it's better to
remove deprecation for the old APIs in AI 2.8 and discuss and merge the new
facade (IGNITE-12553) in a more calm and structured way. My observations on
the changes:
- I am not sure if Iterable would suffice bot
> it's better to remove deprecation for the old APIs in AI 2.8
Are you suggest to have 2 concurrent metrics implementations(both not
deprecated)?
> Let's say I am writing a custom exporter in binary format and I need to write
> the number of exported metrics in a packet beforehand.
This an `Me
I used squash for last two years, no problemo with that. Of course we
should have 1 commit to 1 PR relationship, don't put all your commits to
the table:)
пн, 27 янв. 2020 г. в 15:50, Alexei Scherbakov :
> Petr Ivanov
>
> The script works great for me under windows.
>
> пн, 27 янв. 2020 г. в 15:3
Of course, telegram/slack and etc are indexed by google and results
couldn't be found there, but we should provide more options for onboarding
for newcomers and share knowledge and help for them.
I suggest to use official ASF slack for simple questions about development
and asking help.
The current
Count me in!
пн, 27 янв. 2020 г. в 15:12, Dmitriy Pavlov :
> Hi Denis,
>
> yes, sorry for late reply, I just did double check that I can access
> answers. Additionally, Ksenia R. have access to proposals.
>
> Anyone from PMC who would like to volunteer and being PMC Representative
> for Apache Ig
INFRA ticket filed:
https://issues.apache.org/jira/browse/INFRA-19778
On Mon, Jan 27, 2020 at 4:38 PM Alexey Zinoviev
wrote:
> I used squash for last two years, no problemo with that. Of course we
> should have 1 commit to 1 PR relationship, don't put all your commits to
> the table:)
>
> пн, 27
Igniters,
I want to add one more issue to the Apache Ignite 2.8 release scope [1].
The problem is impossibility of using communication metrics gathered
for nodes in the cluster because node ID will changed in case of
restart. Obvious solution is using consistent ID instead of node ID.
PR is alre
Folks,
Will it be better to schedule an ASF Slack call to choose the best
option which we have? Since this discussion thread is valuable for 2.8
release and we do not have a strong consensus here.
How about 30-th January 16-00 MSK time?
On Mon, 27 Jan 2020 at 16:37, Nikolay Izhikov wrote:
>
>
Hi Igniters! GridGain wants to start IMC meetup in Seattle[1] and the first
session can be as soon as in March.
Do we have here someone from Seattle? It would be cool if you want to
present a talk about Apache Ignite - please use this IMC CFP form[2]. Or
maybe your company can host the session? Or
My congratulations!
пн, 27 янв. 2020 г. в 14:53, Dmitriy Pavlov :
> Hi Igor,
>
> congrats with new role.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 27 янв. 2020 г. в 12:51, Petr Ivanov :
>
> > Congratulations, Igor.
> >
> > Well deserved!
> >
> >
> > > On 27 Jan 2020, at 08:57, Ivan Pavlukhin wrote
Great, congrats!
пн, 27 янв. 2020 г. в 19:03, Kseniya Romanova :
> My congratulations!
>
> пн, 27 янв. 2020 г. в 14:53, Dmitriy Pavlov :
>
> > Hi Igor,
> >
> > congrats with new role.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 27 янв. 2020 г. в 12:51, Petr Ivanov :
> >
> > > Congratulation
Hello, Andrey.
I’m OK to include these changes to 2.8.
I don’t review PR, but the ticket description makes sense to me.
But, we must gather yardstick benchmark results for PR(comparing to current
master) before merge to ensure there is no performance drop.
Note, that these metrics updated on eac
Nikolay,
> But, we must gather yardstick benchmark results for PR(comparing to current
> master) before merge to ensure there is no performance drop.
"If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
I believe that benchmarks ignite-2.7.6 vs ignite-2.8 will show
noticeable d
I support the idea of triggering such tests on demand. We can create a wiki
page with instructions on how to run the tests. Unless there is a more
elegant solution.
Sergey, would you be able to review Emmanouil's changes in the IP Finder
source code?
https://issues.apache.org/jira/browse/IGNITE-86
Alex, could you please list all the modules that will be excluded? It will
help to confirm we haven't dumped anything essential.
-
Denis
On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Got it, sounds good!
> Should we consider the list of modules include
Andrey.
> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
Please, clarify, what do you mean by «doesn’t work»?
Are there any unresolved bugs?
> IGINTE-12576 affects it minimally
All I asking for is to confirm this statement with the benchmark results.
> User can disable m
Folks,
We had this discussion about communication channels before and summarized
it on this wiki:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Collaborate
Dev list is a preferred channel but we're free to go to Slack or Telegram
(mention it there if you'd like) on some occasions.
-
Igor, thanks for being an invaluable member of the community all this time!
Congrats!
-
Denis
On Sun, Jan 26, 2020 at 9:58 PM Ivan Pavlukhin wrote:
> Hello Ignite Community,
>
> The Project Management Committee (PMC) for Apache Ignite has invited
> Igor Sapego to join the PMC as a new member a
Igor Seliverstov created IGNITE-12585:
-
Summary: Calcite integration. Splitter improvements.
Key: IGNITE-12585
URL: https://issues.apache.org/jira/browse/IGNITE-12585
Project: Ignite
Issu
Igor Seliverstov created IGNITE-12586:
-
Summary: Calcite integration. NodesMapping simplification.
Key: IGNITE-12586
URL: https://issues.apache.org/jira/browse/IGNITE-12586
Project: Ignite
>> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
> Please, clarify, what do you mean by «doesn’t work»?
> Are there any unresolved bugs?
Obviously some communication metrics can't be monitored or analyzed
retrospectively due to changing node ID during node restart. It's bug
> I think it could be fixed easily by adding metricsEnabled flag to
> TcpCommunicationSpi.
We still can’t accept patches that badly affects the performance of
TcpCommuncationMetricsListener.
So we should perform yardstick tests before the merge.
I can help to run yardstick benchmarks if you don
>> I just want to remove the deprecations on the classes for which there is no
>> a well-defined replacement.
> Well-defined replacement for these classes exists.
Nikolay, statements like this are not arguments. At least because
there are people who disagree with this.
Current implementation is
> We still can’t accept patches that badly affects the performance of
> TcpCommuncationMetricsListener.
> So we should perform yardstick tests before the merge.
Absolutely all metrics are on the hot path. They inevitably affect
performance and this case is the same. May be we should rollback all
Andrey.
> My choice: correctness over performance
I don’t think we should select performance OR correctness here.
It seems we can got both.
> May be we should rollback all metrics related changes because we don't have
> benchmark results
I perform benchmarking for initial refactoring of
TcpCo
Igniters,
I prepared PR removing custom ThreadGroup for a ticket [1]. Everybody
is welcome to review. If there will be no objections I am going to
merge the patch by the end of this week.
[1] https://issues.apache.org/jira/browse/IGNITE-12554
пт, 24 янв. 2020 г. в 13:15, Alexey Goncharuk :
>
> I
52 matches
Mail list logo
