Hello!
Maybe we could issue a developer warning as soon as we detect putAll() with
something which has more than one element and which is not a sorted map?
Like we do with indexed when they don't fit inline, etc.
Regards,
--
Ilya Kasnacheev
пн, 18 мар. 2019 г. в 09:13, Павлухин Иван :
> Hi,
To avoid deadlocks you have to always take locks in the same order.
* That order is not always going to be "sorted with default comparer".
* Not every type has a default comparer
So Ignite can't sort the keys for you, nor can it check if they are sorted.
And even if it could, it would be making un
Dmitry,
Phrase "Code modifications can be approved by silence: by lazy consensus
(72h) after Dev.List announcement." looks unacceptable to me.
Please roll back the changes and start the discussion at the private list
and never do such updates in the future without the discussion.
On Fri, Mar 15,
Yury Gerzhedovich created IGNITE-11557:
--
Summary: flaky test
SqlSystemViewsSelfTest.testQueryHistoryMetricsModes
Key: IGNITE-11557
URL: https://issues.apache.org/jira/browse/IGNITE-11557
Project:
The major objection is to release 2.7.1 as 2.8.
1) A lot of people fixed issues at master with version 2.8.
So, they and their companies/customers (who used Ignite) waits for 2.8
because of fixes.
At least my company waits for fixes at 2.8.
It will be a real problem to update all private links for
+1 to 2.7.1 version.
I think it's time to learn to do minor releases.
пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov :
> The major objection is to release 2.7.1 as 2.8.
>
> 1) A lot of people fixed issues at master with version 2.8.
> So, they and their companies/customers (who used Ignite) waits
Hi,
This is tough question, and first of all I'd like to ask participants to
keep cold head. This is a public question and can be discussed on the dev
list safely.
On the one hand, it is true that a number of patches are not reviewed for a
long time, what negatively affects community development.
Huge +1 to "We should stress out that a patch should be committed if and
only if committer is confident with the changes."
On Mon, Mar 18, 2019 at 11:54 AM Vladimir Ozerov
wrote:
> Hi,
>
> This is tough question, and first of all I'd like to ask participants to
> keep cold head. This is a public
Hello Igniters,
current improvement has been merged to master recently,
please feel free to use it in your tests.
пт, 15 февр. 2019 г. в 11:26, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com>:
> ++1 from my side. I guess it will be a more reliable way for works with
> properties in the tests.
Hello, Vladimir.
Thanks for the detailed answer.
I think your statement doesn't differs with Dmitry statement much.
Do we have committer who merge without confidence in patch content?
If yes, they should stop to do it.
пн, 18 мар. 2019 г. в 12:00, Anton Vinogradov :
> Huge +1 to "We should stre
Hello!
We can defnitely do a heuristic check that passed map is HashMap (therefore
unordered), since HashMap is basically "the" map. If we do a warning in 99%
of problematic cases but fail to detect the remaining 1%, it's still a big
improvement over the current behavior.
Same thing in .Net with
Ilya Kasnacheev created IGNITE-11558:
Summary: Developer warning when HashMap is passed to putAll()
Key: IGNITE-11558
URL: https://issues.apache.org/jira/browse/IGNITE-11558
Project: Ignite
Hello!
Did the first, can you rebase the second one? I'm relying on script and it
requires that change will merge flawlessly.
Regards,
--
Ilya Kasnacheev
вс, 17 мар. 2019 г. в 21:29, Павлухин Иван :
> Hi Igniters,
>
> Recently I created 2 PRs with simple changes related our testing framework.
Hi Ilya,
Thanks a lot!
I rebased second PR. Can you please take a look?
пн, 18 мар. 2019 г. в 12:57, Ilya Kasnacheev :
>
> Hello!
>
> Did the first, can you rebase the second one? I'm relying on script and it
> requires that change will merge flawlessly.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
>
Hi, thank you all for your replies, I'm happy we discussing it, so we could
clearly understand this policy and how to apply it.
a committer will always merge the change, was it approved by another
contributor/committer/lazy consensus/vote - does not matter. And a
committer will be responsible to t
In case nobody cares, most likely we have a problem with a contribution or
motivation, not with lazy committers :)
Please remove the "lazy" phrase, since it can be interpreted as "silence as
an agreement" which is always not true.
On Mon, Mar 18, 2019 at 1:13 PM Dmitriy Pavlov wrote:
> Hi, thank
Anton, thanks for checking compatibility.
Anton or Nikolay, would you like to be a release manager for 2.7.1 ?
1) Ticket version update happens from time to time, it is a mass update in
JIRA - 1 operation. Actually, we have tradition noticed by Alex G:
even-numbered minor release all were emerge
Andrew Mashenkov created IGNITE-11559:
-
Summary: MVCC: Tx hangs on finish if StorageException occurs.
Key: IGNITE-11559
URL: https://issues.apache.org/jira/browse/IGNITE-11559
Project: Ignite
Ivan Bessonov created IGNITE-11560:
--
Summary: @WithSystemProperty annotation breaks some existing tests.
Key: IGNITE-11560
URL: https://issues.apache.org/jira/browse/IGNITE-11560
Project: Ignite
As far as I remember that's not the first time we choose X.Y instead of
X.Y.Z, because of ...
So, seems we have to choose it now.
>> Anton or Nikolay, would you like to be a release manager for 2.7.1?
I can assist or perform the technical part of the release.
>> Also, I can suggest 2.7.3 release
Alexey Platonov created IGNITE-11561:
Summary: [ML] IgniteDistributedModel for XGBoost doesn't work in
example
Key: IGNITE-11561
URL: https://issues.apache.org/jira/browse/IGNITE-11561
Project: Ig
Hi Ivan,
reasonable points, but we had a long and hot discussion about this logic.
Reason for selecting auto-generation was users that just try to use Apache
Ignite with native persistence for the first time. They must be able to
test features without any extensive setup, but before go-live we ex
I'm not second-guessing someone's motivation. And without a particular
case, it is not reasonable to discuss reasons why a patch is not merged.
Silence=agreement in case there was clearly stated about it. Lazy consensus
is simply an announcement of 'silence gives assent.' When someone wants to
det
Hi Dmitriy,
Quick start for a new user is a perfect concern. I thought about it as
well. I and would like to outline that I am completely ok with an
approach in your patch.
пн, 18 мар. 2019 г. в 16:16, Dmitriy Pavlov :
>
> Hi Ivan,
>
> reasonable points, but we had a long and hot discussion about
Dmitriy.
Actually, I doesn't understand your last mail.
Do we have some issue to solve?
If yes, can you write it down?
What fixes need to be reviewed?
пн, 18 мар. 2019 г. в 16:31, Dmitriy Pavlov :
> I'm not second-guessing someone's motivation. And without a particular
> case, it is not reason
=1552915586426, loc=false, ver=2.7.0#20190318-sha1:,
isClient=false], topVer=4, nodeId8=7355a5c6, msg=null,
type=DISCOVERY_CUSTOM_EVT, tstamp=1552915586506]], crd=TcpDiscoveryNode
[id=b9afbb48-3396-4ca6-b714-d2aa4e90,
consistentId=53086654-443a-44ab-88e3-a4d4f50d2477, addrs=ArrayList
Nikolay, sorry for going off-topic of the current thread. Just a few
examples:
https://issues.apache.org/jira/browse/IGNITE-8376
https://issues.apache.org/jira/browse/IGNITE-11521
https://issues.apache.org/jira/browse/IGNITE-11397
https://issues.apache.org/jira/browse/IGNITE-11346
https://issues.ap
Hello Ignite Community!
My name is Alexandr Shapkin. I want to contribute to Apache Ignite, my JIRA
username is ashapkin.
Thanks!
Hi Alexandr,
Thank you for interest in Apache Ignite, and welcome to the community.
I've added your account to the list of contributors, now you could assign
issues.
Full Guide
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute (now
wiki can be down, please check later); shorter
29 matches
Mail list logo
