anybody can help me to do a code review for PR https://github.com/apache/ignite/pull/35

[kcheng.mvp]

Hi Devs,

Anybody can help me to do a code review for PR

https://github.com/apache/ignite/pull/35

Thanks,
kcheng

[kcheng.mvp]

I noticed that there are some build failure, how to fix such issue:

I have execute the command "mvn clean validate -Pcheck-licenses" there are
no issues reported.

Build errors
[06:31:29]Step 4/7: Check License Headers (by RAT) (Maven) (7s)
[06:31:34][Step 4/7] org.apache.ignite:ignite-platform
[06:31:34][org.apache.ignite:ignite-platform] Failed to execute goal
org.apache.rat:apache-rat-plugin:0.11:check (default) on project
ignite-platform: Too many files with unapproved license: 1 See RAT report
in:
/home/teamcity/agent/work/cf2353597844dbf3/modules/platform/target/rat.txt
[06:31:36][Step 4/7] Step Check License Headers (by RAT) (Maven) failed



Thanks,
kcheng

On Wed, Aug 26, 2015 at 1:53 PM, Ken Cheng <[hidden email]> wrote:

> Hi Devs,
>
> Anybody can help me to do a code review for PR
>
> https://github.com/apache/ignite/pull/35
>
> Thanks,
> kcheng
>

[Alexey Goncharuk]

Ken, I added comments to the pull request on GitHub.

I would prefer another committer to review this pull request as well since
public API is being changed (Dmitriy, Yakov?)

--
AG

2015-08-25 22:53 GMT-07:00 Ken Cheng <[hidden email]>:

> Hi Devs,
>
> Anybody can help me to do a code review for PR
>
> https://github.com/apache/ignite/pull/35
>
> Thanks,
> kcheng
>

[Konstantin Boudnik-2]

Reading this I thought it would be a good idea to articulate some of the
possible challenges that we will face in the future.

Say, how we add/release incompatible changes like API modifications,
deprecations, etc. Say, introduction of incompatible changes shouldn't be done
in minor release of a project: Scala "transition" 2.9 -> 2.10 comes to mind as
a biggest screw-up of the kind. Hence, to avoid being a laughing stock of the
world's developers it would makes perfect sense to have some of these
seemingly obvious principles either written or referred among other
development resources.

Thoughts?
    Cos

On Tue, Aug 25, 2015 at 11:17PM, Alexey Goncharuk wrote:

> Ken, I added comments to the pull request on GitHub.
>
> I would prefer another committer to review this pull request as well since
> public API is being changed (Dmitriy, Yakov?)
>
> --
> AG
>
> 2015-08-25 22:53 GMT-07:00 Ken Cheng <[hidden email]>:
>
> > Hi Devs,
> >
> > Anybody can help me to do a code review for PR
> >
> > https://github.com/apache/ignite/pull/35
> >
> > Thanks,
> > kcheng
> >

[Alexey Goncharuk]

This particular change does not break the compatibility (a new method is
being added to the public API), however I am +1 for adding these principles
to the dev documentation.

2015-08-25 23:44 GMT-07:00 Konstantin Boudnik <[hidden email]>:

> Reading this I thought it would be a good idea to articulate some of the
> possible challenges that we will face in the future.
>
> Say, how we add/release incompatible changes like API modifications,
> deprecations, etc. Say, introduction of incompatible changes shouldn't be
> done
> in minor release of a project: Scala "transition" 2.9 -> 2.10 comes to
> mind as
> a biggest screw-up of the kind. Hence, to avoid being a laughing stock of
> the
> world's developers it would makes perfect sense to have some of these
> seemingly obvious principles either written or referred among other
> development resources.
>
> Thoughts?
>     Cos
>
> On Tue, Aug 25, 2015 at 11:17PM, Alexey Goncharuk wrote:
> > Ken, I added comments to the pull request on GitHub.
> >
> > I would prefer another committer to review this pull request as well
> since
> > public API is being changed (Dmitriy, Yakov?)
> >
> > --
> > AG
> >
> > 2015-08-25 22:53 GMT-07:00 Ken Cheng <[hidden email]>:
> >
> > > Hi Devs,
> > >
> > > Anybody can help me to do a code review for PR
> > >
> > > https://github.com/apache/ignite/pull/35
> > >
> > > Thanks,
> > > kcheng
> > >
>

[Branko Čibej]

On 26.08.2015 08:54, Alexey Goncharuk wrote:
> This particular change does not break the compatibility (a new method is
> being added to the public API), however I am +1 for adding these principles
> to the dev documentation.

Way back when Ignite was still a podling I pointed out this:

    http://apr.apache.org/versioning.html
   
http://subversion.apache.org/docs/community-guide/releasing.html#release-compat

As I did then, I suggest we either refer to these docs directly, or copy
over essentially the same principles to our docs.

-- Brane

> 2015-08-25 23:44 GMT-07:00 Konstantin Boudnik <[hidden email]>:
>
>> Reading this I thought it would be a good idea to articulate some of the
>> possible challenges that we will face in the future.
>>
>> Say, how we add/release incompatible changes like API modifications,
>> deprecations, etc. Say, introduction of incompatible changes shouldn't be
>> done
>> in minor release of a project: Scala "transition" 2.9 -> 2.10 comes to
>> mind as
>> a biggest screw-up of the kind. Hence, to avoid being a laughing stock of
>> the
>> world's developers it would makes perfect sense to have some of these
>> seemingly obvious principles either written or referred among other
>> development resources.
>>
>> Thoughts?
>>     Cos
>>
>> On Tue, Aug 25, 2015 at 11:17PM, Alexey Goncharuk wrote:
>>> Ken, I added comments to the pull request on GitHub.
>>>
>>> I would prefer another committer to review this pull request as well
>> since
>>> public API is being changed (Dmitriy, Yakov?)
>>>
>>> --
>>> AG
>>>
>>> 2015-08-25 22:53 GMT-07:00 Ken Cheng <[hidden email]>:
>>>
>>>> Hi Devs,
>>>>
>>>> Anybody can help me to do a code review for PR
>>>>
>>>> https://github.com/apache/ignite/pull/35
>>>>
>>>> Thanks,
>>>> kcheng
>>>>

[Vladimir Ozerov]

One more important thing here - distinction between overall compatibility
and module compatibility. We may face serious bugs which severely affects
single module/subsystem and fix will break backward ocmpatibility only on
of that module.
E.g. currently in IGFS file might be locked for write forever in case of
abrupt shutdown of a node from which this write were initiated. The only
way to fix this reliably is to change an object which travels over a wire,
what might break backward compatibility.

May be we should be able to relax compatibility requirements on module
level sometimes?

Vladimir.

On Wed, Aug 26, 2015 at 10:40 AM, Branko Čibej <[hidden email]> wrote:

> On 26.08.2015 08:54, Alexey Goncharuk wrote:
> > This particular change does not break the compatibility (a new method is
> > being added to the public API), however I am +1 for adding these
> principles
> > to the dev documentation.
>
> Way back when Ignite was still a podling I pointed out this:
>
>     http://apr.apache.org/versioning.html
>
>
> http://subversion.apache.org/docs/community-guide/releasing.html#release-compat
>
> As I did then, I suggest we either refer to these docs directly, or copy
> over essentially the same principles to our docs.
>
> -- Brane
>
>
> > 2015-08-25 23:44 GMT-07:00 Konstantin Boudnik <[hidden email]>:
> >
> >> Reading this I thought it would be a good idea to articulate some of the
> >> possible challenges that we will face in the future.
> >>
> >> Say, how we add/release incompatible changes like API modifications,
> >> deprecations, etc. Say, introduction of incompatible changes shouldn't
> be
> >> done
> >> in minor release of a project: Scala "transition" 2.9 -> 2.10 comes to
> >> mind as
> >> a biggest screw-up of the kind. Hence, to avoid being a laughing stock
> of
> >> the
> >> world's developers it would makes perfect sense to have some of these
> >> seemingly obvious principles either written or referred among other
> >> development resources.
> >>
> >> Thoughts?
> >>     Cos
> >>
> >> On Tue, Aug 25, 2015 at 11:17PM, Alexey Goncharuk wrote:
> >>> Ken, I added comments to the pull request on GitHub.
> >>>
> >>> I would prefer another committer to review this pull request as well
> >> since
> >>> public API is being changed (Dmitriy, Yakov?)
> >>>
> >>> --
> >>> AG
> >>>
> >>> 2015-08-25 22:53 GMT-07:00 Ken Cheng <[hidden email]>:
> >>>
> >>>> Hi Devs,
> >>>>
> >>>> Anybody can help me to do a code review for PR
> >>>>
> >>>> https://github.com/apache/ignite/pull/35
> >>>>
> >>>> Thanks,
> >>>> kcheng
> >>>>
>
>

[kcheng.mvp]

Hi Alexey,

Thank you very much!
I did the changes according your comments;

Dmitriy & Yako can you help to review the code?

https://github.com/apache/ignite/pull/35


Thanks,
kcheng

On Wed, Aug 26, 2015 at 2:17 PM, Alexey Goncharuk <
[hidden email]> wrote:

> Ken, I added comments to the pull request on GitHub.
>
> I would prefer another committer to review this pull request as well since
> public API is being changed (Dmitriy, Yakov?)
>
> --
> AG
>
> 2015-08-25 22:53 GMT-07:00 Ken Cheng <[hidden email]>:
>
> > Hi Devs,
> >
> > Anybody can help me to do a code review for PR
> >
> > https://github.com/apache/ignite/pull/35
> >
> > Thanks,
> > kcheng
> >
>

[Branko Čibej]

On 26.08.2015 15:56, Vladimir Ozerov wrote:

> One more important thing here - distinction between overall compatibility
> and module compatibility. We may face serious bugs which severely affects
> single module/subsystem and fix will break backward ocmpatibility only on
> of that module.
> E.g. currently in IGFS file might be locked for write forever in case of
> abrupt shutdown of a node from which this write were initiated. The only
> way to fix this reliably is to change an object which travels over a wire,
> what might break backward compatibility.
>
> May be we should be able to relax compatibility requirements on module
> level sometimes?

It's better to have the same kind of versioning rules for the wire
protocol, too; a capability discovery can tell you when you can use a
new kind of message.

I don't know how important this kind of compatibility is for Ignite;
it's extremely important in Subversion, because it allows independent
updates/rollbacks of servers and clients.

Or you can avoid the compatibility issue by calling the fixed protocol
Ignite 2.0. :)

-- Brane


On Wed, Aug 26, 2015 at 10:40 AM, Branko Čibej <[hidden email]> wrote:

>> On 26.08.2015 08:54, Alexey Goncharuk wrote:
>>> This particular change does not break the compatibility (a new method is
>>> being added to the public API), however I am +1 for adding these
>> principles
>>> to the dev documentation.
>> Way back when Ignite was still a podling I pointed out this:
>>
>>     http://apr.apache.org/versioning.html
>>
>>
>> http://subversion.apache.org/docs/community-guide/releasing.html#release-compat
>>
>> As I did then, I suggest we either refer to these docs directly, or copy
>> over essentially the same principles to our docs.
>>
>> -- Brane
>>
>>
>>> 2015-08-25 23:44 GMT-07:00 Konstantin Boudnik <[hidden email]>:
>>>
>>>> Reading this I thought it would be a good idea to articulate some of the
>>>> possible challenges that we will face in the future.
>>>>
>>>> Say, how we add/release incompatible changes like API modifications,
>>>> deprecations, etc. Say, introduction of incompatible changes shouldn't
>> be
>>>> done
>>>> in minor release of a project: Scala "transition" 2.9 -> 2.10 comes to
>>>> mind as
>>>> a biggest screw-up of the kind. Hence, to avoid being a laughing stock
>> of
>>>> the
>>>> world's developers it would makes perfect sense to have some of these
>>>> seemingly obvious principles either written or referred among other
>>>> development resources.
>>>>
>>>> Thoughts?
>>>>     Cos
>>>>
>>>> On Tue, Aug 25, 2015 at 11:17PM, Alexey Goncharuk wrote:
>>>>> Ken, I added comments to the pull request on GitHub.
>>>>>
>>>>> I would prefer another committer to review this pull request as well
>>>> since
>>>>> public API is being changed (Dmitriy, Yakov?)
>>>>>
>>>>> --
>>>>> AG
>>>>>
>>>>> 2015-08-25 22:53 GMT-07:00 Ken Cheng <[hidden email]>:
>>>>>
>>>>>> Hi Devs,
>>>>>>
>>>>>> Anybody can help me to do a code review for PR
>>>>>>
>>>>>> https://github.com/apache/ignite/pull/35
>>>>>>
>>>>>> Thanks,
>>>>>> kcheng
>>>>>>
>>

[Konstantin Boudnik-2]

Yup, big +1's on both points: the versioning schema (thanks a bunch for
digging it up, Brane!) and sticking to a stricter compatibility rules.
Integers are cheap and abundant, but conveying the clear message that say 2.0
isn't compatible with 1.4 because of XYZ in hadoop module is important. It is
a far clearer than "2.0 and 1.4 are fine, except that hadoop module isn't
because of XYZ".

Regards,
  Cos

On Wed, Aug 26, 2015 at 07:35PM, Branko Čibej wrote:

> On 26.08.2015 15:56, Vladimir Ozerov wrote:
> > One more important thing here - distinction between overall compatibility
> > and module compatibility. We may face serious bugs which severely affects
> > single module/subsystem and fix will break backward ocmpatibility only on
> > of that module.
> > E.g. currently in IGFS file might be locked for write forever in case of
> > abrupt shutdown of a node from which this write were initiated. The only
> > way to fix this reliably is to change an object which travels over a wire,
> > what might break backward compatibility.
> >
> > May be we should be able to relax compatibility requirements on module
> > level sometimes?
>
> It's better to have the same kind of versioning rules for the wire
> protocol, too; a capability discovery can tell you when you can use a
> new kind of message.
>
> I don't know how important this kind of compatibility is for Ignite;
> it's extremely important in Subversion, because it allows independent
> updates/rollbacks of servers and clients.
>
> Or you can avoid the compatibility issue by calling the fixed protocol
> Ignite 2.0. :)
>
> -- Brane
>
>
> On Wed, Aug 26, 2015 at 10:40 AM, Branko Čibej <[hidden email]> wrote:
> >> On 26.08.2015 08:54, Alexey Goncharuk wrote:
> >>> This particular change does not break the compatibility (a new method is
> >>> being added to the public API), however I am +1 for adding these
> >> principles
> >>> to the dev documentation.
> >> Way back when Ignite was still a podling I pointed out this:
> >>
> >>     http://apr.apache.org/versioning.html
> >>
> >>
> >> http://subversion.apache.org/docs/community-guide/releasing.html#release-compat
> >>
> >> As I did then, I suggest we either refer to these docs directly, or copy
> >> over essentially the same principles to our docs.
> >>
> >> -- Brane
> >>
> >>
> >>> 2015-08-25 23:44 GMT-07:00 Konstantin Boudnik <[hidden email]>:
> >>>
> >>>> Reading this I thought it would be a good idea to articulate some of the
> >>>> possible challenges that we will face in the future.
> >>>>
> >>>> Say, how we add/release incompatible changes like API modifications,
> >>>> deprecations, etc. Say, introduction of incompatible changes shouldn't
> >> be
> >>>> done
> >>>> in minor release of a project: Scala "transition" 2.9 -> 2.10 comes to
> >>>> mind as
> >>>> a biggest screw-up of the kind. Hence, to avoid being a laughing stock
> >> of
> >>>> the
> >>>> world's developers it would makes perfect sense to have some of these
> >>>> seemingly obvious principles either written or referred among other
> >>>> development resources.
> >>>>
> >>>> Thoughts?
> >>>>     Cos
> >>>>
> >>>> On Tue, Aug 25, 2015 at 11:17PM, Alexey Goncharuk wrote:
> >>>>> Ken, I added comments to the pull request on GitHub.
> >>>>>
> >>>>> I would prefer another committer to review this pull request as well
> >>>> since
> >>>>> public API is being changed (Dmitriy, Yakov?)
> >>>>>
> >>>>> --
> >>>>> AG
> >>>>>
> >>>>> 2015-08-25 22:53 GMT-07:00 Ken Cheng <[hidden email]>:
> >>>>>
> >>>>>> Hi Devs,
> >>>>>>
> >>>>>> Anybody can help me to do a code review for PR
> >>>>>>
> >>>>>> https://github.com/apache/ignite/pull/35
> >>>>>>
> >>>>>> Thanks,
> >>>>>> kcheng
> >>>>>>
> >>
>