Folks,
As far as I see, branch ignite-2.1 contains all necessary commits. Looks
like we are ready to start a vote tomorrow as agreed.
On Wed, Jul 12, 2017 at 8:54 PM, Denis Magda wrote:
> Cos,
>
> IMO, If we really want to get a valuable feedback from a wider audience
> then in addition to the
Cos,
IMO, If we really want to get a valuable feedback from a wider audience then in
addition to the new version the audience has to be given both a high-level and
deep documentation, proper messaging, etc. It will take time to soak in the
information and a week might not be enough in general.
That's an interesting statement to make, considering the a PMC is
legally responsible for the release they are making and voting for.
What I believe it would achieve is to give a wider group of our users
a chance to get and install the new version and try some of the most
prominent features, while
Vladimir, sounds like a good plan.
On Sun, Jul 9, 2017 at 11:43 PM, Vladimir Ozerov
wrote:
> Folks,
>
> I monitored TeamCity state over several days, as well as "In Progress"
> tickets. My observation is that situation gradually improving, number of
> failing tests goes down, and most of the tic
Folks,
I monitored TeamCity state over several days, as well as "In Progress"
tickets. My observation is that situation gradually improving, number of
failing tests goes down, and most of the tickets in work are already
dedicated to stabilization, rather to new development. Provided that
release a
Cos,
I am not sure what a 7 day vote will accomplish. As we all know, Apache
[VOTE] is not about the release quality, but about proper build procedure,
release signing, and licensing. I do not see the community needing more
time than usual to verify this release.
D.
On Fri, Jul 7, 2017 at 8:14 P
Fair enough, I will try to collect more and share with the team.
And +1 on the proposed release schedule: considering the complexity of the
changes we better have some time to play with the bits. In fact, I'd suggest
we give it 7 days for the [VOTE] so people have time to play with the bits.
Thoug
Cos,
I am not aware of performance degradation in regards to Cassandra. AFAIK
there were extensive benchmarking prior to 2.0 release. And in the end 2.0
release had performance not worse than 1.9. If you have more information on
the matter, let's discuss it in the separate thread.
On Thu, Jul 6,
Vyacheslav, Denis,
7 July is too abrupt date. Scope of 2.1 is still too broad, and what is
more important - persistent store has been merged only several days ago. We
need some room for stabilization. I propose the following timeline:
16 July - code freeze
17-21 July - QA
21-24 July - vote and rel
Thanks everyone for giving us enough time to take a look into the code
and architecture of this new feature. The webinar was certainly quite
helpful (thanks Denis!).
It seems to be a good time to add the feature into the dot-release, so
more users can have a taste of it "officially". I have a some
Yes, I think so.
—
Denis
> On Jul 5, 2017, at 7:48 AM, Vyacheslav Daradur wrote:
>
> Hi Igniters!
>
> When code freeze of v.2.1 is planned?
>
>>> tickets which will not be ready by the end of the week to the next
> release.
> 7 July?
>
> 2017-07-04 18:39 GMT+03:00 Vladimir Ozerov :
>
>> Ign
Hi Igniters!
When code freeze of v.2.1 is planned?
>> tickets which will not be ready by the end of the week to the next
release.
7 July?
2017-07-04 18:39 GMT+03:00 Vladimir Ozerov :
> Igniters,
>
> We have 536 tickets assinged to 2.1 release [1]. I propose to move all the
> tickets which will
Igniters,
We have 536 tickets assinged to 2.1 release [1]. I propose to move all the
tickets which will not be ready by the end of the week to the next release.
You may use this report [2], which will show all the issues which are
either reported by you or assigned to you (you must be logged in to
Igniters,
Persistent store has been merged to master branch! "master-bak" branch was
created to keep the state before merge for safety. As release date for 2.1
is mid July, I created "ignite-2.1" branch where we will stabilize the
release as usual. Please push features and fixes planned for 2.1 re
Hi Denis,
Awesome news! I'll take care of necessary release procedures if nobody
minds.
Vladimir.
On Sat, Jul 1, 2017 at 12:25 AM, Denis Magda wrote:
> Igniters,
>
> It’s time to refresh this abandoned thread and finally rollout out all the
> changes appeared in 2.1.
>
> In addition, recently
Igniters,
It’s time to refresh this abandoned thread and finally rollout out all the
changes appeared in 2.1.
In addition, recently donated Persistent Store got the green light [1] to
become a part of the master branch (no one asked for extra time to dive into
its details) and, personally, it’
IGNITE-5327 Create predefined cache templates for CREATE TABLE command
- minor comments left, ETA is Friday.
IGNITE-5380 Validate cache QueryEntities in discovery thread - in
progress, the meat of code is written, but need to add lots of tests.
ETA is Friday.
IGNITE-5188 Support AFFINITY KEY keyw
1. IGNITE-5386 Inactive mode must be forced on starting up grid with
persistence is enabled
It is important improvement to fix critical bug IGNITE-5363.
Working on it, ETA - tomorrow.
2. IGNITE-5375 New PersistentStoreMetrics, MemoryMetrics interface
improvements
A lot of discu
Compute for C++ - https://issues.apache.org/jira/browse/IGNITE-3355 -
merged to master.
Best Regards,
Igor
On Thu, Jun 1, 2017 at 6:56 PM, Taras Ledkov wrote:
> Folks,
>
> IGNITE-4922 JDBC Driver: renew thin client based solution:
>
> On 2.1 the functionality of the new thin client JDBC driver
Folks,
IGNITE-4922 JDBC Driver: renew thin client based solution:
On 2.1 the functionality of the new thin client JDBC driver will be
between deprecated Ignite thin JDBC and Ignite JDBCv2.
1. The most functions of SQL query (include DML) are implemented and
ready for review;
2. The most funct
.NET:
* IGNITE-2492 Peer assembly loading - merged
* IGNITE-1894 Delegate support in the API via extension methods - postponed
to 2.2 (see comments)
* IGNITE-4904 DML Delete via LINQ - merged
On Thu, Jun 1, 2017 at 6:43 PM, Vladimir Ozerov
wrote:
> Folks,
>
> We are almost reached proposed featu
Folks,
We are almost reached proposed feature-complete date (June 2), Could you
please share current status of your major features?
On Tue, May 16, 2017 at 3:51 AM, Dmitriy Setrakyan
wrote:
> Looks a little tight. Let's hope we can make it.
>
> On Mon, May 15, 2017 at 1:29 PM, Denis Magda wrot
Looks a little tight. Let's hope we can make it.
On Mon, May 15, 2017 at 1:29 PM, Denis Magda wrote:
> Well, let me propose the following milestones for 2.1 release then.
>
> Code freeze: June 2nd.
> Final QA and benchmarking: June 5 - June 8
> Voting: ~ June 9
> Release: ~ June 13
>
> Also I he
Well, let me propose the following milestones for 2.1 release then.
Code freeze: June 2nd.
Final QA and benchmarking: June 5 - June 8
Voting: ~ June 9
Release: ~ June 13
Also I heard H2 has to be released once again to support Ignite’s CREATE table
command. Think that we should talk to H2 folks
As for .NET, I would propose to concentrate on peer deployment (IGNITE-2492)
and related stuff, like IGNITE-1894 .NET: Delegate support in the API via
extension methods.
SQL Dependency does not look important to me, we can reschedule it for
later versions.
On Thu, May 11, 2017 at 12:01 PM, Dmitri
Vyacheslav, I think it is worth the research, but you should always keep
data querying and indexing in mind. For example, I don't see how by-page
compression will solve it.
On Thu, May 11, 2017 at 1:52 AM, Vyacheslav Daradur
wrote:
> Dmitriy,
>
> I'm researching a best way for this future.
>
> A
Dmitriy,
I'm researching a best way for this future.
At the moment I found only one way (querying and indexing compatible), this
is per-objects-field compression.
But there is a good proffit only for long strings or fields with large
objects.
Maybe it makes sense just to introduce compression f
On Thu, May 11, 2017 at 12:44 AM, Vyacheslav Daradur
wrote:
> Denis,
>
> The described roadmap looks great!
>
> Additional, I vote for introducing an ability (OOTB) to store objects in a
> cache in a compressed form.
> This will allow to store more data at the cost of incriasing of CPU
> utilizat
Denis,
The described roadmap looks great!
Additional, I vote for introducing an ability (OOTB) to store objects in a
cache in a compressed form.
This will allow to store more data at the cost of incriasing of CPU
utilization.
2017-05-11 4:23 GMT+03:00 Denis Magda :
> Igniters,
>
> Let me start
Igniters,
Let me start a discussion around the scope for 2.1 release.
In my vision the main direction of our ongoing efforts should be implementing
in life a use case of Ignite as a transactional distributed SQL database and
HTAP platform. The current use cases (database cache, data grid, micro
30 matches
Mail list logo
