Ok. In case of TC questions — ask me.
> On 18 Sep 2018, at 13:16, Nikolay Izhikov <nizhi...@apache.org> wrote: > > Hello, Petr. > > I want to make ignite-2.7 branch today. > And execute release procedure based on this branch. > > However, ignite-2.7 branch will be copy of master until code freeze date. > > В Вт, 18/09/2018 в 13:13 +0300, Petr Ivanov пишет: >> Will it be just a test or there is already ignite-2.7 branch? >> >> Fabric removal related TC modifications are not ready yet, and code is not >> in master. >> >> >> >>> On 18 Sep 2018, at 13:07, Nikolay Izhikov <nizhi...@apache.org> wrote: >>> >>> Hello, Igniters. >>> >>> I want to start and release procedures and make an RC1 build. >>> >>> It has a 2 intention: >>> >>> 1. I want to walk through all release steps to make sure they all works for >>> me. >>> So I will be fully ready on release date. >>> >>> 2. We have updated some dependencies in 2.7 and we need to make sure binary >>> build is still workable. >>> >>> Any objections? >>> >>> >>> В Пт, 14/09/2018 в 18:52 +0300, Alexey Goncharuk пишет: >>>> We already have all the mechanics in place to work with properties - we use >>>> ignite.build and ignite.revision from ignite.properties which are adjusted >>>> during the build in the binary package. >>>> >>>> Should I create the ticket if there are no objections? >>>> >>>> пт, 14 сент. 2018 г. в 13:22, Ilya Kasnacheev <ilya.kasnach...@gmail.com>: >>>> >>>>> Hello! >>>>> >>>>> So now there's an issue that this script makes source change after every >>>>> build, show up in git status. >>>>> >>>>> What we could do to it: >>>>> - Commit the changes after the build, once. In hopes that it won't change >>>>> very often. With benefit that we could do that right now, before the code >>>>> freeze. >>>>> - Move these values to a properties file from both pom.xml and >>>>> IgniteProvider.java. Any problems with this approach? We'll just read them >>>>> from classpath properties file. >>>>> - Update the links in the file once and remove them from build process. >>>>> Why >>>>> were they added to build process in the first place - to make them >>>>> configurable during build? >>>>> >>>>> Regards, >>>>> -- >>>>> Ilya Kasnacheev >>>>> >>>>> >>>>> вт, 11 сент. 2018 г. в 5:53, Roman Shtykh <rsht...@yahoo.com>: >>>>> >>>>>> Ilya, >>>>>> >>>>>> The "latest" version is the default, and resolved by >>>>>> https://ignite.apache.org/latest which is used by our web site when a >>>>>> user download the latest Ignite version. And I think this is the >>>>> >>>>> authority >>>>>> to judge of the latest official release (pom.xml you suggest can have >>>>>> SNAPSHOTs etc.). >>>>>> Also, as I explained during our review sessions, ignite-mesos-2.6.0 is a >>>>>> driver and doesn't mean you need to have Ignite 2.6.0. User can run any >>>>>> version of Ignite he/she specifies. By default, it's "latest" but a user >>>>>> can specify any version needed, even from a non-archive URL. >>>>>> >>>>>> In short, what we have now >>>>>> 1. mesos driver (ignite-mesos-x.x.x) will use "latest" version by default >>>>>> -> it will try to resolve the latest officially releases version of >>>>> >>>>> Apache >>>>>> Ignite, find the closest mirror and download Ignite in a minute. If the >>>>>> version resolution fails, we fall back to the slow apache archive (as you >>>>>> suggest; in my opinion we better fail-fast instead of waiting for hours >>>>> >>>>> to >>>>>> download, so the user can choose another download option (3)) >>>>>> 2. If the user specifies the version explicitly, it goes to the slow >>>>>> apache archive. >>>>>> 3. The user can put ignite zip file on his/her http server and provide >>>>> >>>>> the >>>>>> URL as a parameter to the driver, if options 1 and 2 don't work. >>>>>> >>>>>> As you see, there are 3 options. And I just fix the 1st one with >>>>>> https://issues.apache.org/jira/browse/IGNITE-9388 and don't change the >>>>>> original logic (which I find reasonable) documented on our site -- I >>>>> >>>>> don't >>>>>> see how it blocks anything. >>>>>> >>>>>> Roman Shtykh >>>>>> >>>>>> >>>>>> On Monday, September 10, 2018, 6:16:15 p.m. GMT+9, Ilya Kasnacheev < >>>>>> ilya.kasnach...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> Hello! >>>>>> >>>>>> There's still two issues with the submission. >>>>>> >>>>>> The first one is that we're downloading "latest" version from preferred >>>>>> mirror but a specified version, such as "2.6", we're also going to >>>>> >>>>> download >>>>>> from "slow" archive.apache.org/dist. >>>>>> That's a great limitation for this change, since most real deployments of >>>>>> Apache Ignite will have their Ignite version pegged to a specific >>>>> >>>>> release. >>>>>> But in this case there's no win in download speed. >>>>>> *In my opinion it is a blocker.* >>>>>> >>>>>> The second one is that we can't download anything when we failed to >>>>>> resolve "latest". My idea is that we should try and download last known >>>>>> version in this case, which can be pushed to source from pom.xml, as we >>>>>> already do with URLs. So if you could not resolve "latest" you will >>>>>> download 2.7.0. >>>>>> >>>>>> Buuut, maybe it's not necessary, maybe we should just *discourage >>>>>> "latest"*, which is in my opinion almost always a bad idea. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Regards, >>>>>> -- >>>>>> Ilya Kasnacheev >>>>>> >>>>>> >>>>>> вс, 9 сент. 2018 г. в 5:47, Roman Shtykh <rsht...@yahoo.com>: >>>>>> >>>>>> Hi Ilya, >>>>>> >>>>>> Sorry, missed that. >>>>>> Added now. >>>>>> >>>>>> -- >>>>>> Roman Shtykh >>>>>> >>>>>> >>>>>> On Thursday, September 6, 2018, 6:16:58 p.m. GMT+9, Ilya Kasnacheev < >>>>>> ilya.kasnach...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> Hello! >>>>>> >>>>>> The last of my requests still standing is that we should fall-back to >>>>>> single URL download in case of error with 'latest' version. Everything >>>>> >>>>> else >>>>>> looks good to me. >>>>>> >>>>>> Can we do that? I'm really worried that Apache API will go sour. >>>>>> >>>>>> Regards, >>>>>> -- >>>>>> Ilya Kasnacheev >>>>>> >>>>>> >>>>>> чт, 6 сент. 2018 г. в 8:56, Roman Shtykh <rsht...@yahoo.com>: >>>>>> >>>>>> Hi Ilya, >>>>>> >>>>>> Thanks again. >>>>>> >>>>>> 1) Done. >>>>>> 2) Used catch() for latest version. >>>>>> >>>>>> Please see my comments on github. >>>>>> -- >>>>>> Roman Shtykh >>>>>> >>>>>> >>>>>> On Wednesday, September 5, 2018, 11:30:10 p.m. GMT+9, Ilya Kasnacheev < >>>>>> ilya.kasnach...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> Hello! >>>>>> >>>>>> I've left a new wave of replies. >>>>>> >>>>>> Basically, 1) let's keep DOWNLOAD_URL_PATTERN string value inlined so >>>>>> that it will work even if build process is broken (would be useful for >>>>> >>>>> e.g. >>>>>> developing out of IDE) >>>>>> And also I urge you to catch() around new fragile Apache JSON API >>>>>> resolving, and download the 'current' version instead, as defined by >>>>>> ignite-mesos version. >>>>>> >>>>>> This is because this module is not under continuouos scrutiny so extra >>>>>> care should be applied. >>>>>> -- >>>>>> Ilya Kasnacheev >>>>>> >>>>>> >>>>>> вт, 4 сент. 2018 г. в 13:42, Roman Shtykh <rsht...@yahoo.com>: >>>>>> >>>>>> Thanks, Ilya! >>>>>> I will check your comments, and discuss it at JIRA. >>>>>> >>>>>> -- >>>>>> Roman Shtykh >>>>>> >>>>>> >>>>>> On Tuesday, September 4, 2018, 7:17:53 p.m. GMT+9, Ilya Kasnacheev < >>>>>> ilya.kasnach...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> Hello! >>>>>> >>>>>> IGNITE-9408 <https://issues.apache.org/jira/browse/IGNITE-9408> looks >>>>>> good to me and may be merged right away. >>>>>> >>>>>> IGNITE-9388 <https://issues.apache.org/jira/browse/IGNITE-9388> needs >>>>>> more work in my opinion, I have commented the PR. I also advice having >>>>> >>>>> test >>>>>> for this functionality. >>>>>> >>>>>> Regards, >>>>>> -- >>>>>> Ilya Kasnacheev >>>>>> >>>>>> >>>>>> вт, 4 сент. 2018 г. в 6:52, Roman Shtykh <rsht...@yahoo.com.invalid>: >>>>>> >>>>>> Igniters, >>>>>> I would like Mesos integration update be included in the upcoming >>>>>> release.Can anyone review prs for the following issues? >>>>>> IGNITE-9388: mesos IgniteProvider tries to access obsolete ignite.run or >>>>>> download from slow archiveIGNITE-9408: Update mesos version >>>>>> >>>>>> Roman Shtykh >>>>>> >>>>>> On Thursday, August 30, 2018, 9:25:43 p.m. GMT+9, Vyacheslav Daradur >>>>> >>>>> < >>>>>> daradu...@gmail.com> wrote: >>>>>> >>>>>> Hi Igniters! >>>>>> >>>>>> I'm working on the following Service Grid tasks: >>>>>> - IGNITE-8361 Use discovery messages for service deployment >>>>>> - IGNITE-8362 Collect service deployment results asynchronously on >>>>>> coordinator >>>>>> - IGNITE-8363 Handle topology changes during service deployment >>>>>> - IGNITE-8364 Propagate deployed services to joining nodes >>>>>> - IGNITE-8365 Introduce service failure events >>>>>> - IGNITE-3392 Propagate service deployment results from assigned nodes >>>>>> to initiator >>>>>> >>>>>> Let's call them *phase 1* because the should be implemented together >>>>>> (atomically). >>>>>> >>>>>> I do my best to finish phase 1 for including to 2.7 release. >>>>>> >>>>>> But I'm not sure that the solution will be fully completed till the >>>>>> beginning of October. >>>>>> >>>>>> On Wed, Aug 29, 2018 at 7:18 PM Nikolay Izhikov <nizhi...@apache.org> >>>>>> wrote: >>>>>>> >>>>>>> Hell, Yakov >>>>>>> >>>>>>> I'm ok with your proposal. >>>>>>> >>>>>>> * Scope freeze - September 17 - We should have a full list of >>>>>> >>>>>> tickets for 2.7 here. >>>>>>> * Code freeze - October 01 - We should merge all 2.7 tickets to >>>>>> >>>>>> master here. >>>>>>> * Vote on RC1 - October 11. >>>>>>> * Vote on release - October 15. >>>>>>> >>>>>>> В Ср, 29/08/2018 в 12:39 +0300, Yakov Zhdanov пишет: >>>>>>>> Nikolay, >>>>>>>> >>>>>>>> I think we should have 2 weeks after code freeze which by the way may >>>>>>>> include RC1 voting stage. This way I would like us to agree that >>>>>> >>>>>> release >>>>>>>> candidate should be sent to vote on Oct, 11th and we can release on >>>>>> >>>>>> Oct, >>>>>>>> 15th. >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> --Yakov >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Regards, Vyacheslav D. >>>>>> >>
