Re: [DISCUSSION] Code style. Variable abbrevations
Hello, Pavel > But it doesn't mean that now we need to use only full names. > Abbreviations may be used e.g. for local variables with short scope. > Here we must follow common sense and existing practices of effective naming. > It shouldn't be a cargo cult as it is now. But «common sense» has a very different definition for each community member. So, it seems, your proposal will end with different naming styles through codebase. Moreover, one reviewer will require «first» naming style and another «second» because of personal common sense. Personally, I believe strict automatically checked code style rules are better than common sense rules. Meanwhile, please, keep in mind that abbreviation rules is mandatory. And this discussion shown there are many Ignite developers who want to keep it. If someone wants to change or make it optional - please, start a vote. > 21 июня 2021 г., в 21:45, Pavel Kovalenko написал(а): > >>> But do you have a plan what should we do with the subject? > > I think we need to just turn off the required rule for abbreviations and > start to write new code without this requirement. > But it doesn't mean that now we need to use only full names. Abbreviations > may be used e.g. for local variables with short scope. > Here we must follow common sense and existing practices of effective > naming. It shouldn't be a cargo cult as it is now. > If there are doubts about naming they should be resolved on a code review. > > And we shouldn't rush to migrate all existing code to names without > existing abbreviations, it doesn't make sense - most core components are > modified very rarely now. > If you touch some class and you see that you can make existing naming > better - do it. But starting to renaming everything is the same cargo cult > but only of a different polarity. > >>> Actually it seems to me offtopic > > My concern was in Nikita's words that such rules about abbreviations > simplifies entry of new members that were actually not. > Every such rule actually complicates new member contributions. Statistics > above from Ilya just confirms it. Only 4 external valuable contributors for > 6 years of the project. 2 of them have been offline for the last 5 years. > > пн, 21 июн. 2021 г. в 05:00, Ivan Pavlukhin : > >> Hi Pavel, >> >> Thank you for sharing your thoughts! My personal opinion is very >> similar. But do you have a plan what should we do with the subject? Do >> you suggest to cleanup whole codebase from abbreviations? Or do you >> think that it is fine to keep existing code as is and avoid >> abbreviations for new code? Or something else? >> >>> Who can tell me at least 5 contributors with 10+ commits who are not >> working/worked in GridGain or SberBank? It's sad to hide behind an open >> source community that really does not exist. >> >> Actually it seems to me offtopic. But here my opinion is different. It >> is ok to me that the project is mainly driven by aforementioned >> companies. And I would rather care more about ease of single >> contributions. I contributed to other open source projects and did < >> 10 commits to each. Because in daily work generally we use stable >> libraries and can allow ourselves to work only with bugs or >> improvements in open source libraries. And I consider it a way to go >> in open source. >> >> 2021-06-20 14:13 GMT+03:00, Pavel Kovalenko : >>> I think in this discussion there should be a question - why do we still >>> need abbreviations for all variables and fields? What problem does it >>> solve? >>> Nobody still clearly answered this question. >>> I saw only 2 arguments to keep abbreviations: >>> 1) Less codebase symbols. I think it is a weak argument. We're not in the >>> 80-90s when there were no modern IDEs with hints and auto-completion. >>> Ideally code should be read just as english text. That really helps to >>> understand the code if you see it for the first time. Abbreviations >>> everywhere (except well-known CS terms) don't improve code readability. >>> 2) We shouldn't break constitency with old codebase written with enforced >>> abbreviations. Hence the question - why was this rule introduced at >> project >>> startup? Who knows that? >>> I guess most people who decided to introduce this rule left the Ignite >>> project. >>> > Consistency is what makes it easier to contribute to the project >>> Yes it is. But what makes it easier is actually clear architecture, >> simple >>> and convenient abstractions and well-documented code. Ignite has a big >> lack >>> of that. >>> For example, look at the transactions or PME codebase. It's darkness and >> no >>> abbreviations for "consistency" will help to understand that code. >>> > and attract new members >>> Who can tell me at least 5 contributors with 10+ commits who are not >>> working/worked in GridGain or SberBank? >>> It's sad to hide behind an open source community that really does not >>> exist. >>> >>> >>> пт, 18 июн. 2021 г. в 14:21, Anton Vin
Re: Temporary TC Outage
Good news. TC is back online. In case of any problems, please, write them on dev list, I will check. > On 21 Jun 2021, at 19:40, Dmitry Pavlov wrote: > > Hi Petr, > > Sad news, but anyway, thank you for letting community know. > > Sincerely, > Dmitriy Pavlov > > On 2021/06/21 16:19:16, Petr Ivanov wrote: >> Hi, Igniters! >> >> >> Currently our TC instance is out of order due to power outage (power booth >> burned down). >> Restoration can take 1-2 days at least. >> >> I will keep you updated on further news. Please, stand by.
Share my Apache Ignite Use Case
Thanks, Ken Cheng
IndexOutOfBoundsException in GridCacheWriteBehindStore Flusher thread lookup (IGNITE-14893)
Hi, All. I'm going to fix issue with IndexOutOfBoundsException in GridCacheWriteBehindStore#flusher(K key) method. https://issues.apache.org/jira/browse/IGNITE-14893 This could happen when flush thread count is not a power of 2 an we fallback to mapping via modulo operation: idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt I assume that to fix this issue, wrapping the whole expression to abs() function should be enough. But since there is also a lot of places where we need to perform hash -> array_index mappings, there also could be potential bugs, if we forget to check incoming hash sign. So I guess that it would be convenient to introduce dedicated method in IgniteUtils class for such cases.
IGNITE-14812: Statistics
Hello, Igniters. Recently huge commit was merged [1]. Taras, Alexander, can you, please, explain what is purpose of the commit? What feature it implemented? Looked inside the ticket and found no explanation. Description is "Add statistics collection and usage.» Do we have plans to document this new feature? Also, I see very strange license in added files [2] ``` * Copyright 2013 Aggregate Knowledge, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); ``` Is it OK to have those copyright inside ASF codebase? Is it some kind of external dependency we adopted as part of the code? Why do we need it? [1] https://github.com/apache/ignite/commit/503a98495433e1d0cf84f8be8c1e2adc57034fbb [2] https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/stat/hll/serialization/IHLLMetadata.java
Re: IGNITE-14812: Statistics
Hi Nikolai, thank you for noticing. I guess it's not about license, but about Intellectual Property (IP) ownership. AFAIK, Apache License 2.0 is here and AL 2.0 is definetely allowed to be used in the codebase for an Apache project (https://www.apache.org/legal/resolved.html) But licenese and IP owner are 2 sligthly different things. E.g at the end of any website you can find: Copyright © 2021 The Apache Software Foundation, Licensed under the Apache License, Version 2.0. Incubated projects are mandated to transfer IP to the ASF. And I'm not aware of any exceptions. In this PR there are 5 classes which licenses with AL 2.0, but IP owner is 3rd party company. I'm a bit concerned about having such code in the project. I'd rather reverted it until we have approval from experts at mailing list: legal-disc...@apache.org Sincerely, Dmitriy Pavlov On 2021/06/22 14:56:49, Nikolay Izhikov wrote: > Hello, Igniters. > > Recently huge commit was merged [1]. > > Taras, Alexander, can you, please, explain what is purpose of the commit? > What feature it implemented? > > Looked inside the ticket and found no explanation. > Description is "Add statistics collection and usage.» > > Do we have plans to document this new feature? > > Also, I see very strange license in added files [2] > > ``` > * Copyright 2013 Aggregate Knowledge, Inc. > * > * Licensed under the Apache License, Version 2.0 (the "License"); > ``` > > Is it OK to have those copyright inside ASF codebase? > Is it some kind of external dependency we adopted as part of the code? > Why do we need it? > > [1] > https://github.com/apache/ignite/commit/503a98495433e1d0cf84f8be8c1e2adc57034fbb > [2] > https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/stat/hll/serialization/IHLLMetadata.java
Re: [DISCUSSION] Code style. Variable abbrevations
Nikolay,
I'm confused. Konstantin gave you an example of a bad abbreviation that
cannot be caught by automated validation, and you referred to the code
review as a solution. But then you said that common sense doesn't work.
Code review IS common sense for the most part though.
Either way, I'm not against enforced rules per se, but in this case, we are
clearly struggling to come up with a rule that could work. This and several
previous discussions show that.
It's also clear why we're struggling. Just one example: we have the rule to
abbreviate "exception" as "e". This is perfectly fine for the following
line:
catch (Exception e) {}
But then I see the following in your PR:
boolean isE = false;
I'm ready to argue that this is not an example of good code :) How would
you propose to fix that? It's really hard to set up generic rules like that
-- common sense is required.
Also, in general, the impression I get from your PR is that the code
becomes less readable. So many abbreviations simply make it look cryptic
and weird -- this might easily confuse a newcomer. And honestly, I have no
idea how to formalize this.
What is the exact problem that you're trying to solve? Is it that we have a
rule that is not followed because it's too complicated? In that case, I
propose to cancel the rule and then try to come up with more general
guidelines for contributors and reviewers. Again -- common sense is our
friend here.
WDYT?
-Val
On Tue, Jun 22, 2021 at 12:04 AM Nikolay Izhikov
wrote:
> Hello, Pavel
>
> > But it doesn't mean that now we need to use only full names.
> > Abbreviations may be used e.g. for local variables with short scope.
> > Here we must follow common sense and existing practices of effective
> naming.
> > It shouldn't be a cargo cult as it is now.
>
> But «common sense» has a very different definition for each community
> member.
>
> So, it seems, your proposal will end with different naming styles through
> codebase.
> Moreover, one reviewer will require «first» naming style and another
> «second» because of personal common sense.
>
> Personally, I believe strict automatically checked code style rules are
> better than common sense rules.
>
> Meanwhile, please, keep in mind that abbreviation rules is mandatory.
> And this discussion shown there are many Ignite developers who want to
> keep it.
>
> If someone wants to change or make it optional - please, start a vote.
>
>
> > 21 июня 2021 г., в 21:45, Pavel Kovalenko
> написал(а):
> >
> >>> But do you have a plan what should we do with the subject?
> >
> > I think we need to just turn off the required rule for abbreviations and
> > start to write new code without this requirement.
> > But it doesn't mean that now we need to use only full names.
> Abbreviations
> > may be used e.g. for local variables with short scope.
> > Here we must follow common sense and existing practices of effective
> > naming. It shouldn't be a cargo cult as it is now.
> > If there are doubts about naming they should be resolved on a code
> review.
> >
> > And we shouldn't rush to migrate all existing code to names without
> > existing abbreviations, it doesn't make sense - most core components are
> > modified very rarely now.
> > If you touch some class and you see that you can make existing naming
> > better - do it. But starting to renaming everything is the same cargo
> cult
> > but only of a different polarity.
> >
> >>> Actually it seems to me offtopic
> >
> > My concern was in Nikita's words that such rules about abbreviations
> > simplifies entry of new members that were actually not.
> > Every such rule actually complicates new member contributions. Statistics
> > above from Ilya just confirms it. Only 4 external valuable contributors
> for
> > 6 years of the project. 2 of them have been offline for the last 5 years.
> >
> > пн, 21 июн. 2021 г. в 05:00, Ivan Pavlukhin :
> >
> >> Hi Pavel,
> >>
> >> Thank you for sharing your thoughts! My personal opinion is very
> >> similar. But do you have a plan what should we do with the subject? Do
> >> you suggest to cleanup whole codebase from abbreviations? Or do you
> >> think that it is fine to keep existing code as is and avoid
> >> abbreviations for new code? Or something else?
> >>
> >>> Who can tell me at least 5 contributors with 10+ commits who are not
> >> working/worked in GridGain or SberBank? It's sad to hide behind an open
> >> source community that really does not exist.
> >>
> >> Actually it seems to me offtopic. But here my opinion is different. It
> >> is ok to me that the project is mainly driven by aforementioned
> >> companies. And I would rather care more about ease of single
> >> contributions. I contributed to other open source projects and did <
> >> 10 commits to each. Because in daily work generally we use stable
> >> libraries and can allow ourselves to work only with bugs or
> >> improvements in open source libraries. And I consider it a way to go
> >> in open source.
> >>
> >> 20
Re: IGNITE-14812: Statistics
Dmitry, As the PMC chair, would you mind contacting legal regarding the matter? This is not the only example of such code (e.g. [1]), so we should look into this asap. [1] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/mindrot/BCrypt.java As for this particular commit, can HLL be added as a dependency instead? Is there any particular reason to include the source code? @Sasha Belyak , can you please chime in? -Val On Tue, Jun 22, 2021 at 8:10 AM Dmitry Pavlov wrote: > Hi Nikolai, > > thank you for noticing. I guess it's not about license, but about > Intellectual Property (IP) ownership. > > AFAIK, Apache License 2.0 is here and AL 2.0 is definetely allowed to be > used in the codebase for an Apache project ( > https://www.apache.org/legal/resolved.html) > > But licenese and IP owner are 2 sligthly different things. E.g at the end > of any website you can find: > Copyright © 2021 The Apache Software Foundation, Licensed under the Apache > License, Version 2.0. > > Incubated projects are mandated to transfer IP to the ASF. And I'm not > aware of any exceptions. > > In this PR there are 5 classes which licenses with AL 2.0, but IP owner is > 3rd party company. > > I'm a bit concerned about having such code in the project. I'd rather > reverted it until we have approval from experts at mailing list: > legal-disc...@apache.org > > Sincerely, > Dmitriy Pavlov > > On 2021/06/22 14:56:49, Nikolay Izhikov wrote: > > Hello, Igniters. > > > > Recently huge commit was merged [1]. > > > > Taras, Alexander, can you, please, explain what is purpose of the commit? > > What feature it implemented? > > > > Looked inside the ticket and found no explanation. > > Description is "Add statistics collection and usage.» > > > > Do we have plans to document this new feature? > > > > Also, I see very strange license in added files [2] > > > > ``` > > * Copyright 2013 Aggregate Knowledge, Inc. > > * > > * Licensed under the Apache License, Version 2.0 (the "License"); > > ``` > > > > Is it OK to have those copyright inside ASF codebase? > > Is it some kind of external dependency we adopted as part of the code? > > Why do we need it? > > > > [1] > https://github.com/apache/ignite/commit/503a98495433e1d0cf84f8be8c1e2adc57034fbb > > [2] > https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/stat/hll/serialization/IHLLMetadata.java >
Re: [DISCUSSION] Code style. Variable abbrevations
What's worked for countless companies is the combination of the following:
1. Well defined rules (abbreviations, code styles & documentation, code
organization, etc., etc.) for common/frequent use cases.
2. Some basic tooling (wherever possible) plus a strong culture of code
reviews.
3. And... common sense! None of the rules in (1) are axiomatic but rather a
guidance that requires common sense.
Code review culture takes time and organizational discipline to become
effective & productive. Rules alone or some fiat enforcement is unlikely to
work.
--
Nikita Ivanov
On Tue, Jun 22, 2021 at 4:44 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Nikolay,
>
> I'm confused. Konstantin gave you an example of a bad abbreviation that
> cannot be caught by automated validation, and you referred to the code
> review as a solution. But then you said that common sense doesn't work.
> Code review IS common sense for the most part though.
>
> Either way, I'm not against enforced rules per se, but in this case, we are
> clearly struggling to come up with a rule that could work. This and several
> previous discussions show that.
>
> It's also clear why we're struggling. Just one example: we have the rule to
> abbreviate "exception" as "e". This is perfectly fine for the following
> line:
>
> catch (Exception e) {}
>
> But then I see the following in your PR:
>
> boolean isE = false;
>
> I'm ready to argue that this is not an example of good code :) How would
> you propose to fix that? It's really hard to set up generic rules like that
> -- common sense is required.
>
> Also, in general, the impression I get from your PR is that the code
> becomes less readable. So many abbreviations simply make it look cryptic
> and weird -- this might easily confuse a newcomer. And honestly, I have no
> idea how to formalize this.
>
> What is the exact problem that you're trying to solve? Is it that we have a
> rule that is not followed because it's too complicated? In that case, I
> propose to cancel the rule and then try to come up with more general
> guidelines for contributors and reviewers. Again -- common sense is our
> friend here.
>
> WDYT?
>
> -Val
>
> On Tue, Jun 22, 2021 at 12:04 AM Nikolay Izhikov
> wrote:
>
> > Hello, Pavel
> >
> > > But it doesn't mean that now we need to use only full names.
> > > Abbreviations may be used e.g. for local variables with short scope.
> > > Here we must follow common sense and existing practices of effective
> > naming.
> > > It shouldn't be a cargo cult as it is now.
> >
> > But «common sense» has a very different definition for each community
> > member.
> >
> > So, it seems, your proposal will end with different naming styles through
> > codebase.
> > Moreover, one reviewer will require «first» naming style and another
> > «second» because of personal common sense.
> >
> > Personally, I believe strict automatically checked code style rules are
> > better than common sense rules.
> >
> > Meanwhile, please, keep in mind that abbreviation rules is mandatory.
> > And this discussion shown there are many Ignite developers who want to
> > keep it.
> >
> > If someone wants to change or make it optional - please, start a vote.
> >
> >
> > > 21 июня 2021 г., в 21:45, Pavel Kovalenko
> > написал(а):
> > >
> > >>> But do you have a plan what should we do with the subject?
> > >
> > > I think we need to just turn off the required rule for abbreviations
> and
> > > start to write new code without this requirement.
> > > But it doesn't mean that now we need to use only full names.
> > Abbreviations
> > > may be used e.g. for local variables with short scope.
> > > Here we must follow common sense and existing practices of effective
> > > naming. It shouldn't be a cargo cult as it is now.
> > > If there are doubts about naming they should be resolved on a code
> > review.
> > >
> > > And we shouldn't rush to migrate all existing code to names without
> > > existing abbreviations, it doesn't make sense - most core components
> are
> > > modified very rarely now.
> > > If you touch some class and you see that you can make existing naming
> > > better - do it. But starting to renaming everything is the same cargo
> > cult
> > > but only of a different polarity.
> > >
> > >>> Actually it seems to me offtopic
> > >
> > > My concern was in Nikita's words that such rules about abbreviations
> > > simplifies entry of new members that were actually not.
> > > Every such rule actually complicates new member contributions.
> Statistics
> > > above from Ilya just confirms it. Only 4 external valuable contributors
> > for
> > > 6 years of the project. 2 of them have been offline for the last 5
> years.
> > >
> > > пн, 21 июн. 2021 г. в 05:00, Ivan Pavlukhin :
> > >
> > >> Hi Pavel,
> > >>
> > >> Thank you for sharing your thoughts! My personal opinion is very
> > >> similar. But do you have a plan what should we do with the subject? Do
> > >> you suggest to cleanup whole codebase from abbrev
Re: [DISCUSSION] Code style. Variable abbrevations
Folks,
I suppose we should rollout voting regarding abbreviations in Ignite 3.
BTW, are you actually aware of any other project defining something similar to
our abbreviations?
Sent from my iPhone
> On 23 Jun 2021, at 14:53, Nikita Ivanov wrote:
>
> What's worked for countless companies is the combination of the following:
> 1. Well defined rules (abbreviations, code styles & documentation, code
> organization, etc., etc.) for common/frequent use cases.
> 2. Some basic tooling (wherever possible) plus a strong culture of code
> reviews.
> 3. And... common sense! None of the rules in (1) are axiomatic but rather a
> guidance that requires common sense.
>
> Code review culture takes time and organizational discipline to become
> effective & productive. Rules alone or some fiat enforcement is unlikely to
> work.
> --
> Nikita Ivanov
>
>
>
> On Tue, Jun 22, 2021 at 4:44 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
>> Nikolay,
>>
>> I'm confused. Konstantin gave you an example of a bad abbreviation that
>> cannot be caught by automated validation, and you referred to the code
>> review as a solution. But then you said that common sense doesn't work.
>> Code review IS common sense for the most part though.
>>
>> Either way, I'm not against enforced rules per se, but in this case, we are
>> clearly struggling to come up with a rule that could work. This and several
>> previous discussions show that.
>>
>> It's also clear why we're struggling. Just one example: we have the rule to
>> abbreviate "exception" as "e". This is perfectly fine for the following
>> line:
>>
>>catch (Exception e) {}
>>
>> But then I see the following in your PR:
>>
>>boolean isE = false;
>>
>> I'm ready to argue that this is not an example of good code :) How would
>> you propose to fix that? It's really hard to set up generic rules like that
>> -- common sense is required.
>>
>> Also, in general, the impression I get from your PR is that the code
>> becomes less readable. So many abbreviations simply make it look cryptic
>> and weird -- this might easily confuse a newcomer. And honestly, I have no
>> idea how to formalize this.
>>
>> What is the exact problem that you're trying to solve? Is it that we have a
>> rule that is not followed because it's too complicated? In that case, I
>> propose to cancel the rule and then try to come up with more general
>> guidelines for contributors and reviewers. Again -- common sense is our
>> friend here.
>>
>> WDYT?
>>
>> -Val
>>
>> On Tue, Jun 22, 2021 at 12:04 AM Nikolay Izhikov
>> wrote:
>>
>>> Hello, Pavel
>>>
But it doesn't mean that now we need to use only full names.
Abbreviations may be used e.g. for local variables with short scope.
Here we must follow common sense and existing practices of effective
>>> naming.
It shouldn't be a cargo cult as it is now.
>>>
>>> But «common sense» has a very different definition for each community
>>> member.
>>>
>>> So, it seems, your proposal will end with different naming styles through
>>> codebase.
>>> Moreover, one reviewer will require «first» naming style and another
>>> «second» because of personal common sense.
>>>
>>> Personally, I believe strict automatically checked code style rules are
>>> better than common sense rules.
>>>
>>> Meanwhile, please, keep in mind that abbreviation rules is mandatory.
>>> And this discussion shown there are many Ignite developers who want to
>>> keep it.
>>>
>>> If someone wants to change or make it optional - please, start a vote.
>>>
>>>
21 июня 2021 г., в 21:45, Pavel Kovalenko
>>> написал(а):
>> But do you have a plan what should we do with the subject?
I think we need to just turn off the required rule for abbreviations
>> and
start to write new code without this requirement.
But it doesn't mean that now we need to use only full names.
>>> Abbreviations
may be used e.g. for local variables with short scope.
Here we must follow common sense and existing practices of effective
naming. It shouldn't be a cargo cult as it is now.
If there are doubts about naming they should be resolved on a code
>>> review.
And we shouldn't rush to migrate all existing code to names without
existing abbreviations, it doesn't make sense - most core components
>> are
modified very rarely now.
If you touch some class and you see that you can make existing naming
better - do it. But starting to renaming everything is the same cargo
>>> cult
but only of a different polarity.
>> Actually it seems to me offtopic
My concern was in Nikita's words that such rules about abbreviations
simplifies entry of new members that were actually not.
Every such rule actually complicates new member contributions.
>> Statistics
above from Ilya just confirms it. Only 4 external valuable contributors
>>> for
6 years of the project. 2 of them hav
Re: IGNITE-14812: Statistics
Hi, We have discussed BCrypt include/add dependency here [1]. AFAIK and as long as I can remember Ignite project try to minimize external dependencies usage and adds new external dependency only when there is no other way out. [1]. http://apache-ignite-developers.2346864.n4.nabble.com/Username-password-authentication-for-thin-clients-tp26058p26954.html On 23.06.2021 3:08, Valentin Kulichenko wrote: Dmitry, As the PMC chair, would you mind contacting legal regarding the matter? This is not the only example of such code (e.g. [1]), so we should look into this asap. [1] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/mindrot/BCrypt.java As for this particular commit, can HLL be added as a dependency instead? Is there any particular reason to include the source code? @Sasha Belyak , can you please chime in? -Val On Tue, Jun 22, 2021 at 8:10 AM Dmitry Pavlov wrote: Hi Nikolai, thank you for noticing. I guess it's not about license, but about Intellectual Property (IP) ownership. AFAIK, Apache License 2.0 is here and AL 2.0 is definetely allowed to be used in the codebase for an Apache project ( https://www.apache.org/legal/resolved.html) But licenese and IP owner are 2 sligthly different things. E.g at the end of any website you can find: Copyright © 2021 The Apache Software Foundation, Licensed under the Apache License, Version 2.0. Incubated projects are mandated to transfer IP to the ASF. And I'm not aware of any exceptions. In this PR there are 5 classes which licenses with AL 2.0, but IP owner is 3rd party company. I'm a bit concerned about having such code in the project. I'd rather reverted it until we have approval from experts at mailing list: legal-disc...@apache.org Sincerely, Dmitriy Pavlov On 2021/06/22 14:56:49, Nikolay Izhikov wrote: Hello, Igniters. Recently huge commit was merged [1]. Taras, Alexander, can you, please, explain what is purpose of the commit? What feature it implemented? Looked inside the ticket and found no explanation. Description is "Add statistics collection and usage.» Do we have plans to document this new feature? Also, I see very strange license in added files [2] ``` * Copyright 2013 Aggregate Knowledge, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); ``` Is it OK to have those copyright inside ASF codebase? Is it some kind of external dependency we adopted as part of the code? Why do we need it? [1] https://github.com/apache/ignite/commit/503a98495433e1d0cf84f8be8c1e2adc57034fbb [2] https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/stat/hll/serialization/IHLLMetadata.java -- Taras Ledkov Mail-To: tled...@gridgain.com
Re: IGNITE-14812: Statistics
Hello, Taras. Thanks for feedback. > AFAIK and as long as I can remember Ignite project try to minimize external > dependencies usage and adds new external dependency only when there is no > other way out. Does it mean we have to incapsulate every external library we want to use? Taras, can you, please, describe the features that was implemented in this merge? How users supposed to use them? Do we have plans to document? > 23 июня 2021 г., в 09:21, Taras Ledkov написал(а): > > Hi, > > We have discussed BCrypt include/add dependency here [1]. > AFAIK and as long as I can remember Ignite project try to minimize external > dependencies usage > and adds new external dependency only when there is no other way out. > > [1]. > http://apache-ignite-developers.2346864.n4.nabble.com/Username-password-authentication-for-thin-clients-tp26058p26954.html > > On 23.06.2021 3:08, Valentin Kulichenko wrote: >> Dmitry, >> >> As the PMC chair, would you mind contacting legal regarding the matter? >> This is not the only example of such code (e.g. [1]), so we should look >> into this asap. >> >> [1] >> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/mindrot/BCrypt.java >> >> As for this particular commit, can HLL be added as a dependency instead? Is >> there any particular reason to include the source code? @Sasha Belyak >> , can you please chime in? >> >> -Val >> >> On Tue, Jun 22, 2021 at 8:10 AM Dmitry Pavlov wrote: >> >>> Hi Nikolai, >>> >>> thank you for noticing. I guess it's not about license, but about >>> Intellectual Property (IP) ownership. >>> >>> AFAIK, Apache License 2.0 is here and AL 2.0 is definetely allowed to be >>> used in the codebase for an Apache project ( >>> https://www.apache.org/legal/resolved.html) >>> >>> But licenese and IP owner are 2 sligthly different things. E.g at the end >>> of any website you can find: >>> Copyright © 2021 The Apache Software Foundation, Licensed under the Apache >>> License, Version 2.0. >>> >>> Incubated projects are mandated to transfer IP to the ASF. And I'm not >>> aware of any exceptions. >>> >>> In this PR there are 5 classes which licenses with AL 2.0, but IP owner is >>> 3rd party company. >>> >>> I'm a bit concerned about having such code in the project. I'd rather >>> reverted it until we have approval from experts at mailing list: >>> legal-disc...@apache.org >>> >>> Sincerely, >>> Dmitriy Pavlov >>> >>> On 2021/06/22 14:56:49, Nikolay Izhikov wrote: Hello, Igniters. Recently huge commit was merged [1]. Taras, Alexander, can you, please, explain what is purpose of the commit? What feature it implemented? Looked inside the ticket and found no explanation. Description is "Add statistics collection and usage.» Do we have plans to document this new feature? Also, I see very strange license in added files [2] ``` * Copyright 2013 Aggregate Knowledge, Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); ``` Is it OK to have those copyright inside ASF codebase? Is it some kind of external dependency we adopted as part of the code? Why do we need it? [1] >>> https://github.com/apache/ignite/commit/503a98495433e1d0cf84f8be8c1e2adc57034fbb [2] >>> https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/stat/hll/serialization/IHLLMetadata.java >>> > -- > Taras Ledkov > Mail-To: tled...@gridgain.com >
