Re: I would like to work on the jira IGNITE-1226

[Branko Čibej]

On 24.08.2015 20:54, Ken Cheng wrote:
> Hi devs,
>
> please add my email address kcheng@gmail.com to the dev subscription
> list.

Why don't you just subscribe? Instructions are here:
http://ignite.apache.org/community/resources.html#mail-lists

-- Brane

Re: Code is ready for bug fix https://issues.apache.org/jira/browse/IGNITE-1226

[Branko Čibej]

On 25.08.2015 11:58, Raul Kripalani wrote:
> The Github repo of Ignite is read only. It's just a mirror of the Apache
> repo.
>
> You need to fork it into your own Github account. Then you clone the fork
> locally and push the branch to it.
>
> Later, you open a Pull Request to the apache/ignite repo, making sure that
> you include the ticket number (IGNITE-) in the description.
>
> The ASF Github bot will pick up the pull request and notify the Dev team on
> the mailing list and on JIRA.


And does everyone who's writing these instructions really think this is
a reasonable process for new contributors? Why not just clone from
git-wip-us, make the change on a local branch and either send the patch
to the dev list or attach it to the Jira issue? There's no sane reason
to involve GitHub at all.

As it is, you're telling him to jump through 4 hoops when he could just
as easily get the same done by jumping through 2. Meh.

-- Brane



> On 25 Aug 2015 10:49, "Ken Cheng"  wrote:
>
>> [image: Inline image 1]
>>
>> Just as the screen shows, I have created a branch with the Jira number,
>> but when I try to push my fix it promotes me to input username/password, I
>> tried with my github account but got the authentication failure.
>>
>> Thanks,
>> kcheng
>>
>> On Tue, Aug 25, 2015 at 5:44 PM, Alexey Kuznetsov >> wrote:
>>> Ken,
>>>
>>> Please, get familiar with process
>>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>>>
>>> In short, you should fork apache-ignite on git hub, create branch, push
>>> you
>>> fixes and create a pull request.
>>>
>>> Someone from committers will review your patch and merge it or give you a
>>> review comments.
>>>
>>> Hope this help.
>>>
>>> On Tue, Aug 25, 2015 at 4:40 PM, Ken Cheng  wrote:
>>>
 grant me the write privilege to github, as I need user/password to push
>>> my
 fix.

 Thanks,
 kcheng

 On Tue, Aug 25, 2015 at 5:36 PM, Ken Cheng 
>>> wrote:
> Hi All,
>
> My first fix for Ignite
 https://issues.apache.org/jira/browse/IGNITE-1226
> is ready.
> Can someone grant the write privilege to github?
>
>
> Thanks,
> kcheng
>
>>>
>>>
>>> --
>>> Alexey Kuznetsov
>>> GridGain Systems
>>> www.gridgain.com
>>>
>>

Re: Contribution routes to Apache Ignite - updating the website

[Branko Čibej]

On 25.08.2015 13:09, Raul Kripalani wrote:
> The "Start Contributing" section is somewhat unclear and outdated IMHO.
> Unfortunately since this is not Wiki, I cannot modify it (where is the
> site's source?).


The site is, of course, in Subversion at
https://svn.apache.org/repos/asf/ignite/site/trunk. Any changes are
automatically published on commit via SVNPubSub.

-- Brane

Re: [DiSCUSS] Incompatible changes

[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 :
>
>> 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 :
>>>
 Hi Devs,

 Anybody can help me to do a code review for PR

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

 Thanks,
 kcheng

Re: [DiSCUSS] Incompatible changes

[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  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 :
>>>
>>>> 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 :
>>>>>
>>>>>> Hi Devs,
>>>>>>
>>>>>> Anybody can help me to do a code review for PR
>>>>>>
>>>>>> https://github.com/apache/ignite/pull/35
>>>>>>
>>>>>> Thanks,
>>>>>> kcheng
>>>>>>
>>

Re: Documentation by contributors

[Branko Čibej]

On 26.08.2015 21:02, Dmitriy Setrakyan wrote:
> On Wed, Aug 26, 2015 at 9:15 PM, Konstantin Boudnik  wrote:
>
>> On Wed, Aug 26, 2015 at 09:07PM, Dmitriy Setrakyan wrote:
>>> On Wed, Aug 26, 2015 at 8:44 PM, Konstantin Boudnik 
>> wrote:
 Just as a friendly reminder: readme.io hosting still opens us to the
 issue we've been
 discussing at length. Namely - the source of the documentation isn't
 hosted on
 the Apache premises. I remember there were some conversations with
 readme.io
 folks to add some extras for the imports or something like that. Were
>> there
 any follow-ups on that front?

>>> Cos, good point. I was actually going to start a thread about this.
>>> Readme.io actually is replicated in GitHub with by-directional
>> integration
>>> here:
>>>
>>> https://github.com/apacheignite/documentation
>>>
>>> The only thing we need is to move this repository to Apache, with Readme
>>> application having access to it. If there are no objections, I will
>> start a
>>> discussion with INFRA on this. Let me know your thoughts.
>> this 'documentation' repo is the official project documentation, as far as
>> I
>> remember? If so - yes, let's move it to Apache git. Also, I don't see a
>> reason to keep it separated from the rest of the source code - it's a part
>> of the project. And it would be easier to track the documentation relevance
>> to the releases if they are together, IMO.
>>
> I think it should be a separate repo, mainly because we probably should not
> allow a 3rd party app have write privilege to our main repo.

We've been through this before. No 3rd-party app (IOW,
untrusted/uncontrolled account) should have write access to *any* ASF
repository. Doesn't matter if you put docs in a separate repo or not;
some bot at readme.io *will not* have write access.

>  On top of
> that, readme.io process has already been tested this way and it works (I
> don't think there is a need to ask them to change it).
>
> If we setup a new repo, do you think Apache GIT would allow an external
> application to connect to it?

See above, not even in your dreams.

The way to do this is for readme.io to provide some way to export the
documentation contents, then we can set up automation *within* the ASF
to update docs in an internal repo.

Even then, there's the question of authorship tracking. Any non-trivial
documentation change requires an ICLA just like code.

-- Brane

Re: How to fix build failure Check License Headers (by RAT) (Maven

[Branko Čibej]

On 27.08.2015 17:56, Ken Cheng wrote:
> I got below error in the TC, how to fix such issue?
>
> [12:27:35]Step 4/8: Check License Headers (by RAT) (Maven) (7s)
> [12:27:41][Step 4/8] org.apache.ignite:ignite-platform
> [12:27:41][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
> [12:27:43][Step 4/8] Step Check License Headers (by RAT) (Maven) failed
> [12:27:43]Step 7/8: Build and run tests (Maven)
> [12:27:44][Step 7/8] Step Build and run tests (Maven) failed

Did you add a new file without the required license header?

-- Brane

Re: How to fix build failure Check License Headers (by RAT) (Maven

[Branko Čibej]

On 27.08.2015 18:13, Ken Cheng wrote:
> Summary
> ---
> Generated at: 2015-08-28T00:09:54+08:00
> Notes: 0
> Binaries: 0
> Archives: 0
> Standards: 41
>
> Apache Licensed: 0
> Generated Documents: 0
>
> JavaDocs are generated and so license header is optional
> Generated files do not required license headers
>
> 1 Unknown Licenses
>
> ***
>
> Unapproved licenses:
>
>
> /Users/kcheng/sandbox/ignite/modules/platform/src/main/dotnet/Apache.Ignite.sln.DotSettings



Ah, that would be a side-effect of the new .net/C++ code import. The RAT
exclusion list needs to be updated.

-- Brane

Re: API stability.

[Branko Čibej]

On 29.08.2015 00:06, Konstantin Boudnik wrote:
> On Fri, Aug 28, 2015 at 05:14PM, Vladimir Ozerov wrote:
>> Dima,
>>
>> I'm not suggesting doing this, they are already not stable. For example,
>> take a look at IgniteCacheObjectProcessor. This is a component which can be
>> injected through plugins, thus it is "semi-public". However, it is under
>> heavy changes and if some unlucky guy is to implement a plugin using this
>> processor, he will face compilation errors with each new Ignite release.
>>
>> My suggestion is to define policies for things like that. One of possible
>> solutions - is to annotate APIs so that developers are aware of potential
>> problems.
>>
>> One more example from Hadoop:
>> 1) org.apache.hadoop.fs.FileSystem: @Public, @Stable
>> 2) org.apache.hadoop.fs.AbstractFileSystem: @Public, *@Evolving*
> I think having those annotations aren't making developers more aware about
> potential compatibility problems, nor enforce any kind of policy mechanism
> around API compatibility. There's a plenty of examples in Hadoop (YARN in 2.4
> and some other stuff before it) where incompatible changes were introduced in
> minor releases and had to be quickly corrected in a consequent patch release.
>
> What these annotations might help with is to quickly settle the argument that
> certain APIs shouldn't have been used in the first place, because they were
> @Evolving or otherwise. It's more like a UML diagram: if something goes wrong
> ppl have a common ground to find our who has screwed up and why; but it
> doesn't prevent the screw-up itself.
>  
> Perhaps relying on public APIs as the only fully approved for 3rd party
> software developers is the only recourse in this case.

There's nothing inherently wrong with publishing experimental public
APIs, as long as they're clearly marked as such. Subversion does that,
on rare occasions; we don't loose sleep over people writing code against
those APIs, they get ample warning at compile time and in the docs. Once
the APIs are finalized, we remove the experimental annotation.

-- Brane

Re: Ignite 1.4

[Branko Čibej]

On 31.08.2015 08:14, Konstantin Boudnik wrote:
> On Mon, Aug 31, 2015 at 01:29AM, Yakov Zhdanov wrote:
>> Igniters,
>>
>> I think we have got to the point to start finalization of 1.4 release.
>>
>> It contains many important fixes and several new features (e.g. secure
>> communication). One more point - this will be our first release as top
>> level project.
>>
>> The complete list of issues closed/resolved on 1.4 is here:
>> https://issues.apache.org/jira/issues/?filter=12333035&jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20ignite-1.4%20AND%20(status%20%3D%20closed%20or%20status%20%3D%20resolved)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> Let's do the following:
>>
>> 1. Make sure TC is green
>> 2. Run final benchmarks to make sure that there is no drop
>> 3. Make sure that documentation for all features is on the website
>>
>> It will be perfect if we can release on Fri Sep 4th.
> Here's the calculation: 9/4 - 72 hours of the vote = 9/1 Hence, the RC should
> be in the vote on Tuesday hence the release will go without much of the
> testing by the community, right?

Plus 24 hours for mirrors to catch up.

And a side note: a Friday release? Really? :)

-- Brane

Re: Ignite 1.4

[Branko Čibej]

On 31.08.2015 20:06, Konstantin Boudnik wrote:
> Submitting for vote and releasing are two different events. The release date
> is when the vote is closed and its tally is counted.

Heh, actually, the release date is when the release is announced. :)
Which is typically after it's on all the mirrors, heh.

-- Brane

> On Mon, Aug 31, 2015 at 02:29PM, Yakov Zhdanov wrote:
>> Guys,
>>
>> Here is the correct link to jira issues that should work for everyone -
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20ignite-1.4%20AND%20(status%20%3D%20resolved%20or%20status%20%3D%20closed)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> Brane, if we are ready on Friday I would prefer to submit the build for
>> vote immediately. If not, Monday is still fine.
>>
>> Thanks!
>> --
>> Yakov
>>
>>
>>
>>> Plus 24 hours for mirrors to catch up.
>>>
>>> And a side note: a Friday release? Really? :)
>>>
>>> -- Brane
>>>
>>>

Download page on the Ignite website

[Branko Čibej]

Guys,

I just updated the download page magic because Infra made a major change
in the way download scripts work last night.

As I was doing this, I noticed that someone ripped out the logic that
made the site offer downloads from our closest mirror instead of
*straight out of the repository*.

How many times do I have to explain that we do *not* tell people to
download our releases straight off the ASF infrastructure? Why do you
think ASF Infra goes to all the trouble to maintain mirror lists and
geoip-aware scripting to make automatic (and manual) mirror selection
possible?

Whoever did this, please put the logic for automatic and manual mirror
selection back, preferably yesterday.

-- Brane

Re: Ignite 1.4

[Branko Čibej]

On 01.09.2015 20:46, Konstantin Boudnik wrote:
> On Tue, Sep 01, 2015 at 08:45PM, Sergey Kozlov wrote:
>> FYI: We've at least 161 unclosed issues planned to fix in version 1.4
> If there're so many issues to go - perhaps it makes sense not to branch out
> this early to avoid extra merges? 

Or just go ahead and release 1.4 and get those issues addressed in 1.5.
It's not as if skipping a  "planned to fix" issue would be the end of
the world.

-- Brane

Re: Download page on the Ignite website

[Branko Čibej]

On 02.09.2015 01:09, Dmitriy Setrakyan wrote:
> Brane,
>
> I have fixed it. The reason it was pointing to the apache repo is because
> the download mirrors were broken for several days during the graduation
> upgrade, and while the INFRA issues were resolved, we had to redirect the
> downloads to the main repo.

Ah, I remember now; thanks for the reminder.

> Another weird issue I noticed now is that there are only 2 mirrors listed.
> Is this the way it is supposed to be now?

You probably saw Gavin's mail to committers@. I'm guessing Infra's first
priority is getting the mirror service working again.

-- Brane

> On Tue, Sep 1, 2015 at 12:36 AM, Branko Čibej  wrote:
>
>> Guys,
>>
>> I just updated the download page magic because Infra made a major change
>> in the way download scripts work last night.
>>
>> As I was doing this, I noticed that someone ripped out the logic that
>> made the site offer downloads from our closest mirror instead of
>> *straight out of the repository*.
>>
>> How many times do I have to explain that we do *not* tell people to
>> download our releases straight off the ASF infrastructure? Why do you
>> think ASF Infra goes to all the trouble to maintain mirror lists and
>> geoip-aware scripting to make automatic (and manual) mirror selection
>> possible?
>>
>> Whoever did this, please put the logic for automatic and manual mirror
>> selection back, preferably yesterday.
>>
>> -- Brane
>>

Re: SVN changes

[Branko Čibej]

On 02.09.2015 03:26, Dmitriy Setrakyan wrote:
> Brane,
>
> Since recently I am constantly asked to confirm an SVN certificate before
> updating or committing. This is really hurting my productivity :)

Yeah, right, one extra keypress, heh.

> Any advise on how this can be fixed?

You should be able to permanently trust the certificate (that Infra
replaced a while ago). Can you show me the command-line transcript from
an svn commit? If the client doesn't offer you to permanently trust the
cert, you're probably Doing Something Wrong™. Don't forget to include
the output of 'svn --version'.

-- Brane

Re: SVN changes

[Branko Čibej]

On 02.09.2015 09:27, Dmitriy Setrakyan wrote:
> On Tue, Sep 1, 2015 at 8:01 PM, Branko Čibej  wrote:
>
>> On 02.09.2015 03:26, Dmitriy Setrakyan wrote:
>>> Brane,
>>>
>>> Since recently I am constantly asked to confirm an SVN certificate before
>>> updating or committing. This is really hurting my productivity :)
>> Yeah, right, one extra keypress, heh.
>>
>>> Any advise on how this can be fixed?
>> You should be able to permanently trust the certificate (that Infra
>> replaced a while ago). Can you show me the command-line transcript from
>> an svn commit? If the client doesn't offer you to permanently trust the
>> cert, you're probably Doing Something Wrong™. Don't forget to include
>> the output of 'svn --version'.
>>
> Brane, the situation is actually the reverse. The client always offers to
> accept a certificate every time I execute any SVN command, even after  I
> had already previously accepted it "permanently".
>
> Here is the output of "svn --version":
>
> --
> dsetmac:root $ svn --version
> svn, version 1.7.19 (r1643991)
>compiled Jun 17 2015, 13:48:11
>
> Copyright (C) 2014 The Apache Software Foundation.
> This software consists of contributions made by many people; see the NOTICE
> file for more information.
> Subversion is open source software, see http://subversion.apache.org/
>
> The following repository access (RA) modules are available:
>
> * ra_neon : Module for accessing a repository via WebDAV protocol using
> Neon.
>   - handles 'http' scheme
>   - handles 'https' scheme
> * ra_svn : Module for accessing a repository using the svn network protocol.
>   - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
>   - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.
>   - handles 'http' scheme
>   - handles 'https' scheme
> ---

What's the value of the store-auth-creds setting in your
~/.subversion/servers or /etc/subversion/servers file?

-- Brane

Re: SVN changes

[Branko Čibej]

On 02.09.2015 11:29, Branko Čibej wrote:
> On 02.09.2015 09:27, Dmitriy Setrakyan wrote:
>> On Tue, Sep 1, 2015 at 8:01 PM, Branko Čibej  wrote:
>>
>>> On 02.09.2015 03:26, Dmitriy Setrakyan wrote:
>>>> Brane,
>>>>
>>>> Since recently I am constantly asked to confirm an SVN certificate before
>>>> updating or committing. This is really hurting my productivity :)
>>> Yeah, right, one extra keypress, heh.
>>>
>>>> Any advise on how this can be fixed?
>>> You should be able to permanently trust the certificate (that Infra
>>> replaced a while ago). Can you show me the command-line transcript from
>>> an svn commit? If the client doesn't offer you to permanently trust the
>>> cert, you're probably Doing Something Wrong™. Don't forget to include
>>> the output of 'svn --version'.
>>>
>> Brane, the situation is actually the reverse. The client always offers to
>> accept a certificate every time I execute any SVN command, even after  I
>> had already previously accepted it "permanently".
>>
>> Here is the output of "svn --version":
>>
>> --
>> dsetmac:root $ svn --version
>> svn, version 1.7.19 (r1643991)
>>compiled Jun 17 2015, 13:48:11
>>
>> Copyright (C) 2014 The Apache Software Foundation.
>> This software consists of contributions made by many people; see the NOTICE
>> file for more information.
>> Subversion is open source software, see http://subversion.apache.org/
>>
>> The following repository access (RA) modules are available:
>>
>> * ra_neon : Module for accessing a repository via WebDAV protocol using
>> Neon.
>>   - handles 'http' scheme
>>   - handles 'https' scheme
>> * ra_svn : Module for accessing a repository using the svn network protocol.
>>   - handles 'svn' scheme
>> * ra_local : Module for accessing a repository on local disk.
>>   - handles 'file' scheme
>> * ra_serf : Module for accessing a repository via WebDAV protocol using
>> serf.
>>   - handles 'http' scheme
>>   - handles 'https' scheme
>> ---
> What's the value of the store-auth-creds setting in your
> ~/.subversion/servers or /etc/subversion/servers file?

Also, any info about the platform you're using, and what kind of
authentication store you're using (KWallet? Gnome Keyring? OSX
Keychain?) would be useful here.

-- Brane

Re: SVN changes

[Branko Čibej]

On 02.09.2015 21:58, Dmitriy Setrakyan wrote:
> On Wed, Sep 2, 2015 at 2:53 AM, Branko Čibej  wrote:
>> Also, any info about the platform you're using, and what kind of
>> authentication store you're using (KWallet? Gnome Keyring? OSX
>> Keychain?) would be useful here.
>>
> I am running on Mac. To my knowledge I am not using any authentication
> store.

Keychain is probably enabled, but it doesn't usually play a role in
trusting the server (public) certificate. You're using the default svn
on OSX which is hacked a bit ... in fact so much that I can't find where
it's storing the server cert :)

In any case: I wasn't able to reproduce what you describe, using
/usr/bin/svn; it did ask about trusting the cert the first time, and
apparently recorded that *somewhere*.

> I should also mention that this started happening after Apache SVN was
> upgraded to a newer version recently.

I expect it started happening when Infra replaced the server certs;
that's more likely, since trusting the cert is a completely client-side
decision.

If you use Homebrew, I suggest you 'brew install subversion' which will
(currently) give you 1.8.14.

-- Brane

Re: Update version for master

[Branko Čibej]

On 03.09.2015 13:47, Raul Kripalani wrote:
> If development of the 1.4.x release line will continue in the ignite-1.4
> branch, the master/develop branch should carry 1.5.0-SNAPSHOT (or
> 2.0.0-SNAPSHOT, depending on the type of changes expected).
>
> BTW - it seems the tag for ignite-1.4.0 is missing:

There hasn't been a 1.4.0 release package yet, so of course no tag?

-- Brane

Re: Update version for master

[Branko Čibej]

On 03.09.2015 14:29, Raul Kripalani wrote:
> On Thu, Sep 3, 2015 at 1:16 PM, Branko Čibej  wrote:
>
>> There hasn't been a 1.4.0 release package yet, so of course no tag?
>>
> Well, that would explain it ;-) But why is the POM version for both master
> and ignite-1.4 branches already on 1.4.1-SNAPSHOT in that case?
>
> https://github.com/apache/ignite/blob/master/pom.xml#L35
> https://github.com/apache/ignite/blob/ignite-1.4/pom.xml#L35

No idea ... possibly an oversight.


> Is the 1.4.0 release cut and under VOTE?

I don't see any vote mail, so my best guess is, nope.

-- Brane

Re: Ignite Teamcity at Apache side

[Branko Čibej]

On 03.09.2015 15:11, Anton Vinogradov wrote:
> Hello,
>
> As you may know we already have Ignite Teamcity server where contributors
> can check it's patches. But, as Cos said before, this test environment
> should be runned under apache hardware.
>
> Apache test environment based on Jenkins, but it is not so simple to
> migrate from TeamCity to Jenkins.
>
> Is it possible to make Ignite test environment at Apache side using
> TeamCity, not Jenkins?
> TeamCity can be used under opensource license (
> https://www.jetbrains.com/teamcity/buy/opensource.html).

There are two ways to do this:

  * Ask Infra (in JIRA or mail) to provide a TeamCity instance on our
infrastructure. This is far more likely to succeed if several PMCs
make the request.
  * Ask Infra to set up a VM for Ignite and manage a dedicated instance.

The first option is by far preferred, but be aware that Infra has very
limited resources.

-- Brane

Re: Ignite Teamcity at Apache side

[Branko Čibej]

On 03.09.2015 20:31, Konstantin Boudnik wrote:
> On Thu, Sep 03, 2015 at 04:11PM, Anton Vinogradov wrote:
>>Hello,
>>As you may know we already have Ignite Teamcity server where contributors
>>can check it's patches. But, as Cos said before, this test environment
>>should be runned under apache hardware.
> It isn't like test env. _should_ be running on Apache infra, but that's what
> most
> projects do and it takes away a bunch of chores of maintenance. The part that
> _should_ be on Apache infra is where you build and deploy project's artifacts
> and/or building releases. The main reason is trust: with Infra you know where
> your bits are coming from and can be relatively sure there's no malware and
> other nasty things on it.
>
> Say, in Bigtop we are running all the CI on our own infra, but all the
> deployable artifacts are created by builds.a.o. Same goes with Ignite already.
> So I am not particularly married to an idea that CI just _has_ to be moved
> over.

Yeah, there's that. For example, many projects that use buildbot instead
of jenkins have buildslaves peppered all over the place. There's nothing
wrong with having a complete test environment outside ASF the ASF, but
of course it does cause additional sysadmin work for someone.

-- Brane

Re: Apache 2.0 license with JetBrains copyright in Ignite repository.

[Branko Čibej]

On 04.09.2015 10:07, Vladimir Ozerov wrote:
> Igniters,
>
> As a part of continuous intergration process we need to add several
> JetBrains .cpp and .h files to our repository. Here is the license header
> from these files:
>
> /* Copyright 2011 JetBrains s.r.o.
>
>  *
>  * Licensed under the Apache License, Version 2.0 (the "License");
>  * you may not use this file except in compliance with the License.
>  * You may obtain a copy of the License at
>  *
>  * http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  *
>  * $Revision: 88625 $
> */
>
> On the one hand, it is Apache 2.0 license. On the other hand, it has
> JetBrains copyright. Is it fine to add such files to our repo from legal
> perspective? If yes, are there any additional actions required (e.g.
> mentioning it in LICENSES.txt)?

It's of course OK to put this in to the repository and to distribute it.
You have to add an entry in NOTICE mentioning the copyright, but don't
need anything in LICENSE since ALv2 is already there.

-- Brane

Re: Nodes starts in tests

[Branko Čibej]

On 20.09.2015 10:11, Yakov Zhdanov wrote:
> Very cool idea! However this will not be working in 100% cases since
> sometimes we need custom grid configurations, SPIs, etc, but for
> significant number of tests this will work.

This is actually, IMO, a very bad idea. One of the most important
principles when designing tests is that each test case should be
independent of others. In practice that means that if you run test cases
in random order, their results should always be the same. If a test case
depends on a particular way the grid is started up, then moving the grid
startup outside the test case will introduce dependencies between test
cases that could hide bugs.

The primary goal of a test suite is not to be efficient and fast but to
be accurate.

-- Brane


> 2015-09-20 11:00 GMT+03:00 Sergi Vladykin :
>
>> Guys,
>>
>> A little observation. We have really many tests which start and stop nodes
>> for each test method.
>> Example is IgniteCacheAbstractQuerySelfTest, it contains about 30 test
>> methods and 3 subclasses.
>> In beforeTest method it starts nodes in afterTest it stops them, while
>> cache setup is the same.
>>
>> What I'm trying to say is that each test method itself takes milliseconds
>> to run, but grid start/stop takes* more than 5 seconds* for each test
>> method. So from the standpoint of time we are testing grid start/stop all
>> the time. It is not surprising that our tests take very long time to
>> finish.
>>
>> Since we already support dynamic cache start/destroy which are much more
>> fast than grid start/stop,
>> I think we should go through a refactoring and use existing nodes within a
>> suite as much as possible.
>> I believe this can reduce run time of cache related tests like 10 times.
>>
>> Sergi
>>

Re: LGPL in 1.4 examples

[Branko Čibej]

On 30.09.2015 09:29, Dmitriy Setrakyan wrote:
> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov  wrote:
>
>> I filed the ticket:
>> Build examples failed from binary fabric package
>> 
>>
>
> I think the reason is that we do not upload Ignite LGPL integrations, e.g.
> ignite-hiberbnate artifact to maven central. I don't see why we do not,
> because even though they depend on some LGPL-based code, the ignite module
> itself is licensed under ASL.
>
> Can we upload these artifacts manually?

We've been through this any number of times, yes? We cannot distribute
(L)GPL dependencies. If you can't run a reasonable grid that doesn't
depend on LGPL-licensed modules, then those modules are not "optional"
by any reasonable definition.

It's quite all right to have examples that require those modules; just
tell users that if they want to run those examples, they'll have to
build Ignite (or at least the LGPL dependencies) themselves.

-- Brane

Re: Introducing "compatibility level" concept.

[Branko Čibej]

On 30.09.2015 09:51, Vladimir Ozerov wrote:
> Igniters,
>
> Normally we are trying to maintain backward compatibility with previous
> versions. But it is not always possible.
>
> E.g. we are about to release portable protocol. There are lots suggestions
> how to optimize it, but all of them are relatively hard to implement. It
> would not be a problem if are able to improve it iteratively from release
> to release while still allowing for different versions (e.g. 1.5 and 1.6)
> to communicate.
>
> What if we add a top-level property "*compatibility level*" allowing user
> to "downgrade" some parts of the system to communicate with earlier
> versions?

That's likely to be a huge pain to maintain. The problem is that it
doesn't force you to think about compatibility too much, and you'll end
up having any number of incompatible protocols that you'll have to
maintain simultaneously.

There's an IMO better way: define the protocol to be natrually
extensible, and introduce a capability exchange step. Map protocol
extensions to capabilities (these can represented as simple tokens, or
whatever), then make the client and server use any capabilities that are
common to both.

We do this in Subversion; that's how a 1.9 server can work with a 1.0
client but the same server will work much better (with more features
available) with a 1.9 client. And the other way around, of course.

-- Brane

Re: Introducing "compatibility level" concept.

[Branko Čibej]

My point is that is has to be just one extensible protocol. So in your
case, either: in step 6, the node A would be able to read the
A-compatible bits of data; or: in step 5, the B-nodes will know that the
persistent store was made with A.

Doing it any other way will force you to dumb down your whole grid,
caches, etc. to the lowest common denominator; which makes heterogeneous
grids impossible, and therefore makes rolling upgrades on a live grid
impossible.

Of course you may not care about these scenarios.

-- Brane

On 30.09.2015 10:12, Vladimir Ozerov wrote:
> Brane,
>
> I see you point, but I do not see how we can implement it in our
> distributed environment. Very weird situations could appear. E.g. if there
> are two versions A and B:
> 1) Node A starts.
> 2) Node B starts and agrees with A to use old A-protocol.
> 3) Some data is persisted on disk using A-protocol;
> 4) Cluster shuts down.
> 5) Several new B-nodes appear, but have no clue that something was
> persisted using A-protocol. They decide to use B-protocol.
> 6) Node A restarts and meets unknown B-protocol.
>
> On Wed, Sep 30, 2015 at 11:01 AM, Branko Čibej  wrote:
>
>> On 30.09.2015 09:51, Vladimir Ozerov wrote:
>>> Igniters,
>>>
>>> Normally we are trying to maintain backward compatibility with previous
>>> versions. But it is not always possible.
>>>
>>> E.g. we are about to release portable protocol. There are lots
>> suggestions
>>> how to optimize it, but all of them are relatively hard to implement. It
>>> would not be a problem if are able to improve it iteratively from release
>>> to release while still allowing for different versions (e.g. 1.5 and 1.6)
>>> to communicate.
>>>
>>> What if we add a top-level property "*compatibility level*" allowing user
>>> to "downgrade" some parts of the system to communicate with earlier
>>> versions?
>> That's likely to be a huge pain to maintain. The problem is that it
>> doesn't force you to think about compatibility too much, and you'll end
>> up having any number of incompatible protocols that you'll have to
>> maintain simultaneously.
>>
>> There's an IMO better way: define the protocol to be natrually
>> extensible, and introduce a capability exchange step. Map protocol
>> extensions to capabilities (these can represented as simple tokens, or
>> whatever), then make the client and server use any capabilities that are
>> common to both.
>>
>> We do this in Subversion; that's how a 1.9 server can work with a 1.0
>> client but the same server will work much better (with more features
>> available) with a 1.9 client. And the other way around, of course.
>>
>> -- Brane
>>

Re: LGPL in 1.4 examples

[Branko Čibej]

On 30.09.2015 10:28, Sergey Kozlov wrote:
> Could we build these modules during building example project? It seems a
> bit excessively from user standpoint.

Why do you think users are dumb and lazy and can't issue two build
commands instead of one?


> On Wed, Sep 30, 2015 at 10:45 AM, Branko Čibej  wrote:
>
>> On 30.09.2015 09:29, Dmitriy Setrakyan wrote:
>>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov 
>> wrote:
>>>> I filed the ticket:
>>>> Build examples failed from binary fabric package
>>>> <https://issues.apache.org/jira/browse/IGNITE-1579>
>>>>
>>> I think the reason is that we do not upload Ignite LGPL integrations,
>> e.g.
>>> ignite-hiberbnate artifact to maven central. I don't see why we do not,
>>> because even though they depend on some LGPL-based code, the ignite
>> module
>>> itself is licensed under ASL.
>>>
>>> Can we upload these artifacts manually?
>> We've been through this any number of times, yes? We cannot distribute
>> (L)GPL dependencies. If you can't run a reasonable grid that doesn't
>> depend on LGPL-licensed modules, then those modules are not "optional"
>> by any reasonable definition.
>>
>> It's quite all right to have examples that require those modules; just
>> tell users that if they want to run those examples, they'll have to
>> build Ignite (or at least the LGPL dependencies) themselves.
>>
>> -- Brane
>>
>>
>

Re: LGPL in 1.4 examples

[Branko Čibej]

On 30.09.2015 10:33, Dmitriy Setrakyan wrote:
> On Wed, Sep 30, 2015 at 10:30 AM, Branko Čibej  wrote:
>
>> On 30.09.2015 10:28, Sergey Kozlov wrote:
>>> Could we build these modules during building example project? It seems a
>>> bit excessively from user standpoint.
>> Why do you think users are dumb and lazy and can't issue two build
>> commands instead of one?
>>
> Brane, users don't have to issue any build commands right now, they just
> import the POM file into IDE. I suggested some possible solutions in my
> other email, let's see what the community will choose.


This is not a community decision. This is a legal decision. And it's
already been made and is documented in ASF release policy, you've all
seen read that page.

-- Brane

Re: LGPL in 1.4 examples

[Branko Čibej]

On 30.09.2015 10:30, Dmitriy Setrakyan wrote:
> On Wed, Sep 30, 2015 at 9:45 AM, Branko Čibej  wrote:
>
>> On 30.09.2015 09:29, Dmitriy Setrakyan wrote:
>>> On Wed, Sep 30, 2015 at 8:25 AM, Sergey Kozlov 
>> wrote:
>>>> I filed the ticket:
>>>> Build examples failed from binary fabric package
>>>> <https://issues.apache.org/jira/browse/IGNITE-1579>
>>>>
>>> I think the reason is that we do not upload Ignite LGPL integrations,
>> e.g.
>>> ignite-hiberbnate artifact to maven central. I don't see why we do not,
>>> because even though they depend on some LGPL-based code, the ignite
>> module
>>> itself is licensed under ASL.
>>>
>>> Can we upload these artifacts manually?
>> We've been through this any number of times, yes? We cannot distribute
>> (L)GPL dependencies. If you can't run a reasonable grid that doesn't
>> depend on LGPL-licensed modules, then those modules are not "optional"
>> by any reasonable definition.
>>
>> It's quite all right to have examples that require those modules; just
>> tell users that if they want to run those examples, they'll have to
>> build Ignite (or at least the LGPL dependencies) themselves.
>>
>
> Hm... I thought that ignite-hibernate module could still be published to
> Maven because the module itself is licensed under ASL2.0 license.

People keep misunderstanding the LGPL. You really should read it. The
"module itself" cannot be licensed under ALv2. For example, this is
LGPL2.1 section 5 paragraph 2:

However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because
it contains portions of the Library), rather than a "work that uses
the library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.


In other words, as soon as you *build* something that is linked with
LGPL, it's covered by the LGPL. The sources of the module can be ALv2,
but the built module isn't.

This is why ASF policy forbids mandatory (L)GPL dependencies and
absolutely forbids releases containing (L)GPL code. And whilst the
binaries we put on Maven aren't "releases", they must follow these policies.

> If not, then we should not include these modules into the main set of
> examples, primarily because there is no way for a user to build them out of
> the box.
>
> I see 2 solutions:
>
> 1. Remove modules that depend on LGPL from the examples altogether.
> 2. Add a separate LGPL folder in examples, which will not be included into
> the POM file with a special README explaining how to build them.


Option 2 is acceptable.

-- Brane

Re: what is "communication encryption"?

[Branko Čibej]

On 30.09.2015 11:18, Nikolay Tikhonov wrote:
> SslContextFactory allows to set different encryption protocols (by default
> TLS). I think that just "ssl" confuses users. Might be "ssl\tls=off" more
> acceptable?

SSL is one (rather old) specification of Transport Layer Security (TLS).
These days, you shouldn't be using any version of the SSL protocol; they
all have unfixable security holes.

To be moderately safe, you should implement TLS v1.2 with fallback
allowed to TLS v1.0 but not lower. Even then, certificates should use at
least SHA256, preferably SHA512; SHA1 is no longer considered secure. I
don't recall offhand which ciphers are considered secure, but there
aren't very many of them.

-- Brane


> On Wed, Sep 30, 2015 at 11:53 AM, Dmitriy Setrakyan 
> wrote:
>
>> On Wed, Sep 30, 2015 at 10:18 AM, Alexey Goncharuk <
>> alexey.goncha...@gmail.com> wrote:
>>
>>> Given that encryption is enabled by setting SslContextFactory, I believe
>>> that SSL is the only option. I am +1 for changing the output.
>>>
>> I changed it and committed to master.
>>
>>
>>> 2015-09-30 10:21 GMT+03:00 Dmitriy Setrakyan :
>>>
 On Wed, Sep 30, 2015 at 8:01 AM, Sergey Kozlov 
 wrote:

> On Wed, Sep 30, 2015 at 4:51 AM, Dmitriy Setrakyan <
 dsetrak...@apache.org>
> wrote:
>
>> I got the following printout on 1.4 startup:
>> -
>> Security status [authentication=off, communication encryption=off]
>> -
>>
>> Do we mean SSL by "communication encryption"? If yes, shouldn't we
>>> just
> say
>> "ssl=off"?
>
>> D.
>>
> Yes, in that case communication encryption is SSL
>
 Do we have another case? If not, let's rename to "ssl", shorter and to
>>> the
 point. I think this can be done directly in the master. Any objections?

> --
> Sergey Kozlov
>

Re: Let's please fix the mess in Git

[Branko Čibej]

Stop. Right. There.

If you're going to start pointing fingers at people you can just shut
down the project because you're going down the road of petty bickering.
That's a great way to dissolve the community into chaos.


On the topic of git usage:

  * Raul is absolutely right about commit messages. When you write a
commit message, think about how useful it would be to *you* if
someone else were writing it.

  * I find it really ludicrous that committers on this project are going
through the GitHub pull request rigmarole instead of pushing
directly to the ASF repository. Surely you're not serious? You're
forcing others to RTC instead of doing the right thing in the first
place.

  * Last but not least: learn to use your tools. The best way to do this
is for someone who really gets git to write up usage guidelines. The
"Git Process" page in cwiki is missing quite a few important bits:
especially actual examples, naming conventions (for tags etc.) and
so on. Git semantics are fsck'd up enough as it is, it makes no
sense for every developer to try to figure out the right way by herself.


-- Brane



On 01.10.2015 19:01, Pavel Tupitsyn wrote:
> Sergi, your point is valid, but you are shifting the point of the
> discussion.
>
> Current master branch history, indeed, looks unacceptable. Mostly due to
> insufficient commit descriptions from Anton and Semyon.
>
> On Thu, Oct 1, 2015 at 7:34 PM, Sergi Vladykin 
> wrote:
>
>> Raul,
>>
>> First of all I think it is not an excuse that you did bad thing because
>> others did as well.
>> Lets try to be perfect ourselves before blaming others.
>>
>> Do you know how I lately solve these issues with comments, squashing and
>> other stuff?
>> I do not do any merges of *my* changes to master at all. Almost never.
>> I just provide pull request on GitHub and ask a reviewer to merge it or
>> return with comments.
>> And when someone asks me to do the same I just do it using provided script
>> *scripts/apply-pull-request.sh*
>> There is no chance to do something wrong here.
>>
>> I encourage you to do the same and all of your questions will disappear in
>> a second.
>>
>> Sergi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2015-10-01 1:52 GMT+03:00 Konstantin Boudnik :
>>
>>> On Wed, Sep 30, 2015 at 09:32PM, Raul Kripalani wrote:
 Igniters,

 1. Git history is polluted by lots of commits like: "Merge
>>> remote-tracking
 branch 'origin/ignite-1.4' into ignite-1.4". Is there a logical reason
>>> for
 this? Why doesn't the team use git pull --rebase?

 2. Let's please define a policy for Git commit messages. The current
>> Git
 history is an *utter mess*. This is totally unacceptable on master:
 https://imgur.com/I95TPMd.

a. Commit messages must carry a context. You should not oblige your
 fellows to dig into the diff to understand what you've done.

b. Even if you are referencing a JIRA ticket, please include some
 context. Nobody remembers ticket numbers by heart and it's a waste of
>>> time
 to open a browser tab for every commit.

c. Pasting the full JIRA URL is wasteful and uses precious real
>>> estate.
 Everybody knows that if you refer to IGNITE-, you're referring to
>> an
 ASF JIRA ticket.

 I agree with many of the tips on this post about Git commit message
>> best
 practices [1]. I suggest you read if you haven't yet.

 3. Let's clarify the merging policy. Yakov complained because I merged
>> a
 branch without squashing. But I see people are doing this. He also
 referenced a Wiki page that explained the procedure for Github pull
 requests. Are we allowed to merge internal branches without squashing?
>>> We shouldn't be. We had this lengthy discussion about proper git
>> practices
>>> where it has been established that squashing of intermediate commits  is
>> a
>>> blessing because
>>>  a) no one is interested in "Oh, heck - I forgot the letter" commits
>>>  b) rebase-then-merge allows to avoid meaningless "Merge commits", which
>>> might
>>> only be valuable for bring in some big feature branches, etc.
>>>
>>> Good points on the rest of it as well - let's have some discipline around
>>> this.
>>>
>>> Cos
 [1] http://chris.beams.io/posts/git-commit/

 Regards,

 *Raúl Kripalani*
 PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
>> and
 Messaging Engineer
 http://about.me/raulkripalani |
>> http://www.linkedin.com/in/raulkripalani
 http://blog.raulkr.net | twitter: @raulvk
>
>

Re: Fwd: Coding Guidelines: zookeeper IP finder and mqtt streamer

[Branko Čibej]

On 29.09.2015 00:41, Konstantin Boudnik wrote:
> Hmm...
>
> Negligence, n. : the trait of neglecting responsibilities and lacking concern
> syn : omission, oversight

"Negligence" usually means continued and repeated (non-)action. In that
respect it's an extremely negative label to use; you're effectively
accusing someone of being an incompetent lazy b**rd.

The "synonyms" are not synonymous because both "omission" and
"oversight" imply a on-time event.


-- Brane


> Doesn't sound catastrophic in my vocabulary, really. Does this
>> case of negligence and needs to be addressed accordingly.
> translate to "should face a firing squad without a trial of his peers"?
> Have I anywhere pointed a finger at you or anyone else? Or attacked someone? 
> Why are you all upset and defensive about it?
>
> Cos
>
> On September 28, 2015 7:39:51 AM PDT, Raul Kripalani  wrote:
>> Cos, your language seems too harsh for the situation.
>>
>> No one here is committing negligence. The explanation is simple: people
>> aren't perfect.
>>
>> Now, let's take a step back and see the big picture. Around 95% of the
>> commits in this project are by GridGain personnel (check git shortlog
>> -s
>> -n) who have spent months/years working on this codebase during their
>> daily
>> job. Their eyes are accustomed to this code style and naturally they'll
>> spot oddities in a twitch. It's obvious.
>>
>> For newer people, we don't even have checkstyle nor decent facilities
>> for
>> newer people to spot formatting issues quickly. Because, surprise! The
>> issues that Yakov spotted are simply of formatting. The code is
>> functional
>> and much better tested than other streamers and IP Finders. Other
>> streamers
>> have 1 test, this streamer has 9 unit tests! Look at the code.
>> Furthermore,
>> Yakov seems to have made a mistake reading the Git commit history.
>> There
>> were never WIP commits on master.
>>
>> So may I ask you to stop using catastrophic vocabulary. The situation
>> is
>> not catastrophic, it's simply improvable.
>>
>> Now, as an ASF member, I ask you to recognise that unaffiliated
>> volunteers
>> like me bring diversity to the project that's otherwise dominated by a
>> company. You should appreciate that – more so given that you're a
>> former
>> mentor. I do this for the fun, and attacks like yours take the fun out
>> of
>> it. Have a look again at this project's team composition and, for those
>> people not affiliated to GridGain, try to find when their last commit
>> was... Then you'll see what I mean.
>>
>> P.S.: I did not merge the ZK IP Finder myself and I'm assuming that
>> Valentin will want to comment.
>>
>> Regards,
>>
>> *Raúl Kripalani*
>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
>> and
>> Messaging Engineer
>> http://about.me/raulkripalani |
>> http://www.linkedin.com/in/raulkripalani
>> http://blog.raulkr.net | twitter: @raulvk
>>
>> On Mon, Sep 28, 2015 at 1:53 PM, Konstantin Boudnik 
>> wrote:
>>
>>> Are these official guidelines that are worked-out and communicated by
>>> community? Basically, were they made clear when the project went on
>> the CTR
>>> model? I presume it is/was looking at the wikipage. Hence
>> non-sticking
>>> to them is a case of negligence and needs to be addressed
>> accordingly.
>>> I would also want to highlight the other side of such negligence: by
>>> dumping
>>> semi-baked code to the master one creates a burden for the rest of
>> the
>>> community as the code degrades in quality, potentially breaks tests,
>> style
>>> checks, etc. And someone else needs to deal with it to unblock her's
>> future
>>> progress. And that's brings forward another point that Brane and I
>> were
>>> making on a few occasions: in the CTR communities you need to invite
>> in
>>> people
>>> with great deal of attention to how they work with others. Are they
>>> respecting
>>> others' time and effort? Are they good citizens of the community? And
>> on,
>>> and
>>> on.
>>>
>>> Another purely technically matter: master isn't a trash can. Master
>> should
>>> be
>>> close to releasable at any given point of time. WIP stuff doesn't
>> belong to
>>> master, that's what the dev and integration branches are for.
>>>
>>> Cos
>>>
>>> On Mon, Sep 28, 2015 at 03:31PM, Yakov Zhdanov wrote:
 Guys,

 I have just reviewed the code and have some comments. 1-2 are very
>>> serious
 from my point of view.

 1. Code is in master. Did anyone checked tests on TC? Moreover, are
>> there
 suites for those tests?
 2. It seems that work on streamer has been done directly in master.
>> I see
 WIP commits, but I think I should not. As agreed finished work
>> should be
 committed as a single set of changes.
 3. I see unused variable
 - org.apache.ignite.stream.mqtt.MqttStreamer#cachedLogPrefix
 4. Unused import - import com.google.common.base.Joiner;
 5. Code and javadocs lines exceed 120 chars restriction.
 6. Plenty of javadocs issues - absence

Re: Why portable marshaller handle Date and Timestamp in the same way?

[Branko Čibej]

On 06.10.2015 12:26, Vladimir Ozerov wrote:
> Yakov, this could work in .Net where you have real generics. But it will
> not work in Java in general case due to type erasure - you simply cannot
> infer the type.
>
> Let's look closely to this:
> Date  Java: 10^-3
> Timestamp Java: 10^-9
> DateTime  .Net: 10^-7
>
> What we see here, is that mapping Java Date to .Net DateTime is alomst
> certainly a bad thing because we loos too much data. But interoping between
> Timestamp and DateTime is more or less sensible, we loose only 0.1-s of
> microseconds.
>
> I would suggest the following solution:
> 1) Fully decouple Date and Timestamp in Java. These are completely
> different types from Java perspective, H2 perspective (see GridH2Date,
> GridH2Timestamp), any data database perspective, etc..
> 2) Map .Net DateTime to Java Timestamp with warning about possible
> precision loss.

>From the peanut gallery ... it seems like a really bad idea to design a
marshalling format based on what some language standard library happens
to provide. IMO, the way to do this is to define your own max precision
timestamp type, marshal it at full precision, and provide conversions to
standard types. That way your users can choose to use your type which
provides full precision on all platforms, or decide to use the standard
types with the potential loss of precision that entails; but it becomes
*their* decision, not a limitation set by the library.

-- Brane


> On Tue, Oct 6, 2015 at 1:08 PM, Yakov Zhdanov  wrote:
>
>> 2015-10-06 12:45 GMT+03:00 Dmitriy Setrakyan :
>>
>>> On Tue, Oct 6, 2015 at 2:42 AM, Vladimir Ozerov 
>>> wrote:
>>>
 This doesn't answers the question. First, Java Timestamp has greater
 precision than .Net DateTime, so silent data loss could happen in this
>>> case
 as well. Second, "use timestamp" is defined on class level. It means we
 cannot handle a class which have both Date and Timestamp fields.

 Looks like a bug and/or invalid design for me.

>>> Agree, current design is not ideal. Vladimir, do you have other
>>> suggestions?
>>
>> how about writing at max precision possible (+ proper type ID) and
>> interpreting binary data on read depending on (a) portable reader method
>> call or (b) on actual field type.
>>
>> --Yakov
>>

Re: MSDN subscriptions for ASF Committers

[Branko Čibej]

On 16.10.2015 09:48, Raul Kripalani wrote:
> According to the feedback of other fellow committers, they can take weeks
> to approve it (!). When did you apply?

Just found this thread ... indeed, it can take weeks or even months. At
some point, the subscriptions were bulk-updated every 6 months. :)

But they are indeed extremely useful.

-- Brane


> On 16 Oct 2015 02:13, "Dmitriy Setrakyan"  wrote:
>
>> I still have not received any response for my MSDN subscription, so I guess
>> Microsoft must had canceled the program.
>>
>> D.
>>
>> On Wed, Oct 14, 2015 at 11:15 AM, Dmitriy Setrakyan <
>> dsetrak...@gridgain.com
>>> wrote:
>>> Thanks Raul,
>>>
>>> I applied, but didn't get any confirmation email. Let's see if they
>>> respond.
>>>
>>> D.
>>>
>>> On Wed, Oct 14, 2015 at 10:49 AM, Raul Kripalani 
>> wrote:
 Hey guys,

 Just wanted to remind you that Microsoft offers MSDN subscriptions to
>> ASF
 committers – for those committers working on Apache Ignite.NET.

 You also get a free monthly credit of 130 EUR (or equivalent, I guess)
>> on
 Azure with your subscription, in case you want to use that environment
>> for
 platform-testing Ignite.



>> https://mail-archives.apache.org/mod_mbox/www-community/201402.mbox/%3CCAB56zCXOSpR86ZrY_TDdhche=yoptce7+efvbk0dsl8_9e8...@mail.gmail.com%3E
 Regards,

 *Raúl Kripalani*
 PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data
>> and
 Messaging Engineer
 http://about.me/raulkripalani |
>> http://www.linkedin.com/in/raulkripalani
 http://blog.raulkr.net | twitter: @raulvk

>>>

Re: Branch deletion prohibited

[Branko Čibej]

On 23.11.2015 04:13, Konstantin Boudnik wrote:
> On Sun, Nov 22, 2015 at 02:16PM, Dmitriy Setrakyan wrote:
>> Cos,
>>
>> I believe this is the ticket:
>> https://issues.apache.org/jira/browse/INFRA-10798
>>
>> This policy does seem myopic, would be great if Ignite could get an
>> exemption.
> Thanks! I already have sent email to the board where this discussion is going
> right now. Hopefully, this ban will be lifted soon.

The best way to get this changed is to invent a workflow that doesn't
delete important information. "Important" in this case meaning "always
knowing where a particular bit of code came from". Most "optimal" Git
workflows tend to happily rebase and squash such info out the window.


Case in point: when Ignite was incubating, we had an issue where we
could not track the IP of the JSR166 backports (ConcurrentHashMap et
al.), neither in the ASF repo (which was sort-of expected) nor in the
original GridGain repo, because info about the original import was lost.
We ended up having to remove those files and re-import them from the
canonical source, so that we could be certain about the license. In this
case, by sheer luck, the solution was simple.


The ASF promises its users that we have complete oversight of the IP in
our released source and can easily audit any single byte of source all
the way to its original author. Deleting a branch in Git (and other
destructive changes) can make auditing extremely hard, in some cases
impossible.

Granted that forbidding branch deletions isn't the only way to solve
this problem; but it certainly goes a long way towards fixing it. Now
it's up to *you* guys (i.e., every project at the ASF that uses Git
repos) to come up with a workflow that allows branch deletions but
doesn't lose the ability to audit the source; forbidding squashed merges
would probably do it, but I'm sure there are other ways.

-- Brane


>> D.
>>
>> On Sun, Nov 22, 2015 at 11:58 AM, Konstantin Boudnik  wrote:
>>
>>> Raul
>>>
>>> is there are a ticket for this INFRA ticket? Sorry if I missed it...
>>>
>>> I regurgitate about this no-branch-delete policy imposed by a myopic
>>> "policy"
>>> considerations. And I want to increase the pressure on board@ for this
>>> sort of
>>> things. Would appreciate the pointer if exist.
>>>
>>> Thanks!
>>>   Cos
>>>
>>> On Thu, Nov 19, 2015 at 11:47AM, Raul Kripalani wrote:
 Ok. So Infra replied and referred to an email on November 3rd which I
 somehow missed, indicating that it is indeed an ASF-wide temporary
 restriction.

 +1 to liberty of options to contribute/commit and to temporarily keeping
 track of branches to delete in the Wiki.

 Regards,

 *Raúl Kripalani*
 PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
 Messaging Engineer
 http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
 http://blog.raulkr.net | twitter: @raulvk

 On Thu, Nov 19, 2015 at 10:21 AM, Semyon Boikov 
 wrote:

> +1
>
> On Thu, Nov 19, 2015 at 1:07 PM, Vladimir Ozerov  wrote:
>
>> I agree that there is absolutely no problems of have multiple ways to
>> provide contributions.
>>
>> If you are contributor, you can:
>> - Provide a patch;
>> - Provide a PR using GitHub mirror.
>>
>> If you are committer, you can:
>> - Provide a patch;
>> - Provide a PR using GitHub mirror;
>> - Use branch in ASF repo and remove it in the end.
>>
>> ASF branches removal is temporary restricted by INFRA. As soon as it
>>> is
>> enabled again why not using it? It is the easiest way to provide
>> contributions and review them.
>>
>> On Thu, Nov 19, 2015 at 12:49 PM, Raul Kripalani 
> wrote:
>>> Lads,
>>>
>>> It is not clear to me whether branch deletion is prohibited
>>> ASF-wide
>>> (Dmitriy: "we *cannot* delete branches") or by express project
>>> request.
>>> I've understood both things from the thread. So let's wait for
>>> INFRA to
>>> clarify: [1].
>>>
>>> Can someone please explain why we resort to Github in the first
>>> place?
>> Was
>>> it for CI integration purposes?
>>>
>>> Regards,
>>>
>>> [1]
>>>
>>> https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-10798
>>> *Raúl Kripalani*
>>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big
>>> Data
> and
>>> Messaging Engineer
>>> http://about.me/raulkripalani |
> http://www.linkedin.com/in/raulkripalani
>>> http://blog.raulkr.net | twitter: @raulvk
>>>
>>> On Thu, Nov 19, 2015 at 9:34 AM, Pavel Tupitsyn <
> ptupit...@gridgain.com>
>>> wrote:
>>>
 I'd like to add that there is virtually no difference between
>>> using a
 branch in original repo and a branch in your personal fork on
>>> GitHub.
 Merges and other operations work seamlessly between multiple
>>> remotes.
 Comm

Re: Branch deletion prohibited

[Branko Čibej]

On 23.11.2015 20:41, Konstantin Boudnik wrote:
> On Mon, Nov 23, 2015 at 09:08AM, Branko Čibej wrote:
>> On 23.11.2015 04:13, Konstantin Boudnik wrote:
>>> On Sun, Nov 22, 2015 at 02:16PM, Dmitriy Setrakyan wrote:
>>>> Cos,
>>>>
>>>> I believe this is the ticket:
>>>> https://issues.apache.org/jira/browse/INFRA-10798
>>>>
>>>> This policy does seem myopic, would be great if Ignite could get an
>>>> exemption.
>>> Thanks! I already have sent email to the board where this discussion is 
>>> going
>>> right now. Hopefully, this ban will be lifted soon.
>> The best way to get this changed is to invent a workflow that doesn't
>> delete important information. "Important" in this case meaning "always
>> knowing where a particular bit of code came from". Most "optimal" Git
>> workflows tend to happily rebase and squash such info out the window.
> How it is different if I take _all_ code in an SVN trunk, pack into a giant
> tarball, then create a fresh branch and commit that blob as a single commit?

Not different at all. But my point is that Git allows you to do that
with one command, and many workflows based on Git actively encourage
(dare I say mandate) that sort of thing. Whereas it's less likely that
anyone using SVN would propose such a workflow, since it'd be such a
huge pain to follow.

> The situation isn't git specific - it's people specific. Solving people
> problem with tech never works, really.

That's why I wrote "Git workflows", not "Git"; workflows are invented by
people, not software. I agree that the prohibition on branch deletions
isn't a solution; it's a stopgap, which everyone admits.


>> Case in point: when Ignite was incubating, we had an issue where we
>> could not track the IP of the JSR166 backports (ConcurrentHashMap et
>> al.), neither in the ASF repo (which was sort-of expected) nor in the
>> original GridGain repo, because info about the original import was lost.
>> We ended up having to remove those files and re-import them from the
>> canonical source, so that we could be certain about the license. In this
>> case, by sheer luck, the solution was simple.
> The assumption that it happened because of git is non consequential, actually.
> Most likely that was a result of some mundane reasons like moving
> repos/re-importing the code from one place to another, etc. Keep in mind, the
> code base is like 8 years old, and wasn't in git originally. Perhaps it was
> sitting in SVN and brought-up to git with fast-import, which shouldn't be used
> really.

Did I say it's "because of Git"? I did not; I said it's because of the
workflows people tend to use with Git. Let's not make this a Git vs. SVN
debate, because it's not and the embers (not flames yet) are just
distracting from the topic.

I guess my example wasn't well chosen; I should've looked for one that
happened recently in ASF code.


>> The ASF promises its users that we have complete oversight of the IP in
>> our released source and can easily audit any single byte of source all
>> the way to its original author. Deleting a branch in Git (and other
>> destructive changes) can make auditing extremely hard, in some cases
>> impossible.
>>
>> Granted that forbidding branch deletions isn't the only way to solve
>> this problem; but it certainly goes a long way towards fixing it. Now
>> it's up to *you* guys (i.e., every project at the ASF that uses Git
>> repos) to come up with a workflow that allows branch deletions but
>> doesn't lose the ability to audit the source; forbidding squashed merges
>> would probably do it, but I'm sure there are other ways.
> That sounds like tossing the problem from one side of the fence to another.
> PMC should be in control of the project IP and all other paraphernalia. PMC is
> responsible before the board for this type if policy commotions. I am not 
> trying
> to dismiss the importance of the paper-trail for IP-related issues. All I am
> saying that disabling a perfectly valid functionality because there's a chance
> of somebody misusing it, is like UK prohibiting the sales of the butter-knives
> to the under aged: ludicrous at best.

You'll note that the board told Infra to do this as a stopgap to prevent
"responsible PMCs" from further messing up our IP provenance. Clearly,
some PMCs are not responsible. It's painful that the restriction hurt
all PMCs.

Instead of complaining to me, it'd be far more useful to work with those
other PMCs to produce a set of rules for using Git -- *not* a single

Re: Branch deletion prohibited

[Branko Čibej]

On 24.11.2015 05:53, Branko Čibej wrote:
> Instead of complaining to me, it'd be far more useful to work with those
> other PMCs to produce a set of rules for using Git -- *not* a single
> blessed workflow -- that prevent losing important information about the
> code base. Ideally, the rules would be easily implemented as checks in
> Git hooks. The idea being to prevent mistakes, not to constrain developers.

On the topic of hooks: Subversion allows changes to revision properties
(not by default of course) that would be quite inappropriate; for
example, you could, theoretically, change the name of the author of a
commit. At the ASF we have a specific hook to allow changing log
messages, but none of the other revision properties; and the commit
mailer sends diffs of changed log messages to the project's mailing list.

This is an example of the sort of rule I'm talking about: it does not
impose any particular workflow; it allows changing log messages and
provides a permanent audit trail (in list archives); it does not allow
changing commit date, author, etc., because those would be obvious mistakes.

(And FWIW: Yes, Subversion has a design bug in not maintaining an
archive of previous values of revision properties to provide that audit
trail.)

-- Brane

Re: EA versioning

[Branko Čibej]

It was fun watching this thread. I don't even know what EA means, but I
have to wonder ... what's wrong with releasing 1.5.0-beta? Or does the
Java world need its own special terminology for yet another
well-established process? :)

-- Brane

Re: Ignite Voting Process

[Branko Čibej]

On 30.12.2015 16:30, Raul Kripalani wrote:
> Hi Anton,
>
> Why don't we publish artifacts for ignite-geospatial, ignite-hibernate and
> ignite-schedule? The lgpl profile is not triggered in these instructions,
> and these artifacts cease existing in Maven Central 1.2.0-incubating
> onwards.
>
> I know they depend on LGPL-licensed libraries, but we can publish our
> Ignite components WITHOUT packaging the upstream dependencies (Hibernate,
> etc.). Then we would be complying with the ASF ruleset to my understanding,
> because:
>
> 1. These modules are optional.
> 2. We don't package the LGPL dependencies: we simply write instructions on
> our docs on how to fetch them separately.

We'd be publishing modules that can't be used without the LGPL
components. I'm not sure how that stands WRT our policies but I can't
see how it would be a service to our users to actively nudge them
towards using restrictive-licensed code.

-- Brane

Re: Ignite Voting Process

[Branko Čibej]

On 31.12.2015 09:58, Branko Čibej wrote:
> On 30.12.2015 16:30, Raul Kripalani wrote:
>> Hi Anton,
>>
>> Why don't we publish artifacts for ignite-geospatial, ignite-hibernate and
>> ignite-schedule? The lgpl profile is not triggered in these instructions,
>> and these artifacts cease existing in Maven Central 1.2.0-incubating
>> onwards.
>>
>> I know they depend on LGPL-licensed libraries, but we can publish our
>> Ignite components WITHOUT packaging the upstream dependencies (Hibernate,
>> etc.). Then we would be complying with the ASF ruleset to my understanding,
>> because:
>>
>> 1. These modules are optional.
>> 2. We don't package the LGPL dependencies: we simply write instructions on
>> our docs on how to fetch them separately.
> We'd be publishing modules that can't be used without the LGPL
> components. I'm not sure how that stands WRT our policies but I can't
> see how it would be a service to our users to actively nudge them
> towards using restrictive-licensed code.

I mean "binary modules;" the ASF release policy doesn't really apply to
binaries, but by analogy, we probably could publish those modules. My
doubt about this being a service to users still stands, however.

-- Brane

Re: Switching back to review-then-commit process

[Branko Čibej]

On 05.03.2016 04:43, Konstantin Boudnik wrote:
> It saddens me to see this coming to it ;(

Yeah. You guys are introducing red tape that's a barrier for new
committers and a bureaucratic trap for everyone else.

For example: what happens when a module owner takes off for a couple
months? Which is likely, since this is, after all, a volunteer effort.
Are you going to block any changes to that module until/unless she
becomes active again, or just break your own rules for convenience?

Maybe you're counting on many module owners being employed to do this
stuff ... in which case you should all go back to the incubator because
you've learned NOTHING about open source collaboration in all this time.

Pah, what nonsense.

-- Brane

P.S.: Also please stop using "Ignite is complex" as an argument for
locking down on progress. Give the other guy the courtesy of assuming
he's not a total idiot. How about spending time on a comprehensive test
suite and developer documentation instead?


> On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote:
>> Igniters,
>>
>> I would propose to switch back to review-then-commit process. This
>> process has to be followed by both contributors and committers.
>>
>> There is a reason for this I have in mind. Ignite is a complex
>> platform with several big modules. Some of the people may be experts
>> in module A while others in module B etc.
>> If a committer, who is good in module A, makes changes in module B
>> merging the changes without a review this can break module's B
>> internal functionality that the committer didn't take into account.
>>
>> My proposal is to introduce a list of maintainers for every Ignite
>> module like it's done in Spark [1] and a rule that will require a
>> committer to get an approval from a module maintainer before merging
>> changes.
>>
>> Thoughts?
>>
>> --
>> Denis
>>
>> [1] 
>> https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers
>>
>>
>>

Re: [VOTE] Apche Ignite PMC Chair Election

[Branko Čibej]

On 2016-12-10 21:24 (+0100), Dmitriy Setrakyan  wrote: 
> According to the discussion on the dev list [1], the following candidates
> were proposed for the Apache Ignite PMC Chair position:
> 
>  Vladimir Ozerov
>  Konstantin Boudnik
>  Valentin Kulichenko
>  Denis Magda
>  Branko Čibej


I'm mildly intrigued that anyone would put my name on a PMC Chair vote proposal 
without asking me first ... especially since I've not been subscribed to any of 
the mailing lists for a looong time now. Not that there's any danger of my 
being elected, but just for the record: I'm not a candidate, please do not 
waste any of your votes on me.

And since I have not been active in the community and have not contributed to 
the project for so long, nor do I expect this state of affairs to change in the 
foreseeable future, I'd like to take this opportunity to announce my 
resignation from the Ignite PMC.

My decision is final, and is the result of changing interests and personal 
circumstances. I wish you all the best of luck with the project and community.

-- Brane