Re: request for contributors permissions

[Konstantin Sirotkin]

ksirotkin

Thank you,
Konstantin Sirotkin

On 2020/07/16 15:33:15, Denis Magda  wrote: 
> Hello Konstantin and welcome to the community!> 
> 
> Please share your JIRA id so that we can add you to the contributors' list> 
> there and you can select a ticket of your interest.> 
> 
> -> 
> Denis> 
> 
> 
> On Thu, Jul 16, 2020 at 8:29 AM Konstantin Sirotkin <> 
> konstantins...@gmail.com> wrote:> 
> 
> > Helloi've registered on> 
> > https://issues.apache.org/jira/secure/Dashboard.jsp> 
> >  and> 
> > according to> 
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute I'm> 
> > requesting contributors permissionsthank you> 
> >> 
> > Konstantin Sirotkin> 
> >> 
>  

С уважением,
Konstantin Sirotkin (Константин Сироткин) | Senior Java Developer
skype, telegram: konstantins304 | linkedin 
 | career.habr 

Re: IEP-50 Thin Client Continuous Queries

[Pavel Tupitsyn]

The pull request is ready for review.

On Fri, Jul 17, 2020 at 4:11 AM Igor Sapego  wrote:

> I've reviewed changes made to IEP and they look good to me.
>
> Best Regards,
> Igor
>
>
> On Wed, Jul 15, 2020 at 1:03 PM Pavel Tupitsyn 
> wrote:
>
> > Alex,
> >
> > You are correct, OP_RESOURCE_CLOSE is enough.
> > Removed the extra op.
> >
> > > If client closes CQ it doesn't want to receive any new events. Why
> can't
> > we
> > > just ignore events for this CQ after that moment?
> > I don't think that our protocol should involve ignoring messages.
> > If the client stops the query, the server should guarantee that no events
> > will be sent
> > to the client after the OP_RESOURCE_CLOSE response.
> >
> > I had some concerns about this guarantee, but after reviewing
> GridNioServer
> > logic,
> > the current implementation with OP_RESOURCE_CLOSE seems to be fine.
> >
> >
> >
> > On Wed, Jul 15, 2020 at 10:09 AM Alex Plehanov 
> > wrote:
> >
> > > Pavel,
> > >
> > > > OP_QUERY_CONTINUOUS_END_NOTIFICATION is another client -> server
> > message
> > > I think you mean "server -> client" here.
> > >
> > > But I still didn't get why do we need it.
> > > I've briefly looked to the POC implementation and, as far as I
> > understand,
> > > OP_QUERY_CONTINUOUS_END_NOTIFICATION can be sent only when
> > > OP_RESOURCE_CLOSE is received by server (client closes the CQ
> > explicitly).
> > > If client closes CQ it doesn't want to receive any new events. Why
> can't
> > we
> > > just ignore events for this CQ after that moment?
> > > Also, in current implementation OP_QUERY_CONTINUOUS_END_NOTIFICATION is
> > > sent before OP_RESOURCE_CLOSE response, so OP_RESOURCE_CLOSE response
> can
> > > be used the same way as OP_QUERY_CONTINUOUS_END_NOTIFICATION.
> > >
> > > Such notification (or something more generalized like
> OP_RESOURCE_CLOSED)
> > > can be helpful if CQ is closed by someone else (for example if
> > > administrator call QueryMXBean.cancelContinuous), but AFAIK now we
> don't
> > > have callbacks for this action on user side.
> > >
> > >
> > > ср, 15 июл. 2020 г. в 01:26, Pavel Tupitsyn :
> > >
> > > > Igniters,
> > > >
> > > > I've made an important change to the IEP (and the POC):
> > > > OP_QUERY_CONTINUOUS_END_NOTIFICATION is another client -> server
> > message
> > > > that notifies the client that the query has stopped and no more
> events
> > > > should be expected.
> > > >
> > > > This is important because client can't immediately stop listening
> > > > for OP_QUERY_CONTINUOUS_EVENT_NOTIFICATION
> > > > after sending OP_RESOURCE_CLOSE - some more events can be present in
> > one
> > > of
> > > > the buffers/queues of the server and/or the OS.
> > > >
> > > > Let me know if this makes sense.
> > > >
> > > > On Tue, Jul 14, 2020 at 3:25 PM Pavel Tupitsyn  >
> > > > wrote:
> > > >
> > > > > I've removed Initial Query from the POC and IEP (left a note there
> > > about
> > > > > the decision).
> > > > >
> > > > > Since there are no other comments and concerns, I'll move on with
> the
> > > > > final implementation.
> > > > >
> > > > > On Fri, Jul 10, 2020 at 4:14 PM Pavel Tupitsyn <
> ptupit...@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > >> Igor, Alex,
> > > > >>
> > > > >> I was aware of the duplicates issue with the initial query, but I
> > did
> > > > not
> > > > >> give it a second thought.
> > > > >>
> > > > >> Now I see that Vladimir was right - Initial query seems to be
> > > pointless,
> > > > >> since users can
> > > > >> achieve the same by simply invoking the regular query.
> > > > >>
> > > > >> I will remove Initial Query from the IEP and POC next week if
> there
> > > are
> > > > >> no objections by then.
> > > > >>
> > > > >>
> > > > >> On Fri, Jul 10, 2020 at 3:58 PM Alex Plehanov <
> > > plehanov.a...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >>> Igor, Pavel,
> > > > >>>
> > > > >>> Here is discussion about removal: [1]
> > > > >>>
> > > > >>> [1] :
> > > > >>>
> > > > >>>
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/ContinuousQueryWithTransformer-implementation-questions-2-td21418i20.html#a22041
> > > > >>>
> > > > >>> пт, 10 июл. 2020 г. в 17:44, Igor Sapego :
> > > > >>>
> > > > >>> > Can not find proposal to remove them, so maybe it was not on
> > > devlist,
> > > > >>> > but here is discussion about the problem: [1]
> > > > >>> >
> > > > >>> > [1] -
> > > > >>> >
> > > > >>> >
> > > > >>>
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Continuous-queries-and-duplicates-td39444.html
> > > > >>> >
> > > > >>> > Best Regards,
> > > > >>> > Igor
> > > > >>> >
> > > > >>> >
> > > > >>> > On Fri, Jul 10, 2020 at 3:27 PM Pavel Tupitsyn <
> > > ptupit...@apache.org
> > > > >
> > > > >>> > wrote:
> > > > >>> >
> > > > >>> > > > What's about "stop" message? How can user unsubscribe from
> > > > >>> receiving
> > > > >>> > > notifications?
> > > > >>> > > OP_RESOURCE_CLOSE is used for that. I've updated the IEP in
> an
> > > > >>> at

Re: request for contributors permissions

[Konstantin Sirotkin]

ksirotkin

On 2020/07/16 15:33:15, Denis Magda  wrote: 
> Hello Konstantin and welcome to the community!> 
> 
> Please share your JIRA id so that we can add you to the contributors' list> 
> there and you can select a ticket of your interest.> 
> 
> -> 
> Denis> 
> 
> 
> On Thu, Jul 16, 2020 at 8:29 AM Konstantin Sirotkin <> 
> konstantins...@gmail.com> wrote:> 
> 
> > Helloi've registered on> 
> > https://issues.apache.org/jira/secure/Dashboard.jsp> 
> >  and> 
> > according to> 
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute I'm> 
> > requesting contributors permissionsthank you> 
> >> 
> > Konstantin Sirotkin> 
> >> 
>  

С уважением,
Konstantin Sirotkin (Константин Сироткин) | Senior Java Developer
skype, telegram: konstantins304 | linkedin 
 | career.habr 

[jira] [Created] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required

[Vladislav Pyatkov (Jira)]

Vladislav Pyatkov created IGNITE-13265:
--

 Summary: Historical iterator for atomic group should transfer few 
more rows than required
 Key: IGNITE-13265
 URL: https://issues.apache.org/jira/browse/IGNITE-13265
 Project: Ignite
  Issue Type: Improvement
Reporter: Vladislav Pyatkov


On a historical rebalance some updates move from one node to another wherein 
this update may have various order in nodes. Reordering can happen in smell 
interval, but it cannot avoid at all in current implementation atomic protocol.

This mean we will reduce a probably of loosing update if we make a margin from 
initial counter for the historical iterator on atomic cache.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

New Committer: Sergey Chugunov

[Dmitriy Pavlov]

Dear Ignite Community,



The Project Management Committee (PMC) for Apache Ignite has invited Sergey
Chugunov to become a committer and we are pleased to announce that he has
accepted.



Sergey has a long story of Ignite contributions. Besides the code
contributions, Sergey has contributed the TCP Discovery Under The Hood wiki
page, posted a blog post about running Apache Ignite on AWS, and also
mentors newcomer contributors.



Being a committer enables easier contribution to the project since there is
no need to go via the patch submission process. This should enable better
productivity.



Sergey, congratulations on a new role in the Apache Ignite Community.



Best Regards,

Dmitriy Pavlov

on behalf of Apache Ignite PMC

P.S. this announce is a little bit overdue, but I guess Sergey's new role
was not announced to the community.

Re: Choosing historical rebalance heuristics

[Alexei Scherbakov]

Hi.

The proposed approach to improve rebalancing efficiency looks a little bit
naive to me.

A mature solution to a problem should include a computation of a "cost" for
each rebalancing type.

The cost formula should take into consideration various aspects, like
number of pages in the memory cache, page replacement, a disk read speed, a
number of indexes, etc.

For a short term solution the proposed heuristic looks acceptable.

My suggestions for an implementation:

1. Implement the cost framework right now.
The rebalance cost is measured as a sum of all costs for each rebalancing
group. This sum should be minimized.
Rebalancing behavior should be dependent only on cost formula outcome,
without the need of modifying other code.

2. Avoid unnecessary WAL scanning.
Ideally we should scan only segments containing required updates.
We can build for each partition a tracking data structure and adjust it on
each checkpoint and WAL archive removal, then use it for efficient scanning
during WAL iteration.

3. Avoid any calculations during the PME sync phase. The coordinator should
only collect available WAL history, switch lagging OWNING partitions to
MOVING, and send all this to the nodes.
After PME nodes should calculate a cost and choose the most efficient
rebalancing for local data.

4. We should log a reason for choosing a specific rebalancing type due to a
cost.

I'm planning to implement tombstones in the near future. This should remove
the requirement for clearing a partition before full rebalancing in most
cases, improving it's cost.

This can be further enhanced later using some kind of merkle trees, file
based rebalancing or something else.

чт, 16 июл. 2020 г. в 18:33, Ivan Rakov :

> >
> >  I think we can modify the heuristic so
> > 1) Exclude partitions by threshold (IGNITE_PDS_WAL_REBALANCE_THRESHOLD -
> > reduce it to 500)
> > 2) Select only that partition for historical rebalance where difference
> > between counters less that partition size.
>
> Agreed, let's go this way.
>
> On Thu, Jul 16, 2020 at 11:03 AM Vladislav Pyatkov 
> wrote:
>
> > I completely forget about another promise to favor of using historical
> > rebalance where it is possible. When cluster decided to use a full
> balance,
> > demander nodes should clear not empty partitions.
> > This can to consume a long time, in some cases that may be compared with
> a
> > time of rebalance.
> > It also accepts a side of heuristics above.
> >
> > On Thu, Jul 16, 2020 at 12:09 AM Vladislav Pyatkov  >
> > wrote:
> >
> > > Ivan,
> > >
> > > I agree with a combined approach: threshold for small partitions and
> > count
> > > of update for partition that outgrew it.
> > > This helps to avoid partitions that update not frequently.
> > >
> > > Reading of a big WAL piece (more than 100Gb) it can happen, when a
> client
> > > configured it intentionally.
> > > There are no doubts we can to read it, otherwise WAL space was not
> > > configured that too large.
> > >
> > > I don't see a connection optimization of iterator and issue in atomic
> > > protocol.
> > > Reordering in WAL, that happened in checkpoint where counter was not
> > > changing, is an extremely rare case and the issue will not solve for
> > > generic case, this should be fixed in bound of protocol.
> > >
> > > I think we can modify the heuristic so
> > > 1) Exclude partitions by threshold (IGNITE_PDS_WAL_REBALANCE_THRESHOLD
> -
> > > reduce it to 500)
> > > 2) Select only that partition for historical rebalance where difference
> > > between counters less that partition size.
> > >
> > > Also implement mentioned optimization for historical iterator, that may
> > > reduce a time on reading large WAL interval.
> > >
> > > On Wed, Jul 15, 2020 at 3:15 PM Ivan Rakov 
> > wrote:
> > >
> > >> Hi Vladislav,
> > >>
> > >> Thanks for raising this topic.
> > >> Currently present IGNITE_PDS_WAL_REBALANCE_THRESHOLD (default is
> > 500_000)
> > >> is controversial. Assuming that the default number of partitions is
> > 1024,
> > >> cache should contain a really huge amount of data in order to make WAL
> > >> delta rebalancing possible. In fact, it's currently disabled for most
> > >> production cases, which makes rebalancing of persistent caches
> > >> unreasonably
> > >> long.
> > >>
> > >> I think, your approach [1] makes much more sense than the current
> > >> heuristic, let's move forward with the proposed solution.
> > >>
> > >> Though, there are some other corner cases, e.g. this one:
> > >> - Configured size of WAL archive is big (>100 GB)
> > >> - Cache has small partitions (e.g. 1000 entries)
> > >> - Infrequent updates (e.g. ~100 in the whole WAL history of any node)
> > >> - There is another cache with very frequent updates which allocate
> >99%
> > of
> > >> WAL
> > >> In such scenario we may need to iterate over >100 GB of WAL in order
> to
> > >> fetch <1% of needed updates. Even though the amount of network traffic
> > is
> > >> still optimized, it would be more effective to transfer

Re: [RESULT][VOTE] Stop Maintenance of Ignite Web Console

[Dmitriy Pavlov]

Hello,

It makes sense, thank you

Sincerely,
Dmitriy Pavlov

ср, 15 июл. 2020 г. в 17:23, Ilya Kasnacheev :

> Hello!
>
> I think that we indeed should version this change, i.e., only remove
> mentions of Web Console in the version where it's already in the attic.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 15 июл. 2020 г. в 17:17, Denis Magda :
>
> > We should remove the docs and all the mentioning from the website once
> this
> > ticket is complete:
> > https://issues.apache.org/jira/plugins/servlet/mobile#issue/IGNITE-13038
> >
> > Alex Kuznetsov, are you planning to finish the task in Ignite 2.9
> > timeframe?
> >
> > Denis
> >
> > On Wednesday, July 15, 2020, Ilya Kasnacheev 
> > wrote:
> >
> > > Hello!
> > >
> > > Well, why? I think we can keep Web Console docs for now, just add some
> > note
> > > that it is discontinued. We can also put deprecation notice here.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 13 июл. 2020 г. в 19:46, Dmitriy Pavlov :
> > >
> > > > Hi Folks,
> > > >
> > > > I've just found our doc still point and recommend using it.
> > > >
> > > > I suggest removing the automatic RDBMS import option from Cache-Store
> > > > documentation:
> > > > https://apacheignite.readme.io/docs/3rd-party-store#automatic
> > > >
> > > > Sincerely
> > > > Dmitriy Pavlov
> > > >
> > > > ср, 20 мая 2020 г. в 01:49, Denis Magda :
> > > >
> > > > > Igniters,
> > > > >
> > > > > The vote is over [1] with a decision to phase out Ignite Web
> Console
> > by
> > > > > moving to a separate repository and stopping its
> > > development/maintenance
> > > > > officially. The following PMC members cast +1 binding votes:
> > > > >
> > > > >- Saikat Maitra
> > > > >- Alexey Zinoviev
> > > > >- Nikolay Izhikov
> > > > >
> > > > > There are no -1 votes thus we can proceed with the tool
> > discontinuation
> > > > > procedure [2].
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > > http://apache-ignite-developers.2346864.n4.nabble.
> > > com/VOTE-Stop-Maintenance-of-Ignite-WebConsole-td47451.html
> > > > > [2] https://issues.apache.org/jira/browse/IGNITE-13038
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > >
> > >
> >
> >
> > --
> > -
> > Denis
> >
>

Re: [RESULT][VOTE] Stop Maintenance of Ignite Web Console

[Alexey Kuznetsov]

Dmitriy,

I'm working on moving Web Console to separate repository IGNITE-13038
,
 but I can not commit to https://github.com/apache/ignite-web-console

Do you know how I can be granted with commit rights?

---
Alexey Kuznetsov

Re: New Committer: Sergey Chugunov

[Nikita Amelchev]

Hi Sergey,

My congratulations!

пт, 17 июл. 2020 г. в 12:32, Dmitriy Pavlov :
>
> Dear Ignite Community,
>
>
>
> The Project Management Committee (PMC) for Apache Ignite has invited Sergey
> Chugunov to become a committer and we are pleased to announce that he has
> accepted.
>
>
>
> Sergey has a long story of Ignite contributions. Besides the code
> contributions, Sergey has contributed the TCP Discovery Under The Hood wiki
> page, posted a blog post about running Apache Ignite on AWS, and also
> mentors newcomer contributors.
>
>
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
>
>
>
> Sergey, congratulations on a new role in the Apache Ignite Community.
>
>
>
> Best Regards,
>
> Dmitriy Pavlov
>
> on behalf of Apache Ignite PMC
>
> P.S. this announce is a little bit overdue, but I guess Sergey's new role
> was not announced to the community.



-- 
Best wishes,
Amelchev Nikita

Re: New Committer: Sergey Chugunov

[Roman Kondakov]

Sergey, congratulations!

--
Roman Kondakov

On 17.07.2020 12:32, Dmitriy Pavlov wrote:

Dear Ignite Community,



The Project Management Committee (PMC) for Apache Ignite has invited Sergey
Chugunov to become a committer and we are pleased to announce that he has
accepted.



Sergey has a long story of Ignite contributions. Besides the code
contributions, Sergey has contributed the TCP Discovery Under The Hood wiki
page, posted a blog post about running Apache Ignite on AWS, and also
mentors newcomer contributors.



Being a committer enables easier contribution to the project since there is
no need to go via the patch submission process. This should enable better
productivity.



Sergey, congratulations on a new role in the Apache Ignite Community.



Best Regards,

Dmitriy Pavlov

on behalf of Apache Ignite PMC

P.S. this announce is a little bit overdue, but I guess Sergey's new role
was not announced to the community.

Re: A few small pull requests

[Stephen Darlington]

I had the same problem with “your" link… not sure what is going on!

I’ve added suggestions for documentation in the ticket as suggested.

Regards,
Stephen

> On 17 Jul 2020, at 01:00, Denis Magda  wrote:
> 
> Weird, works now. Seems to be some browser-related issue on my end.
> 
> Overall, thanks a lot for the contribution. I'm suggesting us to merge
> IGNITE-11715 into the Ignite 2.9 release branch. Left details in JIRA.
> 
> -
> Denis
> 
> 
> On Thu, Jul 16, 2020 at 9:44 AM Stephen Darlington <
> stephen.darling...@gridgain.com> wrote:
> 
>> This link works for me: https://issues.apache.org/jira/browse/IGNITE-11715
>> 
>> 
>>> On 16 Jul 2020, at 16:47, Denis Magda  wrote:
>>> 
>>> Hi Stephen,
>>> 
>>> Thanks for reminding us about these pending contributions.
>>> 
>>> IGNITE-12192 Allow ignitevisorcmd to quit when pressing ^D <
 https://github.com/apache/ignite/pull/6877>
>>> 
>>> 
>>> Merged the changes. Thanks!
>>> 
>>> IGNITE-12182 ExecutorService defaults to only server nodes <
 https://github.com/apache/ignite/pull/6876>
>>> 
>>> 
>>> I'm afraid we can't merge this change until Ignite 3.0. Otherwise, it
>> will
>>> break backward compatibility.
>>> 
>>> IGNITE-11715 Allow extra options to be passed in to ignite.sh from
>> Docker <
 https://github.com/apache/ignite/pull/6552>
>>> 
>>> 
>>> Could you confirm that the JIRA ticket is correct? Whenever I try to open
>>> IGNITE-11715 in JIRA it redirects me to
>>> https://issues.apache.org/jira/projects/IGNITE/issues/IGNITE-13264
>>> 
>>> 
>>> -
>>> Denis
>>> 
>>> 
>>> On Wed, Jul 15, 2020 at 6:42 AM Stephen Darlington <
>>> stephen.darling...@gridgain.com> wrote:
>>> 
 Hi,
 
 I have a few small quality-of-life pull requests languishing in the
 backlog. Can anyone take a look or suggest what else I need to do to
 progress them?
 
 IGNITE-12192 Allow ignitevisorcmd to quit when pressing ^D <
 https://github.com/apache/ignite/pull/6877>
 IGNITE-12182 ExecutorService defaults to only server nodes <
 https://github.com/apache/ignite/pull/6876>
 IGNITE-11715 Allow extra options to be passed in to ignite.sh from
>> Docker <
 https://github.com/apache/ignite/pull/6552>
 
 Thanks,
 Stephen
 
 
>> 
>> 
>> 

Re: New Committer: Sergey Chugunov

[Petr Ivanov]

Congratulations!


> On 17 Jul 2020, at 14:14, Roman Kondakov  wrote:
> 
> Sergey, congratulations!
> 
> -- 
> Roman Kondakov
> 
> On 17.07.2020 12:32, Dmitriy Pavlov wrote:
>> Dear Ignite Community,
>> The Project Management Committee (PMC) for Apache Ignite has invited Sergey
>> Chugunov to become a committer and we are pleased to announce that he has
>> accepted.
>> Sergey has a long story of Ignite contributions. Besides the code
>> contributions, Sergey has contributed the TCP Discovery Under The Hood wiki
>> page, posted a blog post about running Apache Ignite on AWS, and also
>> mentors newcomer contributors.
>> Being a committer enables easier contribution to the project since there is
>> no need to go via the patch submission process. This should enable better
>> productivity.
>> Sergey, congratulations on a new role in the Apache Ignite Community.
>> Best Regards,
>> Dmitriy Pavlov
>> on behalf of Apache Ignite PMC
>> P.S. this announce is a little bit overdue, but I guess Sergey's new role
>> was not announced to the community.

Re: New Committer: Sergey Chugunov

[Ivan Pavlukhin]

Sergey, congratulations!

2020-07-17 14:25 GMT+03:00, Petr Ivanov :
> Congratulations!
>
>
>> On 17 Jul 2020, at 14:14, Roman Kondakov 
>> wrote:
>>
>> Sergey, congratulations!
>>
>> --
>> Roman Kondakov
>>
>> On 17.07.2020 12:32, Dmitriy Pavlov wrote:
>>> Dear Ignite Community,
>>> The Project Management Committee (PMC) for Apache Ignite has invited
>>> Sergey
>>> Chugunov to become a committer and we are pleased to announce that he
>>> has
>>> accepted.
>>> Sergey has a long story of Ignite contributions. Besides the code
>>> contributions, Sergey has contributed the TCP Discovery Under The Hood
>>> wiki
>>> page, posted a blog post about running Apache Ignite on AWS, and also
>>> mentors newcomer contributors.
>>> Being a committer enables easier contribution to the project since there
>>> is
>>> no need to go via the patch submission process. This should enable
>>> better
>>> productivity.
>>> Sergey, congratulations on a new role in the Apache Ignite Community.
>>> Best Regards,
>>> Dmitriy Pavlov
>>> on behalf of Apache Ignite PMC
>>> P.S. this announce is a little bit overdue, but I guess Sergey's new
>>> role
>>> was not announced to the community.
>
>


-- 

Best regards,
Ivan Pavlukhin

Re: [RESULT][VOTE] Stop Maintenance of Ignite Web Console

[Ivan Pavlukhin]

Alexey,

How exactly are you trying to commit? A have just committed an empty
README without any additional configuration. I did it directly from
GitHub web UI. Have you tried "real" repository address
https://gitbox.apache.org/repos/asf/ignite-web-console.git ?

2020-07-17 14:01 GMT+03:00, Alexey Kuznetsov :
> Dmitriy,
>
> I'm working on moving Web Console to separate repository IGNITE-13038
> ,
>  but I can not commit to https://github.com/apache/ignite-web-console
>
> Do you know how I can be granted with commit rights?
>
> ---
> Alexey Kuznetsov
>


-- 

Best regards,
Ivan Pavlukhin

[jira] [Created] (IGNITE-13266) PDS (Indexing) fails with 'Exit code 137"

[Ivan Bessonov (Jira)]

Ivan Bessonov created IGNITE-13266:
--

 Summary: PDS (Indexing) fails with 'Exit code 137"
 Key: IGNITE-13266
 URL: https://issues.apache.org/jira/browse/IGNITE-13266
 Project: Ignite
  Issue Type: Test
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


[https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsIndexing&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeHistoryList]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: New Committer: Sergey Chugunov

[Вячеслав Коптилин]

Hi,

Well deserved! Keep it up, Sergey!

Thanks,
S.

пт, 17 июл. 2020 г. в 14:36, Ivan Pavlukhin :

> Sergey, congratulations!
>
> 2020-07-17 14:25 GMT+03:00, Petr Ivanov :
> > Congratulations!
> >
> >
> >> On 17 Jul 2020, at 14:14, Roman Kondakov 
> >> wrote:
> >>
> >> Sergey, congratulations!
> >>
> >> --
> >> Roman Kondakov
> >>
> >> On 17.07.2020 12:32, Dmitriy Pavlov wrote:
> >>> Dear Ignite Community,
> >>> The Project Management Committee (PMC) for Apache Ignite has invited
> >>> Sergey
> >>> Chugunov to become a committer and we are pleased to announce that he
> >>> has
> >>> accepted.
> >>> Sergey has a long story of Ignite contributions. Besides the code
> >>> contributions, Sergey has contributed the TCP Discovery Under The Hood
> >>> wiki
> >>> page, posted a blog post about running Apache Ignite on AWS, and also
> >>> mentors newcomer contributors.
> >>> Being a committer enables easier contribution to the project since
> there
> >>> is
> >>> no need to go via the patch submission process. This should enable
> >>> better
> >>> productivity.
> >>> Sergey, congratulations on a new role in the Apache Ignite Community.
> >>> Best Regards,
> >>> Dmitriy Pavlov
> >>> on behalf of Apache Ignite PMC
> >>> P.S. this announce is a little bit overdue, but I guess Sergey's new
> >>> role
> >>> was not announced to the community.
> >
> >
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>

Re: [RESULT][VOTE] Stop Maintenance of Ignite Web Console

[Alexey Kuznetsov]

Ivan, thanks!

I tried to commit to GitHub mirror.

On Fri, Jul 17, 2020 at 6:43 PM Ivan Pavlukhin  wrote:

> Alexey,
>
> How exactly are you trying to commit? A have just committed an empty
> README without any additional configuration. I did it directly from
> GitHub web UI. Have you tried "real" repository address
> https://gitbox.apache.org/repos/asf/ignite-web-console.git ?
>
> 2020-07-17 14:01 GMT+03:00, Alexey Kuznetsov :
> > Dmitriy,
> >
> > I'm working on moving Web Console to separate repository IGNITE-13038
> > ,
> >  but I can not commit to https://github.com/apache/ignite-web-console
> >
> > Do you know how I can be granted with commit rights?
> >
> > ---
> > Alexey Kuznetsov
> >
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>


-- 
---
Alexey Kuznetsov

Re: Moving Ignite documentation to github

[Artem Budnikov]

Hi everyone,

I've prepared the initial set of source files for the Ignite 
documentation. If you are interested, you can take a look at 
https://github.com/apache/ignite/tree/IGNITE-7595/docs


You can run a local web-server (jekyll) if you want to view the docs in 
your browser. Refer to the README.adoc for instructions. Some people had 
troubles installing Jekyll locally, so I added an instruction on how to 
use jekyll docker image.


If you have any comments on the overall approach, please let me know. 
The styles and content are still a work in progress, so please don't 
report issues related to that.


-Artem

On 26.06.2020 01:54, Guru Stron wrote:

+1 for migrating docs to github. It will allow an easier contribution for
docs, I think. As a nice feature - adding an edit link (submit PR for docs)
to the document page on site.

As for keeping them separate - Microsoft keeps docs for it's products in
separate repos, for example.

On Thu, 25 Jun 2020 at 15:48, Artem Budnikov 
wrote:


OK, let's give it a try.

The way I see it, the documentation source files will be located in the
"/docs" folder, including UI templates/styles, asciidoc files, and build
scripts. I'll start experimenting with this and will let you know when
basic setup is ready.

-Artem

On 23.06.2020 20:19, Denis Magda wrote:

I believe that by keeping the documentation sources in the same

repository

with the source code will help us to prepare and release all the release
artifacts at the same time. So, +1 for hosting raw documentation

ascii-doc

pages in the main Ignite repo. However, the HTML version needs to reside

on

the Ignite website, which is similar to the API docs. We can create tools
to do this in one click.

Post-reviews are not prohibited in Apache, quite the opposite, and they
suit the documentation contribution process better. It's ok if committers
to the documentation merge the changes first and ask for a review later

if

needed.

-
Denis


On Tue, Jun 23, 2020 at 6:53 AM Artem Budnikov <

a.budnikov.ign...@gmail.com>

wrote:


Pavel,


I don't think so: we can't add snippets pointing to new APIs from a
separate repo,

Snippets are kept together with the docs, they /don't need/ to be stored
in the main repo, although they can. They are compilable and up to date.
I update the docs and API samples for features that hasn't been released
in the GridGain docs and never thought it was a problem. I understand
that you don't want to do extra work when adding code samples, but it
looks like just an inconvenience. Let me suggest this: Let's think about
a solution that will be comfortable for you, I'm pretty sure this
inconvenience can be solved technically. But I need time to think it
through.


we can't see the docs when doing global search (and/or replace) from
the IDE.

I think you can add the docs repo to your IDE as a project. I used to do
it in the beginning but then switched to Sublime Text, because it's more
convenient to me. We are looking at it from different perspectives. I'm
trying to create a process that is comfortable for tech writers rather
than developers. And everybody has to accept some kind of a compromise:)


Well, no one is able to "freely" commit code to Apache master, there
is a process to follow - CI, reviews, etc.
Same should happen for the docs, separate repo or not.
But a separate repo will require separate ownership/management
(probably?),
but we already have everything in the main repo, why introduce

overhead?

Just think about it from my perspective. That creates a HUUUGE overhead
for technical writers who work on the docs, and they are the ones who
provide 90% of updates. I agree about the review process, and I'm going
to think it over. But now it seems that we don't have to impose any
strict process that impedes preparation of the docs.

-Artem


On 23.06.2020 15:35, Pavel Tupitsyn wrote:

all your pros points work just as well for a separate repository

I don't think so: we can't add snippets pointing to new APIs from a
separate repo,
we can't see the docs when doing global search (and/or replace) from
the IDE.


I am able to freely commit to master

Well, no one is able to "freely" commit code to Apache master, there
is a process to follow - CI, reviews, etc.
Same should happen for the docs, separate repo or not.
But a separate repo will require separate ownership/management
(probably?),
but we already have everything in the main repo, why introduce

overhead?

On Tue, Jun 23, 2020 at 2:59 PM Artem Budnikov
mailto:a.budnikov.ign...@gmail.com>>

wrote:

  Pavel,

  As far as I can see, all your pros points work just as well for a
  separate repository (except for "everybody knows about it"). I

don't

  mind keeping the docs in Ignite repo as long as I am able to

freely

  commit to master. Will I be able to do that?

  -Artem

  On 23.06.2020 14:04, Pavel Tupitsyn wrote:
  > Ilya, Artem,
  >
  > "Separate repo just because we can't finish docs before

Re: [RESULT][VOTE] Stop Maintenance of Ignite Web Console

[Dmitriy Pavlov]

Hi Alexey,

You can commit to the GitHub mirror as well as to the original repo. The
only thing you should do it to set up a correspondence between GitHub
account and Apache account

You can do it here https://gitbox.apache.org/setup/ Please keep in mind,
additional 2FA should be enabled for the Github login.

Sincerely,
Dmitriy Pavlov

пт, 17 июл. 2020 г. в 15:24, Alexey Kuznetsov :

> Ivan, thanks!
>
> I tried to commit to GitHub mirror.
>
> On Fri, Jul 17, 2020 at 6:43 PM Ivan Pavlukhin 
> wrote:
>
> > Alexey,
> >
> > How exactly are you trying to commit? A have just committed an empty
> > README without any additional configuration. I did it directly from
> > GitHub web UI. Have you tried "real" repository address
> > https://gitbox.apache.org/repos/asf/ignite-web-console.git ?
> >
> > 2020-07-17 14:01 GMT+03:00, Alexey Kuznetsov :
> > > Dmitriy,
> > >
> > > I'm working on moving Web Console to separate repository IGNITE-13038
> > > ,
> > >  but I can not commit to https://github.com/apache/ignite-web-console
> > >
> > > Do you know how I can be granted with commit rights?
> > >
> > > ---
> > > Alexey Kuznetsov
> > >
> >
> >
> > --
> >
> > Best regards,
> > Ivan Pavlukhin
> >
>
>
> --
> ---
> Alexey Kuznetsov
>

Re: Moving Ignite documentation to github

[Ilya Kasnacheev]

Hello!

I was able to eventually run it. The trick is to only install bundler with
apt, and not jekyll, once you install any other gems, they collide and it
will fail.

Looks OK. For some reason "Working with SQL" leads nowhere.

Regards,
-- 
Ilya Kasnacheev


пт, 17 июл. 2020 г. в 15:27, Artem Budnikov :

> Hi everyone,
>
> I've prepared the initial set of source files for the Ignite
> documentation. If you are interested, you can take a look at
> https://github.com/apache/ignite/tree/IGNITE-7595/docs
>
> You can run a local web-server (jekyll) if you want to view the docs in
> your browser. Refer to the README.adoc for instructions. Some people had
> troubles installing Jekyll locally, so I added an instruction on how to
> use jekyll docker image.
>
> If you have any comments on the overall approach, please let me know.
> The styles and content are still a work in progress, so please don't
> report issues related to that.
>
> -Artem
>
> On 26.06.2020 01:54, Guru Stron wrote:
> > +1 for migrating docs to github. It will allow an easier contribution for
> > docs, I think. As a nice feature - adding an edit link (submit PR for
> docs)
> > to the document page on site.
> >
> > As for keeping them separate - Microsoft keeps docs for it's products in
> > separate repos, for example.
> >
> > On Thu, 25 Jun 2020 at 15:48, Artem Budnikov <
> a.budnikov.ign...@gmail.com>
> > wrote:
> >
> >> OK, let's give it a try.
> >>
> >> The way I see it, the documentation source files will be located in the
> >> "/docs" folder, including UI templates/styles, asciidoc files, and build
> >> scripts. I'll start experimenting with this and will let you know when
> >> basic setup is ready.
> >>
> >> -Artem
> >>
> >> On 23.06.2020 20:19, Denis Magda wrote:
> >>> I believe that by keeping the documentation sources in the same
> >> repository
> >>> with the source code will help us to prepare and release all the
> release
> >>> artifacts at the same time. So, +1 for hosting raw documentation
> >> ascii-doc
> >>> pages in the main Ignite repo. However, the HTML version needs to
> reside
> >> on
> >>> the Ignite website, which is similar to the API docs. We can create
> tools
> >>> to do this in one click.
> >>>
> >>> Post-reviews are not prohibited in Apache, quite the opposite, and they
> >>> suit the documentation contribution process better. It's ok if
> committers
> >>> to the documentation merge the changes first and ask for a review later
> >> if
> >>> needed.
> >>>
> >>> -
> >>> Denis
> >>>
> >>>
> >>> On Tue, Jun 23, 2020 at 6:53 AM Artem Budnikov <
> >> a.budnikov.ign...@gmail.com>
> >>> wrote:
> >>>
>  Pavel,
> 
> > I don't think so: we can't add snippets pointing to new APIs from a
> > separate repo,
>  Snippets are kept together with the docs, they /don't need/ to be
> stored
>  in the main repo, although they can. They are compilable and up to
> date.
>  I update the docs and API samples for features that hasn't been
> released
>  in the GridGain docs and never thought it was a problem. I understand
>  that you don't want to do extra work when adding code samples, but it
>  looks like just an inconvenience. Let me suggest this: Let's think
> about
>  a solution that will be comfortable for you, I'm pretty sure this
>  inconvenience can be solved technically. But I need time to think it
>  through.
> 
> > we can't see the docs when doing global search (and/or replace) from
> > the IDE.
>  I think you can add the docs repo to your IDE as a project. I used to
> do
>  it in the beginning but then switched to Sublime Text, because it's
> more
>  convenient to me. We are looking at it from different perspectives.
> I'm
>  trying to create a process that is comfortable for tech writers rather
>  than developers. And everybody has to accept some kind of a
> compromise:)
> 
> >> Well, no one is able to "freely" commit code to Apache master, there
> >> is a process to follow - CI, reviews, etc.
> >> Same should happen for the docs, separate repo or not.
> >> But a separate repo will require separate ownership/management
> >> (probably?),
> >> but we already have everything in the main repo, why introduce
> >> overhead?
>  Just think about it from my perspective. That creates a HUUUGE
> overhead
>  for technical writers who work on the docs, and they are the ones who
>  provide 90% of updates. I agree about the review process, and I'm
> going
>  to think it over. But now it seems that we don't have to impose any
>  strict process that impedes preparation of the docs.
> 
>  -Artem
> 
> 
>  On 23.06.2020 15:35, Pavel Tupitsyn wrote:
> >> all your pros points work just as well for a separate repository
> > I don't think so: we can't add snippets pointing to new APIs from a
> > separate repo,
> > we can't see the docs when doing global search (and/or replace) from
> >

[jira] [Created] (IGNITE-13267) AffinityFunction & AffinityKeyMapper are not peer class loadable

[Ilya Kasnacheev (Jira)]

Ilya Kasnacheev created IGNITE-13267:


 Summary: AffinityFunction & AffinityKeyMapper are not peer class 
loadable
 Key: IGNITE-13267
 URL: https://issues.apache.org/jira/browse/IGNITE-13267
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.8.1
Reporter: Ilya Kasnacheev


We have a test GridP2PAffinitySelfTest/GridAffinityP2PSelfTest which suggest 
they should be peer loadable, but they are not, and for a good reason - they 
are passed as a part of cache configuration via Discovery.

Maybe we should investigate this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: request for contributors permissions

[Denis Magda]

Konstantin,

You're in. Go ahead and select a ticket you'd like to work on. Just in
case, here is a list of tasks collected by the community members for
newcomers (see Code Contributions and Contributions to Ignite Core
sections):
https://ignite.apache.org/community/contribute.html

Let us know if you have any questions or need further guidance. Good luck!

-
Denis


On Fri, Jul 17, 2020 at 1:41 AM Konstantin Sirotkin <
konstantins...@gmail.com> wrote:

> ksirotkin
>
> On 2020/07/16 15:33:15, Denis Magda  wrote:
> > Hello Konstantin and welcome to the community!>
> >
> > Please share your JIRA id so that we can add you to the contributors'
> list>
> > there and you can select a ticket of your interest.>
> >
> > ->
> > Denis>
> >
> >
> > On Thu, Jul 16, 2020 at 8:29 AM Konstantin Sirotkin <>
> > konstantins...@gmail.com> wrote:>
> >
> > > Helloi've registered on>
> > > https://issues.apache.org/jira/secure/Dashboard.jsp>
> > >  and>
> > > according to>
> > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> I'm>
> > > requesting contributors permissionsthank you>
> > >>
> > > Konstantin Sirotkin>
> > >>
> >
>
> С уважением,
> Konstantin Sirotkin (Константин Сироткин) | Senior Java Developer
> skype, telegram: konstantins304 | linkedin <
> https://www.linkedin.com/in/konstantin-sirotkin-609b31100> | career.habr <
> https://career.habr.com/konstantins304>
>

Re: New Committer: Sergey Chugunov

[Andrey Mashenkov]

Congratulations, Sergey.

пт, 17 июл. 2020 г., 15:06 Вячеслав Коптилин :

> Hi,
>
> Well deserved! Keep it up, Sergey!
>
> Thanks,
> S.
>
> пт, 17 июл. 2020 г. в 14:36, Ivan Pavlukhin :
>
> > Sergey, congratulations!
> >
> > 2020-07-17 14:25 GMT+03:00, Petr Ivanov :
> > > Congratulations!
> > >
> > >
> > >> On 17 Jul 2020, at 14:14, Roman Kondakov 
> > >> wrote:
> > >>
> > >> Sergey, congratulations!
> > >>
> > >> --
> > >> Roman Kondakov
> > >>
> > >> On 17.07.2020 12:32, Dmitriy Pavlov wrote:
> > >>> Dear Ignite Community,
> > >>> The Project Management Committee (PMC) for Apache Ignite has invited
> > >>> Sergey
> > >>> Chugunov to become a committer and we are pleased to announce that he
> > >>> has
> > >>> accepted.
> > >>> Sergey has a long story of Ignite contributions. Besides the code
> > >>> contributions, Sergey has contributed the TCP Discovery Under The
> Hood
> > >>> wiki
> > >>> page, posted a blog post about running Apache Ignite on AWS, and also
> > >>> mentors newcomer contributors.
> > >>> Being a committer enables easier contribution to the project since
> > there
> > >>> is
> > >>> no need to go via the patch submission process. This should enable
> > >>> better
> > >>> productivity.
> > >>> Sergey, congratulations on a new role in the Apache Ignite Community.
> > >>> Best Regards,
> > >>> Dmitriy Pavlov
> > >>> on behalf of Apache Ignite PMC
> > >>> P.S. this announce is a little bit overdue, but I guess Sergey's new
> > >>> role
> > >>> was not announced to the community.
> > >
> > >
> >
> >
> > --
> >
> > Best regards,
> > Ivan Pavlukhin
> >
>

Re: New Committer: Sergey Chugunov

[Sergey Antonov]

Congratulations, Sergey!

сб, 18 июл. 2020 г., 0:24 Andrey Mashenkov :

> Congratulations, Sergey.
>
> пт, 17 июл. 2020 г., 15:06 Вячеслав Коптилин :
>
> > Hi,
> >
> > Well deserved! Keep it up, Sergey!
> >
> > Thanks,
> > S.
> >
> > пт, 17 июл. 2020 г. в 14:36, Ivan Pavlukhin :
> >
> > > Sergey, congratulations!
> > >
> > > 2020-07-17 14:25 GMT+03:00, Petr Ivanov :
> > > > Congratulations!
> > > >
> > > >
> > > >> On 17 Jul 2020, at 14:14, Roman Kondakov  >
> > > >> wrote:
> > > >>
> > > >> Sergey, congratulations!
> > > >>
> > > >> --
> > > >> Roman Kondakov
> > > >>
> > > >> On 17.07.2020 12:32, Dmitriy Pavlov wrote:
> > > >>> Dear Ignite Community,
> > > >>> The Project Management Committee (PMC) for Apache Ignite has
> invited
> > > >>> Sergey
> > > >>> Chugunov to become a committer and we are pleased to announce that
> he
> > > >>> has
> > > >>> accepted.
> > > >>> Sergey has a long story of Ignite contributions. Besides the code
> > > >>> contributions, Sergey has contributed the TCP Discovery Under The
> > Hood
> > > >>> wiki
> > > >>> page, posted a blog post about running Apache Ignite on AWS, and
> also
> > > >>> mentors newcomer contributors.
> > > >>> Being a committer enables easier contribution to the project since
> > > there
> > > >>> is
> > > >>> no need to go via the patch submission process. This should enable
> > > >>> better
> > > >>> productivity.
> > > >>> Sergey, congratulations on a new role in the Apache Ignite
> Community.
> > > >>> Best Regards,
> > > >>> Dmitriy Pavlov
> > > >>> on behalf of Apache Ignite PMC
> > > >>> P.S. this announce is a little bit overdue, but I guess Sergey's
> new
> > > >>> role
> > > >>> was not announced to the community.
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> >
>

Re: New Committer: Sergey Chugunov

[Ivan Daschinsky]

Congrats! Well deserved!

пт, 17 июл. 2020 г. в 20:46, Sergey Antonov :

> Congratulations, Sergey!
>
> сб, 18 июл. 2020 г., 0:24 Andrey Mashenkov :
>
> > Congratulations, Sergey.
> >
> > пт, 17 июл. 2020 г., 15:06 Вячеслав Коптилин :
> >
> > > Hi,
> > >
> > > Well deserved! Keep it up, Sergey!
> > >
> > > Thanks,
> > > S.
> > >
> > > пт, 17 июл. 2020 г. в 14:36, Ivan Pavlukhin :
> > >
> > > > Sergey, congratulations!
> > > >
> > > > 2020-07-17 14:25 GMT+03:00, Petr Ivanov :
> > > > > Congratulations!
> > > > >
> > > > >
> > > > >> On 17 Jul 2020, at 14:14, Roman Kondakov
>  > >
> > > > >> wrote:
> > > > >>
> > > > >> Sergey, congratulations!
> > > > >>
> > > > >> --
> > > > >> Roman Kondakov
> > > > >>
> > > > >> On 17.07.2020 12:32, Dmitriy Pavlov wrote:
> > > > >>> Dear Ignite Community,
> > > > >>> The Project Management Committee (PMC) for Apache Ignite has
> > invited
> > > > >>> Sergey
> > > > >>> Chugunov to become a committer and we are pleased to announce
> that
> > he
> > > > >>> has
> > > > >>> accepted.
> > > > >>> Sergey has a long story of Ignite contributions. Besides the code
> > > > >>> contributions, Sergey has contributed the TCP Discovery Under The
> > > Hood
> > > > >>> wiki
> > > > >>> page, posted a blog post about running Apache Ignite on AWS, and
> > also
> > > > >>> mentors newcomer contributors.
> > > > >>> Being a committer enables easier contribution to the project
> since
> > > > there
> > > > >>> is
> > > > >>> no need to go via the patch submission process. This should
> enable
> > > > >>> better
> > > > >>> productivity.
> > > > >>> Sergey, congratulations on a new role in the Apache Ignite
> > Community.
> > > > >>> Best Regards,
> > > > >>> Dmitriy Pavlov
> > > > >>> on behalf of Apache Ignite PMC
> > > > >>> P.S. this announce is a little bit overdue, but I guess Sergey's
> > new
> > > > >>> role
> > > > >>> was not announced to the community.
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > >
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: Moving Ignite documentation to github

[Denis Magda]

Worked out well on my end. Thanks for sending the update!

How about the next step of taking the HTML and committing it to the website
repository? Did you have a chance to think through this step?

-
Denis


On Fri, Jul 17, 2020 at 5:27 AM Artem Budnikov 
wrote:

> Hi everyone,
>
> I've prepared the initial set of source files for the Ignite
> documentation. If you are interested, you can take a look at
> https://github.com/apache/ignite/tree/IGNITE-7595/docs
>
> You can run a local web-server (jekyll) if you want to view the docs in
> your browser. Refer to the README.adoc for instructions. Some people had
> troubles installing Jekyll locally, so I added an instruction on how to
> use jekyll docker image.
>
> If you have any comments on the overall approach, please let me know.
> The styles and content are still a work in progress, so please don't
> report issues related to that.
>
> -Artem
>
> On 26.06.2020 01:54, Guru Stron wrote:
> > +1 for migrating docs to github. It will allow an easier contribution for
> > docs, I think. As a nice feature - adding an edit link (submit PR for
> docs)
> > to the document page on site.
> >
> > As for keeping them separate - Microsoft keeps docs for it's products in
> > separate repos, for example.
> >
> > On Thu, 25 Jun 2020 at 15:48, Artem Budnikov <
> a.budnikov.ign...@gmail.com>
> > wrote:
> >
> >> OK, let's give it a try.
> >>
> >> The way I see it, the documentation source files will be located in the
> >> "/docs" folder, including UI templates/styles, asciidoc files, and build
> >> scripts. I'll start experimenting with this and will let you know when
> >> basic setup is ready.
> >>
> >> -Artem
> >>
> >> On 23.06.2020 20:19, Denis Magda wrote:
> >>> I believe that by keeping the documentation sources in the same
> >> repository
> >>> with the source code will help us to prepare and release all the
> release
> >>> artifacts at the same time. So, +1 for hosting raw documentation
> >> ascii-doc
> >>> pages in the main Ignite repo. However, the HTML version needs to
> reside
> >> on
> >>> the Ignite website, which is similar to the API docs. We can create
> tools
> >>> to do this in one click.
> >>>
> >>> Post-reviews are not prohibited in Apache, quite the opposite, and they
> >>> suit the documentation contribution process better. It's ok if
> committers
> >>> to the documentation merge the changes first and ask for a review later
> >> if
> >>> needed.
> >>>
> >>> -
> >>> Denis
> >>>
> >>>
> >>> On Tue, Jun 23, 2020 at 6:53 AM Artem Budnikov <
> >> a.budnikov.ign...@gmail.com>
> >>> wrote:
> >>>
>  Pavel,
> 
> > I don't think so: we can't add snippets pointing to new APIs from a
> > separate repo,
>  Snippets are kept together with the docs, they /don't need/ to be
> stored
>  in the main repo, although they can. They are compilable and up to
> date.
>  I update the docs and API samples for features that hasn't been
> released
>  in the GridGain docs and never thought it was a problem. I understand
>  that you don't want to do extra work when adding code samples, but it
>  looks like just an inconvenience. Let me suggest this: Let's think
> about
>  a solution that will be comfortable for you, I'm pretty sure this
>  inconvenience can be solved technically. But I need time to think it
>  through.
> 
> > we can't see the docs when doing global search (and/or replace) from
> > the IDE.
>  I think you can add the docs repo to your IDE as a project. I used to
> do
>  it in the beginning but then switched to Sublime Text, because it's
> more
>  convenient to me. We are looking at it from different perspectives.
> I'm
>  trying to create a process that is comfortable for tech writers rather
>  than developers. And everybody has to accept some kind of a
> compromise:)
> 
> >> Well, no one is able to "freely" commit code to Apache master, there
> >> is a process to follow - CI, reviews, etc.
> >> Same should happen for the docs, separate repo or not.
> >> But a separate repo will require separate ownership/management
> >> (probably?),
> >> but we already have everything in the main repo, why introduce
> >> overhead?
>  Just think about it from my perspective. That creates a HUUUGE
> overhead
>  for technical writers who work on the docs, and they are the ones who
>  provide 90% of updates. I agree about the review process, and I'm
> going
>  to think it over. But now it seems that we don't have to impose any
>  strict process that impedes preparation of the docs.
> 
>  -Artem
> 
> 
>  On 23.06.2020 15:35, Pavel Tupitsyn wrote:
> >> all your pros points work just as well for a separate repository
> > I don't think so: we can't add snippets pointing to new APIs from a
> > separate repo,
> > we can't see the docs when doing global search (and/or replace) from
> > the IDE.
> >
> >> I am able to free