Re: release procedure

[Sergey Kozlov]

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  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 
> wrote:
> >
> > +1
> > option #3 looks good
> >
> > On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin 
> 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 
> >> 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 
> >>> 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

[Denis Magda]

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  wrote:
> 
> +1
> option #3 looks good
> 
> On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin  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 
>> 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 
>>> 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

[Alexey Dmitriev]

+1
option #3 looks good

On Wed, Aug 23, 2017 at 1:35 PM, Oleg Ostanin  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 
> 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 
> > 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

[Oleg Ostanin]

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  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 
> 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

[Konstantin Boudnik]

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  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

[Anton Vinogradov]

Vote for #3

On Sun, Aug 6, 2017 at 3:37 PM, Oleg Ostanin  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.
>