Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5248
---
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5360
---
Ivan Artukhov created IGNITE-10280:
--
Summary: Create Yardstick IgniteGetAllTxBenchmark
Key: IGNITE-10280
URL: https://issues.apache.org/jira/browse/IGNITE-10280
Project: Ignite
Issue Type:
Denis, you can go even further. E.g. you can start topology once for the
full set of single threaded full api cache tests. Each test should start
cache dynamically and run it logic.
As for me, I would think of splitting RunAll to 2 steps - one containing
basic tests and another with more complex
Ivan Rakov created IGNITE-10277:
---
Summary: Prepare-commit ordering is violated for one-phase commit
transactions
Key: IGNITE-10277
URL: https://issues.apache.org/jira/browse/IGNITE-10277
Project:
Hi Denis,
Another side of this decision is the openness of the development.
Since not all contributors pay attention to run their development in an
open/community friendly manner:
- to announce important features, and
- Telegraph their intent
- Draft designs openly
- Submit work in chunks
-
GitHub user antkr opened a pull request:
https://github.com/apache/ignite/pull/5402
Ignite 2.5.3.b2
Pull request for teamcity run.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-2.5.3.b2
GitHub user ibessonov opened a pull request:
https://github.com/apache/ignite/pull/5400
IGNITE-10192 OptimizedMarshallerTest#testAllocationOverflow throws OOME
instead of expected IOE
You can merge this pull request into a Git repository by running:
$ git pull
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5080
---
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5398
---
Dmitry, Sergey,
There is a common pattern in the test codebase, when each test starts its
own set of nodes,
and closes them after the test finishes.
Node startup takes quite a lot of time, and this time could be reduced, if
tests shared the same set of nodes.
I mean, if there is a test class with
Vyacheslav Koptilin created IGNITE-10278:
Summary: The checkpointReadLock must be acquired before calling
MvccProcessor.updateState
Key: IGNITE-10278
URL:
Sergey Antonov created IGNITE-10279:
---
Summary: Control.sh utility unify options naming format
Key: IGNITE-10279
URL: https://issues.apache.org/jira/browse/IGNITE-10279
Project: Ignite
Dmitriy,
> I do believe Igniters can set up a filter.
I doesn't mean we should make them do it.
How do JIRA messages help?
If you want do discuss something – write to dev list.
If you want a code review – write to dev list.
If you have an announcement – write to dev list.
I don't see, how JIRA
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/5399
IGNITE-10273: Fixed retrieval of affinity mapping
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-10273
Igor Seliverstov created IGNITE-10276:
-
Summary: MVCC TX: Optimize logger creations
Key: IGNITE-10276
URL: https://issues.apache.org/jira/browse/IGNITE-10276
Project: Ignite
Issue Type:
Dmitriy,
The problem is already outlined above - JIRA notifications have very little
to do with openness, as most of them are either minor things or decisions
which are already made. You will never see the whole picture of what the
project is doing.
What is *MUCH* worse is that currently we have
Dmitriy,
If we want people to act openly and community-friendly, then we should make
it a part of the required development process.
Otherwise people just won't care about it.
Moreover, all JIRA tickets are open for everyone, so no openness would be
violated if we made a separate mailing list for
Sergey Antonov created IGNITE-10281:
---
Summary: Log to file all jars in classpath on start node.
Key: IGNITE-10281
URL: https://issues.apache.org/jira/browse/IGNITE-10281
Project: Ignite
Completely agree with Denis. Tons of generated messages and community
health are not relevant. Currently we obviously have too much tickets and
too little communications. This is bad. But whether we accumulate generated
stuff here or in some other place is not important at all, provided that we
GitHub user sk0x50 opened a pull request:
https://github.com/apache/ignite/pull/5401
IGNITE-10278 The checkpointReadLock must be acquired before calling
MvccProcessor.updateState
You can merge this pull request into a Git repository by running:
$ git pull
I do believe Igniters can set up a filter.
JIRA ticket is an intention to be done by contributors in future.
If PMC member admits decisions are made off the list and just provided as
fact-in-the-past for others - it really signs poor community health. So for
me, it is not reasonable to fight
Max, correct link to ticket is
https://issues.apache.org/jira/browse/IGNITE-10258
I would agree with you and Vladimir that parameters in mentioned case may
appear in any order.
--Yakov
Guys,
I vote for moving automatically generated messages to a separate mailing
list (maybe except most important ones).
I already wrote about it here:
http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html
What we have now makes the Nabble portal an absolute mess
ololo3000 closed pull request #71: IGNITE-9939 BuildObserver refactor. Visas
request cancellation added
URL: https://github.com/apache/ignite-teamcity-bot/pull/71
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the
Hi,
In my opinion there should be only development discussions and
important notifications on dev list. But I must say that I started to
look through Jira and even GitHub notifications from time to time. And
I find that it sometimes gives me a useful information like
"contributor A is doing B".
Github user devozerov closed the pull request at:
https://github.com/apache/ignite/pull/5395
---
Let's move git notifications to a separate list. As for JIRA, not sure it
bothers me, it took me several minutes to set up all the filters to spread
the messages out across specific folders. Otherwise, some of us might
ignore subscribing to jira-list and would miss notifications when their
input
Dmitry,
What Apache member do you refer to?
чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov :
> How do you know what to watch if new tickets are not forwarded?
>
> Again, PRs are ok to remove since it is duplicate to jira, but jira removal
> does not make any sense for me.
>
> Com dev folks
What incubator mentor do you refer to? Incubator member are asf members as
well.
I was involved at least to 3 discussions at the list started from Jira
issue created.
If others were not involved, it do not convince me its is not useful to
keep forwarding.
чт, 15 нояб. 2018 г., 21:23 Vladimir
Personal emails for _watched_ JIRA tickets are very useful.
Emails to everyone are not.
+1 for separate mailing list for all automated emails.
I don't think we can avoid automated emails completely, but dev list should
be human-only.
So separate list is the only way.
On Thu, Nov 15, 2018 at
Personally I am comfortable with the way how things are now because mail
filters appear to work well for me.
However this thread made me curious about whether ASF has some guidance or
recommendations on that matter. I searched quite a bit and found none of
that kind. It looks like Apache leaves
Max Shonichev created IGNITE-10282:
--
Summary: control.sh: implement proper shell arguments escaping due
to the possible usage of regular expression in --cache command
Key: IGNITE-10282
URL:
Github user devozerov closed the pull request at:
https://github.com/apache/ignite/pull/4908
---
Max Shonichev created IGNITE-10284:
--
Summary: performance drop on PME time during 1 server node left
Key: IGNITE-10284
URL: https://issues.apache.org/jira/browse/IGNITE-10284
Project: Ignite
Dmitry,
I am not referring to some "authoritative ASF member" as a guide for us. We
are on our own. What I meant is that at some point in time we were pointed
to an idea, that tons of automated messages has nothing to do with healthy
community. Which seems pretty reasonable to me.
On Thu, Nov
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to
Yury Babak created IGNITE-10287:
---
Summary: [ML] Model storage
Key: IGNITE-10287
URL: https://issues.apache.org/jira/browse/IGNITE-10287
Project: Ignite
Issue Type: New Feature
Yury Babak created IGNITE-10289:
---
Summary: [ML] Import models from XGBoost
Key: IGNITE-10289
URL: https://issues.apache.org/jira/browse/IGNITE-10289
Project: Ignite
Issue Type: New Feature
Yury Babak created IGNITE-10288:
---
Summary: [ML] Model inference
Key: IGNITE-10288
URL: https://issues.apache.org/jira/browse/IGNITE-10288
Project: Ignite
Issue Type: New Feature
Dmitriy Govorukhin created IGNITE-10290:
---
Summary: Map.Entry interface for key cache may lead to incorrect
calculation hash code
Key: IGNITE-10290
URL: https://issues.apache.org/jira/browse/IGNITE-10290
Yury Babak created IGNITE-10286:
---
Summary: [ML] Umbrella: Model serving
Key: IGNITE-10286
URL: https://issues.apache.org/jira/browse/IGNITE-10286
Project: Ignite
Issue Type: New Feature
Dmitriy Govorukhin created IGNITE-10285:
---
Summary: U.doInParallel may lead to deadlock
Key: IGNITE-10285
URL: https://issues.apache.org/jira/browse/IGNITE-10285
Project: Ignite
Issue
Vladimir,
Thanks, make perfect sense to me.
On Thu, Nov 15, 2018 at 12:18 AM Vladimir Ozerov
wrote:
> Denis,
>
> The idea is that QueryDetailMetrics will be exposed through separate
> "historical" SQL view in addition to current API. So we are on the same
> page here.
>
> As far as query ID I
GitHub user dgovorukhin opened a pull request:
https://github.com/apache/ignite/pull/5404
IGNITE-10285 Implement job stealing for U.doInParallel
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
GitHub user dgovorukhin opened a pull request:
https://github.com/apache/ignite/pull/5405
IGNITE-10290 Fix missed prepareForCache in localGet operation
Signed-off-by: Dmitriy Govorukhin
You can merge this pull request into a Git repository by running:
$ git pull
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to
How do you know what to watch if new tickets are not forwarded?
Again, PRs are ok to remove since it is duplicate to jira, but jira removal
does not make any sense for me.
Com dev folks instead suggest to forward all comments and all activity from
github to the list. So if Apache member will
GitHub user antkr opened a pull request:
https://github.com/apache/ignite/pull/5403
Ignite 2.4.12 p1
Pull request for teamcity run.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-2.4.12-p1
Max Shonichev created IGNITE-10283:
--
Summary: `control.sh --baseline` does not output other nodes when
cluster is inactive
Key: IGNITE-10283
URL: https://issues.apache.org/jira/browse/IGNITE-10283
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to
Hello, Igniters!
AI 2.6 has added `--cache idle_verify command` to control.sh.
Upcoming changes in 2.7 would add some optional arguments, specifically
`--dump`. Also, all `control.sh` commands, including `--cache`, have optional
connection arguments like, e.g. `--host`, `--port`.
During
Denis,
The idea is that QueryDetailMetrics will be exposed through separate
"historical" SQL view in addition to current API. So we are on the same
page here.
As far as query ID I do not see any easy way to operate on a single integer
value (even 64bit). This is distributed system - we do not
Vladimir Ozerov created IGNITE-10267:
Summary: Deprecate "replicatedOnly" flag in thin clients
Key: IGNITE-10267
URL: https://issues.apache.org/jira/browse/IGNITE-10267
Project: Ignite
Vladimir Ozerov created IGNITE-10268:
Summary: Remove documentation about "replicatedOnly" flag
Key: IGNITE-10268
URL: https://issues.apache.org/jira/browse/IGNITE-10268
Project: Ignite
Vladimir Ozerov created IGNITE-10270:
Summary: MVCC: Pass transaction labels to MVCC
Key: IGNITE-10270
URL: https://issues.apache.org/jira/browse/IGNITE-10270
Project: Ignite
Issue Type:
Vladimir Ozerov created IGNITE-10269:
Summary: MVCC: CacheMvccReplicatedBackupsTest fails when query
over REPLICATED cache is converted to local form
Key: IGNITE-10269
URL:
Vladimir Ozerov created IGNITE-10271:
Summary: Document transaction labels
Key: IGNITE-10271
URL: https://issues.apache.org/jira/browse/IGNITE-10271
Project: Ignite
Issue Type: Task
I think this is definitely a bug. From our experience with millions of
other utilities we know, that relative order of parameters with "-" or "--"
prefixes against each other doesn't matter. This is what users will expect
from our utility too.
On Thu, Nov 15, 2018 at 11:05 AM mshonich wrote:
>
Github user devozerov closed the pull request at:
https://github.com/apache/ignite/pull/5373
---
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4600
---
IMO we need to run a formal vote on this change, and then PMC chair can
create (or reuse) a separate list for messages from Git repos.
ср, 14 нояб. 2018 г. в 16:08, Vladimir Ozerov :
> Igniters,
>
> I would say that "set the filter" is not a solution. First, it is not
> always possible
Hi Igniters,
Some of us started to use the Bot to get an approval of PRs. It helps to
protect master from new failures, but this requires to run RunAll tests set
for each commit and this makes markable pressure to TC infra.
I would like to ask you to share your ideas on how to make runAll
Artem Malykh created IGNITE-10272:
-
Summary: Inject learning environment into scope of dataset compute
task
Key: IGNITE-10272
URL: https://issues.apache.org/jira/browse/IGNITE-10272
Project: Ignite
Dmitriy,
You brought up really important topic that has a great impact on our
project. Faster runAlls mean quicker feedback and faster progress on issues
and features.
We have a pretty big code base of tests, about 50 thousands tests. Do we
have an idea of how these tests overlap with each
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5383
---
Igor Sapego created IGNITE-10273:
Summary: CPP Thin: Client is unable to get affinity mapping in
some cases
Key: IGNITE-10273
URL: https://issues.apache.org/jira/browse/IGNITE-10273
Project: Ignite
Andrew Mashenkov created IGNITE-10274:
-
Summary: MVCC: Optimize get from local backup.
Key: IGNITE-10274
URL: https://issues.apache.org/jira/browse/IGNITE-10274
Project: Ignite
Issue
Dmitriy Pavlov created IGNITE-10275:
---
Summary: [TC Bot] Several JIRA comments are issued in case
ignite.cache.remove failed
Key: IGNITE-10275
URL: https://issues.apache.org/jira/browse/IGNITE-10275
ololo3000 opened a new pull request #72: IGNITE-10275 Jira spam fast fix
URL: https://github.com/apache/ignite-teamcity-bot/pull/72
This is an automated message from the Apache Git Service.
To respond to the message, please
asfgit closed pull request #72: IGNITE-10275 Jira spam fast fix
URL: https://github.com/apache/ignite-teamcity-bot/pull/72
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull
GitHub user SpiderRus opened a pull request:
https://github.com/apache/ignite/pull/5398
ignite-10246 StandaloneWALRecordIterator must throw checkBounds exception
You can merge this pull request into a Git repository by running:
$ git pull
72 matches
Mail list logo
