Nikolay, 1) *Do not* create ignite-2.7 branch until we're not started preparation to real 2.7. Use some temporary branch for this check instead, eg. ignite-2.7-release-test
2) Please make sure you'll not cause real release actions (maven release and so on). Perform only vote_* steps. 3) Make sure you'll remove all tags, branches, and other RC artifacts after check. 4) Mark this release as RC0 to make sure it will be clear to everybody that it's a check. вт, 18 сент. 2018 г. в 13:24, Dmitriy Setrakyan <dsetrak...@apache.org>: > If it is an Ignite release, then it has to pass through the vote. If not, > then you can do the test without publishing or uploading the release. > > D. > > On Tue, Sep 18, 2018 at 1:18 PM Petr Ivanov <mr.wei...@gmail.com> wrote: > > > 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. > > >>>>>> > > >> > > > > >
