Ignite Voting Process

[Anton Vinogradov <av...@gridgain.com>]

Igniters,

We've published Ignite Voting Process, please have a look before sending +1
to vote ;)

https://cwiki.apache.org/confluence/display/IGNITE/Voting+Process

Re: Ignite Voting Process

[Konstantin Boudnik <co...@apache.org>]

This shouldn't be called "Voting Process". This is "How to verify the release"
at best ;)

Also, it needs to be a part of "How to release" document because it describes
certain mechanics of it ie sending emails, making announcements, etc.

Cos

On Wed, Dec 30, 2015 at 06:05PM, Anton Vinogradov wrote:
> Igniters,
> 
> We've published Ignite Voting Process, please have a look before sending +1
> to vote ;)
> 
> https://cwiki.apache.org/confluence/display/IGNITE/Voting+Process

Re: Ignite Voting Process

[Dmitriy Setrakyan <ds...@apache.org>]

Thanks Anton, this is great!

As Cos mentioned, Voting Process is not a good name this doc. I have
renamed it to Release Process.

Also, looks like the RAT step is missing. Can it be added?

D.

On Wed, Dec 30, 2015 at 7:05 AM, Anton Vinogradov <av...@gridgain.com>
wrote:

> Igniters,
>
> We've published Ignite Voting Process, please have a look before sending +1
> to vote ;)
>
> https://cwiki.apache.org/confluence/display/IGNITE/Voting+Process
>

Re: Ignite Voting Process

[Branko Čibej <br...@apache.org>]

On 31.12.2015 09:58, Branko Čibej wrote:
> On 30.12.2015 16:30, Raul Kripalani wrote:
>> Hi Anton,
>>
>> Why don't we publish artifacts for ignite-geospatial, ignite-hibernate and
>> ignite-schedule? The lgpl profile is not triggered in these instructions,
>> and these artifacts cease existing in Maven Central 1.2.0-incubating
>> onwards.
>>
>> I know they depend on LGPL-licensed libraries, but we can publish our
>> Ignite components WITHOUT packaging the upstream dependencies (Hibernate,
>> etc.). Then we would be complying with the ASF ruleset to my understanding,
>> because:
>>
>> 1. These modules are optional.
>> 2. We don't package the LGPL dependencies: we simply write instructions on
>> our docs on how to fetch them separately.
> We'd be publishing modules that can't be used without the LGPL
> components. I'm not sure how that stands WRT our policies but I can't
> see how it would be a service to our users to actively nudge them
> towards using restrictive-licensed code.

I mean "binary modules;" the ASF release policy doesn't really apply to
binaries, but by analogy, we probably could publish those modules. My
doubt about this being a service to users still stands, however.

-- Brane

Re: Ignite Voting Process

[李玉...@163, 18...@163.com]

Great！

在 16/1/1 02:35, Dmitriy Setrakyan 写道:
> I tend to agree with Raul.
>
> We have been anal-retentive to a fault with regard to LGPL, instead of
> focusing on usability. Our users are already required to take a conscious
> step to include LGPL modules into Ignite builds, so there is no implicit
> “drag-in”, as Raul mentioned.
>
> I would vote for publishing all Ignite modules to Maven, without exception.
>
> D.
>
>
>
> On Thu, Dec 31, 2015 at 5:21 AM, Raul Kripalani <ra...@apache.org> wrote:
>
>> Hi Brane,
>>
>> On Thu, Dec 31, 2015 at 8:58 AM, Branko Čibej <br...@apache.org> wrote:
>>
>>> We'd be publishing modules that can't be used without the LGPL
>>> components. I'm not sure how that stands WRT our policies but I can't
>>> see how it would be a service to our users to actively nudge them
>>> towards using restrictive-licensed code.
>>>
>> The ASF policies specify that, as long as our components are optional and
>> not needed by the core project, we can publish them, obviously *without*
>> packaging the LGPL binary nor implicitly "dragging it in" during the build.
>> This can be achieved with a 'runtime' scope in Maven.
>>
>> It does make a huge difference to the end user of these 3 modules – being
>> able to reference ignite-hibernate and simply having to manually drop in
>> the Hibernate dependency vs. having to: (1) check out the source, (2) run
>> the build, (3) publish the artifacts in their corporate Nexus repo, etc. +
>> having to do this *for each release*.
>>
>> *Raúl Kripalani*
>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
>> Messaging Engineer
>> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
>> http://blog.raulkr.net | twitter: @raulvk
>>

Re: Ignite Voting Process

[Dmitriy Setrakyan <ds...@apache.org>]

I tend to agree with Raul.

We have been anal-retentive to a fault with regard to LGPL, instead of
focusing on usability. Our users are already required to take a conscious
step to include LGPL modules into Ignite builds, so there is no implicit
“drag-in”, as Raul mentioned.

I would vote for publishing all Ignite modules to Maven, without exception.

D.



On Thu, Dec 31, 2015 at 5:21 AM, Raul Kripalani <ra...@apache.org> wrote:

> Hi Brane,
>
> On Thu, Dec 31, 2015 at 8:58 AM, Branko Čibej <br...@apache.org> wrote:
>
> > We'd be publishing modules that can't be used without the LGPL
> > components. I'm not sure how that stands WRT our policies but I can't
> > see how it would be a service to our users to actively nudge them
> > towards using restrictive-licensed code.
> >
>
> The ASF policies specify that, as long as our components are optional and
> not needed by the core project, we can publish them, obviously *without*
> packaging the LGPL binary nor implicitly "dragging it in" during the build.
> This can be achieved with a 'runtime' scope in Maven.
>
> It does make a huge difference to the end user of these 3 modules – being
> able to reference ignite-hibernate and simply having to manually drop in
> the Hibernate dependency vs. having to: (1) check out the source, (2) run
> the build, (3) publish the artifacts in their corporate Nexus repo, etc. +
> having to do this *for each release*.
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>

Re: Ignite Voting Process

[Raul Kripalani <ra...@apache.org>]

Hi Brane,

On Thu, Dec 31, 2015 at 8:58 AM, Branko Čibej <br...@apache.org> wrote:

> We'd be publishing modules that can't be used without the LGPL
> components. I'm not sure how that stands WRT our policies but I can't
> see how it would be a service to our users to actively nudge them
> towards using restrictive-licensed code.
>

The ASF policies specify that, as long as our components are optional and
not needed by the core project, we can publish them, obviously *without*
packaging the LGPL binary nor implicitly "dragging it in" during the build.
This can be achieved with a 'runtime' scope in Maven.

It does make a huge difference to the end user of these 3 modules – being
able to reference ignite-hibernate and simply having to manually drop in
the Hibernate dependency vs. having to: (1) check out the source, (2) run
the build, (3) publish the artifacts in their corporate Nexus repo, etc. +
having to do this *for each release*.

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

Re: Ignite Voting Process

[Branko Čibej <br...@apache.org>]

On 30.12.2015 16:30, Raul Kripalani wrote:
> Hi Anton,
>
> Why don't we publish artifacts for ignite-geospatial, ignite-hibernate and
> ignite-schedule? The lgpl profile is not triggered in these instructions,
> and these artifacts cease existing in Maven Central 1.2.0-incubating
> onwards.
>
> I know they depend on LGPL-licensed libraries, but we can publish our
> Ignite components WITHOUT packaging the upstream dependencies (Hibernate,
> etc.). Then we would be complying with the ASF ruleset to my understanding,
> because:
>
> 1. These modules are optional.
> 2. We don't package the LGPL dependencies: we simply write instructions on
> our docs on how to fetch them separately.

We'd be publishing modules that can't be used without the LGPL
components. I'm not sure how that stands WRT our policies but I can't
see how it would be a service to our users to actively nudge them
towards using restrictive-licensed code.

-- Brane

Re: Ignite Voting Process

[Raul Kripalani <ra...@apache.org>]

Hi Anton,

Why don't we publish artifacts for ignite-geospatial, ignite-hibernate and
ignite-schedule? The lgpl profile is not triggered in these instructions,
and these artifacts cease existing in Maven Central 1.2.0-incubating
onwards.

I know they depend on LGPL-licensed libraries, but we can publish our
Ignite components WITHOUT packaging the upstream dependencies (Hibernate,
etc.). Then we would be complying with the ASF ruleset to my understanding,
because:

1. These modules are optional.
2. We don't package the LGPL dependencies: we simply write instructions on
our docs on how to fetch them separately.

[1] https://issues.apache.org/jira/browse/LEGAL-192
[2] https://www.apache.org/legal/resolved.html#optional

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Wed, Dec 30, 2015 at 3:05 PM, Anton Vinogradov <av...@gridgain.com>
wrote:

> Igniters,
>
> We've published Ignite Voting Process, please have a look before sending +1
> to vote ;)
>
> https://cwiki.apache.org/confluence/display/IGNITE/Voting+Process
>