From dev-return-44749-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Thu Feb 14 12:21:31 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 6D793180626 for ; Thu, 14 Feb 2019 13:21:30 +0100 (CET) Received: (qmail 24204 invoked by uid 500); 14 Feb 2019 12:21:29 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 24190 invoked by uid 99); 14 Feb 2019 12:21:28 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Feb 2019 12:21:28 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 6B29A181875 for ; Thu, 14 Feb 2019 12:21:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.467 X-Spam-Level: ** X-Spam-Status: No, score=2.467 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_REPLY=1, FROM_EXCESS_BASE64=0.105, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.313] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id QAE5XdZ21F81 for ; Thu, 14 Feb 2019 12:21:25 +0000 (UTC) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 818505F6CB for ; Thu, 14 Feb 2019 12:21:25 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id b3so10136795otp.4 for ; Thu, 14 Feb 2019 04:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=8CrEyqFEql4lCAHFkACtKLM249qxQz3FrTMWAZwjqyU=; b=mflMavkU82nigk9QWBHVyUpUU8oeMDTgH+q+vwrTX3i/bbzBgGQuvIezqZrFi5kP4f eRJghcXVLqngpTKDPyK/jJt6qbPA9fkNiQ+Mz9S2/Ef+GHMdzKkUWV8rv+N7qyeTiA9b IJ63ZBqaZuIVeD6DqjdT2nnr04PXAum9YRbzTuFMVtWaIfFzxAEEtJQNSa9flQ9rx9Gu RE19hSTIgECHRHbhgE5mKXS3BryQdGP0WhBctfnWKUzHiN9c4i9owIBIihJe7Tzp1QLd naC9N7LE7O6zvaPNkrcpXjnKEiY2k92q4owwcPJTVyjI+KLEyBiO3H8lRx9N2fbfneaF CVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=8CrEyqFEql4lCAHFkACtKLM249qxQz3FrTMWAZwjqyU=; b=iT2kXaY/U1aestsfyzJHbeK4ljF13lThUCI+fdmcKjoY+9PcK8w3Ati3FPNQieqn8b ecimM9l+5wSqFRyamjvOJMrUMeERZd8l6kXDKxVdPoHYrVnt3Sc0v6DdS57+cs71eV1h oXvyDpSxUq3Y677eeKIqFDK6YitOqcHG0qE86X9GdjHCQ2plrjqGjXYlaTieYw4deern AVP/aMvqilSZbw3w5KL7JdRmizwR6lNa/O7TVk1s/MfxkaAEmuVPQVLWLK1EztyMkDgH n9fDIvpNX3sh9BspqE6DHUFlG8+IXcoU8cpSE799JIyPlmvxuhwFfuXjkn6almI2kQsW yQ2A== X-Gm-Message-State: AHQUAubbTfD/mogkHW+FBhuP3mz7OrwFZZhlvWHYxcHDgnYOplbhAKE0 9tzUXyfzMrEkoAW5aJwUlBXi3G0ZfL8mALPclNqMHK1C X-Google-Smtp-Source: AHgI3IbK32JZgphcTa5+ObejhEYg1mC+ujg3itj9bNAROTPrzdED/od9zsLp15lBwYzCrdBItshM7Z8Q8RCcEipXfpo= X-Received: by 2002:aca:e886:: with SMTP id f128mr2259345oih.68.1550146879157; Thu, 14 Feb 2019 04:21:19 -0800 (PST) MIME-Version: 1.0 References: <1549753115822-0.post@n4.nabble.com> <6D73E5EC-A96B-4194-AD06-FB765466A3BA@gmail.com> In-Reply-To: From: =?UTF-8?B?0J/QsNCy0LvRg9GF0LjQvSDQmNCy0LDQvQ==?= Date: Thu, 14 Feb 2019 15:21:06 +0300 Message-ID: Subject: Re: Code inspection To: dev@ignite.apache.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nikolay, > Should the community spend TC resources for prototype? Why not? I think it is not bad idea to run all tests against some changes into core classes. If I have a clever idea which is easy to test drive I can do couple of prototype-test iterations. If tests shows me that everything is bad then the idea was not so clever and easy. But if I was lucky then I should discuss the idea with other Igniters. I think it is the cheapest way to check the idea because the check is fully automated. Requiring a human feedback is much more expensive in my opinion. > But, If our code style is not convinient for every day coding for many co= ntributors, should you initiate discussion to change it? Generally I am fine with our codestyle requirements. Also, I would like to keep a focus on the subject. Could you please outline the benefits you see of failing compilation and skipping tests execution if inspections detect a problem? =D1=87=D1=82, 14 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 14:14, Nikol= ay Izhikov : > > Hello, Ivan. > > > Requirements for a prototype code are not the same as for a patch ready > to merge > > True. > > > I do not see much need in writing good javadocs for prototype. > > We, as a community, can't force you to do it. > > > Why should I stub it to be able run any build on TC? > > Should the community spend TC resources for prototype? > You always can check tests for your prototype locally. > > And when it's ready, at least from code style point of view run it on TC. > > I, personally, always try to follow project code style, even for prototyp= es. > But, If our code style is not convinient for every day coding for many > contributors, should you initiate discussion to change it? > > > =D1=81=D1=80, 13 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 16:45, =D0= =9F=D0=B0=D0=B2=D0=BB=D1=83=D1=85=D0=B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD : > > > Maxim, > > > > Oh, my poor tabs.. Joke. > > > > I am totally ok with currently enabled checks. But I am mostly > > concerned about a general approach. I would like to outline one thing. > > Requirements for a prototype code are not the same as for a patch > > ready to merge (see a little bit more in the end of that message). > > > > We have a document defining code style which every contributor should > > follow [1]. And many points can be checked automatically. Personally, > > I do not see much need in writing good javadocs for prototype. Why > > should I stub it to be able run any build on TC? > > > > Also, we a have a review process which should be applied to every > > patch. Partially it is described in [2]. And due to this process every > > patch should not introduce new failures on TC. So, the patch should > > not be merged if inspections failed. > > > > P.S. Something more about prototypes and production code. There is a > > common bad practice in software engineering. It is turning prototypes > > into production code. Often it is much faster to create a prototype by > > price of violating some rules of writing "clean code". And often > > prototype after successful piloting is turned into production code. > > And it is very easy in practice to keep some pieces of initially > > "dirty" prototype code. I believe human factor plays a great role > > here. How should it be done right then? In my opinion good production > > code should be designed as "good production code" from the beginning. > > So, only ideas are taken from the prototype and a code is fully > > rewritten. > > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guideline= s > > [2] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist > > > > =D1=81=D1=80, 13 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 15:05, M= axim Muzafarov : > > > > > > Ivan, > > > > > > As the first implementation of this addition, I'd prefer to make it > > > working like _Licenses Headers_ suite check. It will fail when some o= f > > > the code style checks violated. Moreover, these licenses header check= s > > > can be included in the checkstyle plugin configuration. > > > > > > In general, I'd prefer to have a compilation fail error with code > > > style checks and after we will get a stable checkstyle suite I propos= e > > > to change it in a "compilation error" way. If we are talking about th= e > > > coding style convenient for most of the community members I see no > > > difference with coding sketches or production-ready branches equally. > > > Indeed, no one will be against unused imports [or spaces instead of > > > tabs :-) ] in their PRs or prototypes, right? (for instance, it can b= e > > > automatically removed by IDE at commit phase). > > > > > > Please, note currently enabled checks are: > > > - list.isEmpty() instead of list.size() =3D=3D 0 > > > - unused imports > > > - missing @Override > > > - sotred modifiers checks (e.g. pulic static final ..) > > > - redundunt suppersion checks > > > - spaces insted of tabs. > > > > > > Are you really what to violate these checks in your sketches? Hope no= t > > :-) > > > > > > On Wed, 13 Feb 2019 at 10:25, Nikolay Izhikov > > wrote: > > > > > > > > Actually, I dont see anything wrong with failing *compilation* task= . > > > > > > > > I think one should use project code style for everyday coding, not > > only for > > > > ready-to-merge PRs. > > > > > > > > If we cant use code style for everyday coding, we should change the > > > > codestyle. > > > > > > > > What do you think? > > > > > > > > =D1=81=D1=80, 13 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3., 10:11 Petr= Ivanov mr.weider@gmail.com: > > > > > > > > > I guess that was about failing build configuration with Checkstyp= e, > > not > > > > > compilation build itself. > > > > > > > > > > > On 12 Feb 2019, at 18:03, =D0=9F=D0=B0=D0=B2=D0=BB=D1=83=D1=85= =D0=B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD > > wrote: > > > > > > > > > > > > Folks, > > > > > > > > > > > > Are you going to fail job compiling Ignite sources [1] if some > > > > > > inspection found a problem? Can we avoid it? It is quite common > > > > > > pattern to start some feature implementation with making a sket= ch > > and > > > > > > running tests against it. I found it convenient to skip some st= yle > > > > > > requirements for such sketches (e.g. well formed javadocs). > > > > > > > > > > > > [1] > > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=3DIgniteTests24J= ava8_BuildApacheIgnite > > > > > > > > > > > > =D0=BF=D0=BD, 11 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. =D0=B2 = 11:38, Nikolay Izhikov > >: > > > > > >> > > > > > >> Petr, we should have 1 configuration for project, may be 1 > > configuration > > > > > >> per programming language. > > > > > >> > > > > > >> =D0=BF=D0=BD, 11 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3., 11:33= Petr Ivanov mr.weider@gmail.com: > > > > > >> > > > > > >>> I was asking about how many build configuration is intended? = One > > for > > > > > all > > > > > >>> and multiple per module? > > > > > >>> > > > > > >>> With IDEA inspections it was going to be build configuration = per > > > > > module. > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>>> On 11 Feb 2019, at 11:24, Nikolay Izhikov > > > > > wrote: > > > > > >>>> > > > > > >>>> Hello, Petr. > > > > > >>>> > > > > > >>>> Are you saying that we have not single build task? And each > > module > > > > > builds > > > > > >>>> when it required? If yes, then I propose to create a task li= ke > > > > > "Licence > > > > > >>>> check" which will be run for every patch. > > > > > >>>> > > > > > >>>> My point is that violation of codestyle should be treated as > > hard as > > > > > >>>> compile error. > > > > > >>>> > > > > > >>>> =D0=BF=D0=BD, 11 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3., 11:= 16 Petr Ivanov mr.weider@gmail.com: > > > > > >>>> > > > > > >>>>> Is build configuration Inspections [Core] meant to transfor= m > > into > > > > > single > > > > > >>>>> all-modules check build configuration (without module > > subdivision)? > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>> On 11 Feb 2019, at 11:02, Nikolay Izhikov < > > nizhikov@apache.org> > > > > > wrote: > > > > > >>>>>> > > > > > >>>>>> Hello, Maxim. > > > > > >>>>>> > > > > > >>>>>> +1 from me for migrating to checkstyle. > > > > > >>>>>> > > > > > >>>>>> Oleg, there is plugin for IDEA with 2mln downloads - > > > > > >>>>>> https://plugins.jetbrains.com/plugin/1065-checkstyle-idea > > > > > >>>>>> > > > > > >>>>>> I propose do the following: > > > > > >>>>>> > > > > > >>>>>> 1. Migrate current checks to checkstyle. > > > > > >>>>>> 2. Apply checks to all Ignite modules. Currently, only cor= e > > module > > > > > are > > > > > >>>>>> checked. > > > > > >>>>>> I will review and commit this patch, or do it by my own. > > > > > >>>>>> > > > > > >>>>>> 3. Include code style checks to "Build Apache Ignite" suit= e. > > Ignite > > > > > has > > > > > >>>>> to > > > > > >>>>>> fail to build if patch violates codestyle. > > > > > >>>>>> > > > > > >>>>>> =D0=B2=D1=81, 10 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. = =D0=B2 07:54, =D0=9F=D0=B0=D0=B2=D0=BB=D1=83=D1=85=D0=B8=D0=BD =D0=98=D0=B2= =D0=B0=D0=BD < > > vololo100@gmail.com>: > > > > > >>>>>> > > > > > >>>>>>> Hi, > > > > > >>>>>>> > > > > > >>>>>>> I also think that some warning from IDEA that some code > > style rule > > > > > is > > > > > >>>>>>> violated is a must-have. > > > > > >>>>>>> > > > > > >>>>>>> =D0=B2=D1=81, 10 =D1=84=D0=B5=D0=B2=D1=80. 2019 =D0=B3. = =D0=B2 01:58, oignatenko < > > oignatenko@gridgain.com > > > > > >: > > > > > >>>>>>>> > > > > > >>>>>>>> Hi Maxim, > > > > > >>>>>>>> > > > > > >>>>>>>> I believe that whatever style checks we establish at > > Teamcity, we > > > > > >>>>> better > > > > > >>>>>>>> take care of making it easy for developers to find and f= ix > > > > > violations > > > > > >>>>> in > > > > > >>>>>>>> their typical dev environment (for Ignite this means, in > > IDEA). I > > > > > >>> think > > > > > >>>>>>> it > > > > > >>>>>>>> is important that developers can maintain required style > > with > > > > > minimal > > > > > >>>>>>> effort > > > > > >>>>>>>> on their side. > > > > > >>>>>>>> > > > > > >>>>>>>> If above is doable then I am 200% for migrating our Team= city > > > > > >>>>> inspections > > > > > >>>>>>> to > > > > > >>>>>>>> checkstyle / maven. > > > > > >>>>>>>> > > > > > >>>>>>>> This is because I am very disappointed observing how it > > stays > > > > > broken > > > > > >>>>> for > > > > > >>>>>>> so > > > > > >>>>>>>> long. And worst of all, even when (if) it is fixed, I fe= el > > we will > > > > > >>>>>>> always be > > > > > >>>>>>>> at risk that it breaks again and that we will have to ag= ain > > wait > > > > > for > > > > > >>>>>>> months > > > > > >>>>>>>> for it to be fixed. > > > > > >>>>>>>> > > > > > >>>>>>>> This is such a stark contrast with my experience regardi= ng > > > > > checkstyle > > > > > >>>>>>> based > > > > > >>>>>>>> inspections. These just work and you just never fear tha= t > > it is > > > > > going > > > > > >>>>> to > > > > > >>>>>>>> break for some obscure reason, this is so much better th= an > > what I > > > > > >>>>> observe > > > > > >>>>>>>> now. > > > > > >>>>>>>> > > > > > >>>>>>>> One suggestion in case if we pick checkstyle - I recomme= nd > > keeping > > > > > >>> its > > > > > >>>>>>>> config file somewhere in the project under version contr= ol. > > I > > > > > used to > > > > > >>>>>>>> maintain such a shared style config at one of past jobs = and > > after > > > > > >>> some > > > > > >>>>>>>> experimenting it turned out most convenient to have it t= his > > way - > > > > > so > > > > > >>>>> that > > > > > >>>>>>>> developers could easily assess and discuss style setting= s > > and keep > > > > > >>>>> track > > > > > >>>>>>> of > > > > > >>>>>>>> changes in these. (note how Kafka folks from your link [= 5] > > appear > > > > > to > > > > > >>> be > > > > > >>>>>>>> doing it this way) > > > > > >>>>>>>> > > > > > >>>>>>>> regards, Oleg > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> Mmuzaf wrote > > > > > >>>>>>>>> Igniters, > > > > > >>>>>>>>> > > > > > >>>>>>>>> I've found that some of the community members have face= d > > with > > > > > >>>>>>>>> `[Inspections] Core suite [1]` is not working well enou= gh > > on TC. > > > > > The > > > > > >>>>>>>>> suite has a `FAILED` status for more than 2 months due = to > > some > > > > > >>> issues > > > > > >>>>>>>>> in TeamCity application [2]. Current suite behaviour > > confuses not > > > > > >>> only > > > > > >>>>>>>>> new contributors but also other community members. > > Moreover, this > > > > > >>>>>>>>> suite is no longer checks rules we previously configure= d. > > For > > > > > >>>>>>>>> instance, in the master branch, I've found 11 `Unused > > imports` > > > > > which > > > > > >>>>>>>>> should have been caught earlier (e.g. for > > > > > >>>>>>>>> {{IgniteCachePutAllRestartTest} [3]). > > > > > >>>>>>>>> > > > > > >>>>>>>>> I think we should make the next step to enable an > > automatic code > > > > > >>> style > > > > > >>>>>>>>> checks. As an example, we can consider the Apache Kafka > > code > > > > > style > > > > > >>> [5] > > > > > >>>>>>>>> way and configure for the Ignite project a > > > > > maven-checkstyle-plugin > > > > > >>>>>>>>> with its own maven profile and run it simultaneously wi= th > > other > > > > > TC. > > > > > >>> We > > > > > >>>>>>>>> can also enable the previously configured inspection > > rules, so no > > > > > >>>>>>>>> coding style violations will be missed. > > > > > >>>>>>>>> > > > > > >>>>>>>>> I see some advantages of using a maven plugin: > > > > > >>>>>>>>> - an IDE agnostic way for code checks > > > > > >>>>>>>>> - can be used with different CI and build tools (Jenkin= s, > > TC) > > > > > >>>>>>>>> - executable from the command line > > > > > >>>>>>>>> - the entry single point to configure new rules > > > > > >>>>>>>>> > > > > > >>>>>>>>> I've created the ticket [4] and will prepare PR for it. > > > > > >>>>>>>>> > > > > > >>>>>>>>> WDYT? > > > > > >>>>>>>>> > > > > > >>>>>>>>> [1] > > > > > >>>>>>>>> > > > > > >>>>>>> > > > > > >>>>> > > > > > >>> > > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=3DIgniteTests24J= ava8_InspectionsCore&branch_IgniteTests24Java8=3D%3Cdefault%3E&tab=3DbuildT= ypeStatusDiv > > > > > >>>>>>>>> [2] https://youtrack.jetbrains.com/issue/TW-58504 > > > > > >>>>>>>>> [3] > > > > > >>>>>>> > > > > > >>>>> > > > > > >>> > > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java= /org/apache/ignite/internal/processors/cache/IgniteCachePutAllRestartTest.j= ava#L29 > > > > > >>>>>>>>> [4] https://issues.apache.org/jira/browse/IGNITE-11277 > > > > > >>>>>>>>> [5] https://github.com/apache/kafka/tree/trunk/checksty= le > > > > > >>>>>>>>> > > > > > >>>>>>>>> On Fri, 21 Dec 2018 at 16:03, Petr Ivanov < > > > > > >>>>>>>> > > > > > >>>>>>>>> mr.weider@ > > > > > >>>>>>>> > > > > > >>>>>>>>> > wrote: > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> It seems there is bug in latest 2018.2 TeamCity > > > > > >>>>>>>>>> Bug is filed [1] > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> [1] https://youtrack.jetbrains.com/issue/TW-58504 > > > > > >>>>>>>>>> > > > > > >>>>>>>>>>> On 19 Dec 2018, at 11:31, Petr Ivanov < > > > > > >>>>>>>> > > > > > >>>>>>>>> mr.weider@ > > > > > >>>>>>>> > > > > > >>>>>>>>> > wrote: > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Investigating problem, stand by. > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>>> On 18 Dec 2018, at 19:41, Dmitriy Pavlov < > > > > > >>>>>>>> > > > > > >>>>>>>>> dpavlov@ > > > > > >>>>>>>> > > > > > >>>>>>>>> > wrote: > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> Both patches were applied. Maxim, thank you! > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> What about 1. An `Unexpected error during build mess= ages > > > > > >>>>>>> processing in > > > > > >>>>>>>>>>>> TeamCity`, what can we do as the next step to fix it= ? > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> Sincerely, > > > > > >>>>>>>>>>>> Dmitriy Pavlov > > > > > >>>>>>>>>>>> [cut] > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> -- > > > > > >>>>>>>> Sent from: > > http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> -- > > > > > >>>>>>> Best regards, > > > > > >>>>>>> Ivan Pavlukhin > > > > > >>>>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>> > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > --=20 Best regards, Ivan Pavlukhin