ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Kozlov <skoz...@gridgain.com>
Subject Re: Ignite 2.0 tasks/roadmap
Date Fri, 09 Sep 2016 13:37:52 GMT
Denis

Generally I'm fine for your approach. I think for 2.0 (or may be for a next
1.x minor version) we can note that currently REST API is deprecated. It
will allow us to replace REST by a new implementation once it will be done.

On Fri, Sep 9, 2016 at 4:11 PM, Denis Magda <dmagda@gridgain.com> wrote:

> Sergey,
>
> I do agree with you that Ignite’s REST API implementation has to be
> revisited. Your concerns sound reasonable. But personally I wouldn’t rush
> trying to release it under 2.0 because NodeJS won’t be a part of this
> release while it can propose additional requirements to the next generation
> of REST API implementation.
>
> Does it make sense to you?
>
> —
> Denis
>
> > On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <skozlov@gridgain.com> wrote:
> >
> > Vova,
> >
> > There are more issues than processing (String, String) only: we can't
> > process JSON objects as values, current implementation doesn't follow
> > general RESTfull API requirements.
> > Moreover we're still have no connectors for PHP, Python and other popular
> > languages for web development of LAMP market and REST API is a single way
> > get access to Apache Ignite.
> >
> > On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> >> Denis,
> >>
> >> Very good catch! Our REST API in ir is current appearance are virtually
> >> useless because it only operates on strings. We'd better to design the
> new
> >> one.with blackjack and etc..
> >>
> >> On Fri, Sep 9, 2016 at 3:39 AM, Denis Magda <dmagda@gridgain.com>
> wrote:
> >>
> >>> Basically, we can have two versions of the REST API if we want to care
> >>> about the compatibility and remove the old one (deprecated) at some
> point
> >>> of time. Moreover, NodeJS feature [1] can highly influence on the next
> >>> generation of our REST API implementation. So I wouldn’t introduce the
> >> next
> >>> version of REST API implementation before NodeJS component is done.
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-961
> >>>
> >>> —
> >>> Denis
> >>>
> >>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <skozlov@gridgain.com>
> >> wrote:
> >>>>
> >>>> I agree with Alexey.
> >>>>
> >>>> The key point is a chance to don't care for compatibility.
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Sep 8, 2016 at 9:56 AM, Alexey Kuznetsov <
> >>> akuznetsov@gridgain.com>
> >>>> wrote:
> >>>>
> >>>>> Just my opinion. If we move this to 2.1 that will result that we
will
> >>> have
> >>>>> to support 2 versions of REST APIs.
> >>>>> In Ignite 2.0 we could break compatibility and redesign REST API
from
> >>>>> scratch.
> >>>>>
> >>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dmagda@gridgain.com>
> >>> wrote:
> >>>>>
> >>>>>> I would move it to 2.1 or 2.2.
> >>>>>>
> >>>>>> —
> >>>>>> Denis
> >>>>>>
> >>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan <
> >> dsetrakyan@apache.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Sergey, I don't think we can fit redesigning of HTTP/REST
into our
> >> 2.0
> >>>>>>> release. The 2.0 already looks pretty packed. Perhaps we
should
> plan
> >>> it
> >>>>>> for
> >>>>>>> the release after, like 2.1?
> >>>>>>>
> >>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <
> skozlov@gridgain.com
> >>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi
> >>>>>>>>
> >>>>>>>> I suppose we should redesign HTTP REST API. We've a
dozen issues
> >>>>> around
> >>>>>> the
> >>>>>>>> REST implementation and the provided functionality is
very limited
> >>> and
> >>>>>>>> doesn't follow last changes for Ignite. The most suitable
ticket
> is
> >>>>>>>> IGNITE-1774
> >>>>>>>> REST API should be implemented using Jersey
> >>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774>
but probably
> >> we
> >>>>>> need
> >>>>>>>> to
> >>>>>>>> have a root ticket for that.
> >>>>>>>>
> >>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan <
> >>>>>> dsetrakyan@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Denis, thanks for taking a role of a release manger
for 2.0. It
> is
> >>>>>>>>> definitely an important release for us and good
supervision is
> >> going
> >>>>> to
> >>>>>>>> be
> >>>>>>>>> very helpful.
> >>>>>>>>>
> >>>>>>>>> I have looked at the tickets and the list seems
nice. I would
> also
> >>>>> add
> >>>>>> a
> >>>>>>>>> ticket about migration of the JTA dependency to
Geronimo as well,
> >>>>>>>>> IGNITE-3793 [1], however I am not sure if we might
be able to do
> >> it
> >>>>>> prior
> >>>>>>>>> to 2.0.
> >>>>>>>>>
> >>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793
> >>>>>>>>>
> >>>>>>>>> D.
> >>>>>>>>>
> >>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dmagda@gridgain.com
> >
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Community,
> >>>>>>>>>>
> >>>>>>>>>> Let me take a role of the release manager for
Apache Ignite 2.0
> >> and
> >>>>>>>>>> coordinate the process.
> >>>>>>>>>>
> >>>>>>>>>> So, my personal view is that Apache Ignite 2.0
should be
> released
> >>> by
> >>>>>>>> the
> >>>>>>>>>> end of the year. This sounds like a good practice
to make a
> major
> >>>>>>>> release
> >>>>>>>>>> once a year. I would suggest us following the
same rule.
> >>>>>>>>>>
> >>>>>>>>>> Actual we have more than 3 month for development
and I’ve
> prepare
> >>>>> the
> >>>>>>>>> wiki
> >>>>>>>>>> page that contains tickets that are required
to be released in
> >> 2.0
> >>>>> and
> >>>>>>>>> that
> >>>>>>>>>> are optional
> >>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/
> >>>>> Apache+Ignite+2.0
> >>>>>>>>>>
> >>>>>>>>>> Proposed release date is December 23rd, 2016.
> >>>>>>>>>>
> >>>>>>>>>> The tickets that are required for the release
basically break
> the
> >>>>>>>>>> compatibility and we postpone fixing them in
minor release or
> >> they
> >>>>>>>> bring
> >>>>>>>>>> significant improvements into the product. Please
review the
> >> page,
> >>>>>>>>> provide
> >>>>>>>>>> your comments and assign the tickets on yourself
if you’re ready
> >> to
> >>>>>>>> work
> >>>>>>>>> on
> >>>>>>>>>> them.
> >>>>>>>>>>
> >>>>>>>>>> —
> >>>>>>>>>> Denis
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko
<
> >>>>>>>>>> valentin.kulichenko@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> There is one more use case where several
types per cache can be
> >>>>>>>> useful
> >>>>>>>>> (I
> >>>>>>>>>>> know that it's utilized by some of our users).
The use case is
> >> the
> >>>>>>>>>>> following: transactional updates with write-behind
and foreign
> >> key
> >>>>>>>>>>> constraints on the database. In case data
within transaction is
> >>>>>>>>>> collocated
> >>>>>>>>>>> and all types are in the same cache, it
works, because there is
> >>>>> only
> >>>>>>>>> one
> >>>>>>>>>>> write-behind queue. Once we split different
types into
> different
> >>>>>>>>> caches,
> >>>>>>>>>>> there is no guarantee that objects will
be written in the
> proper
> >>>>>>>> order
> >>>>>>>>>> and
> >>>>>>>>>>> that the constraints will not be violated.
> >>>>>>>>>>>
> >>>>>>>>>>> However, I think this is not a very clean
way to achieve the
> >>>>> result.
> >>>>>>>>>>> Probably we should just provide better support
for this use
> case
> >>> in
> >>>>>>>>> 2.0.
> >>>>>>>>>>> Basically, we somehow need to allow to share
a single
> >> write-behind
> >>>>>>>>> queue
> >>>>>>>>>>> between different caches.
> >>>>>>>>>>>
> >>>>>>>>>>> Any thoughts?
> >>>>>>>>>>>
> >>>>>>>>>>> -Val
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy
Setrakyan <
> >>>>>>>>>> dsetrakyan@apache.org>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey
Kozlov <
> >>>>>>>> skozlov@gridgain.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Alexey
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> You're right. Of course I meant
growth of caches number.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I see a few points here:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 1. If a grid used by various applications
the cache names may
> >>>>>>>> overlap
> >>>>>>>>>>>> (like
> >>>>>>>>>>>>> "accounts") and the application
needs to use prefixed names
> >> and
> >>>>>>>> etc.
> >>>>>>>>>>>>> 2. For clear or destory caches I
need to know their names (or
> >>>>>>>> iterate
> >>>>>>>>>>>> over
> >>>>>>>>>>>>> caches but I'm not sure that it
is supported by API). For
> >>>>>>>>> destroy/clear
> >>>>>>>>>>>>> caches belonging to same group we
will do it by single
> >> operation
> >>>>>>>>>> without
> >>>>>>>>>>>>> knowledge of cache names.
> >>>>>>>>>>>>> 3. Cache group can have cache attributes
which will be
> >> inherited
> >>>>>>>> by a
> >>>>>>>>>>>> cache
> >>>>>>>>>>>>> created in that group (like eviction
policy or cache mode).
> >>>>>>>>>>>>> 4. No reason to add specific feature
like SqlShema if it
> >>>>> applicable
> >>>>>>>>> for
> >>>>>>>>>>>>> regular caches as well.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Sergey K, setting the same SQL schema
for multiple caches, as
> >>>>>>>> proposed
> >>>>>>>>>> by
> >>>>>>>>>>>> Sergi, solves a different problem of
having too many SQL
> >> schemas
> >>>>> due
> >>>>>>>>> to
> >>>>>>>>>> too
> >>>>>>>>>>>> many different caches. I think Sergi
proposed a good solution
> >> for
> >>>>>>>> it.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM,
Alexey Kuznetsov <
> >>>>>>>>>>>> akuznetsov@gridgain.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Sergey, I belive you mean "increase"
instead of "reduce"?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> How grouping will help?
> >>>>>>>>>>>>>> To do some operation, for example,
clear on group of cashes
> >> at
> >>>>>>>> once?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь
"Sergey Kozlov" <
> >>>>>>>>>>>> skozlov@gridgain.com>
> >>>>>>>>>>>>>> написал:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I mean not only SQL features
for caches. Single type per
> >> cache
> >>>>>>>>>>>>> definitely
> >>>>>>>>>>>>>>> reduces number of caches
for regular user and grouping
> >> caches
> >>>>>>>> will
> >>>>>>>>>>>> help
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> manage caches in grid.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at
5:41 PM, Sergi Vladykin <
> >>>>>>>>>>>>>> sergi.vladykin@gmail.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I'm aware of this issue.
My plan was to allow setting the
> >>> same
> >>>>>>>>>>>> schema
> >>>>>>>>>>>>>>> name
> >>>>>>>>>>>>>>>> to different caches
using CacheConfiguration.
> >>>>> setSqlSchema(...).
> >>>>>>>>>>>> This
> >>>>>>>>>>>>>> way
> >>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>> will have separate caches
but from SQL point of view
> >>>>> respective
> >>>>>>>>>>>>> tables
> >>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>> reside in the same schema.
No need to introduce new
> >> concepts.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Sergi
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00
Sergey Kozlov <
> >>>>> skozlov@gridgain.com
> >>>>>>>>> :
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> HI
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Due to approach
to disable to store more than one type
> per
> >>>>>>>> cache
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> cache
> >>>>>>>>>>>>>>>>> use becomes similar
the table use for databases.
> >>>>>>>>>>>>>>>>> So I suppose would
be good to introduce a
> >>>>>>>> database/schema-similar
> >>>>>>>>>>>>>>> concept
> >>>>>>>>>>>>>>>>> for caches. It may
be implemented as a non-default
> >> behavior
> >>>>> for
> >>>>>>>>>>>>>>> backward
> >>>>>>>>>>>>>>>>> compatibility.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Sat, Aug 6, 2016
at 1:04 AM, Dmitriy Setrakyan <
> >>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, Aug
5, 2016 at 2:46 AM, Alexey Kuznetsov <
> >>>>>>>>>>>>>>>>> akuznetsov@gridgain.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I remember
couple more thing for 2.0
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> How about
to drop **ignite-scalar** module in Ignite
> >> 2.0?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Why?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> And may
be drop **ignite-spark-2.10** module support as
> >> of
> >>>>>>>>>>>>>>> **Spark**
> >>>>>>>>>>>>>>>> 2
> >>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>> on **scala
2.11**.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I would drop
it only if it is difficult to support. Do
> we
> >>>>> know
> >>>>>>>>>>>>> what
> >>>>>>>>>>>>>>>> kind
> >>>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>> impact will
it have on the community? Anyone is still
> >> using
> >>>>>>>>>>>> 2.10?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Tue,
Aug 2, 2016 at 11:09 PM, Denis Magda <
> >>>>>>>>>>>>>> dmagda@gridgain.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Let’s
add this [1] issue to the list because it
> >> requires
> >>>>>>>>>>>>>>>> significant
> >>>>>>>>>>>>>>>>>> work
> >>>>>>>>>>>>>>>>>>>> on the
side of metrics SPI.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> [1]
https://issues.apache.org/jira/browse/IGNITE-3495
> >> <
> >>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> —
> >>>>>>>>>>>>>>>>>>>> Denis
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
Not yet. The thing is that our recent experience
> >> showed
> >>>>>>>>>>>>> that
> >>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>> was
> >>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>
very good idea to go with caches. E.g. when you try
> to
> >>>>>>>>>>>>>>>> deserialize
> >>>>>>>>>>>>>>>>>>> inside
> >>>>>>>>>>>>>>>>>>>>>
continuous query listener on client side it
> implicitly
> >>>>>>>>>>>>> calls
> >>>>>>>>>>>>>>>>>>> cache.get()
> >>>>>>>>>>>>>>>>>>>>>
which in turn may cause deadlock under some
> >>>>>>>>>>>> circumstances.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
--Yakov
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
2016-08-02 2:41 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
One more point.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
I insist on stop using marshaller and meta caches
> >> but
> >>>>>>>>>>>>>> switch
> >>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> spreading
> >>>>>>>>>>>>>>>>>>>>>>>
this info via custom discovery events.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
Do we have a ticket explaining why this needs to be
> >>>>>>>>>>>> done?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
--Yakov
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan <
> >>>>>>>>>>>>>>>>>> dsetrakyan@apache.org
> >>>>>>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> >>>>>>>>>>>>>>>>>>> yzhdanov@apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>>
wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
Guys, I think we can also split event
> notification
> >>>>>>>>>>>> for
> >>>>>>>>>>>>>> user
> >>>>>>>>>>>>>>>>>>> listeners
> >>>>>>>>>>>>>>>>>>>>>>>
and
> >>>>>>>>>>>>>>>>>>>>>>>>>
internal system listeners. I have been seeing a
> >> lot
> >>>>>>>>>>>> of
> >>>>>>>>>>>>>>> issues
> >>>>>>>>>>>>>>>>>>> caused
> >>>>>>>>>>>>>>>>>>>>>>
by
> >>>>>>>>>>>>>>>>>>>>>>>>>
some heavy or blocking operations in user-defined
> >>>>>>>>>>>>>>> listeners.
> >>>>>>>>>>>>>>>>> This
> >>>>>>>>>>>>>>>>>>> may
> >>>>>>>>>>>>>>>>>>>>>>>>
block
> >>>>>>>>>>>>>>>>>>>>>>>>>
internal component notification (e.g. on
> discovery
> >>>>>>>>>>>>> event)
> >>>>>>>>>>>>>>>>> causing
> >>>>>>>>>>>>>>>>>>>>>>>>
topology
> >>>>>>>>>>>>>>>>>>>>>>>>>
hangings.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
Sure. There are a lot of features being added.
> >> Would
> >>>>>>>>>>>> be
> >>>>>>>>>>>>>> nice
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>> assign
> >>>>>>>>>>>>>>>>>>>>>>
a
> >>>>>>>>>>>>>>>>>>>>>>>>
release manager for Ignite 2.0 and document all
> the
> >>>>>>>>>>>>>>> discussed
> >>>>>>>>>>>>>>>>>>> features
> >>>>>>>>>>>>>>>>>>>>>>
on
> >>>>>>>>>>>>>>>>>>>>>>>>
the Wiki.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
--Yakov
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
2016-06-25 2:42 GMT+03:00 Alexey Goncharuk <
> >>>>>>>>>>>>>>>>>>>>>>
alexey.goncharuk@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>
:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
Folks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
Recently I have seen a couple of emails
> >> suggesting
> >>>>>>>>>>>>>>>>>>>>>>
tasks/improvements
> >>>>>>>>>>>>>>>>>>>>>>>>>
that
> >>>>>>>>>>>>>>>>>>>>>>>>>>
we cannot do in 1.x releases due to API
> >>>>>>>>>>>> compatibility
> >>>>>>>>>>>>>>>> reasons,
> >>>>>>>>>>>>>>>>>> so
> >>>>>>>>>>>>>>>>>>>>>>>
they
> >>>>>>>>>>>>>>>>>>>>>>>>>
are
> >>>>>>>>>>>>>>>>>>>>>>>>>>
postponed to 2.0. I would like to keep track of
> >>>>>>>>>>>> these
> >>>>>>>>>>>>>>> tasks
> >>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>>>>>>>>>>
way
> >>>>>>>>>>>>>>>>>>>>>>>>>
in
> >>>>>>>>>>>>>>>>>>>>>>>>>>
our Jira to make sure we do not have anything
> >>>>>>>>>>>> obsolete
> >>>>>>>>>>>>>>> when
> >>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>
comes
> >>>>>>>>>>>>>>>>>>>>>>>
to
> >>>>>>>>>>>>>>>>>>>>>>>>>
the
> >>>>>>>>>>>>>>>>>>>>>>>>>>
next major version release.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
My question for now is how should we track such
> >>>>>>>>>>>> tasks?
> >>>>>>>>>>>>>>>> Should
> >>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>>>>
be a
> >>>>>>>>>>>>>>>>>>>>>>>>>>
label, a parent task with subtasks, something
> >> else?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
I would go with a label + release version.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
--AG
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> Alexey Kuznetsov
> >>>>>>>>>>>>>>>>>>> GridGain
Systems
> >>>>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Sergey Kozlov
> >>>>>>>>>>>>> GridGain Systems
> >>>>>>>>>>>>> www.gridgain.com
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Sergey Kozlov
> >>>>>>>> GridGain Systems
> >>>>>>>> www.gridgain.com
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Alexey Kuznetsov
> >>>>> GridGain Systems
> >>>>> www.gridgain.com
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Sergey Kozlov
> >>>> GridGain Systems
> >>>> www.gridgain.com
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
>
>


-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message