Re: Apache Ignite 2.7 - Release Procedure issues
Please ignore. I missed the branch. On Thu, Sep 27, 2018 at 5:53 PM Vladimir Ozerov wrote: > Igniters, > > Code Freeze date is tomorrow. Bad news is that we still have a number of > important features not-yet-merged (of most important - some MVCC stuff, > TDE, PHP/Python clients). Good news is that we made a good progress with > scope decrease. I propose the following release plan then: > > 1) By 30 Sept, only tickets critical for AI 2.7 release should have 2.7 > fix version. I expect that there should be about ~30 tickets, and most of > them are critical bugs (either existing or in new features). This is what > we call Code Freeze. From this time it is not allowed to add any tickets to > 2.7 unless you are able to prove that it is a blocker for the release. This > means absolute ban for any new features. > 2) Then we take *3 weeks for stabilization*: 1 Oct - 22 Oct. During this > time we fix all known bugs in new features, and finalize those new features > which are slightly behind a schedule. I would even suggest to take *4 > weeks for stabilization* (1 Oct - 29 Oct) > 3) Once stabilization is over, we start vote. > > This big stabilization window is essential for us, as current release will > contain a lot of huge features, which should be tested thoroughly before > going public. But the very critical ingredient here - *no new tickets on > AI 2.7* during this phase except of critical bug fixes found during > stabilization phase. > > In the end we will have nice and well tested AI 2.7 at the end of October. > > What do you think about it? > > Vladimir. > > > On Mon, Sep 24, 2018 at 3:11 PM Nikolay Izhikov > wrote: > >> Hello, Petr. >> >> My suggestion is to migrate to a newer version of GPG and throw an error >> message if one use old version. >> >> В Пн, 24/09/2018 в 14:53 +0300, Petr Ivanov пишет: >> > I’ve checked the changes and they are good both on old and latest >> versions of Ubuntu. >> > >> > >> > However, I’ve stumbled upon another problem — GPG: current release >> scripts do not honour latest GPG versions. >> > I can introduce corresponding changes, but question is — should release >> script check for GPG version and have 2 version of signing commands or just >> warn user about old version of GPG and exit? >> > >> > >> > > On 21 Sep 2018, at 19:46, Nikolay Izhikov >> wrote: >> > > >> > > Hello, Petr. >> > > >> > > Seems that rpm build script doesn't work on a lates Ubuntu Linux. >> > > I've created a ticket [1] and found a fix for it [2] >> > > >> > > With one line fix rpm build is working under my environment. >> > > Can you check fix on your environment? >> > > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-9665 >> > > >> > > [2] https://github.com/apache/ignite/pull/4808 >> > > >> > > В Пт, 21/09/2018 в 16:22 +0300, Petr Ivanov пишет: >> > > > Hi, Nikolay >> > > > >> > > > >> > > > I’ve tested vote_3_step_1 and vote_3_step_2 scripts from [1] and >> they are OK. >> > > > My configuration: >> > > > - generated gnupg key (~/.gnupg) >> > > > - Ubuntu 16.04 (with latest updates) >> > > > - packages: subversion git unzip alien rpm fakeroot gcc dpkg-sig >> gnupg-agent >> > > > >> > > > Please double check you environment for release procedure >> > > > >> > > > >> > > > [1] >> https://ci.ignite.apache.org/viewLog.html?buildId=1914618=ApacheIgniteReleaseJava8_PrepareVote=artifacts#!hkm8d5gqy4ii >> > > > >> > > > >> > > > > On 20 Sep 2018, at 17:39, Nikolay Izhikov >> wrote: >> > > > > >> > > > > Hello, Igniters. >> > > > > >> > > > > I've started to write Wiki article for a future Release Managers. >> > > > > Since release process doesn't described anywhere public I do it >> while releasing 2.7: >> > > > > >> > > > > >> https://cwiki.apache.org/confluence/display/IGNITE/Release+manager+Notes >> > > > > >> > > > > Any feedback is strongly appreciated. >> > > > > >> > > > > I've tried to walk through vote steps in release procedure and >> found some issues: >> > > > > >> > > > > Some of them we already fixed with Petr Ivanod and Anton >> Vinogradov. >> > > > > Thank you, guys! >> > > > > >> > > > > For now, I stuck on the following issue: >> > > > > >> > > > > `vote_3_step_1\[packages\]build.sh` is broken. >> > > > > I got following output: >> > > > > >> > > > > ``` >> > > > > RPM build errors: >> > > > > bogus date in %changelog: Fri Jun 17 2018 Peter Ivanov < >> mr.wei...@gmail.com> - 2.6.0-1 >> > > > > File not found: >> /tmp/tmp.EezfJVTwLm/BUILDROOT/apache-ignite-2.6.0-1.x86_64/usr/share/doc/apache-ignite-2.6.0/MIGRATION_GUIDE.txt >> > > > > + processTrap >> > > > > + echo 'Removing temporary work directories: /tmp/tmp.EezfJVTwLm' >> > > > > Removing temporary work directories: /tmp/tmp.EezfJVTwLm >> > > > > + rm -rf /tmp/tmp.EezfJVTwLm >> > > > > ``` >> > > > > >> > > > > 1. Script uses version number 2.6 somehow. >> > > > > 2. It fails because MIGRATION_GUIDE file doesn't exists. >> > > > > >> > > > > Is there anybody who can help with this issue? >> > > > > >> > > > > >> > > > > >> > >> > > >
Re: Apache Ignite 2.7 - Release Procedure issues
Igniters, Code Freeze date is tomorrow. Bad news is that we still have a number of important features not-yet-merged (of most important - some MVCC stuff, TDE, PHP/Python clients). Good news is that we made a good progress with scope decrease. I propose the following release plan then: 1) By 30 Sept, only tickets critical for AI 2.7 release should have 2.7 fix version. I expect that there should be about ~30 tickets, and most of them are critical bugs (either existing or in new features). This is what we call Code Freeze. From this time it is not allowed to add any tickets to 2.7 unless you are able to prove that it is a blocker for the release. This means absolute ban for any new features. 2) Then we take *3 weeks for stabilization*: 1 Oct - 22 Oct. During this time we fix all known bugs in new features, and finalize those new features which are slightly behind a schedule. I would even suggest to take *4 weeks for stabilization* (1 Oct - 29 Oct) 3) Once stabilization is over, we start vote. This big stabilization window is essential for us, as current release will contain a lot of huge features, which should be tested thoroughly before going public. But the very critical ingredient here - *no new tickets on AI 2.7* during this phase except of critical bug fixes found during stabilization phase. In the end we will have nice and well tested AI 2.7 at the end of October. What do you think about it? Vladimir. On Mon, Sep 24, 2018 at 3:11 PM Nikolay Izhikov wrote: > Hello, Petr. > > My suggestion is to migrate to a newer version of GPG and throw an error > message if one use old version. > > В Пн, 24/09/2018 в 14:53 +0300, Petr Ivanov пишет: > > I’ve checked the changes and they are good both on old and latest > versions of Ubuntu. > > > > > > However, I’ve stumbled upon another problem — GPG: current release > scripts do not honour latest GPG versions. > > I can introduce corresponding changes, but question is — should release > script check for GPG version and have 2 version of signing commands or just > warn user about old version of GPG and exit? > > > > > > > On 21 Sep 2018, at 19:46, Nikolay Izhikov wrote: > > > > > > Hello, Petr. > > > > > > Seems that rpm build script doesn't work on a lates Ubuntu Linux. > > > I've created a ticket [1] and found a fix for it [2] > > > > > > With one line fix rpm build is working under my environment. > > > Can you check fix on your environment? > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9665 > > > > > > [2] https://github.com/apache/ignite/pull/4808 > > > > > > В Пт, 21/09/2018 в 16:22 +0300, Petr Ivanov пишет: > > > > Hi, Nikolay > > > > > > > > > > > > I’ve tested vote_3_step_1 and vote_3_step_2 scripts from [1] and > they are OK. > > > > My configuration: > > > > - generated gnupg key (~/.gnupg) > > > > - Ubuntu 16.04 (with latest updates) > > > > - packages: subversion git unzip alien rpm fakeroot gcc dpkg-sig > gnupg-agent > > > > > > > > Please double check you environment for release procedure > > > > > > > > > > > > [1] > https://ci.ignite.apache.org/viewLog.html?buildId=1914618=ApacheIgniteReleaseJava8_PrepareVote=artifacts#!hkm8d5gqy4ii > > > > > > > > > > > > > On 20 Sep 2018, at 17:39, Nikolay Izhikov > wrote: > > > > > > > > > > Hello, Igniters. > > > > > > > > > > I've started to write Wiki article for a future Release Managers. > > > > > Since release process doesn't described anywhere public I do it > while releasing 2.7: > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+manager+Notes > > > > > > > > > > Any feedback is strongly appreciated. > > > > > > > > > > I've tried to walk through vote steps in release procedure and > found some issues: > > > > > > > > > > Some of them we already fixed with Petr Ivanod and Anton > Vinogradov. > > > > > Thank you, guys! > > > > > > > > > > For now, I stuck on the following issue: > > > > > > > > > > `vote_3_step_1\[packages\]build.sh` is broken. > > > > > I got following output: > > > > > > > > > > ``` > > > > > RPM build errors: > > > > > bogus date in %changelog: Fri Jun 17 2018 Peter Ivanov < > mr.wei...@gmail.com> - 2.6.0-1 > > > > > File not found: > /tmp/tmp.EezfJVTwLm/BUILDROOT/apache-ignite-2.6.0-1.x86_64/usr/share/doc/apache-ignite-2.6.0/MIGRATION_GUIDE.txt > > > > > + processTrap > > > > > + echo 'Removing temporary work directories: /tmp/tmp.EezfJVTwLm' > > > > > Removing temporary work directories: /tmp/tmp.EezfJVTwLm > > > > > + rm -rf /tmp/tmp.EezfJVTwLm > > > > > ``` > > > > > > > > > > 1. Script uses version number 2.6 somehow. > > > > > 2. It fails because MIGRATION_GUIDE file doesn't exists. > > > > > > > > > > Is there anybody who can help with this issue? > > > > > > > > > > > > > > > > > > >
Re: Apache Ignite 2.7 - Release Procedure issues
Hello, Petr. My suggestion is to migrate to a newer version of GPG and throw an error message if one use old version. В Пн, 24/09/2018 в 14:53 +0300, Petr Ivanov пишет: > I’ve checked the changes and they are good both on old and latest versions of > Ubuntu. > > > However, I’ve stumbled upon another problem — GPG: current release scripts do > not honour latest GPG versions. > I can introduce corresponding changes, but question is — should release > script check for GPG version and have 2 version of signing commands or just > warn user about old version of GPG and exit? > > > > On 21 Sep 2018, at 19:46, Nikolay Izhikov wrote: > > > > Hello, Petr. > > > > Seems that rpm build script doesn't work on a lates Ubuntu Linux. > > I've created a ticket [1] and found a fix for it [2] > > > > With one line fix rpm build is working under my environment. > > Can you check fix on your environment? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9665 > > > > [2] https://github.com/apache/ignite/pull/4808 > > > > В Пт, 21/09/2018 в 16:22 +0300, Petr Ivanov пишет: > > > Hi, Nikolay > > > > > > > > > I’ve tested vote_3_step_1 and vote_3_step_2 scripts from [1] and they are > > > OK. > > > My configuration: > > > - generated gnupg key (~/.gnupg) > > > - Ubuntu 16.04 (with latest updates) > > > - packages: subversion git unzip alien rpm fakeroot gcc dpkg-sig > > > gnupg-agent > > > > > > Please double check you environment for release procedure > > > > > > > > > [1] > > > https://ci.ignite.apache.org/viewLog.html?buildId=1914618=ApacheIgniteReleaseJava8_PrepareVote=artifacts#!hkm8d5gqy4ii > > > > > > > > > > On 20 Sep 2018, at 17:39, Nikolay Izhikov wrote: > > > > > > > > Hello, Igniters. > > > > > > > > I've started to write Wiki article for a future Release Managers. > > > > Since release process doesn't described anywhere public I do it while > > > > releasing 2.7: > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+manager+Notes > > > > > > > > Any feedback is strongly appreciated. > > > > > > > > I've tried to walk through vote steps in release procedure and found > > > > some issues: > > > > > > > > Some of them we already fixed with Petr Ivanod and Anton Vinogradov. > > > > Thank you, guys! > > > > > > > > For now, I stuck on the following issue: > > > > > > > > `vote_3_step_1\[packages\]build.sh` is broken. > > > > I got following output: > > > > > > > > ``` > > > > RPM build errors: > > > > bogus date in %changelog: Fri Jun 17 2018 Peter Ivanov > > > > - 2.6.0-1 > > > > File not found: > > > > /tmp/tmp.EezfJVTwLm/BUILDROOT/apache-ignite-2.6.0-1.x86_64/usr/share/doc/apache-ignite-2.6.0/MIGRATION_GUIDE.txt > > > > + processTrap > > > > + echo 'Removing temporary work directories: /tmp/tmp.EezfJVTwLm' > > > > Removing temporary work directories: /tmp/tmp.EezfJVTwLm > > > > + rm -rf /tmp/tmp.EezfJVTwLm > > > > ``` > > > > > > > > 1. Script uses version number 2.6 somehow. > > > > 2. It fails because MIGRATION_GUIDE file doesn't exists. > > > > > > > > Is there anybody who can help with this issue? > > > > > > > > > > > > > > signature.asc Description: This is a digitally signed message part
Re: Apache Ignite 2.7 - Release Procedure issues
I’ve checked the changes and they are good both on old and latest versions of Ubuntu. However, I’ve stumbled upon another problem — GPG: current release scripts do not honour latest GPG versions. I can introduce corresponding changes, but question is — should release script check for GPG version and have 2 version of signing commands or just warn user about old version of GPG and exit? > On 21 Sep 2018, at 19:46, Nikolay Izhikov wrote: > > Hello, Petr. > > Seems that rpm build script doesn't work on a lates Ubuntu Linux. > I've created a ticket [1] and found a fix for it [2] > > With one line fix rpm build is working under my environment. > Can you check fix on your environment? > > [1] https://issues.apache.org/jira/browse/IGNITE-9665 > > [2] https://github.com/apache/ignite/pull/4808 > > В Пт, 21/09/2018 в 16:22 +0300, Petr Ivanov пишет: >> Hi, Nikolay >> >> >> I’ve tested vote_3_step_1 and vote_3_step_2 scripts from [1] and they are OK. >> My configuration: >> - generated gnupg key (~/.gnupg) >> - Ubuntu 16.04 (with latest updates) >> - packages: subversion git unzip alien rpm fakeroot gcc dpkg-sig gnupg-agent >> >> Please double check you environment for release procedure >> >> >> [1] >> https://ci.ignite.apache.org/viewLog.html?buildId=1914618=ApacheIgniteReleaseJava8_PrepareVote=artifacts#!hkm8d5gqy4ii >> >> >>> On 20 Sep 2018, at 17:39, Nikolay Izhikov wrote: >>> >>> Hello, Igniters. >>> >>> I've started to write Wiki article for a future Release Managers. >>> Since release process doesn't described anywhere public I do it while >>> releasing 2.7: >>> >>> https://cwiki.apache.org/confluence/display/IGNITE/Release+manager+Notes >>> >>> Any feedback is strongly appreciated. >>> >>> I've tried to walk through vote steps in release procedure and found some >>> issues: >>> >>> Some of them we already fixed with Petr Ivanod and Anton Vinogradov. >>> Thank you, guys! >>> >>> For now, I stuck on the following issue: >>> >>> `vote_3_step_1\[packages\]build.sh` is broken. >>> I got following output: >>> >>> ``` >>> RPM build errors: >>> bogus date in %changelog: Fri Jun 17 2018 Peter Ivanov >>> - 2.6.0-1 >>> File not found: >>> /tmp/tmp.EezfJVTwLm/BUILDROOT/apache-ignite-2.6.0-1.x86_64/usr/share/doc/apache-ignite-2.6.0/MIGRATION_GUIDE.txt >>> + processTrap >>> + echo 'Removing temporary work directories: /tmp/tmp.EezfJVTwLm' >>> Removing temporary work directories: /tmp/tmp.EezfJVTwLm >>> + rm -rf /tmp/tmp.EezfJVTwLm >>> ``` >>> >>> 1. Script uses version number 2.6 somehow. >>> 2. It fails because MIGRATION_GUIDE file doesn't exists. >>> >>> Is there anybody who can help with this issue? >>> >>> >>> >>
Re: Apache Ignite 2.7 - Release Procedure issues
Hello, Petr. Seems that rpm build script doesn't work on a lates Ubuntu Linux. I've created a ticket [1] and found a fix for it [2] With one line fix rpm build is working under my environment. Can you check fix on your environment? [1] https://issues.apache.org/jira/browse/IGNITE-9665 [2] https://github.com/apache/ignite/pull/4808 В Пт, 21/09/2018 в 16:22 +0300, Petr Ivanov пишет: > Hi, Nikolay > > > I’ve tested vote_3_step_1 and vote_3_step_2 scripts from [1] and they are OK. > My configuration: > - generated gnupg key (~/.gnupg) > - Ubuntu 16.04 (with latest updates) > - packages: subversion git unzip alien rpm fakeroot gcc dpkg-sig gnupg-agent > > Please double check you environment for release procedure > > > [1] > https://ci.ignite.apache.org/viewLog.html?buildId=1914618=ApacheIgniteReleaseJava8_PrepareVote=artifacts#!hkm8d5gqy4ii > > > > On 20 Sep 2018, at 17:39, Nikolay Izhikov wrote: > > > > Hello, Igniters. > > > > I've started to write Wiki article for a future Release Managers. > > Since release process doesn't described anywhere public I do it while > > releasing 2.7: > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+manager+Notes > > > > Any feedback is strongly appreciated. > > > > I've tried to walk through vote steps in release procedure and found some > > issues: > > > > Some of them we already fixed with Petr Ivanod and Anton Vinogradov. > > Thank you, guys! > > > > For now, I stuck on the following issue: > > > > `vote_3_step_1\[packages\]build.sh` is broken. > > I got following output: > > > > ``` > > RPM build errors: > >bogus date in %changelog: Fri Jun 17 2018 Peter Ivanov > > - 2.6.0-1 > >File not found: > > /tmp/tmp.EezfJVTwLm/BUILDROOT/apache-ignite-2.6.0-1.x86_64/usr/share/doc/apache-ignite-2.6.0/MIGRATION_GUIDE.txt > > + processTrap > > + echo 'Removing temporary work directories: /tmp/tmp.EezfJVTwLm' > > Removing temporary work directories: /tmp/tmp.EezfJVTwLm > > + rm -rf /tmp/tmp.EezfJVTwLm > > ``` > > > > 1. Script uses version number 2.6 somehow. > > 2. It fails because MIGRATION_GUIDE file doesn't exists. > > > > Is there anybody who can help with this issue? > > > > > > > > signature.asc Description: This is a digitally signed message part
Re: Apache Ignite 2.7 - Release Procedure issues
Hi, Nikolay I’ve tested vote_3_step_1 and vote_3_step_2 scripts from [1] and they are OK. My configuration: - generated gnupg key (~/.gnupg) - Ubuntu 16.04 (with latest updates) - packages: subversion git unzip alien rpm fakeroot gcc dpkg-sig gnupg-agent Please double check you environment for release procedure [1] https://ci.ignite.apache.org/viewLog.html?buildId=1914618=ApacheIgniteReleaseJava8_PrepareVote=artifacts#!hkm8d5gqy4ii > On 20 Sep 2018, at 17:39, Nikolay Izhikov wrote: > > Hello, Igniters. > > I've started to write Wiki article for a future Release Managers. > Since release process doesn't described anywhere public I do it while > releasing 2.7: > > https://cwiki.apache.org/confluence/display/IGNITE/Release+manager+Notes > > Any feedback is strongly appreciated. > > I've tried to walk through vote steps in release procedure and found some > issues: > > Some of them we already fixed with Petr Ivanod and Anton Vinogradov. > Thank you, guys! > > For now, I stuck on the following issue: > > `vote_3_step_1\[packages\]build.sh` is broken. > I got following output: > > ``` > RPM build errors: >bogus date in %changelog: Fri Jun 17 2018 Peter Ivanov > - 2.6.0-1 >File not found: > /tmp/tmp.EezfJVTwLm/BUILDROOT/apache-ignite-2.6.0-1.x86_64/usr/share/doc/apache-ignite-2.6.0/MIGRATION_GUIDE.txt > + processTrap > + echo 'Removing temporary work directories: /tmp/tmp.EezfJVTwLm' > Removing temporary work directories: /tmp/tmp.EezfJVTwLm > + rm -rf /tmp/tmp.EezfJVTwLm > ``` > > 1. Script uses version number 2.6 somehow. > 2. It fails because MIGRATION_GUIDE file doesn't exists. > > Is there anybody who can help with this issue? > > >
Re: Apache Ignite 2.7 - Release Procedure issues
The file is in place: https://github.com/apache/ignite/blob/master/MIGRATION_GUIDE.txt Tho, I think we could put something there. Regards, -- Ilya Kasnacheev чт, 20 сент. 2018 г. в 17:39, Nikolay Izhikov : > Hello, Igniters. > > I've started to write Wiki article for a future Release Managers. > Since release process doesn't described anywhere public I do it while > releasing 2.7: > > https://cwiki.apache.org/confluence/display/IGNITE/Release+manager+Notes > > Any feedback is strongly appreciated. > > I've tried to walk through vote steps in release procedure and found some > issues: > > Some of them we already fixed with Petr Ivanod and Anton Vinogradov. > Thank you, guys! > > For now, I stuck on the following issue: > > `vote_3_step_1\[packages\]build.sh` is broken. > I got following output: > > ``` > RPM build errors: > bogus date in %changelog: Fri Jun 17 2018 Peter Ivanov < > mr.wei...@gmail.com> - 2.6.0-1 > File not found: > /tmp/tmp.EezfJVTwLm/BUILDROOT/apache-ignite-2.6.0-1.x86_64/usr/share/doc/apache-ignite-2.6.0/MIGRATION_GUIDE.txt > + processTrap > + echo 'Removing temporary work directories: /tmp/tmp.EezfJVTwLm' > Removing temporary work directories: /tmp/tmp.EezfJVTwLm > + rm -rf /tmp/tmp.EezfJVTwLm > ``` > > 1. Script uses version number 2.6 somehow. > 2. It fails because MIGRATION_GUIDE file doesn't exists. > > Is there anybody who can help with this issue? > > > >
Apache Ignite 2.7 - Release Procedure issues
Hello, Igniters. I've started to write Wiki article for a future Release Managers. Since release process doesn't described anywhere public I do it while releasing 2.7: https://cwiki.apache.org/confluence/display/IGNITE/Release+manager+Notes Any feedback is strongly appreciated. I've tried to walk through vote steps in release procedure and found some issues: Some of them we already fixed with Petr Ivanod and Anton Vinogradov. Thank you, guys! For now, I stuck on the following issue: `vote_3_step_1\[packages\]build.sh` is broken. I got following output: ``` RPM build errors: bogus date in %changelog: Fri Jun 17 2018 Peter Ivanov - 2.6.0-1 File not found: /tmp/tmp.EezfJVTwLm/BUILDROOT/apache-ignite-2.6.0-1.x86_64/usr/share/doc/apache-ignite-2.6.0/MIGRATION_GUIDE.txt + processTrap + echo 'Removing temporary work directories: /tmp/tmp.EezfJVTwLm' Removing temporary work directories: /tmp/tmp.EezfJVTwLm + rm -rf /tmp/tmp.EezfJVTwLm ``` 1. Script uses version number 2.6 somehow. 2. It fails because MIGRATION_GUIDE file doesn't exists. Is there anybody who can help with this issue? signature.asc Description: This is a digitally signed message part
[jira] [Created] (IGNITE-8586) Minor fix for Apache Ignite's release procedure
Peter Ivanov created IGNITE-8586: Summary: Minor fix for Apache Ignite's release procedure Key: IGNITE-8586 URL: https://issues.apache.org/jira/browse/IGNITE-8586 Project: Ignite Issue Type: Bug Reporter: Peter Ivanov Assignee: Peter Ivanov Fix package.sh to not require sudo permissions for packages build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: release procedure
Not sure we can go with #4: the binary release requires compilation under Windows and Linux (for platform artifacts). It means at least two containers and looks like overcomplicated. Also windows requires a license even it start somewhere in a virtual environment. my vote for #3 as most simple solution On Wed, Aug 23, 2017 at 9:22 PM, Denis Magda <dma...@apache.org> wrote: > Honestly, #3 and #4 look pretty similar for me. Considering that all the > environment is already set for #3 I would go for it. > > — > Denis > > > On Aug 23, 2017, at 8:37 AM, Alexey Dmitriev <admitr...@gridgain.com> > wrote: > > > > +1 > > option #3 looks good > > > > On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin <oosta...@gridgain.com> > wrote: > > > >> Hello Igniters, I'd like to know which release option is preferred for > the > >> community. I've done some research and some tests and I think the most > >> transparent way is option #3. > >> > >> On Wed, Aug 9, 2017 at 11:28 PM, Konstantin Boudnik <c...@apache.org> > >> wrote: > >> > >>> There's also #4: > >>> - providing an official environment, comprised of the toolchain, > >>> compilers, libs, etc,. The same environment (read "a container") could > >>> be used by an individual developer, RM, and/or in CI system for > >>> builds, tests, etc. And then you can have #3 pretty much for free! > >>> > >>> We are doing this in Bigtop for a much more complex environment, set > >>> of components and supported OS. I am sure it would be easy to do in > >>> Ignite. > >>> -- > >>> With regards, > >>> Konstantin (Cos) Boudnik > >>> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 > >>> > >>> Disclaimer: Opinions expressed in this email are those of the author, > >>> and do not necessarily represent the views of any company the author > >>> might be affiliated with at the moment of writing. > >>> > >>> > >>> On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <oosta...@gridgain.com> > >>> wrote: > >>>> Hi, > >>>> > >>>> I'd like to start a discussion about Apache Ignite release procedure. > >>>> > >>>> I'm working on ticket Ignite-5249 "The release build procedure should > >> be > >>>> placed on the CI/CD server and available to run for the release > >>> engineer." > >>>> > >>>> https://issues.apache.org/jira/browse/IGNITE-5249 > >>>> > >>>> Currently we have three options for release: > >>>> > >>>> 1. Release engineer can do all the necessary steps on his local > >> machine. > >>> It > >>>> will require installing tons of soft like maven, doxigen, candle and > so > >>> on. > >>>> Also building .net part of the project will require access to Windows > >> OS. > >>>> Build steps will not be transparent for community. Environment will > not > >>> be > >>>> the same for each release which can lead to the compatibility issues. > >>>> > >>>> 2. All the steps (including signing) can be done on the public > >> continuous > >>>> integration server. Environment will be the same for each release, all > >>> the > >>>> steps will be transparent for community, but it will require uploading > >> at > >>>> least one private gpg certificate on the server. This is the high > >>> security > >>>> risk and I'm mentioning this option only for the sake of completeness. > >>>> > >>>> 3. Building of the project can be performed on the public continuous > >>>> integration server and then artifacts can be downloaded on the local > >>>> machine and signed and deployed to the staging repository from that > >> local > >>>> machine by running maven commands. No sharing of any credentials and > >>>> certificates will be needed, environment will be the same for each > >>> release, > >>>> all the steps will be transparent for community, artifacts created on > >> the > >>>> CI server can be verified by check-sums after uploading to the > >>> repository. > >>>> > >>>> Please, let me know if you have any suggestion or any questions about > >>>> anything related. > >>> > >> > > > > > > > > -- > > Alexey Dmitriev, VP Engineering > > *GridGain Systems* > > www.gridgain.com > > -- Sergey Kozlov GridGain Systems www.gridgain.com
Re: release procedure
Honestly, #3 and #4 look pretty similar for me. Considering that all the environment is already set for #3 I would go for it. — Denis > On Aug 23, 2017, at 8:37 AM, Alexey Dmitriev <admitr...@gridgain.com> wrote: > > +1 > option #3 looks good > > On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin <oosta...@gridgain.com> wrote: > >> Hello Igniters, I'd like to know which release option is preferred for the >> community. I've done some research and some tests and I think the most >> transparent way is option #3. >> >> On Wed, Aug 9, 2017 at 11:28 PM, Konstantin Boudnik <c...@apache.org> >> wrote: >> >>> There's also #4: >>> - providing an official environment, comprised of the toolchain, >>> compilers, libs, etc,. The same environment (read "a container") could >>> be used by an individual developer, RM, and/or in CI system for >>> builds, tests, etc. And then you can have #3 pretty much for free! >>> >>> We are doing this in Bigtop for a much more complex environment, set >>> of components and supported OS. I am sure it would be easy to do in >>> Ignite. >>> -- >>> With regards, >>> Konstantin (Cos) Boudnik >>> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 >>> >>> Disclaimer: Opinions expressed in this email are those of the author, >>> and do not necessarily represent the views of any company the author >>> might be affiliated with at the moment of writing. >>> >>> >>> On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <oosta...@gridgain.com> >>> wrote: >>>> Hi, >>>> >>>> I'd like to start a discussion about Apache Ignite release procedure. >>>> >>>> I'm working on ticket Ignite-5249 "The release build procedure should >> be >>>> placed on the CI/CD server and available to run for the release >>> engineer." >>>> >>>> https://issues.apache.org/jira/browse/IGNITE-5249 >>>> >>>> Currently we have three options for release: >>>> >>>> 1. Release engineer can do all the necessary steps on his local >> machine. >>> It >>>> will require installing tons of soft like maven, doxigen, candle and so >>> on. >>>> Also building .net part of the project will require access to Windows >> OS. >>>> Build steps will not be transparent for community. Environment will not >>> be >>>> the same for each release which can lead to the compatibility issues. >>>> >>>> 2. All the steps (including signing) can be done on the public >> continuous >>>> integration server. Environment will be the same for each release, all >>> the >>>> steps will be transparent for community, but it will require uploading >> at >>>> least one private gpg certificate on the server. This is the high >>> security >>>> risk and I'm mentioning this option only for the sake of completeness. >>>> >>>> 3. Building of the project can be performed on the public continuous >>>> integration server and then artifacts can be downloaded on the local >>>> machine and signed and deployed to the staging repository from that >> local >>>> machine by running maven commands. No sharing of any credentials and >>>> certificates will be needed, environment will be the same for each >>> release, >>>> all the steps will be transparent for community, artifacts created on >> the >>>> CI server can be verified by check-sums after uploading to the >>> repository. >>>> >>>> Please, let me know if you have any suggestion or any questions about >>>> anything related. >>> >> > > > > -- > Alexey Dmitriev, VP Engineering > *GridGain Systems* > www.gridgain.com
Re: release procedure
+1 option #3 looks good On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin <oosta...@gridgain.com> wrote: > Hello Igniters, I'd like to know which release option is preferred for the > community. I've done some research and some tests and I think the most > transparent way is option #3. > > On Wed, Aug 9, 2017 at 11:28 PM, Konstantin Boudnik <c...@apache.org> > wrote: > > > There's also #4: > > - providing an official environment, comprised of the toolchain, > > compilers, libs, etc,. The same environment (read "a container") could > > be used by an individual developer, RM, and/or in CI system for > > builds, tests, etc. And then you can have #3 pretty much for free! > > > > We are doing this in Bigtop for a much more complex environment, set > > of components and supported OS. I am sure it would be easy to do in > > Ignite. > > -- > > With regards, > > Konstantin (Cos) Boudnik > > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 > > > > Disclaimer: Opinions expressed in this email are those of the author, > > and do not necessarily represent the views of any company the author > > might be affiliated with at the moment of writing. > > > > > > On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <oosta...@gridgain.com> > > wrote: > > > Hi, > > > > > > I'd like to start a discussion about Apache Ignite release procedure. > > > > > > I'm working on ticket Ignite-5249 "The release build procedure should > be > > > placed on the CI/CD server and available to run for the release > > engineer." > > > > > > https://issues.apache.org/jira/browse/IGNITE-5249 > > > > > > Currently we have three options for release: > > > > > > 1. Release engineer can do all the necessary steps on his local > machine. > > It > > > will require installing tons of soft like maven, doxigen, candle and so > > on. > > > Also building .net part of the project will require access to Windows > OS. > > > Build steps will not be transparent for community. Environment will not > > be > > > the same for each release which can lead to the compatibility issues. > > > > > > 2. All the steps (including signing) can be done on the public > continuous > > > integration server. Environment will be the same for each release, all > > the > > > steps will be transparent for community, but it will require uploading > at > > > least one private gpg certificate on the server. This is the high > > security > > > risk and I'm mentioning this option only for the sake of completeness. > > > > > > 3. Building of the project can be performed on the public continuous > > > integration server and then artifacts can be downloaded on the local > > > machine and signed and deployed to the staging repository from that > local > > > machine by running maven commands. No sharing of any credentials and > > > certificates will be needed, environment will be the same for each > > release, > > > all the steps will be transparent for community, artifacts created on > the > > > CI server can be verified by check-sums after uploading to the > > repository. > > > > > > Please, let me know if you have any suggestion or any questions about > > > anything related. > > > -- Alexey Dmitriev, VP Engineering *GridGain Systems* www.gridgain.com
Re: release procedure
Hello Igniters, I'd like to know which release option is preferred for the community. I've done some research and some tests and I think the most transparent way is option #3. On Wed, Aug 9, 2017 at 11:28 PM, Konstantin Boudnik <c...@apache.org> wrote: > There's also #4: > - providing an official environment, comprised of the toolchain, > compilers, libs, etc,. The same environment (read "a container") could > be used by an individual developer, RM, and/or in CI system for > builds, tests, etc. And then you can have #3 pretty much for free! > > We are doing this in Bigtop for a much more complex environment, set > of components and supported OS. I am sure it would be easy to do in > Ignite. > -- > With regards, > Konstantin (Cos) Boudnik > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 > > Disclaimer: Opinions expressed in this email are those of the author, > and do not necessarily represent the views of any company the author > might be affiliated with at the moment of writing. > > > On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <oosta...@gridgain.com> > wrote: > > Hi, > > > > I'd like to start a discussion about Apache Ignite release procedure. > > > > I'm working on ticket Ignite-5249 "The release build procedure should be > > placed on the CI/CD server and available to run for the release > engineer." > > > > https://issues.apache.org/jira/browse/IGNITE-5249 > > > > Currently we have three options for release: > > > > 1. Release engineer can do all the necessary steps on his local machine. > It > > will require installing tons of soft like maven, doxigen, candle and so > on. > > Also building .net part of the project will require access to Windows OS. > > Build steps will not be transparent for community. Environment will not > be > > the same for each release which can lead to the compatibility issues. > > > > 2. All the steps (including signing) can be done on the public continuous > > integration server. Environment will be the same for each release, all > the > > steps will be transparent for community, but it will require uploading at > > least one private gpg certificate on the server. This is the high > security > > risk and I'm mentioning this option only for the sake of completeness. > > > > 3. Building of the project can be performed on the public continuous > > integration server and then artifacts can be downloaded on the local > > machine and signed and deployed to the staging repository from that local > > machine by running maven commands. No sharing of any credentials and > > certificates will be needed, environment will be the same for each > release, > > all the steps will be transparent for community, artifacts created on the > > CI server can be verified by check-sums after uploading to the > repository. > > > > Please, let me know if you have any suggestion or any questions about > > anything related. >
Re: release procedure
There's also #4: - providing an official environment, comprised of the toolchain, compilers, libs, etc,. The same environment (read "a container") could be used by an individual developer, RM, and/or in CI system for builds, tests, etc. And then you can have #3 pretty much for free! We are doing this in Bigtop for a much more complex environment, set of components and supported OS. I am sure it would be easy to do in Ignite. -- With regards, Konstantin (Cos) Boudnik 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 Disclaimer: Opinions expressed in this email are those of the author, and do not necessarily represent the views of any company the author might be affiliated with at the moment of writing. On Sun, Aug 6, 2017 at 5:37 AM, Oleg Ostanin <oosta...@gridgain.com> wrote: > Hi, > > I'd like to start a discussion about Apache Ignite release procedure. > > I'm working on ticket Ignite-5249 "The release build procedure should be > placed on the CI/CD server and available to run for the release engineer." > > https://issues.apache.org/jira/browse/IGNITE-5249 > > Currently we have three options for release: > > 1. Release engineer can do all the necessary steps on his local machine. It > will require installing tons of soft like maven, doxigen, candle and so on. > Also building .net part of the project will require access to Windows OS. > Build steps will not be transparent for community. Environment will not be > the same for each release which can lead to the compatibility issues. > > 2. All the steps (including signing) can be done on the public continuous > integration server. Environment will be the same for each release, all the > steps will be transparent for community, but it will require uploading at > least one private gpg certificate on the server. This is the high security > risk and I'm mentioning this option only for the sake of completeness. > > 3. Building of the project can be performed on the public continuous > integration server and then artifacts can be downloaded on the local > machine and signed and deployed to the staging repository from that local > machine by running maven commands. No sharing of any credentials and > certificates will be needed, environment will be the same for each release, > all the steps will be transparent for community, artifacts created on the > CI server can be verified by check-sums after uploading to the repository. > > Please, let me know if you have any suggestion or any questions about > anything related.
Re: release procedure
Vote for #3 On Sun, Aug 6, 2017 at 3:37 PM, Oleg Ostanin <oosta...@gridgain.com> wrote: > Hi, > > I'd like to start a discussion about Apache Ignite release procedure. > > I'm working on ticket Ignite-5249 "The release build procedure should be > placed on the CI/CD server and available to run for the release engineer." > > https://issues.apache.org/jira/browse/IGNITE-5249 > > Currently we have three options for release: > > 1. Release engineer can do all the necessary steps on his local machine. It > will require installing tons of soft like maven, doxigen, candle and so on. > Also building .net part of the project will require access to Windows OS. > Build steps will not be transparent for community. Environment will not be > the same for each release which can lead to the compatibility issues. > > 2. All the steps (including signing) can be done on the public continuous > integration server. Environment will be the same for each release, all the > steps will be transparent for community, but it will require uploading at > least one private gpg certificate on the server. This is the high security > risk and I'm mentioning this option only for the sake of completeness. > > 3. Building of the project can be performed on the public continuous > integration server and then artifacts can be downloaded on the local > machine and signed and deployed to the staging repository from that local > machine by running maven commands. No sharing of any credentials and > certificates will be needed, environment will be the same for each release, > all the steps will be transparent for community, artifacts created on the > CI server can be verified by check-sums after uploading to the repository. > > Please, let me know if you have any suggestion or any questions about > anything related. >
release procedure
Hi, I'd like to start a discussion about Apache Ignite release procedure. I'm working on ticket Ignite-5249 "The release build procedure should be placed on the CI/CD server and available to run for the release engineer." https://issues.apache.org/jira/browse/IGNITE-5249 Currently we have three options for release: 1. Release engineer can do all the necessary steps on his local machine. It will require installing tons of soft like maven, doxigen, candle and so on. Also building .net part of the project will require access to Windows OS. Build steps will not be transparent for community. Environment will not be the same for each release which can lead to the compatibility issues. 2. All the steps (including signing) can be done on the public continuous integration server. Environment will be the same for each release, all the steps will be transparent for community, but it will require uploading at least one private gpg certificate on the server. This is the high security risk and I'm mentioning this option only for the sake of completeness. 3. Building of the project can be performed on the public continuous integration server and then artifacts can be downloaded on the local machine and signed and deployed to the staging repository from that local machine by running maven commands. No sharing of any credentials and certificates will be needed, environment will be the same for each release, all the steps will be transparent for community, artifacts created on the CI server can be verified by check-sums after uploading to the repository. Please, let me know if you have any suggestion or any questions about anything related.
Re: Suggested changes for Apache Ignite Release procedure
+1 I have assigned the ticket to myself and I did some preliminary investigations in this matter. It seems to me the most complicated part will be configuring tasks in such way that release commiter could use it without exposing his credentials for Git, SVN and Maven. I suggest we create an integration user for public Teamcity and grant him permissions to commit and deploy in the repositories. On Thu, Jun 8, 2017 at 6:10 AM, Denis Magda <dma...@apache.org> wrote: > +1 > > > On Jun 7, 2017, at 3:40 AM, Sergey Kozlov <skoz...@gridgain.com> wrote: > > > > Hi, Igniters > > > > I'd start the discussion for following changes of release procedure. > > As you may know we provided not source artifacts only but also a set of > > binaries that makes using of the release is more friendly namely: > > - binary farbic artifact > > - binary hadoop artifact > > - articats in Apache Ignite Maven repository > > - artifacts for .Net/C++ in NuGet > > > > At the moment we release it by procedure [1] and some actions should be > > processed manually (or some semi-automated way) by the release > > lead committer. > > > > I suggest to implement all such tasks on public teamcity as TC > > configurations in a special project and allow to run them by the release > > lead committer. > > > > Corresponding JIRA issue is [2] > > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process > > [2] https://issues.apache.org/jira/browse/IGNITE-5249 > > -- > > Sergey Kozlov > >
Re: Suggested changes for Apache Ignite Release procedure
+1 > On Jun 7, 2017, at 3:40 AM, Sergey Kozlov <skoz...@gridgain.com> wrote: > > Hi, Igniters > > I'd start the discussion for following changes of release procedure. > As you may know we provided not source artifacts only but also a set of > binaries that makes using of the release is more friendly namely: > - binary farbic artifact > - binary hadoop artifact > - articats in Apache Ignite Maven repository > - artifacts for .Net/C++ in NuGet > > At the moment we release it by procedure [1] and some actions should be > processed manually (or some semi-automated way) by the release > lead committer. > > I suggest to implement all such tasks on public teamcity as TC > configurations in a special project and allow to run them by the release > lead committer. > > Corresponding JIRA issue is [2] > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process > [2] https://issues.apache.org/jira/browse/IGNITE-5249 > -- > Sergey Kozlov
Re: Suggested changes for Apache Ignite Release procedure
Huge +1 On Wed, Jun 7, 2017 at 1:40 PM, Sergey Kozlov <skoz...@gridgain.com> wrote: > Hi, Igniters > > I'd start the discussion for following changes of release procedure. > As you may know we provided not source artifacts only but also a set of > binaries that makes using of the release is more friendly namely: > - binary farbic artifact > - binary hadoop artifact > - articats in Apache Ignite Maven repository > - artifacts for .Net/C++ in NuGet > > At the moment we release it by procedure [1] and some actions should be > processed manually (or some semi-automated way) by the release > lead committer. > > I suggest to implement all such tasks on public teamcity as TC > configurations in a special project and allow to run them by the release > lead committer. > > Corresponding JIRA issue is [2] > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process > [2] https://issues.apache.org/jira/browse/IGNITE-5249 > -- > Sergey Kozlov >
Suggested changes for Apache Ignite Release procedure
Hi, Igniters I'd start the discussion for following changes of release procedure. As you may know we provided not source artifacts only but also a set of binaries that makes using of the release is more friendly namely: - binary farbic artifact - binary hadoop artifact - articats in Apache Ignite Maven repository - artifacts for .Net/C++ in NuGet At the moment we release it by procedure [1] and some actions should be processed manually (or some semi-automated way) by the release lead committer. I suggest to implement all such tasks on public teamcity as TC configurations in a special project and allow to run them by the release lead committer. Corresponding JIRA issue is [2] [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process [2] https://issues.apache.org/jira/browse/IGNITE-5249 -- Sergey Kozlov
