Re: [VOTE] Release Apache NLPCraft (Incubating) 1.0.0

[Konstantin Boudnik]

Transferring my +1 vote from dev@nlpcraft.a.o

With regards,
  Cos

On 2/15/23 12:45, Sergey Kamov wrote:

Hello all,
This is a call for a vote to release Apache NLPCraft (incubating) version
1.0.0.


The Apache NLPCraft community has voted on and approved a proposal to
release Apache NLPCraft (incubating) version 1.0.0. We
would
like to request the Incubator PMC members review and vote on this
incubator
release.

Apache NLPCraft is a library for adding a natural language
interface to any applications. This 1.0.0 release constitutes the biggest
change since the
project inception at ASF. The project architecture and user API are totally
refactored and simplified.
Migration to Scala 3 finished.

Release information:
1. Vote result thread:
https://lists.apache.org/thread/1gtyw8d388k5nv3h58zz02znjo5cbqgk
2. Release (ZIP, PGP, SHA256) location:
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/1.0.0/
3. Git tag:
https://github.com/apache/incubator-nlpcraft/tree/v1.0.0
4. KEYS file:
https://dist.apache.org/repos/dist/release/incubator/nlpcraft/KEYS

The vote will be open for at least 72 hours or until a necessary number
of
votes are reached.

Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Thank you,
--
Sergey Kamov



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Resigning as Datalab mentor

[Konstantin Boudnik]

Please consider this as my official resignation from the role of 
Datalab's mentor as I don't have any cycles for the project anymore.


--
With regards,
  Konstantin Boudnik

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache NLPCraft - Java Client (incubating) 0.7.2

[Konstantin Boudnik]

+1 (binding) carrying the vote over from dev@

With regards,
  Cos

On 14.12.2020 21:15, Aaron Radzinski wrote:

Hello all,
This is a call for a vote to release Apache NLPCraft - Java Client (incubating)
version 0.7.2. Apache NLPCraft is a library for adding a natural language
interface to any application. This release includes bug fixes and necessary
updates for NLPCraft ver. 0.7.2 (main project).

NOTE: NLPCraft Java Client is a Java wrapper for NLPCraft REST APIs. It
is contained in its own Git repository but shares the same JIRA project as
the main NLPCraft project. Community plans to release Java Client along
with the main project to maintain a simple compatibility matrix.

The Apache NLPCraft community has voted on and approved a proposal to
release Apache NLPCraft - Java Client (Incubating) version 0.7.2. We would
like to request the Incubator PMC members review and vote on this incubator
release.

Release information:
1. PPMC vote result thread: https://mail-archives.apache.org/mod_mbox/
nlpcraft
-dev/202011.mbox/

2. Release location:
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/java-client/0.7.2/
3. Git tag:
https://github.com/apache/incubator-nlpcraft-java-client/tree/v0.7.2
4. JIRA issues fixed in release: https://issues.apache.org/jira/projects/
NLPCRAFT/versions/12349298
5. KEYS file: https://dist.apache.org/repos/dist/release/incubator/nlpcraft
/KEYS

The vote will be open for at least 72 hours or until a necessary number of
votes are reached.

Please vote accordingly:
+1 approve
+0 no opinion
-1 disapprove with the reason

Thank you,
On behalf of NLPCraft community
--
Aaron Radzinski



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache NLPCraft (incubating) 0.7.2

[Konstantin Boudnik]

+1 [vote carry over from the dev@ voting]

With regards,
  Cos

On 23.11.2020 23:21, Aaron Radzinski wrote:

Hello all,
This is a call for a vote to release Apache NLPCraft (incubating) version
0.7.2. Apache NLPCraft is a library for adding a natural language interface
to any application.

The Apache NLPCraft community has voted on and approved a proposal to
release Apache NLPCraft (Incubating) version 0.7.2. We would like to
request the Incubator PMC members review and vote on this incubator release.

Release information:
1. PPMC vote result thread:
https://mail-archives.apache.org/mod_mbox/nlpcraft-dev/202011.mbox/
2. Release location:
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/0.7.2/
3. Git tag: https://github.com/apache/incubator-nlpcraft/tree/v0.7.2
4. JIRA issues fixed in release:
https://issues.apache.org/jira/projects/NLPCRAFT/versions/12349298
5. KEYS file:
https://dist.apache.org/repos/dist/release/incubator/nlpcraft/KEYS

The vote will be open for at least 72 hours or until a necessary number of
votes are reached.

Please vote accordingly:
+1 approve
+0 no opinion
-1 disapprove with the reason

Thank you,
On behalf of NLPCraft community



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache NLPCraft (incubating) 0.7.1

[Konstantin Boudnik]

+1 [binding], vote carry over from [1]

--
  Cos

[1] 
https://lists.apache.org/thread.html/r333cd17f76303c86b603aa80ce7faa96b443c0351d680b22081a9d64%40%3Cdev.nlpcraft.apache.org%3E

On Mon, Oct 26, 2020 at 10:55PM, Aaron Radzinski wrote:
> Hello all,
> This is a call for a vote to release Apache NLPCraft (incubating) version
> 0.7.1. Apache NLPCraft is a library for adding a natural language interface
> to any application.
> 
> The Apache NLPCraft community has voted on and approved a proposal to
> release Apache NLPCraft (Incubating) version 0.7.1. We would like to
> request the Incubator PMC members review and vote on this incubator release.
> 
> Release information:
> 1. PPMC vote result thread:
> https://mail-archives.apache.org/mod_mbox/nlpcraft-dev/202010.mbox/%3CCACwEJt_8wxZM947eapEFs%2B1DDKch4t_zeH03edky015d0tY1Cw%40mail.gmail.com%3E
> 2. Release location:
> https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/0.7.1/
> 3. Git tag: https://github.com/apache/incubator-nlpcraft/tree/v0.7.1
> 4. JIRA issues fixed in release:
> https://issues.apache.org/jira/projects/NLPCRAFT/versions/1234
> 5. KEYS file: https://dist.apache.org/repos/dist/release/incubator/nlpcraft
> /KEYS
> 
> The vote will be open for at least 72 hours or until a necessary number of
> votes are reached.
> 
> Please vote accordingly:
> +1 approve
> +0 no opinion
> -1 disapprove with the reason
> 
> Thank you,
> --
> Aaron Radzinski
> On behalf of NLPCraft community


signature.asc
Description: PGP signature

Re: [VOTE] Release Apache NLPCraft (incubating) 0.7.0

[Konstantin Boudnik]

+1 [binding] (carrying the vote from dev@)
--
With regards,
  Cos

On September 30, 2020 10:34:10 PM GMT+03:00, Aaron Radzinski 
 wrote:
>Hello all,
>This is a call for a vote to release Apache NLPCraft (incubating)
>version
>0.7.0. Apache NLPCraft is a library for adding a natural language
>interface
>to any application.
>
>The Apache NLPCraft community has voted on and approved a proposal to
>release Apache NLPCraft (Incubating) version 0.7.0. We would like to
>request the Incubator PMC members review and vote on this incubator
>release.
>
>Release information:
>1. PPMC vote result thread:
>https://mail-archives.apache.org/mod_mbox/nlpcraft-dev/202009.mbox/%3ccacwejt8ova52cxczs74ri3ascqskz3gcduh+acd3i2mczyk...@mail.gmail.com%3E
>2. Release location:
>https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/0.7.0/
>3. Git tag: https://github.com/apache/incubator-nlpcraft/tree/v0.7.0
>4. JIRA issues fixed in release:
>https://issues.apache.org/jira/projects/NLPCRAFT/versions/12347776
>5. KEYS file:
>https://dist.apache.org/repos/dist/release/incubator/nlpcraft/KEYS
>
>NOTES:
>- Please re-import KEYS file before checking signatures.
>- Remove local ${USER_HOME}/.nlpcraft file before running 'mvn verify'
>if
>you had previous NLPCraft installation.
>
>The vote will be open for at least 72 hours or until a necessary number
>of
>votes are reached.
>
>Please vote accordingly:
>+1 approve
>+0 no opinion
>-1 disapprove with the reason
>
>Thank you,
>--
>Aaron Radzinski
>On behalf of NLPCraft community

-- 
  Regards,
  Cos

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache NLPCraft (incubating) 0.7.0

[Konstantin Boudnik]

+1 [binding]

carrying the vote over from dev@
--
With regards,
  Cos

On 2020-09-30 22:34, Aaron Radzinski wrote:

Hello all,
This is a call for a vote to release Apache NLPCraft (incubating) version
0.7.0. Apache NLPCraft is a library for adding a natural language interface
to any application.

The Apache NLPCraft community has voted on and approved a proposal to
release Apache NLPCraft (Incubating) version 0.7.0. We would like to
request the Incubator PMC members review and vote on this incubator release.

Release information:
1. PPMC vote result thread:
https://mail-archives.apache.org/mod_mbox/nlpcraft-dev/202009.mbox/%3ccacwejt8ova52cxczs74ri3ascqskz3gcduh+acd3i2mczyk...@mail.gmail.com%3E
2. Release location:
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/0.7.0/
3. Git tag: https://github.com/apache/incubator-nlpcraft/tree/v0.7.0
4. JIRA issues fixed in release:
https://issues.apache.org/jira/projects/NLPCRAFT/versions/12347776
5. KEYS file:
https://dist.apache.org/repos/dist/release/incubator/nlpcraft/KEYS

NOTES:
- Please re-import KEYS file before checking signatures.
- Remove local ${USER_HOME}/.nlpcraft file before running 'mvn verify' if
you had previous NLPCraft installation.

The vote will be open for at least 72 hours or until a necessary number of
votes are reached.

Please vote accordingly:
+1 approve
+0 no opinion
-1 disapprove with the reason

Thank you,
--
Aaron Radzinski
On behalf of NLPCraft community



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache NLPCraft (Incubating) 0.6.2

[Konstantin Boudnik]

+1 [binding]

- DISCLAIMER exists
- LICENSE and NOTICE as expected
- No binary files
- Signatures and checksums are ok

--
With regards,
  Cos

On 2020-07-16 00:23, Aaron Radzinski wrote:

Hello all,
This is a call for a vote to release Apache NLPCraft (incubating) version
0.6.2. Apache NLPCraft is a library for adding a natural language interface
to any application.

The Apache NLPCraft community has voted on and approved a proposal to
release Apache NLPCraft (Incubating) version 0.6.2. We would like to
request the Incubator PMC members review and vote on this incubator release.

Release information:
1. PPMC vote result thread:
https://mail-archives.apache.org/mod_mbox/nlpcraft-dev/202007.mbox/%3CCACwEJt8UFyDacVOa-MpwYj8s-c8vfFXbhmR%3DL1XBdtA4RKyJ7g%40mail.gmail.com%3E
2. Release location:
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/0.6.2/
3. Git tag: https://github.com/apache/incubator-nlpcraft/tree/v0.6.2
4. JIRA issues fixed in release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323722=12347775
5. KEYS file:
https://dist.apache.org/repos/dist/release/incubator/nlpcraft/KEYS

The vote will be open for at least 72 hours or until a necessary number of
votes are reached.

Please vote accordingly:
+1 approve
+0 no opinion
-1 disapprove with the reason

Thank you,
--
Aaron Radzinski



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache NLPCraft (Incubating) 0.5.0

[Konstantin Boudnik]

Justin,

thanks a lot for the comments and keeping us honest. I want to make sure 
we are on the same page: do you see these issues as critical or they can 
be addressed in the consequent release?


Thanks,

On 2020-05-05 06:02, Justin Mclean wrote:

Hi,


Fixed in master. However, there are still questions on hoThw NOTICE file
should look like for binary releases.

Generally the way that is handles is too have seperate NOTICE (and LICENSE) 
files one for teh source release and one for the binary convienance.


These are the model files shipped with Apache OpenNLP (data, not code).

Perhaps call them “.dat” rather than “.bin”?

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org


--
With regards,
  Cos


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache NLPCraft (Incubating) 0.5.0

[Konstantin Boudnik]

+1 [binding]

Checked

- signatures
- license compliance
- checksums

Thank you.
--
  Cos

On 2020-04-23 12:52, Aaron Radzinski wrote:

Hello all,
This is a call for a vote to release Apache NLPCraft (incubating) version
0.5.0.

The Apache NLPCraft community has voted on and approved a proposal to
release Apache NLPCraft (Incubating) version 0.5.0. We would like to
request the Incubator PMC members review and vote on this incubator release.

Apache NLPCraft is a Java-based library for adding a natural language
interface to any applications. Notice that this is a first ASF release for
the NLPCraft community.

Release information:
1. Vote result thread:
https://mail-archives.apache.org/mod_mbox/nlpcraft-dev/202004.mbox/%3CCACwEJt9LEqEJw7gVxS%3D56d%2BA%3DZewjBBEbQQJY%3D%2B6o7N7P-%3D0Ag%40mail.gmail.com%3E
2. Release location:
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/
3. Git tag:
https://gitbox.apache.org/repos/asf?p=incubator-nlpcraft.git;a=tag;h=refs/tags/v0.5.0
4. JIRA issues fixed in release:
https://issues.apache.org/jira/projects/NLPCRAFT/versions/12347774

Quick links:
1. ZIP archive:
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/apache-nlpcraft-incubating-0.5.0.zip
2. PGP signature:
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/apache-nlpcraft-incubating-0.5.0.zip.asc
3. SHA256 signature:
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/apache-nlpcraft-incubating-0.5.0.zip.sha256
4. KEYS file:
https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/KEYS

NOTE: the 'dist' location has double 'nlpcraft' folders which may look
suspicious. First 'nlpcraft' is a root for the project, while the second
denotes core project name. Note that we'll be releasing our sub-projects
(i.e. java client) under the root 'nlpcraft' folder so the dist location
will eventually have structure like this:
-- nlpcraft
   |-- nlpcraft
   |-- nlpcraft-java-client
   |-- nlpcraft-web-ui

The vote will be open for at least 72 hours or until a necessary number of
votes are reached.

Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Thank you,
--
Aaron Radzinski


--
With regards,
  Cos


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT] Was: [VOTE] Accept NLPCraft into Apache Incubator

[Konstantin Boudnik]

Apologies for last email that came out horribly botched... resending

With 13 binding. 5 non-binding +1, none of 0s or -1s the vote has 
passed. Thanks everyone who voted:


[binding]
 Paul King 
 Evans Ye 
 俊平堵 junping...@apache.org 
 Roman Shaposhnik 
 Felix Cheung 
 Gary Wong 
 Michael Wall 
 Justin Mclean 
 Furkan KAMACI 
 Byung-Gon Chun 
 Sheng Wu 
 Kevin Ratnasekera 
 Konstantin Boudnik 


[non-binding]
 Aditya Sharma
 YuanSheng Wang
 coolsoul
 Swapnil M Mane
 Cihad Guzel

I will start all initiation activities in the coming couple of days.
--
With regards,
  Cos

On 2/9/20 4:54 PM, Konstantin Boudnik wrote:

Hello.

As the discussion of NLPCraft proposal [1] has been wrapped up [2] I would like
to call a VOTE to accept this project into the Apache Incubator.

Please cast your vote:

   [ ] +1, bring NLPCraft into Incubator
   [ ] +0, I don't care either way
   [ ] -1, do not bring NLPCraft into Incubator, because...

The vote will open for at least 72 hours until midnight PDT Wednesday, Feb 13,
2020. As a reminder: only votes from the IPMC members are considered binding,
but other votes are welcome!


[1] https://cwiki.apache.org/confluence/display/INCUBATOR/NLPCraftProposal
[2] https://s.apache.org/me4ut

Thank you,
   Cos




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



signature.asc
Description: PGP signature

[RESULT] Was: [VOTE] Accept NLPCraft into Apache Incubator

[Konstantin Boudnik]

With 13 binding. 5 non-binding +1, none of 0s or -1s the vote has 
passed. Thanks everyone who voted:


[binding]
Paul King 
   Evans Ye 

   俊平堵 junping...@apache.org 
Roman 
Shaposhnik 
 Felix Cheung 

 Gary Wong 
 Michael Wall 

 Justin Mclean 

Furkan KAMACI 
   Byung-Gon Chun 

   Sheng Wu 
   Kevin 
Ratnasekera 
 Konstantin Boudnik 




[non-binding]
Aditya Sharma
YuanSheng Wang
coolsoul
Swapnil M Mane
Cihad Guzel

I will start all initiation activities in the coming couple of days.
--
With regards,
  Cos

On 2/9/20 4:54 PM, Konstantin Boudnik wrote:

Hello.

As the discussion of NLPCraft proposal [1] has been wrapped up [2] I would like
to call a VOTE to accept this project into the Apache Incubator.

Please cast your vote:

   [ ] +1, bring NLPCraft into Incubator
   [ ] +0, I don't care either way
   [ ] -1, do not bring NLPCraft into Incubator, because...

The vote will open for at least 72 hours until midnight PDT Wednesday, Feb 13,
2020. As a reminder: only votes from the IPMC members are considered binding,
but other votes are welcome!


[1] https://cwiki.apache.org/confluence/display/INCUBATOR/NLPCraftProposal
[2] https://s.apache.org/me4ut

Thank you,
   Cos




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept NLPCraft into Apache Incubator

[Konstantin Boudnik]

+1 (binding)

On 2/9/20 4:54 PM, Konstantin Boudnik wrote:

Hello.

As the discussion of NLPCraft proposal [1] has been wrapped up [2] I would like
to call a VOTE to accept this project into the Apache Incubator.

Please cast your vote:

   [ ] +1, bring NLPCraft into Incubator
   [ ] +0, I don't care either way
   [ ] -1, do not bring NLPCraft into Incubator, because...

The vote will open for at least 72 hours until midnight PDT Wednesday, Feb 13,
2020. As a reminder: only votes from the IPMC members are considered binding,
but other votes are welcome!


[1] https://cwiki.apache.org/confluence/display/INCUBATOR/NLPCraftProposal
[2] https://s.apache.org/me4ut

Thank you,
   Cos




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Accept NLPCraft into Apache Incubator

[Konstantin Boudnik]

Hello.

As the discussion of NLPCraft proposal [1] has been wrapped up [2] I would like
to call a VOTE to accept this project into the Apache Incubator.

Please cast your vote:

  [ ] +1, bring NLPCraft into Incubator
  [ ] +0, I don't care either way
  [ ] -1, do not bring NLPCraft into Incubator, because...

The vote will open for at least 72 hours until midnight PDT Wednesday, Feb 13,
2020. As a reminder: only votes from the IPMC members are considered binding,
but other votes are welcome!


[1] https://cwiki.apache.org/confluence/display/INCUBATOR/NLPCraftProposal
[2] https://s.apache.org/me4ut

Thank you,
  Cos




signature.asc
Description: PGP signature

Re: [DISCUSS] NLPCraft Proposal

[Konstantin Boudnik]

Looks like the discussion is winding down a bit. So, to sum it up:

- CC shall be removed during code transfer to ASF
- an SGA will be expected from DataLingvo
- as the original NLPCraft developers from DataLingvo are all a part of
  NLPCraft project there is no need for explicit copyright transfer
  permission from them (or at least this is how I understand the
  situation)

Anything else I haven't covered (sorry, the thread was a bit of 
asynchronous and I might have missed some points).


Thanks,
  Cos

On 2/5/20 6:44 PM, Justin Mclean wrote:

Hi,


NLPCraft came originally from DataLingvo.


OK so that clarifies that there is code developed by DataLingvo in this code 
base.


During migration, some DataLingvo artefacts weren't properly
renamed (it should be fixed by now).


I would question why they were “renamed”, while you’re not an ASF project yet 
please see [1] for future expectations. ASF policy is generally to not remove 
3rd party headers.


Just to be clear - NLPCraft has no
affiliation with DataLingvo of any kind (beyond the original roots) nor it
is a legal entity; it's just a project name.


You mentioned all the original developers from DataLingvo worked on NLPCraft. 
Is this still the case? Are any of them initial committers? Will all people who 
worked on the original DataLingvo code base be signing ICLAs?


If required, DataLingvo will execute SGA (as it already open-sourced it
with ASL 2.0 license two years ago). Please advise.


I think that would be best.

Thanks,
Justin

1. https://www.apache.org/legal/src-headers.html#3party
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] NLPCraft Proposal

[Konstantin Boudnik]

Thanks for the offer Furkan. While we have a pretty packed house 
already, I think we can find a spot for one more ;)


Welcome! I will update the proposal to reflect this.

--
  Cos

On 2/4/20 5:45 AM, Furkan KAMACI wrote:

Hi,

I've checked your proposal, website, and blog posts and seems promising! I
can help as a mentor if needed too.

Kind Regards,
Furkan KAMACI


On Tue, Feb 4, 2020 at 1:21 PM Paul King  wrote:


All sounds good to me.

On Tue, Feb 4, 2020 at 4:30 PM Nikita Ivanov  wrote:


Hi Paul,
I'm one of the NLPCraft project members, let me chime in here.

1. The project is very interested in native Groovy/Kotlin/Scala model
APIs. It is a bit unclear for now how much work needs to be done
specifically for these languages given that NLPCraft provides a very

plain

(and Scala-friendly) Java APIs. I think it deserves a separate deep
conversation.
2. The topic of Commons Clause (with ALV2) is very clear - if and when

the

project enters the ASF Incubator the license will change to plain Apache
License, v2.0. There's no disagreement on this among project members.
Thanks!
--
Nikita Ivanov


On Mon, Feb 3, 2020 at 9:35 PM Paul King  wrote:


Looks like you have close to a full house for mentors. I could certainly
put my hat in the ring if you need another, otherwise I will certainly

be

an interested community member. It seems like an interesting project. I
would have a particular interest in Groovy/Micronaut integration.

I did notice in the current repo, usage of the Commons Clause (with

ALV2).

The usage by Redis of something similar, albeit with notable

differences,

was controversial a little while back but seemed to die down as per
LEGAL-402. As someone who hasn't been following this lately, is that
something the project needs to manage expectations for?

Cheers, Paul.


On Tue, Feb 4, 2020 at 10:43 AM Konstantin Boudnik 
wrote:


Good time of the time to all!

I'd like to bring this new interesting project for the discussion,

comments

and feedback with the aim of starting a formal [VOTE] of its

acceptance

into
Incubator.

People behind this project aren't new to Apache: some of them were

behind

the
Apache Ignite incubation, which I consider a huge success as the

community

is
literally thriving almost 5 years after the graduation.

I have been involved a little bit with this project when it just

started

privately a few years ago. And I'd like to emphasize that the

community

however small it might look so far, has been aligned with Apache ways

of

doing
things. Nikita Ivanov (from Ignite PMC) is very instrumental in

tirelessly

helping this group to learn what it means to be a truly open source
project.

The code is already under ALv2 and is publicly available. As you will

see

it
has a lot of organic connections with the rest of Apache ecosystem and

IMO

will fit very well here and continue to grow the community.

The project's proposal is available at [1].

Thank you very much for the feedback you're willing to provide!
--
   With best regards,
 Cos

[1]

https://cwiki.apache.org/confluence/display/INCUBATOR/NLPCraftProposal


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] NLPCraft Proposal

[Konstantin Boudnik]

Paul, I think five is the charm! Groovy has been my favorite language for near
a decade so I would love you to join the group of mentors. And I think I am
expressing the unspoken consensus of the rest of us :) So, welcome!

As for the use of Commons Clause: thanks for the good catch. Let's look into
this issue and make necessary adjustments if needed.

--
  Cos

On Tue, Feb 04, 2020 at 03:34PM, Paul King wrote:
> Looks like you have close to a full house for mentors. I could certainly
> put my hat in the ring if you need another, otherwise I will certainly be
> an interested community member. It seems like an interesting project. I
> would have a particular interest in Groovy/Micronaut integration.
> 
> I did notice in the current repo, usage of the Commons Clause (with ALV2).
> The usage by Redis of something similar, albeit with notable differences,
> was controversial a little while back but seemed to die down as per
> LEGAL-402. As someone who hasn't been following this lately, is that
> something the project needs to manage expectations for?
> 
> Cheers, Paul.
> 
> 
> On Tue, Feb 4, 2020 at 10:43 AM Konstantin Boudnik  wrote:
> 
> > Good time of the time to all!
> >
> > I'd like to bring this new interesting project for the discussion, comments
> > and feedback with the aim of starting a formal [VOTE] of its acceptance
> > into
> > Incubator.
> >
> > People behind this project aren't new to Apache: some of them were behind
> > the
> > Apache Ignite incubation, which I consider a huge success as the community
> > is
> > literally thriving almost 5 years after the graduation.
> >
> > I have been involved a little bit with this project when it just started
> > privately a few years ago. And I'd like to emphasize that the community
> > however small it might look so far, has been aligned with Apache ways of
> > doing
> > things. Nikita Ivanov (from Ignite PMC) is very instrumental in tirelessly
> > helping this group to learn what it means to be a truly open source
> > project.
> >
> > The code is already under ALv2 and is publicly available. As you will see
> > it
> > has a lot of organic connections with the rest of Apache ecosystem and IMO
> > will fit very well here and continue to grow the community.
> >
> > The project's proposal is available at [1].
> >
> > Thank you very much for the feedback you're willing to provide!
> > --
> >   With best regards,
> > Cos
> >
> > [1] https://cwiki.apache.org/confluence/display/INCUBATOR/NLPCraftProposal
> >


signature.asc
Description: PGP signature

Re: [DISCUSS] NLPCraft Proposal

[Konstantin Boudnik]

Dave,

appreciate the offer - having someone of your caliber on the team is a huge
help. I will update the proposal shortly!

Welcome and thank you!
--
  Cos

On Mon, Feb 03, 2020 at 04:59PM, Dave Fisher wrote:
> This is very interesting. You’ve got a good set of mentors!
> 
> If you are looking for a fourth mentor then I volunteer if you are interested.
> 
> Regards,
> Dave
> 
> > On Feb 3, 2020, at 4:43 PM, Konstantin Boudnik  wrote:
> > 
> > Good time of the time to all!
> > 
> > I'd like to bring this new interesting project for the discussion, comments
> > and feedback with the aim of starting a formal [VOTE] of its acceptance into
> > Incubator.
> > 
> > People behind this project aren't new to Apache: some of them were behind 
> > the
> > Apache Ignite incubation, which I consider a huge success as the community 
> > is
> > literally thriving almost 5 years after the graduation.
> > 
> > I have been involved a little bit with this project when it just started
> > privately a few years ago. And I'd like to emphasize that the community
> > however small it might look so far, has been aligned with Apache ways of 
> > doing
> > things. Nikita Ivanov (from Ignite PMC) is very instrumental in tirelessly
> > helping this group to learn what it means to be a truly open source project.
> > 
> > The code is already under ALv2 and is publicly available. As you will see it
> > has a lot of organic connections with the rest of Apache ecosystem and IMO
> > will fit very well here and continue to grow the community.
> > 
> > The project's proposal is available at [1]. 
> > 
> > Thank you very much for the feedback you're willing to provide!
> > --
> >  With best regards,
> >Cos
> > 
> > [1] https://cwiki.apache.org/confluence/display/INCUBATOR/NLPCraftProposal 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: PGP signature

[DISCUSS] NLPCraft Proposal

[Konstantin Boudnik]

Good time of the time to all!

I'd like to bring this new interesting project for the discussion, comments
and feedback with the aim of starting a formal [VOTE] of its acceptance into
Incubator.

People behind this project aren't new to Apache: some of them were behind the
Apache Ignite incubation, which I consider a huge success as the community is
literally thriving almost 5 years after the graduation.

I have been involved a little bit with this project when it just started
privately a few years ago. And I'd like to emphasize that the community
however small it might look so far, has been aligned with Apache ways of doing
things. Nikita Ivanov (from Ignite PMC) is very instrumental in tirelessly
helping this group to learn what it means to be a truly open source project.

The code is already under ALv2 and is publicly available. As you will see it
has a lot of organic connections with the rest of Apache ecosystem and IMO
will fit very well here and continue to grow the community.
 
The project's proposal is available at [1]. 

Thank you very much for the feedback you're willing to provide!
--
  With best regards,
Cos

[1] https://cwiki.apache.org/confluence/display/INCUBATOR/NLPCraftProposal 


signature.asc
Description: PGP signature

Re: [RESULT] [VOTE] Accept DLab into the Apache Incubator

[Konstantin Boudnik]

Cool, would be happy to help! 
--
Regards,
  Cos

On August 20, 2018 10:25:32 PM GMT+03:00, "P. Taylor Goetz"  
wrote:
>Awesome. Thanks Cos. I’ll add you as a mentor.
>
>-Taylor
>
>> On Aug 20, 2018, at 2:11 PM, Konstantin Boudnik 
>wrote:
>> 
>> Looks like I am bit late and vote is closed, but I still want to cast
>> my +1 - I have helped this project during my time at EPAM and wish it
>> all the success!
>> 
>> If the project needs more mentors at this point - I have some spare
>> cycles to burn.
>> 
>> Thanks!
>> --
>>  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 Mon, Aug 20, 2018 at 6:13 PM, P. Taylor Goetz 
>wrote:
>>> The 72 hour voting period has elapsed, and with 4 binding +1 votes
>and no -1 or 0 votes this vote passes.
>>> 
>>> Vote tally (* indicates a binding vote):
>>> 
>>> +1:
>>> - Dave Fisher*
>>> - Ted Dunning*
>>> - P. Taylor Goetz*
>>> - Matt Sicker*
>>> 
>>> Thanks to all who voted. I will begin the bootstrapping process
>shortly.
>>> 
>>> -Taylor
>>> 
>>>> On Aug 15, 2018, at 12:27 PM, P. Taylor Goetz 
>wrote:
>>>> 
>>>> After a brief discussion [1] I would like to call a VOTE to accept
>DLab into the Apache Incubator. The full proposal is available on the
>wiki[2] and is pasted below in text form as well.
>>>> 
>>>> This vote will run at least 72 hours. Please VOTE as follows:
>>>> 
>>>> [ ] +1 Accept DLab into the Apache Incubator
>>>> [ ] +0 No opinion
>>>> [ ] -1 Do not accept DLab into the Apache Incubator because…
>>>> 
>>>> -Taylor
>>>> 
>>>> [1]
>https://lists.apache.org/thread.html/9c96873d49f53da33260e21dc698f7c9b82eec256caf97a0e3f54943@%3Cgeneral.incubator.apache.org%3E
>>>> [2] https://wiki.apache.org/incubator/DLabProposal
>>>> 
>>>> 
>>>> = DLab Proposal =
>>>> 
>>>> == Abstract ==
>>>> DLab is a platform for creating self-service, exploratory data
>science environments in the cloud using best-of-breed data science
>tools.
>>>> 
>>>> DLab includes a self-service web console, used to create and manage
>exploratory environments. It allows teams to spin up analytical
>environments with just a single click of a mouse. Once established, the
>environment can be managed by an analytical team itself, leveraging
>simple and easy-to-use web-based interface.
>>>> 
>>>> == Proposal ==
>>>> In order to work effectively, data scientists rely on a varying
>suite of analytics tools that are readily available. However, many of
>those tools are non-trivial to set up in terms of hardware
>provisioning, software installation, configuration, and deployment.
>Setting up a collaborative, multi-tenant development environment for
>data scientists consumes substantial IT and DevOps resources, as well
>as time. These factors often combine to hinder the agility and
>effectiveness of data science teams within an organization. Current
>solutions are largely closed source and/or proprietary, and committing
>to a given solution introduces the potential for vendor lock-in.
>>>> 
>>>> EPAM Systems developed DLab in response to the lack of open source,
>permissibly licensed solutions to better enable data science workflows.
>The ALv2 was selected to encourage open development and user adoption.
>DLab was open sourced on Dec 29, 2016 and is under active development
>with support from EPAM Systems.
>>>> 
>>>> We believe DLab is a unique solution with no current open source
>equivalent. Our primary goals of incubation are to grow and diversify
>the DLab community to ensure its long-term sustainability.
>>>> 
>>>> == Rationale ==
>>>> DLab is a platform that provides data scientists with the ability
>to self-provision, without IT support, exploratory and production
>environments with their preferred set of tools installed and
>pre-configured. Tool options include, but are not limited to:
>>>> 
>>>> * Apache Spark
>>>> * Apache Flink (planned)
>>>> * Apache Zeppelin
>>>> * Jupyter
>>>> * TensorFlow + Jupyter
>>>> *

Re: [RESULT] [VOTE] Accept DLab into the Apache Incubator

[Konstantin Boudnik]

Looks like I am bit late and vote is closed, but I still want to cast
my +1 - I have helped this project during my time at EPAM and wish it
all the success!

If the project needs more mentors at this point - I have some spare
cycles to burn.

Thanks!
--
  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 Mon, Aug 20, 2018 at 6:13 PM, P. Taylor Goetz  wrote:
> The 72 hour voting period has elapsed, and with 4 binding +1 votes and no -1 
> or 0 votes this vote passes.
>
> Vote tally (* indicates a binding vote):
>
> +1:
> - Dave Fisher*
> - Ted Dunning*
> - P. Taylor Goetz*
> - Matt Sicker*
>
> Thanks to all who voted. I will begin the bootstrapping process shortly.
>
> -Taylor
>
>> On Aug 15, 2018, at 12:27 PM, P. Taylor Goetz  wrote:
>>
>> After a brief discussion [1] I would like to call a VOTE to accept DLab into 
>> the Apache Incubator. The full proposal is available on the wiki[2] and is 
>> pasted below in text form as well.
>>
>> This vote will run at least 72 hours. Please VOTE as follows:
>>
>> [ ] +1 Accept DLab into the Apache Incubator
>> [ ] +0 No opinion
>> [ ] -1 Do not accept DLab into the Apache Incubator because…
>>
>> -Taylor
>>
>> [1] 
>> https://lists.apache.org/thread.html/9c96873d49f53da33260e21dc698f7c9b82eec256caf97a0e3f54943@%3Cgeneral.incubator.apache.org%3E
>> [2] https://wiki.apache.org/incubator/DLabProposal
>>
>>
>> = DLab Proposal =
>>
>> == Abstract ==
>> DLab is a platform for creating self-service, exploratory data science 
>> environments in the cloud using best-of-breed data science tools.
>>
>> DLab includes a self-service web console, used to create and manage 
>> exploratory environments. It allows teams to spin up analytical environments 
>> with just a single click of a mouse. Once established, the environment can 
>> be managed by an analytical team itself, leveraging simple and easy-to-use 
>> web-based interface.
>>
>> == Proposal ==
>> In order to work effectively, data scientists rely on a varying suite of 
>> analytics tools that are readily available. However, many of those tools are 
>> non-trivial to set up in terms of hardware provisioning, software 
>> installation, configuration, and deployment. Setting up a collaborative, 
>> multi-tenant development environment for data scientists consumes 
>> substantial IT and DevOps resources, as well as time. These factors often 
>> combine to hinder the agility and effectiveness of data science teams within 
>> an organization. Current solutions are largely closed source and/or 
>> proprietary, and committing to a given solution introduces the potential for 
>> vendor lock-in.
>>
>> EPAM Systems developed DLab in response to the lack of open source, 
>> permissibly licensed solutions to better enable data science workflows. The 
>> ALv2 was selected to encourage open development and user adoption. DLab was 
>> open sourced on Dec 29, 2016 and is under active development with support 
>> from EPAM Systems.
>>
>> We believe DLab is a unique solution with no current open source equivalent. 
>> Our primary goals of incubation are to grow and diversify the DLab community 
>> to ensure its long-term sustainability.
>>
>> == Rationale ==
>> DLab is a platform that provides data scientists with the ability to 
>> self-provision, without IT support, exploratory and production environments 
>> with their preferred set of tools installed and pre-configured. Tool options 
>> include, but are not limited to:
>>
>> * Apache Spark
>> * Apache Flink (planned)
>> * Apache Zeppelin
>> * Jupyter
>> * TensorFlow + Jupyter
>> * Deep Learning + Jupyter
>>
>> DLab leverages cloud computing providers for virtual hardware provisioning 
>> and currently supports the following:
>>
>> * Amazon Web Services (AWS)
>> * Microsoft Azure
>> * Google Compute Platform (GCP) (under development)
>>
>> DLab offers git-based collaboration tools for data scientists and developers 
>> and integrates with the following git service providers:
>>
>> * GItHub
>> * GitLab
>> * BitBucket
>>
>> Additionally, DLab includes the option to configure the UnGit tool in an 
>> environment to facilitate collaboration.
>> Finally, DLab integrates closely with many security and SSO offerings, 
>> including:
>>
>> * LDAP
>> * Microsoft Active Directory
>> * AWS Identity Access Management service
>>
>> DLab was designed from the ground up to be highly configurable, flexible, 
>> and extensible platform. We believe these qualities will encourage community 
>> growth by enabling contributors to easily add new integrations and 
>> extensions.
>>
>> == Initial Goals ==
>> The initial goal will be to move the existing codebase to Apache and 
>> integrate with the Apache development process and infrastructure. A primary 
>> goal of incubation 

Re: [VOTE]: Apache HAWQ 2.3.0.0-incubating Release

[Konstantin Boudnik]

+1 [biding]

- signature check [ok]
- checksum check [ok]
- licenses check (RAT) [ok]

I haven't tried to build it because of the complexity of the build
process and multiplicity of the environment configurations. To lower
the entry barrier, I would recommend the community to think how to
wrap these steps into the build system. You can go as far as to
provide an "official" toolchain for the project. In Bigtop, we even
provide official Docker containers were people can start working with
the project in under 2 minutes and without any need for additional
error prone configuration steps.
--
  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 Tue, Mar 6, 2018 at 6:56 PM, Yi JIN  wrote:
> Hi IPMC members,
>
> The PPMC vote for the Apache HAWQ 2.3.0.0-incubating release has passed.
> So I request IPMC now to vote on this release candidate. Thank you!
>
> The release page is here:
> https://cwiki.apache.org/confluence/display/HAWQ/Apache+HAWQ+2.3.0.0-incubating+Release
>
> The PPMC vote thread is located here:
> https://lists.apache.org/thread.html/fa5b41cd7461bd729146e10d8f7a54156c818f93e5a1160c42e76c79@%3Cdev.hawq.apache.org%3E
>
> The artifacts can be downloaded here:
> https://dist.apache.org/repos/dist/dev/incubator/hawq/2.3.0.0-incubating.RC2/
> The artifacts have been signed with Key : CE60F90D1333092A
>
> All JIRAs completed for this release are tagged with 'FixVersion
> =2.3.0.0-incubating'
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12340262=Html=12318826
>
> Please vote accordingly:
> [ ] +1, accept as the official Apache HAWQ 2.3.0.0-incubating release
> [ ] -1, do not accept as the official Apache HAWQ 2.3.0.0-incubating release
> because...
>
> The vote will run for at least 72 hours.
>
> Best regards,
> Yi Jin (yjin)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Konstantin Boudnik]

While I am completely agree with your point, and the Ignite graduation
is the water under the bridge, this is in an important point for the
current podlings to consider. Perhaps it could be done elsewhere as
well, but I am not sure where would be the best place for it.
Thoughts?

Thanks,
  Cos
--
  Take care,
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 Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  wrote:
> While these are all great discussion points, I don't believe they're
> relevant to incubator only and probably should have remained on the
> legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
> doesn't have an opinion about this, but it's good to know that the policy
> may change (and I do personally have an opinion on said types of software).
>
> John
>
> On Mon, Jun 5, 2017 at 11:16 PM Roman Shaposhnik 
> wrote:
>
>> On Mon, Jun 5, 2017 at 8:02 PM, Julian Hyde  wrote:
>> > Thanks for the explanation, Roman. I had no idea that policies for
>> hosted binaries
>> > were stricter than for source code (other than the obvious effect on
>> licensing when you bundle in dependencies).
>>
>> Btw, this one is serious enough that I'd like us to update our release
>> policy based on the
>> learnings here.
>>
>> So far it seems that there's an agreement on that having this type of
>> capability...
>>1 ... in the source code disabled by default -- totally OK
>>2 ... in the source code enabled by default -- questionable, but OK
>>3 ... in the binary hosted by ASF disabled by default -- OK
>>4 ... in the binary hosted by ASF enabled by default -- NOT OK
>>
>> #4 can get nuanced if we want to invest in ASF managed infrastructure that
>> is
>> responsible for update tracking and user data collection. With my ASF hat
>> on,
>> I'd say that INFRA should probably stay away from user data
>> collection/retention.
>>
>> That still leaves a possibility of a a ping/pong API that only
>> consumes a name of ASF
>> project and its version and returns a JSON object of some kind as per
>> PMC choice.
>>
>>
>> Thanks,
>> Roman.
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Konstantin Boudnik]

Thanks Greg. I have already started the conversation on private@ignite
and opened IGNITE-5413
--
  Take care,
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 Mon, Jun 5, 2017 at 7:36 PM, Greg Stein  wrote:
> The Infrastructure team is taking this to the Apache Ignite PMC. This is
> completely improper.
>
> On Mon, Jun 5, 2017 at 9:34 PM, Julian Hyde  wrote:
>
>> If the binaries are built from the released source code I don’t think we
>> should restrict what the binaries do. The question is whether the community
>> is aware of what the code is doing, and considers it to be in the best
>> interests of the project.
>>
>> The answer seems to be yes, and yes. I saw that the issue was discussed on
>> dev@ignite[1], and had a corresponding JIRA case[2], and no objections
>> were raised. If anyone has problems with that behavior (including security
>> bugs) they should raise it with Ignite's PMC.
>>
>> Julian
>>
>> [1] https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
>> 3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%3E <
>> https://mail-archives.apache.org/mod_mbox/ignite-dev/201504.mbox/%
>> 3ccalv17qod61yu63__cs9ekgu+kvxhppkxmpagndonrz1t8_t...@mail.gmail.com%3E>
>>
>> [2] https://issues.apache.org/jira/browse/IGNITE-775 <
>> https://issues.apache.org/jira/browse/IGNITE-775>
>>
>>
>>
>> > On Jun 5, 2017, at 6:48 PM, Roman Shaposhnik 
>> wrote:
>> >
>> > Hi!
>> >
>> > after seeing this thread on legal-discuss:
>> >https://mail-archives.apache.org/mod_mbox/www-legal-
>> discuss/201706.mbox/%3CCAGJoAUn-hiE89mWObh1Lb2S_vgqQJ%3DDC%3D1P_
>> V1REQ9hUERCFog%40mail.gmail.com%3E
>> >
>> > I'd like to ask a policy related question.
>> >
>> > What we currently have is a whole bunch of binaries hosted
>> > by ASF: https://ignite.apache.org/download.cgi#binaries that
>> > collect user data and ship it away to a host currently not
>> > associated with ASF (nor does it seem to be associated with
>> > Ignite's PMC). The host name is ignite.run (and, as a side note,
>> > as it turns out the connection to that host in Ignite releases prior
>> > to 1.9 is unsecure:
>> >   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6805
>> > )
>> >
>> > Is this something ASF should be concerned with from a standpoint
>> > of the policy that we have for binary convenience artifacts that are
>> > hosted on our end?
>> >
>> > Would it make it different if ignite.run and the data collected
>> > by it was managed by an Ignite PMC as opposed to an unidentified
>> > 3d party?
>> >
>> > Thanks,
>> > Roman.
>> >
>> > -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional commands, e-mail: general-h...@incubator.apache.org
>> >
>>
>>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Apache MADlib podling

[Konstantin Boudnik]

+1 [binding]

On Sat, May 27, 2017 at 04:56PM, FENG, Xixuan (Aaron) wrote:
> Greetings IPMC!
> 
> The discussion seems to have died down, so I'm calling the
> vote:  I propose that we graduate Apache MADlib from the Incubator.
> The full text of the proposal is below.  The discuss thread can be found
> here:
> https://lists.apache.org/thread.html/535f9871636f6e10c13e47f1ec6e41
> 5eca7f666e1580d8b762d8a42d@%3Cgeneral.incubator.apache.org%3E
> 
> Please vote on the resolution:
> 
> [ ] +1 Graduate Apache MADlib from the Incubator.
> [ ] +0 No opinion
> [ ] -1 Don't graduate Apache MADlib from the Incubator (please provide
> the reason)
> 
> This VOTE will be opened for the next 72 hours.
> 
> Thanks to all Mentors and Apache MADlib Project members for their
> support and contributions.
> 
> Thanks,
> Aaron.
> 
> Resolution:
> 
> Establish the Apache MADlib Project
> 
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to the
> public, related to a scalable, Big Data, SQL-driven machine
> learning framework for Data Scientists.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache MADlib Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
> 
> RESOLVED, that the Apache MADlib Project be and hereby is
> responsible for the creation and maintenance of software
> related to a scalable, Big Data, SQL-driven machine
> learning framework for Data Scientists.
> 
> RESOLVED, that the office of "Vice President, Apache MADlib" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache MADlib Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache MADlib Project; and be it further
> 
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache MADlib Project:
> 
> Sarah Aerni 
> Greg Chase 
> Aaron Feng 
> Rahul Iyer 
> Jim Jagielski 
> Nandish Jayaram 
> Anirudh Kondaveeti 
> Orhan Kışlal 
> Frank McQuillan 
> Srivatsan R 
> Rashmi Raghu 
> Roman Shaposhnik 
> Atri Sharma 
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Aaron Feng
> be appointed to the office of Vice President, Apache MADlib, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
> 
> RESOLVED, that the initial Apache MADlib PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache MADlib Project; and be it further
> 
> RESOLVED, that the Apache MADlib Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator MADlib podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator MADlib podling encumbered upon the Apache Incubator
> Project are hereafter discharged.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] MADlib v1.11-rc3

[Konstantin Boudnik]

+1 [binding]

- checked the RAT, build, NOTICE
- checked the signature, and sha512

Concern: Apache git is the primary source of the code for the release. To me,
it is more credible when you point to the commit is on the Apache server,
rather than a github.

Thanks,
  Cos

On Wed, May 10, 2017 at 12:44AM, Rashmi Raghu wrote:
> Hello Incubator PMC,
> 
> The Apache MADlib (incubating) community has voted on and approved the
> proposal to release MADlib v1.11-rc3.
> 
> The voting result is available at:
> http://mail-archives.apache.org/mod_mbox/incubator-madlib-dev/201705.mbox/%3CCAMtNjo%3Dwq0qQmJRTqAnef%2BtuTawXm508pQmLAcvWho0fOfkEmQ%40mail.gmail.com%3E
> 
> This will be the 5th release for Apache MADlib (incubating).
> 
> The main goals of this release are:
> * new module (PageRank for graph analytics with grouping support included)
> * improvements to existing modules (add grouping support to Single Source
> Shortest Path, reduce memory footprint of DT and RF, include NULL features
> in training DT, add support for array and svec output for Pivot module,
> utility to unnest 2-D arrays into rows of 1-D arrays)
> * platform updates (GPDB 5)
> * updates for Apache Top Level Project readiness and build process on
> Apache infrastructure
> * bug fixes
> * doc improvements
> 
> For more information including release notes, please see:
> https://cwiki.apache.org/confluence/display/MADLIB/MADlib+1.11
> 
> To run check RAT, please do:
> 
> $mvn verify
> 
> first to get the correct RAT output.  Look inside of pom.xml to see the
> classes of exceptions we're managing there for RAT.
> 
> We're voting upon the source and convenience binaries below:
> 
> Source Repository (tag):  rc/1.11-rc3
> https://github.com/apache/incubator-madlib/tree/rc/1.11-rc3
> 
> Source Files and convenience Binaries:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/1.11-incubating-rc3/
> 
> Commit:
> https://github.com/apache/incubator-madlib/commit/8e2778a3921aa99f009962756881ce4bea5eee16
> 
> KEYS file containing PGP Keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/KEYS
> 
> For your convenience, the recent ASF licensing guidance to the MADlib
> community is summarized here:
> https://cwiki.apache.org/confluence/display/MADLIB/ASF+Licensing+Guidance
> 
> Please vote:
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> *** The vote will be open until Monday May 15 at 6 pm Pacific time. ***
> 
> Regards,
> Rashmi Raghu
> 
> -- 
> Rashmi Raghu, Ph.D.
> Pivotal Data Science

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] MADlib v1.10-rc2

[Konstantin Boudnik]

+1 [binding]

- signing: ok
- md5: ok (next time, please use the format that can be used for
auto-validation with -c)
- sha: ok (next time, please use the format that can be used for
auto-validation with -c; please rename the suffix to sha512 - it took
me a while to figure out what algo was used)
- rat: ok
- build: ok
- Readme.txt, NOTICE: ok (perhaps renaming Readme.txt to README would
make sense?)

Thanks,
  Cos

--
  Take care,
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 Tue, Mar 7, 2017 at 1:56 PM, Frank McQuillan  wrote:
> Hello Incubator PMC,
>
> The Apache MADlib (incubating) community has voted on and approved the
> proposal to release MADlib v1.10-rc2.
>
> The voting result is available at:
> http://mail-archives.apache.org/mod_mbox/incubator-madlib-dev/201703.mbox/%3CCAKBQfzQ_BeetybM9cOkXd%2BAvGDQY_BM3KMs3d28sH8tPFzDU8Q%40mail.gmail.com%3E
>
> This will be the 4th release for Apache MADlib (incubating).
>
> The main goals of this release are:
> * new modules (single source shortest path for graph analytics, encode
> categorical variables, K-nearest neighbors)
> * improvements to existing modules (add grouping support to elastic
> net and PCA, add cross validation to elastic net, array input for
> K-means, verbose output option for DT and RF, limit itemset size in
> association rules, various madpack installer improvements)
> * platform updates (PostgreSQL 9.6)
> * bug fixes
> * doc improvements
>
> For more information including release notes, please see:
> https://cwiki.apache.org/confluence/display/MADLIB/MADlib+1.10
>
> To run check RAT, please do:
>
> $mvn verify
>
> first to get the correct RAT output.  Look inside of pom.xml to see the
> classes of exceptions we're managing there for RAT.
>
> We're voting upon the source (tag):  rc/1.10.0-rc2
> https://github.com/apache/incubator-madlib/tree/rc/1.10.0-rc2
>
> Source Files:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/1.10.0-incubating-rc2/
>
> Commit to be voted upon:
> https://github.com/apache/incubator-madlib/commit/a3863b6c2407eb28ba007f6288d167bf88674e6d
>
> KEYS file containing PGP Keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/KEYS
>
> For your convenience, the recent ASF licensing guidance to the MADlib
> community is summarized here:
> https://cwiki.apache.org/confluence/display/MADLIB/ASF+Licensing+Guidance
>
> Please vote:
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> *** The vote will be open until Friday Mar 10 at 6 pm Pacific time. ***
>
> Thank you,
> Frank McQuillan

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: SystemML webpage

[Konstantin Boudnik]

Thank you for quick turn around!

Regards,
  Cos
--
  Take care,
Konstantin (Cos) Boudnik


On Thu, Mar 2, 2017 at 11:48 AM, Deron Eriksson <deroneriks...@gmail.com> wrote:
> Thank you for finding this Konstantin. We will take care of this to ensure
> we follow the Apache Incubator guidelines.
>
> Our project documentation pages (
> http://systemml.incubator.apache.org/docs/0.12.0/index.html) include
> "(incubating)" but our main website pages (
> https://systemml.incubator.apache.org/) do not include "(incubating)". We
> will fix this.
>
> Thanks!
> Deron
>
>
> On Thu, Mar 2, 2017 at 8:13 AM, Konstantin Boudnik <c...@apache.org> wrote:
>
>> Hello.
>>
>> I recently came around
>>   https://systemml.incubator.apache.org/
>>
>> and have noticed that the project name doesn't include "(incubating)"
>> tag, which is a requirement for the incubating podlings, IIRC. Can the
>> PPMC address this issue, please?
>>
>> I am Cc'ing general@incubator.apache.org list to make sure this
>> message isn't missed, Of course this isn't a private message.
>> --
>>   Take care,
>> 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.
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>
>
> --
> Deron Eriksson
> Spark Technology Center
> http://www.spark.tc/

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: SystemML webpage

[Konstantin Boudnik]

Hello.

I recently came around
  https://systemml.incubator.apache.org/

and have noticed that the project name doesn't include "(incubating)"
tag, which is a requirement for the incubating podlings, IIRC. Can the
PPMC address this issue, please?

I am Cc'ing general@incubator.apache.org list to make sure this
message isn't missed, Of course this isn't a private message.
--
  Take care,
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.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Apache Geode (incubating)

[Konstantin Boudnik]

+1 [binding]

On Sun, Nov 06, 2016 at 12:58PM, Roman Shaposhnik wrote:
> Hi!
> 
> after a very positive discussion in the Geode community
> and at the IPMC level:
> http://markmail.org/message/z4prj62hr7rn6cu6
> I'd like to bring the following resolution for a formal vote.
> 
> Please vote on the resolution pasted below to graduate
> Apache Geode from the incubator to top level project.
> 
> [ ] +1 Graduate Apache Geode from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Geode from the Incubator because...
> 
> This vote will be open for at least 72 hours.
> 
> Many thanks to our mentors and everyone else for the support,
> Roman (on behalf of the Apache Geode PPMC).
> 
> Resolution:
> 
> Establish the Apache Geode Project
> 
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to the
> public, related to a data management platform that provides
> real-time, consistent access to data-intensive applications
> throughout widely distributed cloud architectures.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Geode Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
> 
> RESOLVED, that the Apache Geode Project be and hereby is
> responsible for the creation and maintenance of software
> related to a data management platform that provides real-time,
> consistent access to data-intensive applications throughout
> widely distributed cloud architectures.
> 
> RESOLVED, that the office of "Vice President, Apache Geode" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache Geode Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Geode Project; and be it further
> 
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Geode Project:
> 
> * Anilkumar Gingade <aging...@apache.org>
> * Anthony Baker <aba...@apache.org>
> * Ashvin Agrawal <ash...@apache.org>
> * Avinash Dongre <adon...@apache.org>
> * Barry Oglesby < bogle...@apache.org>
> * Bruce Schuchardt <bschucha...@apache.org>
> * Dan Smith <upthewatersp...@apache.org>
> * Darrel Schneider <dschnei...@apache.org>
> * Dave Barnes <dbar...@apache.org>
> * Eric Shu <esh...@apache.org>
> * Greg Chase <gregch...@apache.org>
> * Hitesh Khamesra <hiteshkhame...@apache.org>
> * Jason Huynh <jasonhu...@apache.org>
> * Jens Deppe <jensde...@apache.org>
> * Jianxia Chen <jche...@apache.org>
> * Jinmei Liao <jinmeil...@apache.org>
> * John Blum <jxb...@apache.org>
> * Karen Miller <kmil...@apache.org>
> * Konstantin Boudnik <c...@apache.org>
> * Kirk Lund <kl...@apache.org>
> * Mark Bretl <mbr...@apache.org>
> * Nabarun Nag <n...@apache.org>
> * Niall Pemberton <nia...@apache.org>
> * Nitin Lamba <nla...@apache.org>
> * Roman Shaposhnik <r...@apache.org>
> * Sai Boorlagadda <sai_boorlaga...@apache.org>
> * Swapnil Bawaskar <sbawas...@apache.org>
> * Udo Kohlmeyer <u...@apache.org>
> * William Markito <mark...@apache.org>
> * Xiaojian Zhou <zho...@apache.org>
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Bretl
> be appointed to the office of Vice President, Apache Geode, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
> 
> RESOLVED, that the initial Apache Geode PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Geode Project; and be it further
> 
> RESOLVED, that the Apache Geode Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Geode podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Geode podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Apache Geode (incubating)

[Konstantin Boudnik]

Besides, last time I checked there's no such thing as "diversity requirement"
in the graduation.  It is indeed being asked here and there, but so far it
isn't an official IPMC requirement.

And I'd hate to make a "diversity scape-goat" out of the project that has
created a very welcome environment!

Cos
 
On Tue, Nov 08, 2016 at 02:14PM, Roman Shaposhnik wrote:
> On Tue, Nov 8, 2016 at 1:54 PM, Rich Bowen  wrote:
> >
> >
> > On 11/07/2016 10:05 PM, Niall Pemberton wrote:
> >> On Mon, Nov 7, 2016 at 6:34 PM, Daniel Gruno  wrote:
> >>
> >>> > I was looking at Snoot, and some figures jumped at me.
> >>> >
> >>> > Is the Podling (and the IPMC) satisfied that there is no concern with
> >>> > people affiliated with a single company providing more than 90% of all
> >>> > commits over the past year and, as far as I can tell, the vast majority
> >>> > of tickets and email, as well as a 73% stake in the proposed PMC?
> >>> >
> >>> > Is the IPMC satisfied that, should this company opt to not further spend
> >>> > resources on this project, that the project would still be as viable?
> >>> >
> >> Hi Daniel,
> >>
> >> I've observed this project since it joined the incubator and they've worked
> >> hard to create an open and welcoming community and to fix all the issues
> >> raised that could be barriers to their graduation.
> >>
> >> In terms of percentages, these things have been debated previously in
> >> graduation of projects such as Ignite, Flume, Tez etc and I'm not going to
> >> repeat the arguments from those discussions. Geode would be better with
> >> served with a wider community, but I think what matters is 1) have they
> >> demonstrated the behaviors we expect and 2) are they moving in the right
> >> direction. Geode is a great community and a pleasure to be involved with
> >> and I would say yes to both of these. I believe they are going in the right
> >> direction to make this project less dependent on one company and except to
> >> change the percentages you've pointed out, theres no purpose left for them
> >> being in the incubator. They've shown that they can manage themselves and
> >> theres enough independent oversight to mitigate concerns which is why I
> >> think we should vote for them to graduate.
> >
> > Given the discussions around single-vendor projects that are raging on
> > board@ I would have to agree with Daniel's concerns here. Projects that
> > are heavily dominated by a single vendor/company/organization
> > historically cause problems over time.
> 
> I think that other discussion addresses a very different set of problems.
> 
> > Is there a huge rush to get this project graduated?
> 
> I'd rather flip your argument around and say: at this point sitting in the
> Incubator adds no value to the project nor does it teach anything
> new or useful to its PPMC or a community at large.
> 
> > Surely we serve the
> > Foundation, and this project, better, by ensuring that this problem
> > (and, yes, it's a problem) is addressed before we grant them TLP status?
> 
> I disagree. The Incubator is a place to make sure that the community
> (regardless of its composition) truly understands and practices the
> "Apache Way". As has been suggested on this thread by a number of
> votes from project's mentors and IPMC members embedded in the
> Geode community that mission has been accomplished.
> 
> I see no reason to hold the project hostage over the diversity requirement
> simply because it is pointless for IPMC, project and the foundation.
> 
> > I'm personally less concerned with the sustainability of the project
> > should the company opt out of working on the project, and more concerned
> > with the kind of monoculture "we own it" problems that we're starting to
> > see crop up in other projects that were allowed to graduate without
> > building the community first.
> 
> Then you really should be voting "yes" on this thread. There's a good number
> of us on IPMC who believe that "we own it" is really not a problem with this
> community.
> 
> Thanks,
> Roman.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Graduate Apache Geode (incubating) as a TLP

[Konstantin Boudnik]

gt; hereby are appointed to serve as the initial members of the
> Apache Geode Project:
> 
> * Anilkumar Gingade <aging...@apache.org>
> * Anthony Baker <aba...@apache.org>
> * Ashvin Agrawal <ash...@apache.org>
> * Avinash Dongre <adon...@apache.org>
> * Barry Oglesby < bogle...@apache.org>
> * Bruce Schuchardt <bschucha...@apache.org>
> * Dan Smith <upthewatersp...@apache.org>
> * Darrel Schneider <dschnei...@apache.org>
> * Dave Barnes <dbar...@apache.org>
> * Eric Shu <esh...@apache.org>
> * Greg Chase <gregch...@apache.org>
> * Hitesh Khamesra <hiteshkhame...@apache.org>
> * Jason Huynh <jasonhu...@apache.org>
> * Jens Deppe <jensde...@apache.org>
> * Jianxia Chen <jche...@apache.org>
> * Jinmei Liao <jinmeil...@apache.org>
> * John Blum <jxb...@apache.org>
> * Karen Miller <kmil...@apache.org>
> * Konstantin Boudnik <c...@apache.org>
> * Kirk Lund <kl...@apache.org>
> * Mark Bretl <mbr...@apache.org>
> * Nabarun Nag <n...@apache.org>
> * Niall Pemberton <nia...@apache.org>
> * Nitin Lamba <nla...@apache.org>
> * Roman Shaposhnik <r...@apache.org>
> * Sai Boorlagadda <sai_boorlaga...@apache.org>
> * Swapnil Bawaskar <sbawas...@apache.org>
> * Udo Kohlmeyer <u...@apache.org>
> * William Markito <mark...@apache.org>
> * Xiaojian Zhou <zho...@apache.org>
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Mark Bretl
> be appointed to the office of Vice President, Apache Geode, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
> 
> RESOLVED, that the initial Apache Geode PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Geode Project; and be it further
> 
> RESOLVED, that the Apache Geode Project be and hereby
> is tasked with the miization of the Apache
> Incubator Geode podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Geode podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Geode (incubating) 1.0.0-incubating.M3 release

[Konstantin Boudnik]

+1 (binding)

- archive enames: ok
- keys  : ok
- signatures and hashes : ok
- binary archive's content and DISCLAIMER, LICENSE and NOTICE   : ok
- source archive's content and DISCLAIMER, LICENSE and NOTICE   : ok
- build from source : ok

Thanks,
  Cos

On Tue, Aug 09, 2016 at 06:24PM, William Markito wrote:
> Hello Incubator IPMC,
> 
> This is a call for a vote on the Apache Geode (incubating) release
> 1.0.0-incubating.M3.
> 
> This release candidate, 1.0.0-incubating.M2.RC7, has successfully passed a
> vote for a release on the Apache Geode developer mailing list.
> 
> Vote thread:
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201608.mbox/%
> 3CCAK7stcwXW9a4yV4ehxDf6gJMzoNTBaeaXvXZVDSAQhGvjtiY9Q%40mail.gmail.com%3E
> 
> Results:
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201608.mbox/%
> 3CCAK7stcwtOvE1ctfDY8EAUEN3varUgNG5DWUzg9YoiL5GwncPiQ%40mail.gmail.com%3E
> 
> It fixes the following issues:
>https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12318420=12335358
> 
> 
> Note that we are voting upon the source (tag):
>rel/v1.0.0-incubating.M3.RC7
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=tag;h=refs/tags/rel/v1.0.0-incubating.M3.RC7
> 
> Commit ID: 83f97ceef52febf92ef7737726548aa0865c1a59
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=commit;h=83f97ceef52febf92ef7737726548aa0865c1a59
> 
> Source and binary
> files:https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.0-incubating.M3.RC7
> 
> For this release the documentation on how to install and use Apache Geode
> are hosted on pivotal.io:
>http://geode.docs.pivotal.io
> 
> 
> Maven staging 
> repo:https://repository.apache.org/content/repositories/orgapachegeode-1011
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
>https://github.com/apache/incubator-geode/blob/release/
> 1.0.0-incubating.M3/KEYS
> 
> Release Key: pub  4096R/7AAED8BB 2016-07-13
> Fingerprint: 8E06 B711 DB13 3AE7 0CC1  ABDE 6A14 F0BC 7AAE D8BB
> 
> Please vote on releasing this package as Apache Geode 1.0.0-incubating.M3:
> 
> This vote will be open for 72 hours or until necessary number of
> votes.
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> Thanks!
> 
> -- 
> ~/William on behalf of the Apache Geode (incubating) team

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Geode (incubating) 1.0.0-incubating.M2

[Konstantin Boudnik]

+1 [biding]

Signature is good
sha256 is good
release tar content matches the commit
build works out of the source code

Minor stuff on top of Justin's detailed analysis:
  - suffix for sha256 file is better be sha256, looks confusing otherwise
  - the file itself isn't properly formatted, which prevents automatic checksum
validation with 'sha256sum -c'
  - make sure to have your keys signed by others, so they are a part of wider
WOT

Cos

On Mon, Apr 18, 2016 at 12:08PM, Dan Smith wrote:
> Hello Incubator PMC,
> 
> This is a call for a vote on the Apache Geode (incubating) release
> 1.0.0-incubating.M2.
> 
> This release candidate, 1.0.0-incubating.M2.RC2, has successfully passed a
> vote for a release
> on the geode developer mailing list.
> 
> Vote thread:
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201604.mbox/%3CCAFh%2B7k12K%2B2G%2BbPktOwrSs-9CFc_W2%2BKS%3DyE%2BxTXt_AFfjeQWQ%40mail.gmail.com%3E
> 
> Results:
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201604.mbox/%3CCAFh%2B7k1Bm0XstRZexAUhket1k3sKeP_vMP5T%2Bmrr7QV1j7-t9Q%40mail.gmail.com%3E
> 
> It fixes the following issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12334709
> 
> Release candidate tag:
> rel/v1.0.0-incubating.M2.RC2
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=tag;h=refs/tags/rel/v1.0.0-incubating.M2.RC2
> 
> Commit ID: 3ac74a4e2c72677ef7c85df77922c645c7cce598
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=commit;h=3ac74a4e2c72677ef7c85df77922c645c7cce598
> 
> Source and binary files:
> https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.0-incubating.M2.RC2/
> 
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1004/
> 
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=blob_plain;f=KEYS;hb=refs/heads/release/1.0.0-incubating.M2
> 
> Release Key: pub   4096R/A1688D97 2016-01-20
> Fingerprint: 1776 0439 68F0 FD83 62C7  2CCF 444C 1D20 A168 8D97
> 
> Please vote on releasing this package as Apache Geode 1.0.0-incubating.M2:
> 
> This vote will be open for 72 hours.
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> Thanks!
> Dan on behalf of the Apache Geode (incubating) team


signature.asc
Description: Digital signature

Re: [VOTE] Graduate Zeppelin from the Incubator

[Konstantin Boudnik]

+1 [binding]

On Sat, Apr 16, 2016 at 09:01AM, moon soo Lee wrote:
> Hi,
> 
> Apache Zeppelin started incubating about a year and 4 months ago
> (2014-12-23) and the members of the community think that it is ready to
> graduate from the incubator to be a TLP.
> 
> Since it's inception, Zeppelin community has made 3 releases, recruited 4
> PPMC and resolved 500+ issues [1] with 90+ contributors [2]. Now, community
> is very open, active and continuously growing.
> 
> The Apache Zeppelin community has discussed and voted on graduation to
> top level
> project.
> The vote passed with 22 +1 votes (9 binding) and no 0 or -1 votes.
> 
> Incubation Status:
> http://incubator.apache.org/projects/zeppelin.html
> Maturity Assessment:
> https://cwiki.apache.org/confluence/display/ZEPPELIN/Apache+Zeppelin+Project+Maturity+Model
> Discussion:
> https://s.apache.org/gLi0
> https://s.apache.org/GhqY (continue)
> Vote:
> https://s.apache.org/7hCK
> Result:
> https://s.apache.org/1rJD
> 
> Please vote on the resolution pasted below to graduate Apache Zeppelin
> from the incubator to top level project.
> 
> [ ] +1 Graduate Apache Zeppelin from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Zeppelin from the Incubator because
> 
> This vote will be open for at least 72 hours.
> Many thanks to our mentors and everyone else for the support,
> 
> [1] https://s.apache.org/eswD
> [2] https://s.apache.org/gi3o
> 
> Apache Zeppelin top-level project resolution:
> 
> 
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to
> the public, related to a collaborative data analytics and
> visualization tool for general-purpose data processing systems.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Zeppelin Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
> 
> RESOLVED, that the Apache Zeppelin Project be and hereby is
> responsible for the creation and maintenance of software
> related to a collaborative data analytics and
> visualization tool for general-purpose data processing systems; and be it
> further
> 
> RESOLVED, that the office of "Vice President, Apache Zeppelin" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache Zeppelin Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Zeppelin Project; and be it further
> 
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Zeppelin Project:
> 
> * Alexander Bezzubov 
> * Anthony Corbacho 
> * Damien Corneau 
> * Felix Cheung 
> * Jongyoul Lee 
> * Kevin Sangwoo Kim 
> * Lee Moon Soo 
> * Mina Lee 
> * Prabhjyot Singh 
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Lee Moon Soo
> be appointed to the office of Vice President, Apache Zeppelin, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
> 
> RESOLVED, that the initial Apache Zeppelin PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Zeppelin Project; and be it further
> 
> RESOLVED, that the Apache Zeppelin Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Zeppelin podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Zeppelin podling encumbered upon the Apache Incubator
> Project are hereafter discharge.


signature.asc
Description: Digital signature

Re: [VOTE] MADlib v1.9-rc1

[Konstantin Boudnik]

+1

- checksums/signatures are Ok
- rat is clean (although, having 700+ files without a header looks confusing)
- can build

On the comments side (on top of what Justine already caught): 
  - having a pom just for running rat? Might as well hook up all the cmake
shenanigan to it and safe the labor of having everybody read the
instructions
  - sha1/md5 aren't secure checksums. Please consider moving to sha512 or
similar

Cos

On Sun, Apr 03, 2016 at 12:24PM, Frank McQuillan wrote:
> Hello Incubator PMC,
> 
> Thank you in advance for reviewing MADlib v1.9-rc1.
> 
> This is the 2nd ASF release for Apache MADlib (incubating).  The goal of
> this 2nd release is:  general availability of MADlib v1.9 for community use.
> 
> The software in this release is very similar to the 1st ASF release MADlib
> v1.9alpha on 3/11/16.  The main differences are bug fixes, license and
> notice clarifications, and minor updates.  Feature set is the same.
> 
> Reminder of thread for IPMC vote passing of 1st ASF release:
> http://mail-archives.apache.org/mod_mbox/incubator-general/201603.mbox/%3ccakbqfztg+w4ub6t5awf1gemsxy5ad+j3xnozfkyxmzwd3ro...@mail.gmail.com%3E
> which was intended in part to clear all potential IP issues in the code
> base and make it legally ready to be adopted by the community.
> 
> Reminder of the Apache MADlib (incubating) community vote:
> http://mail-archives.apache.org/mod_mbox/incubator-madlib-dev/201602.mbox/%3CCAKBQfzSkXyGVQSKrY99zc9UmTE_NfXcYrxDGB%3DCMBmuCKLxbAg%40mail.gmail.com%3E
> 
> The specific license and notice recommendations raised by the IPMC during
> the positive vote for MADlib v1.9alpha have been addressed:
> https://issues.apache.org/jira/browse/MADLIB-979
> 
> For more information including release notes, please see:
> https://cwiki.apache.org/confluence/display/MADLIB/MADlib+1.9
> 
> This is a source code tarball only release.
> 
> To run check RAT, please do:
> 
> $mvn verify
> 
> first to get the correct RAT output.  Look inside of pom.xml to see the
> classes of exceptions we're managing there for RAT.
> 
> We're voting on the source (tag): rc/v1.9-rc1
> 
> Source Files:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/1.9-incubating-rc1/
> 
> Commit to be voted on:
> https://git-wip-us.apache.org/repos/asf?p=incubator-madlib.git;a=commit;h=cf59b4d9136cb3680e32800ac774ac977129
> 
> KEYS file containing PGP Keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/KEYS
> 
> Please vote:
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> *** The vote will be open until Wed April 6 at 6 pm Pacific time. ***


signature.asc
Description: Digital signature

Re: [VOTE] MADlib v1.9-rc1

[Konstantin Boudnik]

Yup, 

I found this quite confusing indeed to have a bunch of files like
modules/**/*.c without any licenses nor mentioning anywhere. Am I missing some
previous discussions that wave the need for the headers in those?

Cos

On Tue, Apr 05, 2016 at 04:51PM, Justin Mclean wrote:
> Hi,
> 
> > The only new files are build related cmake or yaml files.
> 
> That's probably OK but given the statement in the LICENSE that all files
> without Apache headers are BSD licensed it probably would of made sense to
> add the headers to reduce any confusion.
> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [VOTE] Accept Quickstep into the Apache Incubator

[Konstantin Boudnik]

WQ (incubating) and Apache MADlib
> (incubating). Although some of the initial committers have not had the
> experience of developing entirely open source, community-driven
> projects, we expect to bring to bear the open development practices
> that have proven successful on longstanding Pivotal open source
> projects to the Quickstep community. Additionally, several ASF
> veterans have agreed to mentor the project and are listed in this
> proposal. The project will rely on their collective guidance and
> wisdom to quickly transition the entire team of initial committers
> towards practicing the Apache Way.
> 
> == Homogeneous Developers ==
> While many of the initial committers are employed by Pivotal or at the
> University of Wisconsin, we have already seen a healthy level of
> interest from existing customers and partners. We intend to convert
> that interest directly into participation and will be investing in
> activities to recruit additional committers from other companies.
> 
> == Reliance on Salaried Developers ==
> Many of the contributors are paid to work in the Big Data and data
> processing space and nearly all are committed to a career in that
> space. While they might wander from their current employers, they are
> unlikely to venture far from their core expertise and thus will
> continue to be engaged with the project regardless of their current
> employers.
> 
> == Relationships with Other Apache Products ==
> As mentioned in the Alignment section, Quickstep may consider various
> degrees of integration and code exchange with Apache Hive, Apache HAWQ
> (incubating), Apache YARN and Apache Mesos.
> 
> == An Excessive Fascination with the Apache Brand ==
> While we intend to leverage the Apache ‘branding’ when talking to
> other projects as testament of our project’s ‘neutrality’, we have no
> plans for making use of Apache brand in press releases nor posting
> billboards advertising acceptance of Quickstep into Apache Incubator.
> 
> == Documentation ==
> The documentation is currently available at http://quickstep.cs.wisc.edu/
> 
> == Initial Source ==
> Initial source code is currently licensed under Apache License v.2 and
> is available at https://github.com/pivotalsoftware/quickstep.
> 
> == Source and Intellectual Property Submission Plan ==
> As soon as Quickstep is approved to join the Incubator, the source
> code will be transitioned via an exhibit to Pivotal's current Software
> Grant Agreement onto ASF infrastructure. We know of no legal
> encumbrances inhibiting the transfer of source code to the ASF.
> 
> == External Dependencies ==
> 
> Runtime dependencies:
>  * farmhash: https://github.com/google/farmhash [License: MIT]
>  * gflags: https://github.com/gflags/gflags [License: BSD]
>  * glog: https://github.com/google/glog [License: BSD]
>  * gperftools: https://github.com/gperftools/gperftools [License: BSD]
>  * linenoise: https://github.com/antirez/linenoise [License: BSD 2-Clause]
>  * protobuf: https://github.com/google/protobuf [License: BSD]
> 
> Build only dependencies:
>  * cmake: https://cmake.org/ [License: BSD]
>  * bison: https://www.gnu.org/software/bison/ [License: GPL with
> exception for generated parsers]
>  * flex: http://flex.sourceforge.net [License: BSD]
> 
> Test only dependencies:
>  * benchmark: https://github.com/google/benchmark [License: Apache 2.0]
>  * cpplint: https://github.com/google/styleguide [License: BSD]
>  * gtest: https://github.com/google/googletest [License: BSD]
>  * iwyu: http://include-what-you-use.org/ [License: UIUC BSD-Like]
> 
> Cryptography: N/A
> 
> == Required Resources ==
> 
> === Mailing lists ===
>   * priv...@quickstep.incubator.apache.org (moderated subscriptions)
>   * comm...@quickstep.incubator.apache.org
>   * d...@quickstep.incubator.apache.org
>   * iss...@quickstep.incubator.apache.org
>   * u...@quickstep.incubator.apache.org
> 
> === Git Repository ===
>   https://git-wip-us.apache.org/repos/asf/incubator-quickstep.git
> 
> === Issue Tracking ===
> 
> JIRA Project QUICKSTEP (QUICKSTEP)
> 
> === Other Resources ===
> Means of setting up regular builds for Quickstep on builds.apache.org
> will require integration with Docker support.
> 
> == Initial Committers ==
>  * Jignesh M. Patel
>  * Harshad Deshmukh
>  * Jianqiao Zhu
>  * Zuyu Zhang
>  * Marc Spehlmann
>  * Saket Saurabh
>  * Hakan Memisoglu
>  * Rogers Jeffrey Leo John
>  * Adalbert Gerald Soosai Raj
>  * Udip Pant
>  * Siddharth Suresh
>  * Rathijit Sen
>  * Craig Chasseur
>  * Qiang Zeng
>  * Shoban Chandrabose
>  * Navneet Potti
>  * Yinan Li
>  * Sangmin Shin
>  * James Paton
>  * Shixuan Fan
>  * Roman Shaposhnik
>  * Konstantin Boudnik
>  * Julian Hyde
>  * Dhruba Borthakur
> 
> == Affiliations ==
>  * Pivotal: Jignesh M. Patel, Zuyu Zhang, Roman Shaposhnik
>  * Google: Craig Chasseur
>  * Facebook: James Paton, Dhruba Borthakur
>  * Pinterest: Sangmin Shin
>  * Microsoft: Yinan Li
>  * Hortonworks: Julian Hyde
>  * Memcore: Konstantin Boudnik
>  * University of Wisconsin (and supported in part by Pivotal): Everyone else
> 
> == Sponsors ==
> 
> === Champion ===
> Roman Shaposhnik
> 
> === Nominated Mentors ===
> The initial mentors are listed below:
>  * Konstantin Boudnik - Apache Member, Memcore
>  * Roman Shaposhnik - Apache Member, Pivotal
>  * Julian Hyde, IPMC Member, Hortonworks
> 
> === Sponsoring Entity ===
> We would like to propose Apache incubator to sponsor this project.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [DISCUSS] Quickstep incubation proposal

[Konstantin Boudnik]

That's a fair statement. In general, however, it isn't a concern of the
Incubator if a proposed podling have some sort of resemblance with some other
software out there. IINM, no one was rejected because they want to develop yet
another web-application server or something like this.

Cos

On Tue, Mar 22, 2016 at 06:44PM, Tom Barber wrote:
> I actually have an opinion!
> 
> I saw yet another database engine land and my heart sank
> 
> Then I did some digging into quickstep and realised it was more of a
> "traditional" database that might take on the likes of Exasol etc rather
> than plugging more SQL into NOSQL etc(from what I gather) and I am happy to
> see it pitched.
> 
> Tom
> 
> On Tue, Mar 22, 2016 at 6:41 PM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > It's been a week since this thread started and surprisingly there isn't any
> > reaction so far. Is it safe to assume the silent consensus has been
> > reached?
> >
> > Cos
> >
> > On Tue, Mar 15, 2016 at 04:52PM, Roman Shaposhnik wrote:
> > > Hi!
> > >
> > > It is my pleasure to present the proposal to incubate the Quickstep
> > project
> > > at the Apache Software Foundation. Quickstep is a high-performance
> > > next generation, database engine available under Apache License 2.0.
> > >
> > > The text of the proposal is included below and is also available at
> > >https://wiki.apache.org/incubator/QuickstepProposal
> > >
> > > Thanks,
> > > Roman.
> > >
> > > == Abstract ==
> > >
> > > Quickstep is a high-performance database engine. It is designed to (1)
> > > convert data to insights at bare-metal speed, (2) support multiple
> > > query surfaces including SQL (the first (and current) version only
> > > supports SQL, and (3) deliver bare-metal performance on any hardware
> > > (including running on a laptop, running on a high-end (single node)
> > > server, and running on a distributed cluster). Since its inception,
> > > the project has been planned to deliver a high-performance single node
> > > system first, followed by a distributed system.
> > >
> > > Quickstep is composed of several different modules that handle
> > > different concerns of a database system. The main modules are:
> > >   * Utility - Reusable general-purpose code that is used by many other
> > modules.
> > >   * Threading - Provides a cross-platform abstraction for threads and
> > > synchronization primitives that abstract the underlying OS threading
> > > features.
> > >   * Types - The core type system used across all of Quickstep. Handles
> > > details of how SQL types are stored, parsed, serialized &
> > > deserialized, and converted. Also includes basic containers for typed
> > > values (tuples and column-vectors) and low-level operations that apply
> > > to typed values (e.g. basic arithmetic and comparisons).
> > >   * Catalog - Tracks database schema as well as physical storage
> > > information for relations (e.g. which physical blocks store a
> > > relation's data, and any physical partitioning and placement
> > > information).
> > >   * Storage - Physically stores relational data in self-contained,
> > > self-describing blocks, both in-memory and on persistent storage (disk
> > > or a distributed filesystem). Also includes some heavyweight run-time
> > > data structures used in query processing (e.g. hash tables for join
> > > and aggregation). Includes a buffer manager component for managing
> > > memory use and a file manager component that handles data persistence.
> > >   * Compression - Implements ordered dictionary compression. Several
> > > storage formats in the Storage module are capable of storing
> > > compressed column data and evaluating some expressions directly on
> > > compressed data without decompressing. The common code supporting
> > > compression is in this module.
> > >   * Expressions - Builds on the simple operations provided by the
> > > Types module to support arbitrarily complex expressions over data,
> > > including scalar expressions, predicates, and aggregate functions with
> > > and without grouping.
> > >   * Relational Operators - This module provides the building blocks
> > > for queries in Quickstep. A query is represented as a directed acyclic
> > > graph of relational operators, each of which is responsible for
> > > applying some relational-algebraic operation(s) to transform its
> > > i

Re: [DISCUSS] Quickstep incubation proposal

[Konstantin Boudnik]

inuing with the creation of a community around
> Apache Geode (incubating), Apache HAWQ (incubating) and Apache MADlib
> (incubating). Although some of the initial committers have not had the
> experience of developing entirely open source, community-driven
> projects, we expect to bring to bear the open development practices
> that have proven successful on longstanding Pivotal open source
> projects to the Quickstep community. Additionally, several ASF
> veterans have agreed to mentor the project and are listed in this
> proposal. The project will rely on their collective guidance and
> wisdom to quickly transition the entire team of initial committers
> towards practicing the Apache Way.
> 
> == Homogeneous Developers ==
> While many of the initial committers are employed by Pivotal or at the
> University of Wisconsin, we have already seen a healthy level of
> interest from existing customers and partners. We intend to convert
> that interest directly into participation and will be investing in
> activities to recruit additional committers from other companies.
> 
> == Reliance on Salaried Developers ==
> Many of the contributors are paid to work in the Big Data and data
> processing space and nearly all are committed to a career in that
> space. While they might wander from their current employers, they are
> unlikely to venture far from their core expertise and thus will
> continue to be engaged with the project regardless of their current
> employers.
> 
> == Relationships with Other Apache Products ==
> As mentioned in the Alignment section, Quickstep may consider various
> degrees of integration and code exchange with Apache Hive, Apache HAWQ
> (incubating), Apache YARN and Apache Mesos.
> 
> == An Excessive Fascination with the Apache Brand ==
> While we intend to leverage the Apache ‘branding’ when talking to
> other projects as testament of our project’s ‘neutrality’, we have no
> plans for making use of Apache brand in press releases nor posting
> billboards advertising acceptance of Quickstep into Apache Incubator.
> 
> == Documentation ==
> The documentation is currently available at http://quickstep.cs.wisc.edu/
> 
> == Initial Source ==
> Initial source code is currently licensed under Apache License v.2 and
> is available at https://github.com/pivotalsoftware/quickstep.
> 
> == Source and Intellectual Property Submission Plan ==
> As soon as Quickstep is approved to join the Incubator, the source
> code will be transitioned via an exhibit to Pivotal's current Software
> Grant Agreement onto ASF infrastructure. We know of no legal
> encumbrances inhibiting the transfer of source code to the ASF.
> 
> == External Dependencies ==
> 
> Runtime dependencies:
>  * farmhash: https://github.com/google/farmhash [License: MIT]
>  * gflags: https://github.com/gflags/gflags [License: BSD]
>  * glog: https://github.com/google/glog [License: BSD]
>  * gperftools: https://github.com/gperftools/gperftools [License: BSD]
>  * linenoise: https://github.com/antirez/linenoise [License: BSD 2-Clause]
>  * protobuf: https://github.com/google/protobuf [License: BSD]
> 
> Build only dependencies:
>  * cmake: https://cmake.org/ [License: BSD]
>  * bison: https://www.gnu.org/software/bison/ [License: GPL with
> exception for generated parsers]
>  * flex: http://flex.sourceforge.net [License: BSD]
> 
> Test only dependencies:
>  * benchmark: https://github.com/google/benchmark [License: Apache 2.0]
>  * cpplint: https://github.com/google/styleguide [License: BSD]
>  * gtest: https://github.com/google/googletest [License: BSD]
>  * iwyu: http://include-what-you-use.org/ [License: UIUC BSD-Like]
> 
> Cryptography: N/A
> 
> == Required Resources ==
> 
> === Mailing lists ===
>   * priv...@quickstep.incubator.apache.org (moderated subscriptions)
>   * comm...@quickstep.incubator.apache.org
>   * d...@quickstep.incubator.apache.org
>   * iss...@quickstep.incubator.apache.org
>   * u...@quickstep.incubator.apache.org
> 
> === Git Repository ===
>   https://git-wip-us.apache.org/repos/asf/incubator-quickstep.git
> 
> === Issue Tracking ===
> 
> JIRA Project QUICKSTEP (QUICKSTEP)
> 
> === Other Resources ===
> Means of setting up regular builds for Quickstep on builds.apache.org
> will require integration with Docker support.
> 
> == Initial Committers ==
>  * Jignesh M. Patel
>  * Harshad Deshmukh
>  * Craig Chasseur
>  * Jianqiao Zhu
>  * Zuyu Zhang
>  * Marc Spehlmann
>  * Saket Saurabh
>  * Hakan Memisoglu
>  * Harshad Deshmukh
>  * Adalbert Gerald Soosai Raj
>  * Udip Pant
>  * Siddharth Suresh
>  * Rathijit Sen
>  * Qiang Zeng
>  * Shoban Chandrabose
>  * Navneet Potti
>  * Yinan Li
>  * Sangmin Shin
>  * James Paton
>  * Shixuan Fan
>  * Roman Shaposhnik
>  * Konstantin Boudnik
>  * Julian Hyde
>  * Dhruba Borthakur
> 
> == Affiliations ==
>  * Pivotal: Jignesh M. Patel, Zuyu Zhang, Roman Shaposhnik
>  * Google: Craig Chasseur
>  * Facebook: James Paton, Dhruba Borthakur
>  * Pinterest: Sangmin Shin
>  * Microsoft: Yinan Li
>  * Hortonworks: Julian Hyde
>  * Memcore: Konstantin Boudnik
>  * University of Wisconsin (and supported in part by Pivotal): Everyone else
> 
> == Sponsors ==
> 
> === Champion ===
> Roman Shaposhnik
> 
> === Nominated Mentors ===
> The initial mentors are listed below:
>  * Konstantin Boudnik - Apache Member, Memcore
>  * Roman Shaposhnik - Apache Member, Pivotal
>  * Julian Hyde, IPMC Member, Hortonworks
> 
> === Sponsoring Entity ===
> We would like to propose Apache incubator to sponsor this project.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [VOTE] MADlib v1.9alpha-rc2

[Konstantin Boudnik]

+1 [binding]

On Tue, Mar 08, 2016 at 11:54AM, Frank McQuillan wrote:
> Hello Incubator PMC,
> 
> Based on comments from the PMC regarding MADlib release candidate
> v1.9alpha-rc1
> http://mail-archives.apache.org/mod_mbox/incubator-general/201603.mbox/%3CCA%2BULb%2Bts1B5r2BGVMj5N0tX0ugKjDqKJ3xjkTAqoGwVm%3D9knnA%40mail.gmail.com%3E
> the following JIRAs have been defined and fixed:
> 
> https://issues.apache.org/jira/browse/MADLIB-971
> https://issues.apache.org/jira/browse/MADLIB-972
> 
> The legal-discuss on how to proceed re: missing BSD licensing headers has
> been satisfactorily addressed as per:
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201603.mbox/%3C9D1AF43C-370B-4E58-B0EF-2E29D242F50B%40jaguNET.com%3E
> 
> Reminder of the Apache MADlib (incubating) community vote:
> http://mail-archives.apache.org/mod_mbox/incubator-madlib-dev/201602.mbox/%3CCAKBQfzSkXyGVQSKrY99zc9UmTE_NfXcYrxDGB%3DCMBmuCKLxbAg%40mail.gmail.com%3E
> 
> For more information including release notes, please see:
> https://cwiki.apache.org/confluence/display/MADLIB/MADlib+1.9+alpha
> 
> This is a source code tarball only release.
> 
> To run check RAT, please do:
> 
> $mvn verify
> 
> first to get the correct RAT output.  Look inside of pom.xml to see the
> classes of exceptions we're managing there for RAT.
> 
> We're voting on the source (tag):
> rc/v1.9alpha-rc2
> 
> Source Files:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/1.9alpha-incubating-rc2/
> 
> Commit to be voted on:
> https://git-wip-us.apache.org/repos/asf?p=incubator-madlib.git;a=commit;h=c9cb10cda6c42839d367ca635c8621d8a0b374a1
> 
> KEYS file containing PGP Keys we use to sign the release:
> https://dist.apache.org/repos/dist/dev/incubator/madlib/KEYS
> Please vote:
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> *** The vote will be open until Thurs Mar 10 at 6 pm Pacific time. ***


signature.asc
Description: Digital signature

In-Memory Computing Summit 2016

[Konstantin Boudnik]

[...not a spam...]

In case someone in the incubating projects is interested to participate in the
2nd annual In-Memory Computing Summit in San Francisco, the CFP is still going
until Feb 3rd

The call for speaking proposals for the In-Memory Computing Summit 2016
 *closes
February 3rd*. The conference is May 23-24 at the Grand Hyatt San
Francisco in Union Square. This event was created for developers, decision
makers and visionaries to network and learn about technologies, solutions
and real-world use cases for in-memory computing.

Speaking proposals for topics related to in-memory computing such as the
following (or topics you suggest) are encouraged:

   - Architecture and design
   - Use cases
   - Performance optimization
   - In-memory computing for Big Data analytics
   - In-memory computing and Apache Spark
   - In-memory streaming
   - Scalable machine learning
   - In-memory computing and Geode
   - Hardware considerations for in-memory computing
   - New in-memory computing solutions

Submit your proposal now at http://imcsummit.org/speaker-proposals/
 by
the *February** 3 deadline*.



signature.asc
Description: Digital signature

Re: [VOTE] Release Apache Zeppelin (incubating) 0.5.6-incubating (RC2)

[Konstantin Boudnik]

Silly me - send this email too early. I see the vote is closed already. Sorry
for the noise.

Cos

On Fri, Jan 22, 2016 at 10:43AM, Konstantin Boudnik wrote:
> Thanks Alex!
> 
> BTW, the vote has been open for the whole week now, and it seems that you have
> enough binding votes to make it happen. Perhaps, this is time to close and
> publish the release? There are people waiting for it, you know ;)
> 
> Cos
> 
> On Wed, Jan 20, 2016 at 04:34PM, Alexander Bezzubov wrote:
> > Thank you Konstantin!
> > 
> > KEYS file in release area has been updated [1]
> > 
> > Feedback has been logged in JIRA:
> >  * enforce minimum maven version [2]
> >  * document "how to validate licences"  [3]
> > 
> > Will do our best to improve UX for the next release!
> > 
> > --
> > Alex
> > 
> > 1. https://dist.apache.org/repos/dist/release/incubator/zeppelin/KEYS
> > 2. https://issues.apache.org/jira/browse/ZEPPELIN-622
> > 3. https://issues.apache.org/jira/browse/ZEPPELIN-623
> > 
> > On Wed, Jan 20, 2016 at 6:22 AM, Konstantin Boudnik <c...@apache.org> wrote:
> > 
> > > +1 [binding]
> > >
> > > Verified:
> > >
> > > - signature (ok). [1]
> > > - sha512 checksum (ok)
> > > - licenses (ok) [2]
> > > - tag (ok)
> > > - build from sources (ok) [3]
> > >
> > > [1] The signing key isn't available from the release area's KEYS file.
> > > Please update ASAP
> > > [2] Every time I need to verify the release I have to spend like half an
> > > hour
> > > to find how to validate the licenses. And considering that Maven made
> > > it impossible to list all the goals in the project, it is frustrating,
> > > really. Please add the instructions in that effect to README or
> > > DEVNOTES
> > > [3] if you expect particular versions of the build tools, it makes sense 
> > > to
> > > enforce it at the beginning. Case in point, one has to go all the way
> > > to
> > > the web module to find out a need for Maven >= 3.1.0. Bad UX
> > >
> > > Cos
> > >
> > > On Sat, Jan 16, 2016 at 12:57AM, Alexander Bezzubov wrote:
> > > > Hi,
> > > >
> > > > on behalf of Apache Zeppelin PPMC I'd like to call this vote for the
> > > > following RC to be released as
> > > > Apache Zeppelin incubating-0.5.6
> > > >
> > > > Vote on dev@zeppelin.i.a.o
> > > > http://s.apache.org/GFy
> > > >
> > > > Result of vote on dev@zeppelin.i.a.o
> > > > http://s.apache.org/DFz
> > > >
> > > >
> > > > The release candidate consists of the following source distribution
> > > archive
> > > > zeppelin-0.5.6-incubating.tgz
> > > >
> > > > In addition, the following supplementary binary distributions are
> > > provided for
> > > > user convenience at the same location
> > > > zeppelin-0.5.6-incubating-bin-all.tgz
> > > >
> > > > The source zip, including signatures, digests, etc. can be found at:
> > > > *
> > > https://dist.apache.org/repos/dist/dev/incubator/zeppelin/0.5.6-incubating-rc2/
> > > > <
> > > https://dist.apache.org/repos/dist/dev/incubator/zeppelin/0.5.6-incubating-rc2/
> > > >*
> > > >
> > > > The maven artifacts are here
> > > > *
> > > https://repository.apache.org/content/repositories/orgapachezeppelin-1006
> > > > <
> > > https://repository.apache.org/content/repositories/orgapachezeppelin-1006
> > > >*
> > > >
> > > > The Git tag is v0.5.6
> > > > The Git commit ID is 8698d0e5d376800b174d8b604f584b86b3037d65
> > > > https://git-wip-us.apache.org/repos/asf
> > > >
> > > ?p=incubator-zeppelin.git;a=commit;h=8698d0e5d376800b174d8b604f584b86b3037d65
> > > ve>
> > > > Release artifacts are signed with the following key:
> > > > https://people.apache.org/keys/committer/bzz
> > > >
> > > > KEYS file available here:
> > > > https://dist.apache.org/repos/dist/dev/incubator/zeppelin/KEYS
> > > >
> > > > 131 issues were closed/resolved for this release:
> > > > https://issues.apache.org/jira/browse/ZEPPELIN/fixforversion/12334165/
> > > >
> > > > Release note highlights can be found here:
> > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId
> > > > =12316221=12334165
> > > >
> > > > The vote will be open for 72 hours.
> > > >
> > > > The please vote:
> > > > [ ] +1 Release this package as Zeppelin 0.5.6-incubating
> > > > [ ] +0 no opinion
> > > > [ ] -1 Do not release this package because because...
> > > >
> > > >
> > > > ---
> > > > Kind regards,
> > > > Alex
> > >
> > 
> > 
> > 
> > -- 
> > --
> > Kind regards,
> > Alexander.




signature.asc
Description: Digital signature

Re: [VOTE] Release Apache Zeppelin (incubating) 0.5.6-incubating (RC2)

[Konstantin Boudnik]

Thanks Alex!

BTW, the vote has been open for the whole week now, and it seems that you have
enough binding votes to make it happen. Perhaps, this is time to close and
publish the release? There are people waiting for it, you know ;)

Cos

On Wed, Jan 20, 2016 at 04:34PM, Alexander Bezzubov wrote:
> Thank you Konstantin!
> 
> KEYS file in release area has been updated [1]
> 
> Feedback has been logged in JIRA:
>  * enforce minimum maven version [2]
>  * document "how to validate licences"  [3]
> 
> Will do our best to improve UX for the next release!
> 
> --
> Alex
> 
> 1. https://dist.apache.org/repos/dist/release/incubator/zeppelin/KEYS
> 2. https://issues.apache.org/jira/browse/ZEPPELIN-622
> 3. https://issues.apache.org/jira/browse/ZEPPELIN-623
> 
> On Wed, Jan 20, 2016 at 6:22 AM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > +1 [binding]
> >
> > Verified:
> >
> > - signature (ok). [1]
> > - sha512 checksum (ok)
> > - licenses (ok) [2]
> > - tag (ok)
> > - build from sources (ok) [3]
> >
> > [1] The signing key isn't available from the release area's KEYS file.
> > Please update ASAP
> > [2] Every time I need to verify the release I have to spend like half an
> > hour
> > to find how to validate the licenses. And considering that Maven made
> > it impossible to list all the goals in the project, it is frustrating,
> > really. Please add the instructions in that effect to README or
> > DEVNOTES
> > [3] if you expect particular versions of the build tools, it makes sense to
> > enforce it at the beginning. Case in point, one has to go all the way
> > to
> > the web module to find out a need for Maven >= 3.1.0. Bad UX
> >
> > Cos
> >
> > On Sat, Jan 16, 2016 at 12:57AM, Alexander Bezzubov wrote:
> > > Hi,
> > >
> > > on behalf of Apache Zeppelin PPMC I'd like to call this vote for the
> > > following RC to be released as
> > > Apache Zeppelin incubating-0.5.6
> > >
> > > Vote on dev@zeppelin.i.a.o
> > > http://s.apache.org/GFy
> > >
> > > Result of vote on dev@zeppelin.i.a.o
> > > http://s.apache.org/DFz
> > >
> > >
> > > The release candidate consists of the following source distribution
> > archive
> > > zeppelin-0.5.6-incubating.tgz
> > >
> > > In addition, the following supplementary binary distributions are
> > provided for
> > > user convenience at the same location
> > > zeppelin-0.5.6-incubating-bin-all.tgz
> > >
> > > The source zip, including signatures, digests, etc. can be found at:
> > > *
> > https://dist.apache.org/repos/dist/dev/incubator/zeppelin/0.5.6-incubating-rc2/
> > > <
> > https://dist.apache.org/repos/dist/dev/incubator/zeppelin/0.5.6-incubating-rc2/
> > >*
> > >
> > > The maven artifacts are here
> > > *
> > https://repository.apache.org/content/repositories/orgapachezeppelin-1006
> > > <
> > https://repository.apache.org/content/repositories/orgapachezeppelin-1006
> > >*
> > >
> > > The Git tag is v0.5.6
> > > The Git commit ID is 8698d0e5d376800b174d8b604f584b86b3037d65
> > > https://git-wip-us.apache.org/repos/asf
> > >
> > ?p=incubator-zeppelin.git;a=commit;h=8698d0e5d376800b174d8b604f584b86b3037d65
> > ve>
> > > Release artifacts are signed with the following key:
> > > https://people.apache.org/keys/committer/bzz
> > >
> > > KEYS file available here:
> > > https://dist.apache.org/repos/dist/dev/incubator/zeppelin/KEYS
> > >
> > > 131 issues were closed/resolved for this release:
> > > https://issues.apache.org/jira/browse/ZEPPELIN/fixforversion/12334165/
> > >
> > > Release note highlights can be found here:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId
> > > =12316221=12334165
> > >
> > > The vote will be open for 72 hours.
> > >
> > > The please vote:
> > > [ ] +1 Release this package as Zeppelin 0.5.6-incubating
> > > [ ] +0 no opinion
> > > [ ] -1 Do not release this package because because...
> > >
> > >
> > > ---
> > > Kind regards,
> > > Alex
> >
> 
> 
> 
> -- 
> --
> Kind regards,
> Alexander.


signature.asc
Description: Digital signature

Re: [VOTE] Release Apache Zeppelin (incubating) 0.5.6-incubating (RC2)

[Konstantin Boudnik]

+1 [binding]

Verified:

- signature (ok). [1] 
- sha512 checksum (ok)
- licenses (ok) [2]
- tag (ok)
- build from sources (ok) [3]

[1] The signing key isn't available from the release area's KEYS file. Please 
update ASAP
[2] Every time I need to verify the release I have to spend like half an hour
to find how to validate the licenses. And considering that Maven made
it impossible to list all the goals in the project, it is frustrating,
really. Please add the instructions in that effect to README or DEVNOTES
[3] if you expect particular versions of the build tools, it makes sense to
enforce it at the beginning. Case in point, one has to go all the way to
the web module to find out a need for Maven >= 3.1.0. Bad UX

Cos

On Sat, Jan 16, 2016 at 12:57AM, Alexander Bezzubov wrote:
> Hi,
> 
> on behalf of Apache Zeppelin PPMC I'd like to call this vote for the
> following RC to be released as
> Apache Zeppelin incubating-0.5.6
> 
> Vote on dev@zeppelin.i.a.o
> http://s.apache.org/GFy
> 
> Result of vote on dev@zeppelin.i.a.o
> http://s.apache.org/DFz
> 
> 
> The release candidate consists of the following source distribution archive
> zeppelin-0.5.6-incubating.tgz
> 
> In addition, the following supplementary binary distributions are provided for
> user convenience at the same location
> zeppelin-0.5.6-incubating-bin-all.tgz
> 
> The source zip, including signatures, digests, etc. can be found at:
> *https://dist.apache.org/repos/dist/dev/incubator/zeppelin/0.5.6-incubating-rc2/
> *
> 
> The maven artifacts are here
> *https://repository.apache.org/content/repositories/orgapachezeppelin-1006
> *
> 
> The Git tag is v0.5.6
> The Git commit ID is 8698d0e5d376800b174d8b604f584b86b3037d65
> https://git-wip-us.apache.org/repos/asf
> ?p=incubator-zeppelin.git;a=commit;h=8698d0e5d376800b174d8b604f584b86b3037d65
ve> 
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/bzz
> 
> KEYS file available here:
> https://dist.apache.org/repos/dist/dev/incubator/zeppelin/KEYS
> 
> 131 issues were closed/resolved for this release:
> https://issues.apache.org/jira/browse/ZEPPELIN/fixforversion/12334165/
> 
> Release note highlights can be found here:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId
> =12316221=12334165
> 
> The vote will be open for 72 hours.
> 
> The please vote:
> [ ] +1 Release this package as Zeppelin 0.5.6-incubating
> [ ] +0 no opinion
> [ ] -1 Do not release this package because because...
> 
> 
> ---
> Kind regards,
> Alex


signature.asc
Description: Digital signature

Re: [VOTE] Retire Ripple

[Konstantin Boudnik]

+1 [binding]

On Mon, Nov 30, 2015 at 08:54PM, Marvin Humphrey wrote:
> Greetings,
> 
> The Ripple community has been discussing retirement on their dev list.
> 
>   http://s.apache.org/LjX
> 
> It would be more clear cut if there had been a VOTE thread, but since the
> discussion took place on the podling dev list (rather than the private list or
> some other non-central channel), since traffic is low and thus the thread is
> very prominent, and since the subject line contains the word "retire",
> hopefully all potential contributors have received sufficient notice.
> 
> This is a vote of the IPMC to retire the podling.
> 
> [ ] +1 to retire Ripple from the Incubator
> [ ] -1 to keep Ripple in the Incubator
> 
> This vote will be held open for at least 72 hours.
> 
> Should this vote pass, I have volunteered to assist Ripple with retirement,
> as I have been assisting Droids, Kalumet and Corinthia.
> 
> Marvin Humphrey
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: Impala commit policy

[Konstantin Boudnik]

I am not sure what "start with no explicit commit policy" even means. Will
there be no commits, until the discussion on the subject happens?

How code changes will be going into the source base?
  Cos

On Wed, Dec 02, 2015 at 10:01AM, Tom White wrote:
> The vote to accept Impala into the incubator has passed
> (http://s.apache.org/u6r), however there are still some concerns about
> CTR/RTC. My main takeaways from the CTR/RTC thread are that it's not a
> binary choice, and that it's entirely reasonable that different
> communities have different commit policies at the ASF.
> 
> I think Julian Hyde's suggestion that the Impala podling start with no
> explicit commit policy is a good one. Incubation should be used as a
> time to work out what works best for a project. The initial Impala
> community should discuss the commit policy as they go through the
> process of setting up ASF infra and start growing the podling. In
> particular this will include how Gerrit can be used as a tool to
> facilitate reviews, and how that fits with ASF culture, which is
> something that other projects are looking at too.
> 
> Cheers,
> Tom
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [VOTE] Accept Impala into the Apache Incubator

[Konstantin Boudnik]

-0 [binding]

On Tue, Nov 24, 2015 at 01:03PM, Henry Robinson wrote:
> Hi -
> 
> The [DISCUSS] thread has been quiet for a few days, so I think there's been
> sufficient opportunity for discussion around our proposal to bring Impala
> to the ASF Incubator.
> 
> I'd like to call a VOTE on that proposal, which is on the wiki at
> https://wiki.apache.org/incubator/ImpalaProposal, and which I've pasted
> below.
> 
> During the discussion period, the proposal has been amended to add Brock
> Noland as a new mentor, to add one missed committer from the list and to
> correct some issues with the dependency list.
> 
> Please cast your votes as follows:
> 
> [] +1, accept Impala into the Incubator
> [] +/-0, non-counted vote to express a disposition
> [] -1, do not accept Impala into the Incubator (please give your reason(s))
> 
> As with the concurrent Kudu vote, I propose leaving the vote open for a
> full seven days (to close at Tuesday, December 1st at noon PST), due to the
> upcoming US holiday.
> 
> Thanks,
> Henry
> 
> 
> 
> = Abstract =
> Impala is a high-performance C++ and Java SQL query engine for data stored
> in Apache Hadoop-based clusters.
> 
> = Proposal =
> 
> We propose to contribute the Impala codebase and associated artifacts (e.g.
> documentation, web-site content etc.) to the Apache Software Foundation
> with the intent of forming a productive, meritocratic and open community
> around Impala’s continued development, according to the ‘Apache Way’.
> 
> Cloudera owns several trademarks regarding Impala, and proposes to transfer
> ownership of those trademarks in full to the ASF.
> 
> = Background =
> Engineers at Cloudera developed Impala and released it as an
> Apache-licensed open-source project in Fall 2012. Impala was written as a
> brand-new, modern C++ SQL engine targeted from the start for data stored in
> Apache Hadoop clusters.
> 
> Impala’s most important benefit to users is high-performance, making it
> extremely appropriate for common enterprise analytic and business
> intelligence workloads. This is achieved by a number of software
> techniques, including: native support for data stored in HDFS and related
> filesystems, just-in-time compilation and optimization of individual query
> plans, high-performance C++ codebase and massively-parallel distributed
> architecture. In benchmarks, Impala is routinely amongst the very highest
> performing SQL query engines.
> 
> = Rationale =
> 
> Despite the exciting innovation in the so-called ‘big-data’ space, SQL
> remains by far the most common interface for interacting with data in both
> traditional warehouses and modern ‘big-data’ clusters. There is clearly a
> need, as evidenced by the eager adoption of Impala and other SQL engines in
> enterprise contexts, for a query engine that offers the familiar SQL
> interface, but that has been specifically designed to operate in massive,
> distributed clusters rather than in traditional, fixed-hardware,
> warehouse-specific deployments. Impala is one such query engine.
> 
> We believe that the ASF is the right venue to foster an open-source
> community around Impala’s development. We expect that Impala will benefit
> from more productive collaboration with related Apache projects, and under
> the auspices of the ASF will attract talented contributors who will push
> Impala’s development forward at pace.
> 
> We believe that the timing is right for Impala’s development to move
> wholesale to the ASF: Impala is well-established, has been Apache-licensed
> open-source for more than three years, and the core project is relatively
> stable. We are excited to see where an ASF-based community can take Impala
> from this strong starting point.
> 
> = Initial Goals =
> Our initial goals are as follows:
> 
>  * Establish ASF-compatible engineering practices and workflows
>  * Refactor and publish existing internal build scripts and test
> infrastructure, in order to make them usable by any community member.
>  * Transfer source code, documentation and associated artifacts to the ASF.
>  * Grow the user and developer communities
> 
> = Current Status =
> 
> Impala is developed as an Apache-licensed open-source project. The source
> code is available at http://github.com/cloudera/Impala, and developer
> documentation is at https://github.com/cloudera/Impala/wiki. The majority
> of commits to the project have come from Cloudera-employed developers, but
> we have accepted some contributions from individuals from other
> organizations.
> 
> All code reviews are done via a public instance of the Gerrit review tool
> at http://gerrit.cloudera.org:8080/, and discussed on a public mailing
> list. All patches must be reviewed before they are accepted into the
> codebase, via a voting mechanism that is similar to that used on Apache
> projects such as Hadoop and HBase.
> 
> Before a patch is committed, it must pass a suite of pre-commit tests.
> These tests are currently run on Cloudera’s internal 

Re: [VOTE] Accept Impala into the Apache Incubator

[Konstantin Boudnik]

Come to think of it a bit more, yes I am not satisfied with the outcome of
the CTR/RTC exchange in the project.

Hence changing my vote to
 -1 [binding]

On Thu, Nov 26, 2015 at 11:47AM, Konstantin Boudnik wrote:
> -0 [binding]
> 
> On Tue, Nov 24, 2015 at 01:03PM, Henry Robinson wrote:
> > Hi -
> > 
> > The [DISCUSS] thread has been quiet for a few days, so I think there's been
> > sufficient opportunity for discussion around our proposal to bring Impala
> > to the ASF Incubator.
> > 
> > I'd like to call a VOTE on that proposal, which is on the wiki at
> > https://wiki.apache.org/incubator/ImpalaProposal, and which I've pasted
> > below.
> > 
> > During the discussion period, the proposal has been amended to add Brock
> > Noland as a new mentor, to add one missed committer from the list and to
> > correct some issues with the dependency list.
> > 
> > Please cast your votes as follows:
> > 
> > [] +1, accept Impala into the Incubator
> > [] +/-0, non-counted vote to express a disposition
> > [] -1, do not accept Impala into the Incubator (please give your reason(s))
> > 
> > As with the concurrent Kudu vote, I propose leaving the vote open for a
> > full seven days (to close at Tuesday, December 1st at noon PST), due to the
> > upcoming US holiday.
> > 
> > Thanks,
> > Henry
> > 
> > 
> > 
> > = Abstract =
> > Impala is a high-performance C++ and Java SQL query engine for data stored
> > in Apache Hadoop-based clusters.
> > 
> > = Proposal =
> > 
> > We propose to contribute the Impala codebase and associated artifacts (e.g.
> > documentation, web-site content etc.) to the Apache Software Foundation
> > with the intent of forming a productive, meritocratic and open community
> > around Impala’s continued development, according to the ‘Apache Way’.
> > 
> > Cloudera owns several trademarks regarding Impala, and proposes to transfer
> > ownership of those trademarks in full to the ASF.
> > 
> > = Background =
> > Engineers at Cloudera developed Impala and released it as an
> > Apache-licensed open-source project in Fall 2012. Impala was written as a
> > brand-new, modern C++ SQL engine targeted from the start for data stored in
> > Apache Hadoop clusters.
> > 
> > Impala’s most important benefit to users is high-performance, making it
> > extremely appropriate for common enterprise analytic and business
> > intelligence workloads. This is achieved by a number of software
> > techniques, including: native support for data stored in HDFS and related
> > filesystems, just-in-time compilation and optimization of individual query
> > plans, high-performance C++ codebase and massively-parallel distributed
> > architecture. In benchmarks, Impala is routinely amongst the very highest
> > performing SQL query engines.
> > 
> > = Rationale =
> > 
> > Despite the exciting innovation in the so-called ‘big-data’ space, SQL
> > remains by far the most common interface for interacting with data in both
> > traditional warehouses and modern ‘big-data’ clusters. There is clearly a
> > need, as evidenced by the eager adoption of Impala and other SQL engines in
> > enterprise contexts, for a query engine that offers the familiar SQL
> > interface, but that has been specifically designed to operate in massive,
> > distributed clusters rather than in traditional, fixed-hardware,
> > warehouse-specific deployments. Impala is one such query engine.
> > 
> > We believe that the ASF is the right venue to foster an open-source
> > community around Impala’s development. We expect that Impala will benefit
> > from more productive collaboration with related Apache projects, and under
> > the auspices of the ASF will attract talented contributors who will push
> > Impala’s development forward at pace.
> > 
> > We believe that the timing is right for Impala’s development to move
> > wholesale to the ASF: Impala is well-established, has been Apache-licensed
> > open-source for more than three years, and the core project is relatively
> > stable. We are excited to see where an ASF-based community can take Impala
> > from this strong starting point.
> > 
> > = Initial Goals =
> > Our initial goals are as follows:
> > 
> >  * Establish ASF-compatible engineering practices and workflows
> >  * Refactor and publish existing internal build scripts and test
> > infrastructure, in order to make them usable by any community member.
> >  * Transfer source code, documentation and associated artifacts to the 

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik]

On Wed, Nov 25, 2015 at 05:12PM, Chris Douglas wrote:
> RTC is regulation. That's not a synonym for control when it's
> conflated with suspicion of people. Regulation is a set of deliberate
> checks on a system.
> 
> Good regulation estimates (or reacts to) a system's natural excesses,
> then attempts to constrain existential threats. It isn't a lack of
> trust, but how trust is scaled. RTC can encourage review (where

And that goes, as always, to the question "Who makes the decision about the
_right_ level of trust". And, of course, how to make sure the governing body
is corruption-proof. In other words: there are no such thing as 'good
externalized regulation' because sooner or later it gets abused one way or
another. And I dare you to prove me wrong on this ;)

> oversight might be weak), throttle the pace of change (where sheer
> volume might discourage volunteers and exclude individuals), and
> identify code with a discouraging "bus factor" for attention or
> removal (where an isolated contributor can't solicit any feedback).
> Todd, Steve, Andrew, and others already covered other, intended
> desiderata.
> 
> Bad regulation erroneously classifies the power structure as part of
> the system, and threats to powerful people as existential threats to
> the system. It preserves privilege at the expense of individual
> initiative. RTC can mire committers in review, throttle the pace of
> change artificially, and entrench project members behind an inertial
> default. These unintended consequences create new existential threats
> to a project, which either require subsequent regulation/monitoring or
> they prove RTC to be worse than the diseases it remedied.[1]

Supposedly, regulations are introduced as a reaction to failures, if I read
what you're saying correctly. Empirically, majority of the failures in the
self-regulating systems are a result of ill-conceived interventions from the
last time. And we are going into a self-perpetuating cycle where a bad idea
leads to an even worst one and so on, until the system grinds to a halt or
collapse.

And you're right - there are always unintended consequences to artificial
limitations of any sort. One can not create a perfect set of fixed rules to
address all possible future permutations. After all, this is exactly how
the complex dynamic systems work.

In this respect, it is wiser to let the system find the equilibrium by
letting it go, and make small, localized tweaks when/if they needed. In our
case, CTR relies on actors' best judgement with postponed negative feedback if
something goes wrong or deemed incorrect. Such systems prove to be the most
effective when compared with the rigidness of N-pager guidelines document for
every step along the way.

Cos

> In practice, RTC does all these simultaneously, and the community is
> responsible for ensuring the implementation is effective, efficient,
> and just. That balance isn't static, either. One chooses RTC not
> because the code has some property (complexity, size, etc.), but
> because the community does, at the time.
> 
> All that said: many, maybe most projects entering incubation should
> try CTR, and adopt RTC if there's some concrete reason that justifies
> added governance. If the culture requests reviews, enforces tests/CI,
> members can keep up with changes, etc. then most probably won't bother
> with RTC. If the project already has an RTC culture and they want to
> keep it, we've seen that work, too. -C
> 
> 
> [1] RTC/CTR isn't the last policy choice the project makes, either.
> Allowing feature branches to work as CTR (complemented by branch
> committers) can dampen the shortcomings of enforcing RTC on
> trunk/release branches. Policies allowing non-code changes, etc. have
> been mentioned elsewhere in the thread.
> 
> 
> On Wed, Nov 25, 2015 at 12:39 PM, Greg Stein  wrote:
> > Boo hoo. Todd said it wasn't about control, and then a few days later said
> > he was forcing people into doing reviews. So yeah: in his case, it *is*
> > about control.
> >
> > Over the 17 years I've been around Apache, every single time I've seen
> > somebody attempt to justify something like RTC, it always goes back to
> > control. Always.
> >
> > -g
> >
> >
> > On Wed, Nov 25, 2015 at 2:35 PM, Andrew Purtell 
> > wrote:
> >
> >> I have to completely disagree and find your assertion vaguely offensive.
> >>
> >> > On Nov 25, 2015, at 12:32 PM, Greg Stein  wrote:
> >> >
> >> > On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell 
> >> > wrote:
> >> >> ...
> >> >>
> >> >> and inherited the RTC ethic from our parent community. I did recently
> >> test
> >> >> the state of consensus on RTC vs CTR there and it still holds. I think
> >> this
> >> >> model makes sense for HBase, which is a mature (read: complex) code base
> >> >> that implements a distributed database. For sure we want multiple sets
> >> of
> >> >>
> >> >
> >> > I call bullshit. "complex" 

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik]

On Mon, Nov 23, 2015 at 12:29PM, Harbs wrote:
> This kind of underscores my observation that a large part of this debate is
> driven by source control technologies.
> 
> RTC seems popular for projects using Git, while CTR seems popular in
> communities using SVN.

Well, Apache Bigtop is now _officially_ a CTR after a few months of
discussions within the community and a few months of trials. And yeah - we are
using git from day one. 

I don't think Git is particularly empowering RTC - there's nothing in it that
requires someone to look over one's shoulder. In Hadoop, HBase and some other
projects I've heard about the default review mode is via patch attached to a
JIRA ticket. And it has nothing to do with git or svn.

Cos

> RTC is a LOT easier using Git than SVN if the model is branching.
> 
> FWIW, I personally could swallow using RTC with Git, but I would seriously
> have problems with RTC with SVN.
> 
> On Nov 23, 2015, at 12:20 PM, Greg Stein  wrote:
> 
> >> 3. community building
> >> 
> >> Lots of successful open source projects, both inside and outside ASF,
> >> employ RTC. As Todd mentioned, almost all the top 10 most starred (on
> >> github) projects use some form of RTC, so it is hard for me to believe that
> >> RTC would hinder community building. Of course, one can always argue that
> >> if those projects had employed CTR, maybe they would've been even more
> >> popular. But then we got into the area that we just have to agree to
> >> disagree.
> >> 
> > 
> > Well, you could also look at openhub.net:
> > https://www.openhub.net/orgs/apache ... I believe those top 10 are *all*
> > CTR. ... in fact, of ALL projects tracked by openhub, httpd and svn are #2
> > and #4 respectively[*]. They are models of communities where trust rules
> > and CTR is the basis of operation.
> > 
> > Using GitHub as a proxy for evaluation skews towards git-based projects,
> > whereas openhub is tool independent.
> 


signature.asc
Description: Digital signature

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik]

On Tue, Nov 24, 2015 at 02:00AM, Ross Gardler wrote:
> The suggestion is to add it to the proposal template - that's before 
> incubation starts.

I think this is a great idea!

> -Original Message-
> From: Niall Pemberton [mailto:niall.pember...@gmail.com] 
> Sent: Monday, November 23, 2015 5:49 PM
> To: general-incubator 
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
> 
> On Mon, Nov 23, 2015 at 12:10 PM, Greg Stein  wrote:
> 
> > On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby  wrote:
> >
> > > On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein  wrote:
> > > >
> > > > Nobody is forcing anything.
> > > >
> > > > Personally, I am saying RTC is destructive, and am willing to give
> > every
> > > > podling that message.
> > >
> > > If it is truly destructive, SHOULDN'T you/we be trying to force 
> > > something?  And if not, doesn't that mean that it isn't really all 
> > > that destructive?
> > >
> >
> > I believe that I represent a minority position, so no... I'm not going 
> > to suggest changes. I wish to forestall more projects falling into the 
> > RTC trap, but (at the moment) don't believe that it makes sense to 
> > attempt to apply mandates against RTC upon existing communities.
> >
> >
> > >  As a Director, would you consider stop approving reports from ASF 
> > > projects that operate under a RTC model?  If not, aren't you sending 
> > > a mixed message?
> > >
> >
> > I have thought about this, yes. Maybe add a question to the proposal 
> > template, on what form they're thinking about (and where I could 
> > debate the proposal against RTC). And maybe debate podlings who want 
> > to graduate under RTC.
> >
> 
> I think this is too late - if you want to debate it, then it needs to be when 
> projects enter incubation. By the time they're ready to graduate then
> (presumably) things are already going well and theres less impetus to change.
> 
> Niall
> 
> 
> 
> 
> > But as a Director, if the community is producing releases, then I find 
> > it difficult to point to RTC as a problem for that community. It is an 
> > unprovable position: there is no way to state their community could be 
> > better off under CTR.
> >
> >
> > >
> > > - Sam Ruby
> > >
> > > P.S.  To be clear: I am not a fan of RTC when applied to 
> > > release.next branches.
> >
> >
> > I'd appreciate your explanation of this, as "most" CTR communities 
> > apply RTC to a branch as they prepare a release. What disturbs you 
> > about this approach?
> >
> > Cheers,
> > -g
> >


signature.asc
Description: Digital signature

Re: [DISCUSS] Kudu incubator proposal

[Konstantin Boudnik]

On Mon, Nov 23, 2015 at 11:17AM, Chris Mattmann wrote:
> Hi Alex,
> 
> We don’t have to hear from every author. If we don’t have an ICLA
> or SGA on file for them, we’ll remove their code from the initial

Yup, that's the concern I was trying to address by asking to reach out to the
contributors. If we simply can do this at the IP-check time - fine.

Thanks for taking time explaining this, Chris.
  Cos

> import. BTW, that’s a few steps away. We’re also rehashing stuff
> that has been discussed many times over, frankly.
> 
> Cheers,
> Chris
> 
> 
> 
> -Original Message-
> From: Alex Harui 
> Reply-To: "general@incubator.apache.org" 
> Date: Monday, November 23, 2015 at 10:46 AM
> To: "general@incubator.apache.org" 
> Subject: Re: [DISCUSS] Kudu incubator proposal
> 
> >
> >
> >On 11/23/15, 8:23 AM, "Mattmann, Chris A (3980)"
> > wrote:
> >
> >>Alex, 
> >>
> >>Please re-read my email. As I stated we don’t take code that
> >>authors don’t want us to have. So far, we haven’t heard from any of
> >>the authors on the incoming Kudu project that that’s the case. If
> >>it’s not the case, we go by the license of the project which stipulates
> >>how code can be copied, modified, reused, etc.
> >
> >Yes, but my interpretation of your words is that folks have to opt out,
> >not the other way around.  I thought the "take rule" meant that folks have
> >to opt in via SGA/CLA or for minor stuff, I'd think an email to dev@ would
> >suffice.
> >
> >So it isn't whether you haven't heard from any of the authors, it is
> >whether you have heard from every author.
> >
> >Thanks,
> >-Alex
> >
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [DISCUSS] Kudu incubator proposal

[Konstantin Boudnik]

My point exactly, thanks Henry!

On Tue, Nov 17, 2015 at 10:51PM, Henry Saputra wrote:
> Hi Todd,
> 
> One concern, other IPMCs could help correct me if I am wrong, for
> project that already open source and accepting contributions from
> individuals which not part of initial committers is that it needs to
> get the consent or grant from those contributors when moving to ASF.
> Unless, the individuals have already signed the one for Cloudera when
> contributing to Kudu.
> 
> Want to make sure the software grant concern be addressed early.
> 
> Thanks,
> 
> - Henry
> 
> On Tue, Nov 17, 2015 at 6:47 PM, Todd Lipcon  wrote:
> > On Tue, Nov 17, 2015 at 6:36 PM, Luke Han  wrote:
> >
> >> In "community" section of this proposal, there are many companies
> >> have been mentioned including Xiaomi, Dropbox, Intel and Dremio,
> >> and said there are contributions from them.
> >>
> >> I think their engineers are more interesting and be involved
> >> in Kudu actively, why not think about to invite them to be committer first?
> >>
> >
> > Per earlier messages on the thread and per the proposal: because they
> > haven't yet shown significant contributions over a sustained period.
> > Interest is one thing, but interest is not sufficient to become a committer
> > in a meritocracy. The folks called out in the community section are those
> > who have interest and are somewhere on the path towards committership, but
> > aren't there yet. I have every hope (and expectation) that they will get
> > there if they keep up their good work.
> >
> > I would rather not discuss specific people's progress towards committership
> > in a public forum. Rather, I hoped that we could start with the proposed
> > committer list, and during incubation we can discuss potential new
> > committers and PMC members following the typical ASF processes on our
> > PPMC's private list. I'm counting on our experienced mentors to keep us all
> > honest -- they should absolutely call us out if the initial committers act
> > exclusionary or otherwise violate the ASF principles of being an inclusive
> > meritocracy.
> >
> > -Todd
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik]

On Tue, Nov 17, 2015 at 11:12PM, Todd Lipcon wrote:
> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny 
> wrote:
> >
> > >>
> > > Except that there seems to be great disagreement among the Members as to
> > > whether RTC is somehow anti-Apache-Way.
> > >
> > > If you want to try to create an ASF-wide resolution that RTC doesn't
> > follow
> > > the Apache Way, and get the board/membership to vote on it, go ahead, but
> > > it confuses podlings who are new to the ASF when people espouse personal
> > > opinions as if they are ASF rules.
> >
> > That is not the point.
> >
> >
> > The question is not to decide if C-T-R is The Apache Way over R-T-C. The
> > question is wether a project entering incubation with a selected R-T-C
> > mode is likely to exit incubation for the simple reason it will be very
> > hard for this project to grow its community due to this choice. It's
> > like starting a 100m race with a 20kb backpack on your shoulder...
> >
> 
> If you have any statistics that show this to be the case, I'd be very
> interested. RTC is the norm in basically every Apache project I've been a
> part of, many of which have thriving communities and are generally regarded
> as successful software projects.

Do you have any statistics on that, Todd? Would be very interesting to see,
indeed.



signature.asc
Description: Digital signature

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik]

On Tue, Nov 17, 2015 at 06:06PM, Todd Lipcon wrote:
> On Tue, Nov 17, 2015 at 5:57 PM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> >
> > On the contrary... The business of the Incubator and IPMC is to help
> > podlings
> > and their communities to grok and follow the Apache Way. Trust is a
> > foundation
> > principal of a healthy community. Hence, this whole discussion has quite a
> > lot
> > of business in the incubator.
> >
> 
> Except that there seems to be great disagreement among the Members as to
> whether RTC is somehow anti-Apache-Way.

Woot?

> If you want to try to create an ASF-wide resolution that RTC doesn't follow
> the Apache Way, and get the board/membership to vote on it, go ahead, but

Thanks, I will thing about this idea.

> it confuses podlings who are new to the ASF when people espouse personal
> opinions as if they are ASF rules.
> 
> -Todd


signature.asc
Description: Digital signature

Re: [DISCUSS] Kudu incubator proposal

[Konstantin Boudnik]

On Sun, Nov 22, 2015 at 08:19PM, Mattmann, Chris A (3980) wrote:
> Hi,
> 
> Todd has answered this question already - that folks will be invited
> based on their contributions made during Incubation. The mentors on
> this project have a history of being inclusive, so I think we’re fine
> on that.
> 
> As for inviting people based on their company affiliation, this has
> been dealt with plenty of times in the Incubator, most recently
> Roy’s comments I believe in 2012 which summarize this - diversity,
> while to be encouraged, is not a strict requirement of Incubation.

Chris, I couldn't care less about where the contributors are coming from.
Basing the "diversity" on affiliaiton (or any other arbitrary property) is
quite bogus - I am with you and Roy on this. All I want to make sure that
people who contributed code and, perhaps, became inactive for a period of
time, are aware about the project trying to enter the incubation. Which might
trigger their wish to participate again.

Hopefully, the third time to clarify my initial point would be a charm ;)

Regards,
  Cos

> Cheers,
> Chris
> 
> ++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++
> 
> 
> 
> 
> 
> -Original Message-
> From: Konstantin Boudnik <c...@apache.org>
> Reply-To: <general@incubator.apache.org>
> Date: Sunday, November 22, 2015 at 12:14 PM
> To: <general@incubator.apache.org>
> Subject: Re: [DISCUSS] Kudu incubator proposal
> 
> >My point exactly, thanks Henry!
> >
> >On Tue, Nov 17, 2015 at 10:51PM, Henry Saputra wrote:
> >> Hi Todd,
> >> 
> >> One concern, other IPMCs could help correct me if I am wrong, for
> >> project that already open source and accepting contributions from
> >> individuals which not part of initial committers is that it needs to
> >> get the consent or grant from those contributors when moving to ASF.
> >> Unless, the individuals have already signed the one for Cloudera when
> >> contributing to Kudu.
> >> 
> >> Want to make sure the software grant concern be addressed early.
> >> 
> >> Thanks,
> >> 
> >> - Henry
> >> 
> >> On Tue, Nov 17, 2015 at 6:47 PM, Todd Lipcon <t...@apache.org> wrote:
> >> > On Tue, Nov 17, 2015 at 6:36 PM, Luke Han <luke...@gmail.com> wrote:
> >> >
> >> >> In "community" section of this proposal, there are many companies
> >> >> have been mentioned including Xiaomi, Dropbox, Intel and Dremio,
> >> >> and said there are contributions from them.
> >> >>
> >> >> I think their engineers are more interesting and be involved
> >> >> in Kudu actively, why not think about to invite them to be committer
> >>first?
> >> >>
> >> >
> >> > Per earlier messages on the thread and per the proposal: because they
> >> > haven't yet shown significant contributions over a sustained period.
> >> > Interest is one thing, but interest is not sufficient to become a
> >>committer
> >> > in a meritocracy. The folks called out in the community section are
> >>those
> >> > who have interest and are somewhere on the path towards
> >>committership, but
> >> > aren't there yet. I have every hope (and expectation) that they will
> >>get
> >> > there if they keep up their good work.
> >> >
> >> > I would rather not discuss specific people's progress towards
> >>committership
> >> > in a public forum. Rather, I hoped that we could start with the
> >>proposed
> >> > committer list, and during incubation we can discuss potential new
> >> > committers and PMC members following the typical ASF processes on our
> >> > PPMC's private list. I'm counting on our experienced mentors to keep
> >>us all
> >> > honest -- they should absolutely call us out if the initial
> >>committers act
> >> > exclusionary or otherwise violate the ASF principles of being an
> >>inclusive
> >> > meritocracy.
> >> >
> >> > -Todd
> >> 
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >> 
> 


signature.asc
Description: Digital signature

Re: [DISCUSS] Impala incubator proposal

[Konstantin Boudnik]

On Tue, Nov 17, 2015 at 02:26PM, Henry Robinson wrote:
> Hi Henry -
> 
> Absolutely, although I want to point out that only two of our three mentors

which clearly constitutes "almost all" as Henry pointed out :)

On a different note: have the initial delopers considered a possibility of
bringing the code to Apache Drill, which in my uneducated view seems to be
covering most of the bases in this case? 

Thanks,
  Cos

> are Cloudera employees. That said, we'd of course be delighted to consider
> any additional offers of mentorship.
> 
> Best,
> Henry
> 
> On 17 November 2015 at 14:17, Henry Saputra  wrote:
> 
> > Glad to have the proposal :)
> >
> > Immediate glance would show almost all, including mentors, are coming from
> > Cloudera. I think it would be beneficial for the podling to have at
> > least mentors from different org to provide bit of balance.
> >
> > - Henry
> >
> > On Tuesday, November 17, 2015, Henry Robinson  wrote:
> >
> > > Hi all -
> > >
> > > We'd like to start a discussion regarding a proposal to submit Impala to
> > > the Apache Incubator.
> > >
> > > The proposal text is available on the Wiki here:
> > > https://wiki.apache.org/incubator/ImpalaProposal
> > >
> > > and pasted below for convenience.
> > >
> > > I'm excited to make this proposal, and look forward to the community's
> > > input!
> > >
> > > Best,
> > > Henry
> > >
> > >
> > > = Abstract =
> > > Impala is a high-performance C++ and Java SQL query engine for data
> > stored
> > > in Apache Hadoop-based clusters.
> > >
> > > = Proposal =
> > >
> > > We propose to contribute the Impala codebase and associated artifacts
> > (e.g.
> > > documentation, web-site content etc.) to the Apache Software Foundation
> > > with the intent of forming a productive, meritocratic and open community
> > > around Impala’s continued development, according to the ‘Apache Way’.
> > >
> > > Cloudera owns several trademarks regarding Impala, and proposes to
> > transfer
> > > ownership of those trademarks in full to the ASF.
> > >
> > > = Background =
> > > Engineers at Cloudera developed Impala and released it as an
> > > Apache-licensed open-source project in Fall 2012. Impala was written as a
> > > brand-new, modern C++ SQL engine targeted from the start for data stored
> > in
> > > Apache Hadoop clusters.
> > >
> > > Impala’s most important benefit to users is high-performance, making it
> > > extremely appropriate for common enterprise analytic and business
> > > intelligence workloads. This is achieved by a number of software
> > > techniques, including: native support for data stored in HDFS and related
> > > filesystems, just-in-time compilation and optimization of individual
> > query
> > > plans, high-performance C++ codebase and massively-parallel distributed
> > > architecture. In benchmarks, Impala is routinely amongst the very highest
> > > performing SQL query engines.
> > >
> > > = Rationale =
> > >
> > > Despite the exciting innovation in the so-called ‘big-data’ space, SQL
> > > remains by far the most common interface for interacting with data in
> > both
> > > traditional warehouses and modern ‘big-data’ clusters. There is clearly a
> > > need, as evidenced by the eager adoption of Impala and other SQL engines
> > in
> > > enterprise contexts, for a query engine that offers the familiar SQL
> > > interface, but that has been specifically designed to operate in massive,
> > > distributed clusters rather than in traditional, fixed-hardware,
> > > warehouse-specific deployments. Impala is one such query engine.
> > >
> > > We believe that the ASF is the right venue to foster an open-source
> > > community around Impala’s development. We expect that Impala will benefit
> > > from more productive collaboration with related Apache projects, and
> > under
> > > the auspices of the ASF will attract talented contributors who will push
> > > Impala’s development forward at pace.
> > >
> > > We believe that the timing is right for Impala’s development to move
> > > wholesale to the ASF: Impala is well-established, has been
> > Apache-licensed
> > > open-source for more than three years, and the core project is relatively
> > > stable. We are excited to see where an ASF-based community can take
> > Impala
> > > from this strong starting point.
> > >
> > > = Initial Goals =
> > > Our initial goals are as follows:
> > >
> > > * Establish ASF-compatible engineering practices and workflows
> > > * Refactor and publish existing internal build scripts and test
> > > infrastructure, in order to make them usable by any community member.
> > > * Transfer source code, documentation and associated artifacts to the
> > ASF.
> > > * Grow the user and developer communities
> > >
> > > = Current Status =
> > >
> > > Impala is developed as an Apache-licensed open-source project. The source
> > > code is available at http://github.com/cloudera/Impala, and developer
> > > documentation is at 

Re: [DISCUSS] Kudu incubator proposal

[Konstantin Boudnik]

On Tue, Nov 17, 2015 at 10:43AM, Todd Lipcon wrote:
> On Tue, Nov 17, 2015 at 10:38 AM, Atri Sharma  wrote:
> 
> > Sounds great.
> >
> > I would love to be an help as a committer, if possible. This seems to be
> > fantastic in line with my focus areas and can help existing big data
> > projects to accelerate so Kudu's growth is something I would care about.
> >
> 
> Hi Atri,
> 
> Thanks for the interest! Following the example of other recent incubator
> projects, we would like to keep the initial committer list to those who are
> already have a track record of contributions to the project. We'd love to
> have you involved as a contributor during incubation, and of course would
> be glad to add you as a committer after you've become a regular contributor.

Considering that the project has been closed-sourced until very recently such
"following" would surely create pretty high entry barrier for new committers.
Which of course would be a concern, from the community growth perspective.

Cos


signature.asc
Description: Digital signature

Re: [VOTE] Retire Corinthia

[Konstantin Boudnik]

+1 (binding)

On Sun, Nov 15, 2015 at 07:01PM, Marvin Humphrey wrote:
> Greetings,
> 
> The Corinthia community has voted to retire:
> 
>   http://s.apache.org/odN
> 
> This is a vote of the IPMC to confirm the decision to retire the podling.
> 
> [ ] +1 to retire Corinthia from the Incubator
> [ ] -1 to keep Corinthia in the Incubator
> 
> This vote will be held open for at least 72 hours.
> 
> Should this vote pass, I have volunteered to assist Corinthia with retirement,
> as I am assisting Droids and Kalumet.
> 
> Marvin Humphrey
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik]

On Tue, Nov 17, 2015 at 04:45PM, Todd Lipcon wrote:
> On Tue, Nov 17, 2015 at 4:37 PM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > On Tue, Nov 17, 2015 at 08:53AM, Bertrand Delacretaz wrote:
> > > On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <ted.dunn...@gmail.com>
> > wrote:
> > > > ...RTC can be framed as "I don't trust you to do things right"...
> > >
> > > Or also "I don't trust myself 100% to do things right here and would
> > > like systematic reviews of my commits".
> >
> > This sounds like "if I don't trust myself then no-one has to have this
> > freedom/choice/ability", eh?
> >
> 
> I'd never advocate that the ASF _mandate_ RTC on other projects. But if a
> project community decides to set up their process as such, I don't see why
> the foundation should have any issues with it. That's all I've been arguing
> in this thread: this whole discussion has pretty much no business in the
> incubator.

On the contrary... The business of the Incubator and IPMC is to help podlings
and their communities to grok and follow the Apache Way. Trust is a foundation
principal of a healthy community. Hence, this whole discussion has quite a lot
of business in the incubator.

Cos


signature.asc
Description: Digital signature

Re: [DISCUSS] Kudu incubator proposal

[Konstantin Boudnik]

On Tue, Nov 17, 2015 at 04:33PM, Todd Lipcon wrote:
> >
> >
> > > Hi Atri,
> > >
> > > Thanks for the interest! Following the example of other recent incubator
> > > projects, we would like to keep the initial committer list to those who
> > are
> > > already have a track record of contributions to the project. We'd love to
> > > have you involved as a contributor during incubation, and of course would
> > > be glad to add you as a committer after you've become a regular
> > contributor.
> >
> > Considering that the project has been closed-sourced until very recently
> > such
> > "following" would surely create pretty high entry barrier for new
> > committers.
> > Which of course would be a concern, from the community growth perspective.
> >
> 
> Sure, I expect the IPMC and our mentors to hold us to reasonable
> expectations during incubation.
> 
> For now, I think "meritocracy" should be followed -- when contributors
> demonstrate sufficient merit, we can add them as committers. Note that
> there are plenty of my coworkers who have made small contributions in the
> past, and they aren't listed as contributors either.

So, you're saying that people were chosen to be listed or not as the
contributors merely by the amount of the code they have contributed to the
project. Am I reading this right?

Cos


signature.asc
Description: Digital signature

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik]

On Tue, Nov 17, 2015 at 08:53AM, Bertrand Delacretaz wrote:
> On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning  wrote:
> > ...RTC can be framed as "I don't trust you to do things right"...
> 
> Or also "I don't trust myself 100% to do things right here and would
> like systematic reviews of my commits".

This sounds like "if I don't trust myself then no-one has to have this
freedom/choice/ability", eh?

> Like all sharp tools I think RTC has its place, but shouldn't be
> abused. It's perfectly possible to have some parts of a project's code
> under RTC and others under CTR.
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik]

On Mon, Nov 16, 2015 at 04:50PM, Greg Stein wrote:
> On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon  wrote:
> >...
> 
> > 1) You're right, I don't trust anybody to make code changes to a complex
> > project with zero oversight. I currently work on a project that I
> >
> 
> I have always found the "complex project" to merely be an excuse for
> control/no-trust.
> 
> All software is hard. Your project is no more complex than others.

+1 on that and what Ralph said. CTR provides a huge stimuli not to
write-n-push a crappy or semi-baked code. Precisely because of the trust put
on them by the community of the peers.

Cos


signature.asc
Description: Digital signature

Re: [DISCUSS] Kudu incubator proposal

[Konstantin Boudnik]

On Tue, Nov 17, 2015 at 04:53PM, Marvin Humphrey wrote:
> On Tue, Nov 17, 2015 at 4:42 PM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > So, you're saying that people were chosen to be listed or not as the
> > contributors merely by the amount of the code they have contributed to the
> > project. Am I reading this right?
> 
> We've had this debate about committer cattle call additions many
> times. The position that Todd is taking is completely reasonable. The
> expectation that just about anybody can join a project during the
> proposal phase is messed up and I wish that tradition had never caught

That's not my point, Marvin. The people who contributed less than 20 commits
(hmm, why not 4 or a 107?) are still contributors. And in my opinion, they at
least have to be invited to participate in the podling, if it is accepted by
IPMC. So, I will re-phrase: "was an invitation to participate in the project
extended to all contributors?".

Shall it be done formally or by providing "Interested Party" is an
implementation detail. 

Cos

> on. Instead, there ought to be an "Interested Party" section in the
> proposal template where people can express interest and "subscribe to
> your newsletter".
> 


signature.asc
Description: Digital signature

Re: Unsubscribe not working

[Konstantin Boudnik]

Potentially it might mean that you have also subscribed from other mail aliases?

On Sun, Nov 08, 2015 at 07:45PM, Robert Kausch - US wrote:
> Sorry for having to send this to the whole list, but I don't think the
> unsubscribe functionality is working. I've been trying for 10 days, and I'm
> still receiving email from the list. 
> 
> Sent from my iPhone
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Konstantin Boudnik]

On Mon, Nov 02, 2015 at 05:27PM, Vinod Vavilapalli wrote:
> Many of the active TLPs do tend to center all project discussions on JIRA as
> opposed to mailing lists. OTOH, non-code discussions are usually best served
> on mailing lists.
> 
> Instead of making it a JIRA vs mailing list discussion, how about the
> podling be advised about putting a cool-off period for JIRA resolutions -
> 24-36hrs before they get closed. Again, this is something a bunch of active
> TLPs practice in the interest of leaving enough time windows for everyone
> (many times around the world in different time-zones) to pitch in.

I think these might be good development practices, but if there's an
underlying issues with off-line decision making none of these tweak will solve
it. The root issue needs to be addressed, if it indeed exists.

But even for the tweaks you've proposed: some fixes/patches are mundane and
keeping them on-hold for an arbitrary number of the hours will simply slow
down the development. Some of the new features might be as well trivial: say
adding new build target to combine certain build functions in a more
convenient way, etc. etc. So, how to line up the rules and control they
are being followed? Creation new policies even before the graduation happened
sounds completely broken to me.

What's important IMO is that committers on a project have enough sense to know
when the input from the rest of the developers is needed and when a change is
trivial enough to "just go in". That's a part of the podling maturity, as I
see it: the effectiveness of the community inner-working; the trust that your
peers are doing "the right thing".

Cos

> > On Nov 2, 2015, at 3:59 AM, Joe Brockmeier  wrote:
> > 
> > Hi all,
> > 
> > I'm one of the mentors of Sentry, which has been in incubation for some
> > time. The project has progressed in a number of ways, but my largest
> > concern is that the podling is doing [in my opinion] too much
> > development and discussion out-of-sight. 
> > 
> > I've raised issues about this, as has David Nalley. David had a
> > conversation with members of Sentry at ApacheCon Big Data in September,
> > and that discussion was brought back to the list. [1] 
> > 
> > Jiras are being filed, and swiftly acted on, in a way that strongly
> > suggests that a lot of discussion and direction of the project are
> > happening off-list and out-of-sight to the average participant. David
> > and myself have suggested ways that the community can remedy this, but
> > the most recent mail from Arvind indicates that he (and others in the
> > podling) don't feel it is a "valid ask." 
> > 
> > At this point, I'm raising this to general@ because I'd like second (and
> > third, etc.) opinions. Perhaps I'm deeply wrong, and others here feel
> > Sentry is ready to graduate. My feeling is that the podling is not
> > operating in "the Apache Way" and doesn't show a great deal of interest
> > in doing so. [2] To quote Arvind: 
> > 
> > "I feel another issue being pointed out or which has been eluded to in
> > the past is - who decides which Jiras should be fixed, what features to
> > create etc, specially when they show up as Jira issues directly with
> > patches that follow soon. It seems that in some ways the lack of using
> > mailing lists directly for discussion is linked to this behavior of
> > filing issues and fixing them rapidly, as if following a roadmap that
> > the community does not have control over. Please pardon me if my
> > interpretation/understanding of the issue is not right. But if it is
> > right, then I do want to say that - that too is not an issue in my
> > opinion at all. And here is why:
> > 
> > When someone files a Jira, they are inviting the entire community to
> > comment on it and provide feedback. If it is not in the interest of the
> > project, I do believe that responsible members of the community will be
> > quick to bring that out for discussion and even Veto it if necessary. If
> > that is not happening, it is not an issue with lack of community
> > participation, but rather it is an indicator of a project team that
> > knows where the gaps are and understands how to go about filling them
> > intuitively."
> > 
> > The model that Sentry is pursing may work very well *for the existing
> > members of the podling.* In my opinion, its process is entirely too
> > opaque to allow for interested parties outside of the existing podling
> > and companies interested in Sentry development to become involved. 
> > 
> > The podling is pressing to move to graduation, and I cannot in good
> > conscience vote +1 or even +0 at this point. I'm strongly -1 as a mentor
> > and don't feel the podling has any interest in working in "the Apache
> > Way" as commonly understood. [3]
> > 
> > However, I feel we've reached an impasse and there's little value in
> > continuing to debate amongst the mentors / podling. They've stated their
> > position(s) and I've stated mine. (I *think* David Nalley 

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Konstantin Boudnik]

On Mon, Nov 02, 2015 at 04:27PM, Joe Brockmeier wrote:
> On 11/02/2015 03:57 PM, Patrick Hunt wrote:
> > I see this (the release discussion threads you linked) as a semi-mature
> > community that's well aligned. A number of folks responded to the request
> > for discussion and said they were in favor. It was done on the ML in the
> > open. What more do we want? I don't see anyone excluded and I'm sure if
> > there was a new person looking to get involved they would have been
> > welcomed into the discussion, no one is being turned away from what I can
> > see.
> 
> No one is being turned away, that I've noticed, but I really don't see
> how anyone is supposed to follow along if they're not part of the team
> already. I will say that the only Jira I've seen from outside recently
> didn't exactly get a warm reception. [1] Not rejected, just radio silence.
> 
> I'm also sad to see that being held up as a standard by other mentors.
> My understanding is that projects should be attempting to create a
> community that is open, and trying to self-perpetuate. Sure, you can't
> do that if you turn people away actively - but you also can't do that by
> having conversations offlist and having an opaque process that newcomers
> can't follow along with.
> 
> I'll say again - maybe my standards are improperly calibrated. If so,
> and "not actively turning people away" is the standard we're going
> for... that's disappointing as all heck.

I don't think your standards have became miscalibrated all of a sudden. These
community principles are what being instilled on new podlings by many here.
Hence I believe that a perceived new norm of "not actively turning people
away" should be dealt with by the first the mentors and backed up by the whole
incubation model, including shepherds.

Cos

> [1] https://issues.apache.org/jira/browse/SENTRY-934
> -- 
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

On Mon, Nov 02, 2015 at 07:25AM, Rich Bowen wrote:
> 
> 
> On 11/01/2015 07:48 PM, Konstantin Boudnik wrote:
> >Thanks for sending this around, Paul - I should've linked it to the vote
> >thread, duh...
> >
> >Anyway, back to Rich's question: the answer is 'yes' as implied by my +1 on
> >the vote. Why would I be voting for the graduation if I weren't sure the
> >project is ready? Looks like a rhetorical question, this one.
> 
> No, it's not a rhetorical question at all. I suspect, as I have
> mentioned in other threads, that some people vote +1 on these things
> without doing a whole lot of background checking. Paul's response is
> what I was looking for.
> 
> If it's all just rhetorical questions then why do we bother at all?
> Graduation is a one-time thing. We can afford to apply a little
> additional scrutiny to it. This is something we can't afford to get
> wrong.

The one I called rhetorical was actually my last quesiton, not yours.

Cos

> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

On Mon, Nov 02, 2015 at 09:11AM, Emmanuel Lécharny wrote:
> Le 01/11/15 20:30, Rich Bowen a écrit :
> > On Oct 28, 2015 4:26 PM, "Konstantin Boudnik" <c...@apache.org> wrote:
> >> Following discussions [1] about its current status, the Groovy community
> >> has voted [2] to graduate from the Incubator. The vote passed [3] with 12
> > +1s
> >> total, 5 are binding:
> >>
> >> Guillaume Laforge
> >> Cédric Champeau
> >> Paul King
> >> Jochen Theodorou
> >> Pascal Schumacher
> >> Emmanuel Lécharny (binding)
> >> Bertrand Delacretaz (binding)
> >> Andrew Bayer (binding)
> >> Jim Jagielski (binding)
> >> Konstantin Boudnik (binding)
> >> Russel Winder
> >> Guillaume Alleon
> >>
> >> The Groovy community has:
> >> * completed all required paperwork:
> >> https://incubator.apache.org/projects/groovy.html
> >> * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works)
> >> * completed the name check procedure:
> >> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88
> >> * addressed 50+ JIRAs:
> >> http://is.gd/1tACON
> >> * voted in multiple new committers/PPMC members
> >>
> >> Therefore, I'm calling a VOTE to graduate Groovy with the following Board
> >> resolution. The VOTE will run for at least 72 hours, ending
> >> Saturday, October 31st 8 PM PST.
> > I recognize that I have missed the vote and thus my response is moot. I
> > have been traveling, but i don't expect preferential treatment.
> >
> > However, as useful as these other measures are, as a member, and as a
> > director who will need to vote on this resolution, I'd like to know if you,
> > as a mentor, feel that this project had attainded maturity as described in
> > the maturity metric document, and will operate according to the Apache way?
> Yes, and Bertrand has conducted the check we now run on poddling we
> think are ready to become TLP.
> 
> As a mentor who have followed a few podlings in the past, I must say
> that Groovy was one of the easiest ! OTOH, the project was already
> mature before being accepted in incubator. Keep in mind that this move
> was dictated by the decision from Pivotal to stop paying the main
> developpers, combined with the shutdown of the Codehaus hosting
> facility. The Groovy fellows decided that The ASF was the best place to
> host the project, and they did a long due diligence to check that the
> ASF requirements were easy to follow for them. In many ways, it was all
> about finding the right place for the project, and The ASF was a perfect
> fit.

If we want the credit go where it's due - let's not forget about Roman's
effort to present the case, spent a lot of time advocating, and helping Groovy
project to finally come under the Foundation's wing.

Cos

> Every single requirements (IP clearance, voting releases, accepting new
> committers, discussion on the ML, etc) where easily met, and the groovy
> community was really open minded and ready for any required change in
> their way of doing things. Mature ? You bet !
> 
> My 2cts
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

Thanks for sending this around, Paul - I should've linked it to the vote
thread, duh... 

Anyway, back to Rich's question: the answer is 'yes' as implied by my +1 on
the vote. Why would I be voting for the graduation if I weren't sure the
project is ready? Looks like a rhetorical question, this one.

Regards,
  Cos

On Mon, Nov 02, 2015 at 09:10AM, Paul King wrote:
> I certainly don't want to limit discussion but if anyone hasn't seen it
> yet,  here is the direct link to our self assessment against the maturity
> metrics (completed with the assistance of our mentors in particular
> Bertrand):
> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc
> On 2 Nov 2015 5:30 am, "Rich Bowen" <rbo...@rcbowen.com> wrote:
> 
> > On Oct 28, 2015 4:26 PM, "Konstantin Boudnik" <c...@apache.org> wrote:
> > >
> > > Following discussions [1] about its current status, the Groovy community
> > > has voted [2] to graduate from the Incubator. The vote passed [3] with 12
> > +1s
> > > total, 5 are binding:
> > >
> > > Guillaume Laforge
> > > Cédric Champeau
> > > Paul King
> > > Jochen Theodorou
> > > Pascal Schumacher
> > > Emmanuel Lécharny (binding)
> > > Bertrand Delacretaz (binding)
> > > Andrew Bayer (binding)
> > > Jim Jagielski (binding)
> > > Konstantin Boudnik (binding)
> > > Russel Winder
> > > Guillaume Alleon
> > >
> > > The Groovy community has:
> > > * completed all required paperwork:
> > > https://incubator.apache.org/projects/groovy.html
> > > * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works)
> > > * completed the name check procedure:
> > > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88
> > > * addressed 50+ JIRAs:
> > > http://is.gd/1tACON
> > > * voted in multiple new committers/PPMC members
> > >
> > > Therefore, I'm calling a VOTE to graduate Groovy with the following Board
> > > resolution. The VOTE will run for at least 72 hours, ending
> > > Saturday, October 31st 8 PM PST.
> >
> > I recognize that I have missed the vote and thus my response is moot. I
> > have been traveling, but i don't expect preferential treatment.
> >
> > However, as useful as these other measures are, as a member, and as a
> > director who will need to vote on this resolution, I'd like to know if you,
> > as a mentor, feel that this project had attainded maturity as described in
> > the maturity metric document, and will operate according to the Apache way?
> >
> > >
> > > [ ] +1 Graduate Apache Groovy from the Incubator.
> > > [ ] +0 Don't care.
> > > [ ] -1 Don't graduate Apache Groovy from the Incubator because ...
> > >
> > > Regards,
> > > Cos
> > >
> > > [1] http://is.gd/DX41lO
> > > [2] http://is.gd/pPweq3
> > > [3] http://is.gd/VTLiqO
> > >
> > >  Apache Groovy graduation resolution draft
> > >
> > > Establish the Apache Groovy Top-Level Project
> > >
> > > WHEREAS, the Board of Directors deems it to be in the best interests
> > > of the Foundation and consistent with the Foundation's purpose to
> > > establish a Project Management Committee charged with the evolution
> > > and maintenance of the Groovy programming language,
> > >
> > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > > (PMC), to be known as the "Apache Groovy Project", be and hereby is
> > > established pursuant to Bylaws of the Foundation; and be it further
> > >
> > > RESOLVED, that the Apache Groovy Project be and hereby is responsible
> > > for the evolution and maintenance of the Groovy programming language;
> > > and be it further
> > >
> > > RESOLVED, that the office of "Vice President, Apache Groovy" be and
> > > hereby is created, the person holding such office to serve at the
> > > direction of the Board of Directors as the chair of the Apache Groovy
> > > Project, and to have primary responsibility for management of the
> > > projects within the scope of responsibility of the Apache Groovy
> > > Project; and be it further
> > >
> > > RESOLVED, that the persons listed immediately below be and hereby are
> > > appointed to serve as the initial members of the Apache Groovy Project
> > > PMC:
> > >
> > > Cédric Champeau <ce

[RESULT] [VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

The VOTE to graduate Groovy to the top-level project has passed with
15 binding +1s and 3 non-binding +1s. No 0 or -1 votes were casted.

Binding:
Chris Mattmann
Konstantin Boudnik
Julian Hyde
Marvin Humphrey
Emmanuel Lécharny
Sergio Fernández
Steve Loughran 
Luciano Resende
Jean-Baptiste Onofré
Jake Farrell   
Jean-Louis MONTEIRO
Edward J. Yoon 
John D. Ament  
Jim Jagielski
Roman Shaposhnik

Non-binding
Phillip Rhodes 
Jacques Le Roux
Luke Han   

Thanks everyone for your Groovy votes!

The following resolution will be added to the next board meeting agenda:

 Apache Groovy graduation resolution draft

Establish the Apache Groovy Top-Level Project

WHEREAS, the Board of Directors deems it to be in the best interests
of the Foundation and consistent with the Foundation's purpose to
establish a Project Management Committee charged with the evolution
and maintenance of the Groovy programming language,

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
(PMC), to be known as the "Apache Groovy Project", be and hereby is
established pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache Groovy Project be and hereby is responsible
for the evolution and maintenance of the Groovy programming language;
and be it further

RESOLVED, that the office of "Vice President, Apache Groovy" be and
hereby is created, the person holding such office to serve at the
direction of the Board of Directors as the chair of the Apache Groovy
Project, and to have primary responsibility for management of the
projects within the scope of responsibility of the Apache Groovy
Project; and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Apache Groovy Project
PMC:
Cédric Champeau <cchamp...@apache.org>
Paul King <pa...@apache.org>
Guillaume Laforge <glafo...@apache.org>
Pascal Schumacher <pascalschumac...@apache.org>
Jochen Theodorou <blackd...@apache.org>
    Andrew Bayer <aba...@apache.org>
Konstantin Boudnik <c...@apache.org>
Roman Shaposhnik <r...@apache.org>
Jim Jagielski <j...@apache.org>


NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be
appointed to the office of Vice President, Apache Groovy, to serve in
accordance with and subject to the direction of the Board of Directors
and the Bylaws of the Foundation until death, resignation, retirement,
removal or disqualification, or until a successor is appointed; and be
it further

RESOLVED, that the Apache Groovy Project be and hereby is tasked with
the migration and rationalization of the Apache Incubator Groovy
podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
Groovy podling encumbered upon the Apache Incubator Project are
hereafter discharged.



signature.asc
Description: Digital signature

Re: [VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

Yup, and as Marvin said it is 'should' which doesn't imply a compulsion.

I am going to wrap the vote now. Thanks,
  Cos

On Sat, Oct 31, 2015 at 10:12PM, John D. Ament wrote:
> Cos,
> 
> You mean this line?
> 
> The resolution
> <https://incubator.apache.org/guides/graduation.html#tlp-resolution> should
> be proposed on the general incubator list <general@incubator.apache.org> 
> before
> a VOTE <http://www.apache.org/foundation/voting.html> is started to allow
> feedback.
> 
> John
> 
> On Fri, Oct 30, 2015 at 2:37 PM Konstantin Boudnik <c...@apache.org> wrote:
> 
> > John,
> >
> > according to [1] the discussion could be done inside of the voting and
> > isn't
> > explicitly required. That was my only motive going to the [VOTE] directly.
> >
> > Regards,
> >   Cos
> >
> > [1]
> > https://incubator.apache.org/guides/graduation.html#ipmc-top-level-recommendation
> >
> > On Fri, Oct 30, 2015 at 06:35AM, John D. Ament wrote:
> > > The only thing that catches me off guard is lack of a discuss thread.
> > But
> > > I can give +1
> > > On Oct 28, 2015 16:26, "Konstantin Boudnik" <c...@apache.org> wrote:
> > >
> > > > Following discussions [1] about its current status, the Groovy
> > community
> > > > has voted [2] to graduate from the Incubator. The vote passed [3] with
> > 12
> > > > +1s
> > > > total, 5 are binding:
> > > >
> > > > Guillaume Laforge
> > > > Cédric Champeau
> > > > Paul King
> > > > Jochen Theodorou
> > > > Pascal Schumacher
> > > > Emmanuel Lécharny (binding)
> > > > Bertrand Delacretaz (binding)
> > > > Andrew Bayer (binding)
> > > > Jim Jagielski (binding)
> > > > Konstantin Boudnik (binding)
> > > > Russel Winder
> > > > Guillaume Alleon
> > > >
> > > > The Groovy community has:
> > > > * completed all required paperwork:
> > > > https://incubator.apache.org/projects/groovy.html
> > > > * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works)
> > > > * completed the name check procedure:
> > > > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88
> > > > * addressed 50+ JIRAs:
> > > > http://is.gd/1tACON
> > > > * voted in multiple new committers/PPMC members
> > > >
> > > > Therefore, I'm calling a VOTE to graduate Groovy with the following
> > Board
> > > > resolution. The VOTE will run for at least 72 hours, ending
> > > > Saturday, October 31st 8 PM PST.
> > > >
> > > > [ ] +1 Graduate Apache Groovy from the Incubator.
> > > > [ ] +0 Don't care.
> > > > [ ] -1 Don't graduate Apache Groovy from the Incubator because ...
> > > >
> > > > Regards,
> > > > Cos
> > > >
> > > > [1] http://is.gd/DX41lO
> > > > [2] http://is.gd/pPweq3
> > > > [3] http://is.gd/VTLiqO
> > > >
> > > >  Apache Groovy graduation resolution draft
> > > >
> > > > Establish the Apache Groovy Top-Level Project
> > > >
> > > > WHEREAS, the Board of Directors deems it to be in the best interests
> > > > of the Foundation and consistent with the Foundation's purpose to
> > > > establish a Project Management Committee charged with the evolution
> > > > and maintenance of the Groovy programming language,
> > > >
> > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > > > (PMC), to be known as the "Apache Groovy Project", be and hereby is
> > > > established pursuant to Bylaws of the Foundation; and be it further
> > > >
> > > > RESOLVED, that the Apache Groovy Project be and hereby is responsible
> > > > for the evolution and maintenance of the Groovy programming language;
> > > > and be it further
> > > >
> > > > RESOLVED, that the office of "Vice President, Apache Groovy" be and
> > > > hereby is created, the person holding such office to serve at the
> > > > direction of the Board of Directors as the chair of the Apache Groovy
> > > > Project, and to have primary responsibility for management of the
> > > > projects within the scope of responsibility of the Apache Groovy
> > > > Proje

Re: [VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

And with Jim's late response to the Groovy community invitation to join the
PMC the final list going into the resolution will look like this

Cédric Champeau <cchamp...@apache.org>
Paul King <pa...@apache.org>
Guillaume Laforge <glafo...@apache.org>
Pascal Schumacher <pascalschumac...@apache.org>
Jochen Theodorou <blackd...@apache.org>
Andrew Bayer <aba...@apache.org>
Konstantin Boudnik <c...@apache.org>
Roman Shaposhnik <r...@apache.org>
Jim Jagielski <j...@apache.org>

Again - my apologies for the mess. The [VOTE] goes for another day, and if
anyone feel like it needs to be restarted because of the last minute additions
- please voice your opinion here.

Thanks,
  Cos

On Thu, Oct 29, 2015 at 10:17PM, Konstantin Boudnik wrote:
> Per suggestions on this thread and thanks to Marvin's effort, the emails of
> the proposed PMC will be updated on the draft with the @apache.org addresses
> as in:
> 
> Cédric Champeau <cchamp...@apache.org>
> Paul King <pa...@apache.org>
> Guillaume Laforge <glafo...@apache.org>
> Pascal Schumacher <pascalschumac...@apache.org>
>     Jochen Theodorou <blackd...@apache.org>
> Andrew Bayer <aba...@apache.org>
> Konstantin Boudnik <c...@apache.org>
> 
> Also, we missed one of the mentors in action; the invitation has been extended
> to him, but due to his travels he was late to respond. So, if there's no
> objections I will add one more PMC member when submitting the resolution to
> the board (given this vote will pass):
> 
> Roman Shaposhnik <r...@apache.org>
> 
> If anyone feels that the [VOTE] needs to be restarted because of the clerical
> error - please speak and I'd be happy to do it. Sorry for all the jitter.
> 
> Cos
> 
> On Wed, Oct 28, 2015 at 11:26PM, Konstantin Boudnik wrote:
> > Following discussions [1] about its current status, the Groovy community
> > has voted [2] to graduate from the Incubator. The vote passed [3] with 12 
> > +1s
> > total, 5 are binding:
> > 
> > Guillaume Laforge
> > Cédric Champeau
> > Paul King
> > Jochen Theodorou
> > Pascal Schumacher
> > Emmanuel Lécharny (binding)
> > Bertrand Delacretaz (binding)
> > Andrew Bayer (binding)
> > Jim Jagielski (binding)
> > Konstantin Boudnik (binding)
> > Russel Winder
> > Guillaume Alleon
> > 
> > The Groovy community has:
> > * completed all required paperwork:
> > https://incubator.apache.org/projects/groovy.html
> > * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works)
> > * completed the name check procedure:
> > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88
> > * addressed 50+ JIRAs:
> > http://is.gd/1tACON
> > * voted in multiple new committers/PPMC members
> > 
> > Therefore, I'm calling a VOTE to graduate Groovy with the following Board
> > resolution. The VOTE will run for at least 72 hours, ending
> > Saturday, October 31st 8 PM PST.
> > 
> > [ ] +1 Graduate Apache Groovy from the Incubator.
> > [ ] +0 Don't care.
> > [ ] -1 Don't graduate Apache Groovy from the Incubator because ...
> > 
> > Regards,
> > Cos
> > 
> > [1] http://is.gd/DX41lO
> > [2] http://is.gd/pPweq3
> > [3] http://is.gd/VTLiqO
> > 
> >  Apache Groovy graduation resolution draft
> > 
> > Establish the Apache Groovy Top-Level Project
> > 
> > WHEREAS, the Board of Directors deems it to be in the best interests
> > of the Foundation and consistent with the Foundation's purpose to
> > establish a Project Management Committee charged with the evolution
> > and maintenance of the Groovy programming language,
> > 
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > (PMC), to be known as the "Apache Groovy Project", be and hereby is
> > established pursuant to Bylaws of the Foundation; and be it further
> > 
> > RESOLVED, that the Apache Groovy Project be and hereby is responsible
> > for the evolution and maintenance of the Groovy programming language;
> > and be it further
> > 
> > RESOLVED, that the office of "Vice President, Apache Groovy" be and
> > hereby is created, the person holding such office to serve at the
> > direction of the Board of Directors as the chair of the Apache Groovy
> > Project, and to have primary responsibility for management of the
> > projects within the scope of responsibility of the Apache Groovy
> > Project; and be it further
> > 
&

Re: [VOTE] Retire Droids (IPMC)

[Konstantin Boudnik]

+1

On Thu, Oct 29, 2015 at 12:36PM, Marvin Humphrey wrote:
> Greetings,
> 
> The Droids community has voted to retire:
> 
>   http://s.apache.org/Rko
> 
> This is a vote of the IPMC to confirm the decision to retire the podling.
> 
> [ ] +1 to retire Droids from the incubator
> [ ] -1 to keep Droids in the incubator
> 
> This vote will be held open for at least 72 hours.
> 
> Marvin Humphrey
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [VOTE] Retire Kalumet (IPMC)

[Konstantin Boudnik]

+1

On Thu, Oct 29, 2015 at 12:38PM, Marvin Humphrey wrote:
> Greetings,
> 
> The Kalumet community has voted to retire:
> 
>   http://s.apache.org/fP
> 
> This is a vote of the IPMC to confirm the decision to retire the podling.
> 
> [ ] +1 to retire Kalumet from the incubator
> [ ] -1 to keep Kalumet in the incubator
> 
> This vote will be held open for at least 72 hours.
> 
> Marvin Humphrey
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

John,

according to [1] the discussion could be done inside of the voting and isn't
explicitly required. That was my only motive going to the [VOTE] directly.

Regards,
  Cos

[1] 
https://incubator.apache.org/guides/graduation.html#ipmc-top-level-recommendation

On Fri, Oct 30, 2015 at 06:35AM, John D. Ament wrote:
> The only thing that catches me off guard is lack of a discuss thread.  But
> I can give +1
> On Oct 28, 2015 16:26, "Konstantin Boudnik" <c...@apache.org> wrote:
> 
> > Following discussions [1] about its current status, the Groovy community
> > has voted [2] to graduate from the Incubator. The vote passed [3] with 12
> > +1s
> > total, 5 are binding:
> >
> > Guillaume Laforge
> > Cédric Champeau
> > Paul King
> > Jochen Theodorou
> > Pascal Schumacher
> > Emmanuel Lécharny (binding)
> > Bertrand Delacretaz (binding)
> > Andrew Bayer (binding)
> > Jim Jagielski (binding)
> > Konstantin Boudnik (binding)
> > Russel Winder
> > Guillaume Alleon
> >
> > The Groovy community has:
> > * completed all required paperwork:
> > https://incubator.apache.org/projects/groovy.html
> > * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works)
> > * completed the name check procedure:
> > https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88
> > * addressed 50+ JIRAs:
> > http://is.gd/1tACON
> > * voted in multiple new committers/PPMC members
> >
> > Therefore, I'm calling a VOTE to graduate Groovy with the following Board
> > resolution. The VOTE will run for at least 72 hours, ending
> > Saturday, October 31st 8 PM PST.
> >
> > [ ] +1 Graduate Apache Groovy from the Incubator.
> > [ ] +0 Don't care.
> > [ ] -1 Don't graduate Apache Groovy from the Incubator because ...
> >
> > Regards,
> > Cos
> >
> > [1] http://is.gd/DX41lO
> > [2] http://is.gd/pPweq3
> > [3] http://is.gd/VTLiqO
> >
> >  Apache Groovy graduation resolution draft
> >
> > Establish the Apache Groovy Top-Level Project
> >
> > WHEREAS, the Board of Directors deems it to be in the best interests
> > of the Foundation and consistent with the Foundation's purpose to
> > establish a Project Management Committee charged with the evolution
> > and maintenance of the Groovy programming language,
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > (PMC), to be known as the "Apache Groovy Project", be and hereby is
> > established pursuant to Bylaws of the Foundation; and be it further
> >
> > RESOLVED, that the Apache Groovy Project be and hereby is responsible
> > for the evolution and maintenance of the Groovy programming language;
> > and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache Groovy" be and
> > hereby is created, the person holding such office to serve at the
> > direction of the Board of Directors as the chair of the Apache Groovy
> > Project, and to have primary responsibility for management of the
> > projects within the scope of responsibility of the Apache Groovy
> > Project; and be it further
> >
> > RESOLVED, that the persons listed immediately below be and hereby are
> > appointed to serve as the initial members of the Apache Groovy Project
> > PMC:
> >
> > Cédric Champeau <cedric.champ...@gmail.com>
> > Paul King <pa...@asert.com.au>
> > Guillaume Laforge <glafo...@gmail.com>
> > Pascal Schumacher <pascalschumac...@gmx.net>
> > Jochen Theodorou <blackd...@gmx.org>
> > Andrew Bayer <andrew.ba...@gmail.com>
> > Konstantin Boudnik <c...@apache.org>
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be
> > appointed to the office of Vice President, Apache Groovy, to serve in
> > accordance with and subject to the direction of the Board of Directors
> > and the Bylaws of the Foundation until death, resignation, retirement,
> > removal or disqualification, or until a successor is appointed; and be
> > it further
> >
> > RESOLVED, that the Apache Groovy Project be and hereby is tasked with
> > the migration and rationalization of the Apache Incubator Groovy
> > podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache Incubator
> > Groovy podling encumbered upon the Apache Incubator Project are
> > hereafter discharged.
> >


signature.asc
Description: Digital signature

Re: [VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

Per suggestions on this thread and thanks to Marvin's effort, the emails of
the proposed PMC will be updated on the draft with the @apache.org addresses
as in:

Cédric Champeau <cchamp...@apache.org>
Paul King <pa...@apache.org>
Guillaume Laforge <glafo...@apache.org>
Pascal Schumacher <pascalschumac...@apache.org>
Jochen Theodorou <blackd...@apache.org>
Andrew Bayer <aba...@apache.org>
Konstantin Boudnik <c...@apache.org>

Also, we missed one of the mentors in action; the invitation has been extended
to him, but due to his travels he was late to respond. So, if there's no
objections I will add one more PMC member when submitting the resolution to
the board (given this vote will pass):

Roman Shaposhnik <r...@apache.org>

If anyone feels that the [VOTE] needs to be restarted because of the clerical
error - please speak and I'd be happy to do it. Sorry for all the jitter.

Cos

On Wed, Oct 28, 2015 at 11:26PM, Konstantin Boudnik wrote:
> Following discussions [1] about its current status, the Groovy community
> has voted [2] to graduate from the Incubator. The vote passed [3] with 12 +1s
> total, 5 are binding:
> 
> Guillaume Laforge
> Cédric Champeau
> Paul King
> Jochen Theodorou
> Pascal Schumacher
> Emmanuel Lécharny (binding)
> Bertrand Delacretaz (binding)
> Andrew Bayer (binding)
> Jim Jagielski (binding)
> Konstantin Boudnik (binding)
> Russel Winder
> Guillaume Alleon
> 
> The Groovy community has:
> * completed all required paperwork:
> https://incubator.apache.org/projects/groovy.html
> * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works)
> * completed the name check procedure:
> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88
> * addressed 50+ JIRAs:
> http://is.gd/1tACON
> * voted in multiple new committers/PPMC members
> 
> Therefore, I'm calling a VOTE to graduate Groovy with the following Board
> resolution. The VOTE will run for at least 72 hours, ending
> Saturday, October 31st 8 PM PST.
> 
> [ ] +1 Graduate Apache Groovy from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Groovy from the Incubator because ...
> 
> Regards,
> Cos
> 
> [1] http://is.gd/DX41lO
> [2] http://is.gd/pPweq3
> [3] http://is.gd/VTLiqO
> 
>  Apache Groovy graduation resolution draft
> 
> Establish the Apache Groovy Top-Level Project
> 
> WHEREAS, the Board of Directors deems it to be in the best interests
> of the Foundation and consistent with the Foundation's purpose to
> establish a Project Management Committee charged with the evolution
> and maintenance of the Groovy programming language,
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Groovy Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
> 
> RESOLVED, that the Apache Groovy Project be and hereby is responsible
> for the evolution and maintenance of the Groovy programming language;
> and be it further
> 
> RESOLVED, that the office of "Vice President, Apache Groovy" be and
> hereby is created, the person holding such office to serve at the
> direction of the Board of Directors as the chair of the Apache Groovy
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache Groovy
> Project; and be it further
> 
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache Groovy Project
> PMC:
> 
> Cédric Champeau <cedric.champ...@gmail.com>
> Paul King <pa...@asert.com.au>
> Guillaume Laforge <glafo...@gmail.com>
> Pascal Schumacher <pascalschumac...@gmx.net>
> Jochen Theodorou <blackd...@gmx.org>
> Andrew Bayer <andrew.ba...@gmail.com>
> Konstantin Boudnik <c...@apache.org>
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be
> appointed to the office of Vice President, Apache Groovy, to serve in
> accordance with and subject to the direction of the Board of Directors
> and the Bylaws of the Foundation until death, resignation, retirement,
> removal or disqualification, or until a successor is appointed; and be
> it further
> 
> RESOLVED, that the Apache Groovy Project be and hereby is tasked with
> the migration and rationalization of the Apache Incubator Groovy
> podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> Groovy podling encumbered upon the Apache Incubator Project are
> hereafter discharged.




signature.asc
Description: Digital signature

Re: [VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

Agree with the use of @apache.org addresses 100% - should've been caught
earlier by the mentors (shame on my, particularly, for submitting without
re-checking this bit). If people here feel like restarting the vote - I'd be
happy to do it. If no one has a strong opinion about the re-voting - I will
fix it before adding to the board's agenda for Nov (assuming the vote passes).

Cos

On Wed, Oct 28, 2015 at 02:14PM, Marvin Humphrey wrote:
> On Wed, Oct 28, 2015 at 1:26 PM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > [ ] +1 Graduate Apache Groovy from the Incubator.
> > [ ] +0 Don't care.
> > [ ] -1 Don't graduate Apache Groovy from the Incubator because ...
> 
> +1
> 
> I lurked on the Groovy dev list for a while and they did great.  The
> community handled some pretty challenging licensing stuff well (stars
> to Paul King for doing some heavy lifting).
> 
> The incubation checklist looks good.  The language of the graduation
> resolution looks good, but one thing:
> 
> > Cédric Champeau <cedric.champ...@gmail.com>
> > Paul King <pa...@asert.com.au>
> > Guillaume Laforge <glafo...@gmail.com>
> > Pascal Schumacher <pascalschumac...@gmx.net>
> > Jochen Theodorou <blackd...@gmx.org>
> > Andrew Bayer <andrew.ba...@gmail.com>
> > Konstantin Boudnik <c...@apache.org>
> 
> If past resolutions are guide, those should all be Apache email addresses.
> 
> No need for a revote, as the text of the resolution is only advisory
> -- but I think it should be updated before submitting to the Board.
> 
> Bon voyage!
> 
> Marvin Humphrey
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

[VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

Following discussions [1] about its current status, the Groovy community
has voted [2] to graduate from the Incubator. The vote passed [3] with 12 +1s
total, 5 are binding:

Guillaume Laforge
Cédric Champeau
Paul King
Jochen Theodorou
Pascal Schumacher
Emmanuel Lécharny (binding)
Bertrand Delacretaz (binding)
Andrew Bayer (binding)
Jim Jagielski (binding)
Konstantin Boudnik (binding)
Russel Winder
Guillaume Alleon

The Groovy community has:
* completed all required paperwork:
https://incubator.apache.org/projects/groovy.html
* completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works)
* completed the name check procedure:
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88
* addressed 50+ JIRAs:
http://is.gd/1tACON
* voted in multiple new committers/PPMC members

Therefore, I'm calling a VOTE to graduate Groovy with the following Board
resolution. The VOTE will run for at least 72 hours, ending
Saturday, October 31st 8 PM PST.

[ ] +1 Graduate Apache Groovy from the Incubator.
[ ] +0 Don't care.
[ ] -1 Don't graduate Apache Groovy from the Incubator because ...

Regards,
Cos

[1] http://is.gd/DX41lO
[2] http://is.gd/pPweq3
[3] http://is.gd/VTLiqO

 Apache Groovy graduation resolution draft

Establish the Apache Groovy Top-Level Project

WHEREAS, the Board of Directors deems it to be in the best interests
of the Foundation and consistent with the Foundation's purpose to
establish a Project Management Committee charged with the evolution
and maintenance of the Groovy programming language,

NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
(PMC), to be known as the "Apache Groovy Project", be and hereby is
established pursuant to Bylaws of the Foundation; and be it further

RESOLVED, that the Apache Groovy Project be and hereby is responsible
for the evolution and maintenance of the Groovy programming language;
and be it further

RESOLVED, that the office of "Vice President, Apache Groovy" be and
hereby is created, the person holding such office to serve at the
direction of the Board of Directors as the chair of the Apache Groovy
Project, and to have primary responsibility for management of the
projects within the scope of responsibility of the Apache Groovy
Project; and be it further

RESOLVED, that the persons listed immediately below be and hereby are
appointed to serve as the initial members of the Apache Groovy Project
PMC:

Cédric Champeau <cedric.champ...@gmail.com>
Paul King <pa...@asert.com.au>
Guillaume Laforge <glafo...@gmail.com>
Pascal Schumacher <pascalschumac...@gmx.net>
Jochen Theodorou <blackd...@gmx.org>
Andrew Bayer <andrew.ba...@gmail.com>
Konstantin Boudnik <c...@apache.org>

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be
appointed to the office of Vice President, Apache Groovy, to serve in
accordance with and subject to the direction of the Board of Directors
and the Bylaws of the Foundation until death, resignation, retirement,
removal or disqualification, or until a successor is appointed; and be
it further

RESOLVED, that the Apache Groovy Project be and hereby is tasked with
the migration and rationalization of the Apache Incubator Groovy
podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
Groovy podling encumbered upon the Apache Incubator Project are
hereafter discharged.


signature.asc
Description: Digital signature

Re: [VOTE] Graduate Groovy from the Incubator

[Konstantin Boudnik]

+1 (binding, reiterating my earlier vote on dev@groovy)

On Wed, Oct 28, 2015 at 11:26PM, Konstantin Boudnik wrote:
> Following discussions [1] about its current status, the Groovy community
> has voted [2] to graduate from the Incubator. The vote passed [3] with 12 +1s
> total, 5 are binding:
> 
> Guillaume Laforge
> Cédric Champeau
> Paul King
> Jochen Theodorou
> Pascal Schumacher
> Emmanuel Lécharny (binding)
> Bertrand Delacretaz (binding)
> Andrew Bayer (binding)
> Jim Jagielski (binding)
> Konstantin Boudnik (binding)
> Russel Winder
> Guillaume Alleon
> 
> The Groovy community has:
> * completed all required paperwork:
> https://incubator.apache.org/projects/groovy.html
> * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works)
> * completed the name check procedure:
> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88
> * addressed 50+ JIRAs:
> http://is.gd/1tACON
> * voted in multiple new committers/PPMC members
> 
> Therefore, I'm calling a VOTE to graduate Groovy with the following Board
> resolution. The VOTE will run for at least 72 hours, ending
> Saturday, October 31st 8 PM PST.
> 
> [ ] +1 Graduate Apache Groovy from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Groovy from the Incubator because ...
> 
> Regards,
> Cos
> 
> [1] http://is.gd/DX41lO
> [2] http://is.gd/pPweq3
> [3] http://is.gd/VTLiqO
> 
>  Apache Groovy graduation resolution draft
> 
> Establish the Apache Groovy Top-Level Project
> 
> WHEREAS, the Board of Directors deems it to be in the best interests
> of the Foundation and consistent with the Foundation's purpose to
> establish a Project Management Committee charged with the evolution
> and maintenance of the Groovy programming language,
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Groovy Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
> 
> RESOLVED, that the Apache Groovy Project be and hereby is responsible
> for the evolution and maintenance of the Groovy programming language;
> and be it further
> 
> RESOLVED, that the office of "Vice President, Apache Groovy" be and
> hereby is created, the person holding such office to serve at the
> direction of the Board of Directors as the chair of the Apache Groovy
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache Groovy
> Project; and be it further
> 
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache Groovy Project
> PMC:
> 
> Cédric Champeau <cedric.champ...@gmail.com>
> Paul King <pa...@asert.com.au>
> Guillaume Laforge <glafo...@gmail.com>
> Pascal Schumacher <pascalschumac...@gmx.net>
> Jochen Theodorou <blackd...@gmx.org>
> Andrew Bayer <andrew.ba...@gmail.com>
> Konstantin Boudnik <c...@apache.org>
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Guillaume Laforge be
> appointed to the office of Vice President, Apache Groovy, to serve in
> accordance with and subject to the direction of the Board of Directors
> and the Bylaws of the Foundation until death, resignation, retirement,
> removal or disqualification, or until a successor is appointed; and be
> it further
> 
> RESOLVED, that the Apache Groovy Project be and hereby is tasked with
> the migration and rationalization of the Apache Incubator Groovy
> podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> Groovy podling encumbered upon the Apache Incubator Project are
> hereafter discharged.




signature.asc
Description: Digital signature

Re: Mentor disengagement - a suggestion

[Konstantin Boudnik]

On Wed, Oct 14, 2015 at 06:10AM, Ted Dunning wrote:
> If it can work, that is very good. With intermittent availability, I have
> often seen the need for a spare.

Exactly! I've been out for 6 weeks back in May/June and missed all the reports
and other activity on the projects I am/was a mentor to. But I didn't fret as
there were a couple of other guys to make sure the podlings aren't hanging
high and dry

Cos

> On Wed, Oct 14, 2015 at 5:53 AM, Jim Jagielski  wrote:
> 
> > Agreed. My only comment would be that I still think that the
> > optimal number of mentors is 1.
> >
> > > On Oct 14, 2015, at 12:45 AM, Julian Hyde  wrote:
> > >
> > > It's not activity on the dev list, or even report signoffs, that
> > > matter most. Podlings, especially new podlings, have lots and lots of
> > > questions, especially about infrastructure. Without at least two
> > > responsive mentors to field those questions you feel like banging your
> > > head on the wall. And you start wondering why you left the comfort and
> > > convenience of github and whether Apache itself is fascinated by its
> > > own brand.
> > >
> > > Before you ask, you won't get podlings to send their questions to
> > > another list, because we're all too proud to ask questions which in
> > > retrospect always turn out to be dumb questions.
> > >
> > > It's not possible to measure that kind of mentor activity, so I think
> > > people are inclined to measure the "public" forms of activity as proxy
> > > indicators.
> > >
> > > Julian
> > >
> > >
> > > On Tue, Oct 13, 2015 at 4:19 AM, Jim Jagielski  wrote:
> > >> For me, I consider being a mentor as I do being a member of a PMC.
> > >> Occasionally one simply lacks cycles to be actively involved, but
> > >> one is involve enough to see that others *ARE* involved, and so I
> > >> am "unconcerned" about my inactivity during those times.
> > >>
> > >> My understanding is that this is OK and its one of the reasons
> > >> why we *have* multiple mentors.
> > >>
> > >> "Shaming" inactive mentors would be akin to "shaming" PMC members who
> > >> didn't post on the dev@ list this month, or who didn't vote on a
> > release
> > >> or etc...
> > >>
> > >> I am not, of course, referring to mentors who are truly MIA month in and
> > >> month out. But, as someone said, if you remove those from the equation,
> > >> the list of "active" mentors is pretty constant.
> > >>
> > >> So the question is "Is there a difference or problem between a podling
> > >> with 10 mentors, of which 4 are 'active', as compared to a podling with
> > >> 4 mentors, all of which are 'active'"??
> > >>
> > >>> On Oct 13, 2015, at 2:29 AM, Ted Dunning 
> > wrote:
> > >>>
> > >>> On Mon, Oct 12, 2015 at 11:05 PM, Sam Ruby 
> > wrote:
> > >>>
> > > Sounds like reaching out to the inactive mentors is a great idea and
> > I
> > > think we have a great example here of how complicated it can be.
> > 
> >  Nope.  I posted that link knowing that my name would be on it, and
> >  advocated that we should be having exactly this discussion.  I should
> >  either become more active on this, or (and probably more likely)
> >  remove myself as a mentor for this podling.
> > >>>
> > >>>
> > >>> And possibly by so doing become a great example to others of us who
> > can't
> > >>> admit to ourselves that we are over-extended.
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >


signature.asc
Description: Digital signature

Re: [DISCUSS] [REVISED] Mentor neutrality policy

[Konstantin Boudnik]

And still -1 on the revised proposal for the same reasons I stated before.

Cos

On Sun, Oct 11, 2015 at 11:39PM, Daniel Gruno wrote:
> First off: Can we *please* focus on the revised proposal and not get
> into a loop about the original email? I'll change the topic if that helps.
> 
> The revised edition, as partly suggested by Sam (and echoed by Bertrand)
> was:
> 
> - Binding votes on incubation, graduation and/or retirement are only
> valid when given by members of the IPMC who are independent from the
> podling in question. Mentors are free to recommend such actions, but
> cannot cast a vote themselves.
> 
> I don't believe I mentioned MIA mentors anywhere - is that something you
> wish to discuss as well?
> 
> With regards,
> Daniel.
> 
> On 10/11/2015 11:34 PM, Alan D. Cabrera wrote:
> > I’m -1 on on this.  The whole premise of the ASF is that it is a 
> > meritocracy and that volunteers at various “levels” of the organization 
> > have attained their status because they are trustworthy.  Without this 
> > premise, the ASF falls apart.
> > 
> > Finally, it’s not clear to me that this addresses the problem of MIA 
> > mentors.  If they were supposedly tied in some manner to the incubation and 
> > graduation of a podling,  then they are definitely active during its 
> > incubation; I have no problem with that because in my book, they are 
> > trustworthy.
> > 
> > I’ve made proposals to solve the problems listed below, the causes of which 
> > are, imo, volunteerism and a free ride into a project and its PMC.  My 
> > proposal was after 3 missed votes, the mentor is automatically removed with 
> > simple no-fuss reinstatement procedures should the mentor wish to redeem 
> > themselves.  Mentors cannot stay with the podling when it graduates.
> > 
> > 
> > Regards,
> > Alan
> > 
> >> On Oct 9, 2015, at 8:07 AM, Daniel Gruno  wrote:
> >>
> >> Hi Incubator folks,
> >>
> >> I would like to propose we adopt a mentor neutrality policy for
> >> incubating podlings:
> >>
> >> - A mentor must not be financially tied to the project or its incubation
> >> status.
> >> - A mentor must not have a vested interest in incubating, graduating or
> >> dismantling a podling that goes beyond the general Apache mission
> >> - A mentor must not be affiliated with the entity granting the code
> >> (company or original project community)
> >>
> >> Furthermore, I would like to see this extended to votes on graduating or
> >> retiring podlings, so that only people with no organizational (aparty
> >> from the ASF) or financial ties to the project (or the companies behind
> >> it) can cast a binding vote on graduation or retirement.
> >>
> >> This would essentially mean:
> >>
> >> - If you work for a company (or are hired as consultant/advisor) that is
> >> entering a project into incubation, you cannot mentor it nor vote
> >> for/against its incubation, graduation or retirement.
> >> - If you are a in the original community behind the project, you cannot
> >> mentor it nor vote for/against it.
> >>
> >> I believe this would create a neutral mentorship whose sole mission is
> >> to guide podlings with the interests of the ASF in mind.
> >>
> >>
> >> Please do discuss this. If there is (mostly) positive feedback, I would
> >> like to, at some point, have a vote on including this in the Incubator
> >> policy. I realize this would cut down on the number of potential
> >> mentors, and I would ask that more people step up to the challenge of
> >> mentoring if adopted.
> >>
> >> With regards,
> >> Daniel
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> > 
> > 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


signature.asc
Description: Digital signature

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sun, Oct 11, 2015 at 06:52PM, Reto Gmür wrote:
> On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik 
> wrote:
> 
> > On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno  wrote:
> > > Hi Incubator folks,
> > >
> > > I would like to propose we adopt a mentor neutrality policy for
> > > incubating podlings:
> > >
> > > - A mentor must not be financially tied to the project or its incubation
> > > status.
> >
> > I'm very strongly -1 on this for two reasons. One fundamental
> > and one operational. Fundamentally, this goes against a core
> > ASF principle that we all collaborate here as individuals by
> > checking our corporate affiliation at the door.
> 
> 
> I think it's naive to think that just because the members are individual
> and corporate affiliations don't formally play a role there is no influence
> by the employer. When I'm paid by a company or government agency to work on
> an apache project I don't have an effective protection against the
> directives of my employer. Maybe if I refuse to follow an employer's
> instruction to write some code for an Apache project of which I'm committer
> I could not be fired without notice, maybe I could write the patch and say
> on the list that I wrote this patch for my employer but that as an
> individual PMC member I vote against it (did something like this ever
> happen?), whichever way I'm likely to act against my financial interest.
> 
> In medical journals the author's are also writing in their own name, yet
> they must declare all competing interests. Following your logic such as
> declaration would be unnecessary if the journal says somewhere that authors
> leave their affiliation at the door.

That's a straw-man argument.

Unlike people writing for the medical journals who're working for the, sadly,
the most regulated industry ever and making millions if their research happen
to be acknowledged as promising, even when harmful, Apache contributors are
_individual volunteers_ developing the software for public consumption. And
you _have_ to leave your affiliation elsewhere when you're wearing your Apache
hat. Hence your affiliation is of no relevance here.

Cos

> > IOW, we are explicitly granting our members and committers the trust
> > required to make sure they do the right thing while they themselves (or
> > their employees) can significantly benefit (financially and otherwise) from
> > the projects.
> >
> 
> Even if we trust our commiters that they do not commit a hidden back door
> on behalf of the spy agency they work for, the conflict of interest can be
> much more subtle. The company has a deadline and a release of an apache
> project before that deadline would come in very handy, will you scrutinize
> the notice files at the risk of finding something that delays the release?
> 
> If a main customer of my consulting firm is the main promoter of the XY
> file format, will I by neutral in choosing the best file format for the
> Apache Project I'm involved in? I probably really believe that XY is the
> way to go, but is should be an Apache rule that I declare that I have some
> financial ties to it.
> 
> 
> >
> > This is what makes ASF unique and anything that goes even slightly
> > in the direction of reducing this level of trust will have me up in arms
> > (regardless of whether it is related to Incubator or not).
> >
> > Operationally, this is extremely tricky to enforce. I speak here
> > from experience of somebody who has to be appreciative of the same
> > set of issues while consulting for companies and yet working for my
> > current employer. Even in a corporate world (where stakes are much
> > higher from legal perspective) this typically gets handled by trusting
> > the individual to do the right thing and disclose any potential conflict
> > of interest (financial or otherwise).
> >
> 
> We would not have to ask people for their tax declaration, a self
> declaration of any potentially competing interest would do.
> 
> Cheers,
> Reto


signature.asc
Description: Digital signature

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

Continuing this line of reasoning I won't be able to mentor _any_ of the
projects I've mentored or still mentoring because of different levels of
involvements either at my $dayjob or with the organizations that donated the
code initially. Is this really an intent of the original proposal to prevent
people from they care doing in the open-source? And based on what again?

Cos

On Mon, Oct 12, 2015 at 11:14AM, Andrew Purtell wrote:
> I would not have been able to mentor Phoenix should it have come along now.
> At the time I was not employed by the originator of the project. Later I
> chose to join them in part because they contributed the results of their
> labor to Apache. My evaluation of how well a podling might be
> functioning would not have been in any way different before or after I took
> the job.
> 
> 
> On Mon, Oct 12, 2015 at 10:13 AM, Ted Dunning  wrote:
> 
> > The practical effect on me of this requirement would be that
> >
> > a) I couldn't have mentored Drill
> >
> > b) I couldn't have mentored Zookeeper (assuming it were to come along now)
> >
> > c) I couldn't mentor Kylin (it affects Drill and MapR customers are
> > considering using it)
> >
> > d) I couldn't mentor Calcite (same as Drill)
> >
> > e) I couldn't mentor Storm (MapR distributes it)
> >
> > f) I couldn't mentor Flink (I am co-writing a book that highlights it)
> >
> > g) I couldn't help with Zeppelin (our SE's use it for demos)
> >
> > h) I couldn't mentor Apex (MapR is a partner of DataTorrent)
> >
> > In fact, I can't think of any project that I have helped out that would be
> > allowable under this policy.
> >
> > Take Julian Hyde and Taylor Goetz as additional examples.  They wouldn't be
> > able to help on any of the projects they have been helping on.
> >
> > So I *could* mentor Corinthia. Or some of the projects that I had never
> > heard of and couldn't care less about.
> >
> > Well, that doesn't work because I don't care about those projects and I am
> > not going to waste my time.  I care about machine learning and big data and
> > streaming and query languages. That is what drives my choice of work and
> > what drives my choice of open source projects to contribute to. It also
> > leads me to advocate for adoption of those projects at work and for driving
> > some of the work I do into open source.
> >
> >
> >
> > On Sat, Oct 10, 2015 at 7:49 AM, Mattmann, Chris A (3980) <
> > chris.a.mattm...@jpl.nasa.gov> wrote:
> >
> > > So here’s my elaboration.
> > >
> > > The proposal below would have prevented me from ever helping
> > > projects to the ASF and convincing them that it may be a good
> > > home for them. I’ve always had financial ties to a project’s
> > > Incubation status. In many cases, projects being at the ASF,
> > > and my involvement in them has assisted my mission of doing
> > > scientific research and helping win proposals and so forth for
> > > NASA and other agencies.
> > >
> > > Further, I’ve many times been at the same institution in which
> > > the project has originated from before the ASF.
> > >
> > > I think I’ve done a good job on the projects I’ve helped to
> > > bring here and they have been successful too and have overall
> > > benefitted the ASF.
> > >
> > > This rings to me very similar to Roy’s email circa 2012 I believe
> > > in which in the Incubator we tried to force the diversity requirement
> > > as a graduation requirement, and Roy succinctly explained that we
> > > can’t punish e.g., a podling for having people all from the same
> > > institution. That would punish that institution for hiring folks
> > > for open source who work on code at the ASF. Diversity is always
> > > a strong property of a podling as I feel it makes it more resilient
> > > but it’s not a hard requirement. I feel the same thing in this thread.
> > >
> > > Cheers,
> > > Chris
> > >
> > > ++
> > > Chris Mattmann, Ph.D.
> > > Chief Architect
> > > Instrument Software and Science Data Systems Section (398)
> > > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > > Office: 168-519, Mailstop: 168-527
> > > Email: chris.a.mattm...@nasa.gov
> > > WWW:  http://sunset.usc.edu/~mattmann/
> > > ++
> > > Adjunct Associate Professor, Computer Science Department
> > > University of Southern California, Los Angeles, CA 90089 USA
> > > ++
> > >
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: jpluser 
> > > Reply-To: "general@incubator.apache.org" 
> > > Date: Friday, October 9, 2015 at 5:14 PM
> > > To: "general@incubator.apache.org" 
> > > Subject: Re: [DISCUSS] Mentor neutrality policy
> > >
> > > >I do not agree with this proposal I will elaborate more later
> > > >
> > > >Sent from my iPhone
> > 

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sun, Oct 11, 2015 at 02:45PM, Pierre Smits wrote:
> Producing good code is a community effort. When it comes down to just the
> mentors fix that themselves, there is something wrong with the community of
> the podling.
> 
> This discussion is not about what participants do with their mentor hat on
> in the podling. I expect we all appreciate what mentors do within the
> podling and how they help out with explanation when a podling is discussed
> in this ML. The discussion is about people wearing two (or more) hats while
> mentoring a podling.
> 
> And yes, the ASF should be wary of mentors pushing their podling toward
> graduation beyond their mentor role. Do the mentors fear podling failure
> (not graduating) so much, that they need a control on both the internal
> process of the podling (e.g. regarding graduation) and the process at IPMC
> level?

At this point, this is all a hearsay. Supporters of the proposal are making an
assumption nearing the base-less accusation of someone putting their
employment or financial affiliation in front of that of Foundation.

It is suboptimal, lacking the implementation mechanism, and finally smells bad
to impose a blanket policy without real ground, but just because "not doing
something isn't a option".

Cos

> Was the whole evalution process not intended to ensure that eyes of others
> than those with a vested interest (and yes graduation success can be regard
> as such) look and decide on the aspects of community diversity/project
> independence/code risk of the podling?
> 
> 
> Best regards,
> 
> Pierre Smits
> 
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
> 
> On Sun, Oct 11, 2015 at 11:48 AM, Mark Struberg  wrote:
> 
> > -1
> >
> > Mentors who have no interest (financially or purely technical doesn’t
> > matter in the end) will not find enough time to _really_ look into the
> > projects health.
> >
> > Be honest with yourself: how much do you look into the code if you are not
> > working on it yourself? How could you then detect that code is
> > bulk-imported from another project (I‚ve even seen LGPLed code slip in).
> > And this doesn’t happen because people want us something bad. They often
> > simply don’t know how much the ASF cares about code provenance and legal
> > things. That’s an important part in the mentor work. And you cannot do this
> > if you are only somehow loosely checking the project every other month.
> >
> > Or do you fear a mentor will push through his own ‚baby‘ with knowingly
> > ignoring ASF rules?
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > > Am 09.10.2015 um 17:07 schrieb Daniel Gruno :
> > >
> > > Hi Incubator folks,
> > >
> > > I would like to propose we adopt a mentor neutrality policy for
> > > incubating podlings:
> > >
> > > - A mentor must not be financially tied to the project or its incubation
> > > status.
> > > - A mentor must not have a vested interest in incubating, graduating or
> > > dismantling a podling that goes beyond the general Apache mission
> > > - A mentor must not be affiliated with the entity granting the code
> > > (company or original project community)
> > >
> > > Furthermore, I would like to see this extended to votes on graduating or
> > > retiring podlings, so that only people with no organizational (aparty
> > > from the ASF) or financial ties to the project (or the companies behind
> > > it) can cast a binding vote on graduation or retirement.
> > >
> > > This would essentially mean:
> > >
> > > - If you work for a company (or are hired as consultant/advisor) that is
> > > entering a project into incubation, you cannot mentor it nor vote
> > > for/against its incubation, graduation or retirement.
> > > - If you are a in the original community behind the project, you cannot
> > > mentor it nor vote for/against it.
> > >
> > > I believe this would create a neutral mentorship whose sole mission is
> > > to guide podlings with the interests of the ASF in mind.
> > >
> > >
> > > Please do discuss this. If there is (mostly) positive feedback, I would
> > > like to, at some point, have a vote on including this in the Incubator
> > > policy. I realize this would cut down on the number of potential
> > > mentors, and I would ask that more people step up to the challenge of
> > > mentoring if adopted.
> > >
> > > With regards,
> > > Daniel
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >


signature.asc
Description: Digital signature

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sat, Oct 10, 2015 at 09:06AM, Daniel Gruno wrote:
> On 10/10/2015 07:51 AM, Andrew Purtell wrote:
> > We should address perceived, and certainly provable, instances of
> > corruption at the Foundation directly, rather than prescribe policy that
> > seeks to prevent future instances as if there is a precedent (but there
> > isn't one here... at least one not spoken aloud, right?).
> 
> We shouldn't need to have publicly available cases of wrong-doings to
> say "no wrong-doings please". We hold our politicians to this standard
> where I come from - it's called the Arm's Length Principle, and it's
> worked very well.

But we aren't dealing with politicians here, who are by definition are the
scam of the earth. So, let's not even get there, please.

Cos

> >> A mentor must not be financially tied to the project or its incubation
> > status.
> > 
> > Aside from deviating greatly from treating mentors and all other persons as
> > individuals, for verification purposes this would require a level of
> > intrusive financial reporting that we don't remotely approach today and to
> > which most members would probably object.
> 
> I'm not suggesting we start auditing people. As later clarified, I am
> suggesting people recuse themselves from voting if they (or others?)
> feel that they have economic or other corporate interests that may cloud
> either their judgment or their perceived judgment. The reason I said
> 'mentors' here is because the mentor role, as it currently is, is a mix
> of attorney, judge, jury and executioner in the podlings. If we were to
> separate this and mentors were solely in charge of _mentoring_, the
> issue would be more moot.
> 
> > 
> >> A mentor must not have a vested interest in incubating, graduating or
> > dismantling a podling that goes beyond the general Apache mission
> > 
> > None of this is well defined.
> 
> Agreed, I picked the wrong word to use here. I prefer Sam's revisement,
> as stated earlier.
> 
> With regards,
> Daniel.
> 
> > 
> >> If you are a in the original community behind the project, you cannot
> > mentor it nor vote for/against it.
> > 
> > ​This diminishes the pool of available mentors and in particular those
> > probably most vested in the success of the podling.​
> > 
> > 
> > 
> > 
> > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  wrote:
> > 
> >> Hi Incubator folks,
> >>
> >> I would like to propose we adopt a mentor neutrality policy for
> >> incubating podlings:
> >>
> >> - A mentor must not be financially tied to the project or its incubation
> >> status.
> >> - A mentor must not have a vested interest in incubating, graduating or
> >> dismantling a podling that goes beyond the general Apache mission
> >> - A mentor must not be affiliated with the entity granting the code
> >> (company or original project community)
> >>
> >> Furthermore, I would like to see this extended to votes on graduating or
> >> retiring podlings, so that only people with no organizational (aparty
> >> from the ASF) or financial ties to the project (or the companies behind
> >> it) can cast a binding vote on graduation or retirement.
> >>
> >> This would essentially mean:
> >>
> >> - If you work for a company (or are hired as consultant/advisor) that is
> >> entering a project into incubation, you cannot mentor it nor vote
> >> for/against its incubation, graduation or retirement.
> >> - If you are a in the original community behind the project, you cannot
> >> mentor it nor vote for/against it.
> >>
> >> I believe this would create a neutral mentorship whose sole mission is
> >> to guide podlings with the interests of the ASF in mind.
> >>
> >>
> >> Please do discuss this. If there is (mostly) positive feedback, I would
> >> like to, at some point, have a vote on including this in the Incubator
> >> policy. I realize this would cut down on the number of potential
> >> mentors, and I would ask that more people step up to the challenge of
> >> mentoring if adopted.
> >>
> >> With regards,
> >> Daniel
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> > 
> > 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Retire the Droids podling (was Re: Droids Podling Issue)

[Konstantin Boudnik]

Looks like it is one of those situations that happens from time to time. Makes
sense to me. Thanks.

Cos

On Sat, Oct 10, 2015 at 06:26AM, Marvin Humphrey wrote:
> It's been a month and we haven't heard from Thorsten, nor any lurker
> in the Droids community.
> 
> I've changed the subject to make it clear that retirement is being
> contemplated.  Per the Incubator Retirement Guide[1], the next step is
> to call a community VOTE on droids-dev, which I will do in a few days.
> Should that vote go as expected given these discussions, I will
> subsequently call a VOTE of the IPMC.
> 
> Marvin Humphrey
> 
> [1] http://incubator.apache.org/guides/retirement.html
> 
> On Tue, Sep 8, 2015 at 6:13 PM, Marvin Humphrey  
> wrote:
> > Thorsten, any commentary?
> >
> > Marvin Humphrey
> >
> > On Mon, Aug 31, 2015 at 8:05 AM, Richard Frovarp 
> >
> >> Thanks Marvin. I'm probably at that point. I'd be happy to work on it, and
> >> help out the community. However, I don't have the energy to push and build 
> >> a
> >> community, which is what is needed. I was waiting to see if Thorsten had
> >> something to say. I know he was out of the office when the last report was
> >> due.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sat, Oct 10, 2015 at 09:05PM, Branko Čibej wrote:
> On 10.10.2015 20:11, Konstantin Boudnik wrote:
> > On Sat, Oct 10, 2015 at 09:06AM, Daniel Gruno wrote:
> >> On 10/10/2015 07:51 AM, Andrew Purtell wrote:
> >>> We should address perceived, and certainly provable, instances of
> >>> corruption at the Foundation directly, rather than prescribe policy that
> >>> seeks to prevent future instances as if there is a precedent (but there
> >>> isn't one here... at least one not spoken aloud, right?).
> >> We shouldn't need to have publicly available cases of wrong-doings to
> >> say "no wrong-doings please". We hold our politicians to this standard
> >> where I come from - it's called the Arm's Length Principle, and it's
> >> worked very well.
> > But we aren't dealing with politicians here, who are by definition are the
> > scam of the earth. So, let's not even get there, please.
> 
> "Scam of the Earth" ... one of the better puns I ran into recently. :)

And indeed they are, as they are scamming everyone into a believe that they
are here to solve "issues" for the rest of dumb-us. I am glad that pun hasn't
gone lost ;)

Cos

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Fri, Oct 09, 2015 at 11:38AM, Greg Trasuk wrote:
> Hi Daniel:
> 
> Discussion intertwined below…
> 
> Cheers,
> 
> Greg Trasuk
> 
> > On Oct 9, 2015, at 11:07 AM, Daniel Gruno  wrote:
> > 
> > Hi Incubator folks,
> > 
> > I would like to propose we adopt a mentor neutrality policy for
> > incubating podlings:
> > 
> > - A mentor must not be financially tied to the project or its incubation
> > status.
> 
> This requirement would seem to be against the idea that we participate in
> Apache as individuals, rather than as employees/representatives of some
> company.  If there is a case where a member appears to be representing their

I'd even go as far as saying this requirement asserts that mentors aren't
capable of separating their employment/advisement affiliation from their
individual contribution to the ASF. If it were indeed a case it should be
dealt with on a case-per-case basis, instead of putting a round of the
red-tape on everything single member of IPMC.

Cos

> company’s interest rather than the Foundation’s interest, shouldn’t that be
> dealt with in itself?
> 
> > - A mentor must not have a vested interest in incubating, graduating or
> > dismantling a podling that goes beyond the general Apache mission
> 
> Could you elaborate on “beyond the general Apache mission”?  You probably 
> have some concrete examples in mind, and I’m sure we don’t want to start 
> dissecting those examples rather than your overall suggestion, but 
> personally, I’m not sure what you mean.
> 
> > - A mentor must not be affiliated with the entity granting the code
> > (company or original project community)
> > 
> 
> That suggestion would seem to preclude a knowledgable insider who happens to 
> be an Apache member from helping out with incubating a project.  Which seems 
> kind of inefficient.
> 
> > Furthermore, I would like to see this extended to votes on graduating or
> > retiring podlings, so that only people with no organizational (aparty
> > from the ASF) or financial ties to the project (or the companies behind
> > it) can cast a binding vote on graduation or retirement.
> > 
> > This would essentially mean:
> > 
> > - If you work for a company (or are hired as consultant/advisor) that is
> > entering a project into incubation, you cannot mentor it nor vote
> > for/against its incubation, graduation or retirement.
> > - If you are a in the original community behind the project, you cannot
> > mentor it nor vote for/against it.
> > 
> > I believe this would create a neutral mentorship whose sole mission is
> > to guide podlings with the interests of the ASF in mind.
> > 
> > 
> > Please do discuss this. If there is (mostly) positive feedback, I would
> > like to, at some point, have a vote on including this in the Incubator
> > policy. I realize this would cut down on the number of potential
> > mentors, and I would ask that more people step up to the challenge of
> > mentoring if adopted.
> > 
> > With regards,
> > Daniel
> > 
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Sat, Oct 10, 2015 at 01:29AM, Pierre Smits wrote:
> What are you referring to, Konstantin?

I am referring to the progressives of the world and all "policy frameworks"
they are so readily unleashing on everybody because they have an urge to
meddle. I am very much agree with Chris and Ross on immorality of the
guilt-by-association policy.

Cos

> Best regards,
> 
> Pierre Smits
> 
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
> 
> On Sat, Oct 10, 2015 at 1:31 AM, Konstantin Boudnik <c...@apache.org> wrote:
> 
> > On Fri, Oct 09, 2015 at 08:36PM, Daniel Gruno wrote:
> > > Does there always have to be an actual problem before we can propose a
> > > policy? must we always be reactive instead of proactive?
> >
> > "We can't just stay on a side and wait, we should do something!" - sounds
> > all
> > too familiar, eh?
> >
> > > Yes, I am in a way implying that some mentors are, perhaps, not neutral
> > > in their work. I will not back it up with specific names or contexts, as
> > > I don't want to take a trip to lawsuit town for things I cannot back up
> > > with publicly available information.
> > >
> > > I don't find this to be uncivil accusations - can you outline a specific
> > > segment that you find uncivil? I am proposing a set of basic rules -
> > > which is naturally up for discussion and improvement - that would
> > > potentially alleviate us from having some nasty discussions - whether
> > > they be public or private - about the neutrality and honesty of
> > > recommendations, and hopefully ensure we have a more leveled playing
> > > field in the incubator.
> > >
> > > I'll stop here, as my eyesight is playing a trick on me today and not
> > > allowing me to see what I type.
> > >
> > > With regards,
> > > Daniel.
> > >
> > > On 10/09/2015 08:03 PM, Chris Douglas wrote:
> > > > What problem does this solve?
> > > >
> > > > This proposal lacks context. It implies that mentors are not neutral,
> > > > and that they are motivated by interests not shared by the ASF. But it
> > > > does not outline the merits of that belief, neither does it specify
> > > > how this proposal would address them. Instead of allowing those
> > > > definitions to float, this discussion would be more productive if it
> > > > were about some concrete problems for which there is evidence. Yet
> > > > another thread of rude responses to uncivil accusations is
> > > > unproductive, even if it is an IPMC tradition. -C
> > > >
> > > > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno <humbed...@apache.org>
> > wrote:
> > > >> Hi Incubator folks,
> > > >>
> > > >> I would like to propose we adopt a mentor neutrality policy for
> > > >> incubating podlings:
> > > >>
> > > >> - A mentor must not be financially tied to the project or its
> > incubation
> > > >> status.
> > > >> - A mentor must not have a vested interest in incubating, graduating
> > or
> > > >> dismantling a podling that goes beyond the general Apache mission
> > > >> - A mentor must not be affiliated with the entity granting the code
> > > >> (company or original project community)
> > > >>
> > > >> Furthermore, I would like to see this extended to votes on graduating
> > or
> > > >> retiring podlings, so that only people with no organizational (aparty
> > > >> from the ASF) or financial ties to the project (or the companies
> > behind
> > > >> it) can cast a binding vote on graduation or retirement.
> > > >>
> > > >> This would essentially mean:
> > > >>
> > > >> - If you work for a company (or are hired as consultant/advisor) that
> > is
> > > >> entering a project into incubation, you cannot mentor it nor vote
> > > >> for/against its incubation, graduation or retirement.
> > > >> - If you are a in the original community behind the project, you
> > cannot
> > > >> mentor it nor vote for/against it.
> > > >>
> > > >> I believe this would create a neutral mentorship whose sole mission is
> > > >> to guide podlings with the interests of the ASF in mind.
> > > >>
> > > >>
> > > >> Please do discuss this. If there is (mostly) positive feedbac

Re: [DISCUSS] Mentor neutrality policy

[Konstantin Boudnik]

On Fri, Oct 09, 2015 at 08:36PM, Daniel Gruno wrote:
> Does there always have to be an actual problem before we can propose a
> policy? must we always be reactive instead of proactive?

"We can't just stay on a side and wait, we should do something!" - sounds all
too familiar, eh?

> Yes, I am in a way implying that some mentors are, perhaps, not neutral
> in their work. I will not back it up with specific names or contexts, as
> I don't want to take a trip to lawsuit town for things I cannot back up
> with publicly available information.
> 
> I don't find this to be uncivil accusations - can you outline a specific
> segment that you find uncivil? I am proposing a set of basic rules -
> which is naturally up for discussion and improvement - that would
> potentially alleviate us from having some nasty discussions - whether
> they be public or private - about the neutrality and honesty of
> recommendations, and hopefully ensure we have a more leveled playing
> field in the incubator.
> 
> I'll stop here, as my eyesight is playing a trick on me today and not
> allowing me to see what I type.
> 
> With regards,
> Daniel.
> 
> On 10/09/2015 08:03 PM, Chris Douglas wrote:
> > What problem does this solve?
> > 
> > This proposal lacks context. It implies that mentors are not neutral,
> > and that they are motivated by interests not shared by the ASF. But it
> > does not outline the merits of that belief, neither does it specify
> > how this proposal would address them. Instead of allowing those
> > definitions to float, this discussion would be more productive if it
> > were about some concrete problems for which there is evidence. Yet
> > another thread of rude responses to uncivil accusations is
> > unproductive, even if it is an IPMC tradition. -C
> > 
> > On Fri, Oct 9, 2015 at 8:07 AM, Daniel Gruno  wrote:
> >> Hi Incubator folks,
> >>
> >> I would like to propose we adopt a mentor neutrality policy for
> >> incubating podlings:
> >>
> >> - A mentor must not be financially tied to the project or its incubation
> >> status.
> >> - A mentor must not have a vested interest in incubating, graduating or
> >> dismantling a podling that goes beyond the general Apache mission
> >> - A mentor must not be affiliated with the entity granting the code
> >> (company or original project community)
> >>
> >> Furthermore, I would like to see this extended to votes on graduating or
> >> retiring podlings, so that only people with no organizational (aparty
> >> from the ASF) or financial ties to the project (or the companies behind
> >> it) can cast a binding vote on graduation or retirement.
> >>
> >> This would essentially mean:
> >>
> >> - If you work for a company (or are hired as consultant/advisor) that is
> >> entering a project into incubation, you cannot mentor it nor vote
> >> for/against its incubation, graduation or retirement.
> >> - If you are a in the original community behind the project, you cannot
> >> mentor it nor vote for/against it.
> >>
> >> I believe this would create a neutral mentorship whose sole mission is
> >> to guide podlings with the interests of the ASF in mind.
> >>
> >>
> >> Please do discuss this. If there is (mostly) positive feedback, I would
> >> like to, at some point, have a vote on including this in the Incubator
> >> policy. I realize this would cut down on the number of potential
> >> mentors, and I would ask that more people step up to the challenge of
> >> mentoring if adopted.
> >>
> >> With regards,
> >> Daniel
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> > 
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Should Apache VOTEs be in a first-come, first-serve queue?

[Konstantin Boudnik]

Am I the only one who sees an issue of moral hazard in this proposal?

On Mon, Sep 14, 2015 at 12:28PM, Marko Rodriguez wrote:
> HI,
> 
> Here is an idea:
> 
> Can we offer $20 to the first 3 binding voters of a release on general@? We 
> would structure the contract as such:
> 
>   "The first 3 binding voters on Apache TinkerPop x.y.z get $20 
> regardless of their vote being a -1 or +1. However, the binding voter must 
> give an honest review of the artifacts and specify exactly what they did 
> which led them to their ultimate vote decision. Any dishonesty in voting 
> disqualifies the individual from receiving their cash prize."
> 
> This seems a reasonable (and fair way) of getting VOTE attention much like 
> the other marketing models currently being posited by the general@ list.
> 
> Thoughts?,
> Marko.
> 
> http://markorodriguez.com
> 
> On Sep 14, 2015, at 12:18 PM, Marko Rodriguez  wrote:
> 
> > Hello,
> > 
> > I suppose my concern is exactly what the two replies thus far espouse -- 
> > "human whim."
> > 
> > This means that a "song and dance" must be done to "entice" the human to 
> > entertain a VOTE. I suspect The Apache Software Foundation would argue that 
> > paying people to VOTE (regardless if they +1 or -1) is bad. Or is it? 
> > However, there seems little difference between paying someone to vote and 
> > doing some other marketing behaviors that would lure the human voter in.
> > 
> > My concern is that this means its a popularity contest and not a "lets 
> > develop software that is respective of the Apache2 license." Shouldn't 
> > Apache's VOTE infrastructure be beyond fancying the human with magical 
> > marketing tricks?
> > 
> > Thank you for your thoughts,
> > Marko.
> > 
> > http://markorodriguez.com
> > 
> > On Sep 14, 2015, at 11:49 AM, John D. Ament  wrote:
> > 
> >> I know one thing that always grabs my attention is when the community
> >> behind it votes on the topic, regardless of having binding/non-binding
> >> votes to back it.  It shows me that there is a lot of interest in it, and
> >> will remind me to look at it closely and throw my vote in.
> >> 
> >> Another way to compare it is is against US Voter turn out.  Typically in
> >> non-presidential elections its down at 40%, but in presidential its up
> >> around 60%.
> >> 
> >> John
> >> 
> >> On Mon, Sep 14, 2015 at 12:50 PM Ted Dunning  wrote:
> >> 
> >>> Marko,
> >>> 
> >>> Isn't the real problem a project level problem?  Some projects are simply
> >>> higher profile than others?
> >>> 
> >>> As such, wouldn't be better to raise the profile of the projects not
> >>> getting the votes rather than impair the ability to vote on popular
> >>> projects?
> >>> 
> >>> Votes on project admission haven't generally been a problem.  The problem
> >>> is generally with release votes.  Doing a good review of a release takes a
> >>> significant amount of time and I think that it is hard to impose that
> >>> burden on everybody who wants to vote on a different project's release.
> >>> 
> >>> In the projects that I have mentored, I have seen the problem with getting
> >>> IPMC votes on releases. My own response has been to
> >>> 
> >>> 1) make darn sure that the mentors will vote if they possibly can
> >>> 
> >>> 2) reach out to others privately to encourage them on a one-to-one basis 
> >>> to
> >>> review the release and vote
> >>> 
> >>> 3) warn the general list that a vote is coming and talk it up
> >>> 
> >>> Most projects should have three mentors who are, by definition, IPMC
> >>> members with the ability to case binding votes. If a project finds that
> >>> some mentors are persistently MIA, they should find some new ones. If
> >>> mentors find that other mentors are MIA, then they should describe to the
> >>> project why that is a problem and suggest ways to get additional mentors
> >>> involved.
> >>> 
> >>> Ultimately, this problem is just a preview of what happens when a project
> >>> doesn't have enough active participation and needs to be handled using
> >>> essentially the same community development methods.
> >>> 
> >>> 
> >>> On Mon, Sep 14, 2015 at 9:26 AM, Marko Rodriguez 
> >>> wrote:
> >>> 
>  Hello,
>  
>  It appears that VOTEing in general@ is inefficient and biased. An Apache
>  member will see a VOTE on the list and can choose whether to participate
> >>> in
>  that VOTE or not. I believe there are problems with this algorithm. The
>  first has to do with efficiency. For instance, Groovy received (out of my
>  foggy memory) some 20+ VOTEs when only 3 were were needed and other
> >>> project
>  VOTEs were sitting around hoping for an Apache member to spend time on
>  their project. Second, if no Apache member really cares about the
> >>> project's
>  VOTE, then the project committee is left "hoping" that someone will care
>  --- pinging around to their mentors (no 

Re: [DISCUSS] Graduate Calcite from the Apache Incbuator

[Konstantin Boudnik]

+1 (binding). Good luck!

On Sat, Sep 12, 2015 at 03:09PM, Julian Hyde wrote:
> The Calcite community has established consensus and held a
> successful vote with 20 +1 votes in favor of proposing
> graduation to a top-level project, including 12 votes from
> committers and 6 votes from IPMC members.
> 
> Here are: the discussion on the dev list [1], vote thread
> [2] and result [3]. Also relevant are the incubation status
> page [4] and a thread on this list requesting review of
> whether Calcite met the criteria to graduate[5].
> 
> We propose that Calcite is ready to become a top-level
> project. If this discussion reaches consensus we will move
> to a formal vote.
> 
> Below is our proposed resolution.
> 
> Julian Hyde, on behalf of Calcite PPMC
> 
> [1] http://s.apache.org/ZPC
> [2] http://s.apache.org/rvB
> [3] http://s.apache.org/sv
> [4] http://incubator.apache.org/projects/calcite.html
> [5] http://s.apache.org/itP
> 
> - - - snip - - -
> 
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to the
> public, related to parsing and planning queries on data in a
> wide variety of formats.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Calcite
> Project", be and hereby is established pursuant to Bylaws of
> the Foundation; and be it further
> 
> RESOLVED, that the Apache Calcite Project be and hereby is
> responsible for the creation and maintenance of software
> related to parsing and planning queries on data in a wide
> variety of formats; and be it further
> 
> RESOLVED, that the office of "Vice President, Apache
> Calcite" be and hereby is created, the person holding such
> office to serve at the direction of the Board of Directors
> as the chair of the Apache Calcite Project, and to have
> primary responsibility for management of the projects within
> the scope of responsibility of the Apache Calcite Project;
> and be it further
> 
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Calcite Project:
> 
> * Alan Gates 
> * Aman Sinha 
> * Ashutosh Chauhan 
> * James R. Taylor 
> * Jacques Nadeau 
> * Jesús Camacho Rodríguez 
> * Jinfeng Ni 
> * John Pullokkaran 
> * Julian Hyde 
> * Nick Dimiduk 
> * Steven Noels 
> * Ted Dunning 
> * Vladimir Sitnikov 
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Julian Hyde be
> appointed to the office of Vice President, Apache Calcite,
> to serve in accordance with and subject to the direction of
> the Board of Directors and the Bylaws of the Foundation
> until death, resignation, retirement, removal or
> disqualification, or until a successor is appointed; and be
> it further
> 
> RESOLVED, that the Apache Calcite Project be and hereby is
> tasked with the migration and rationalization of the Apache
> Incubator Calcite podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Calcite podling encumbered upon the Apache
> Incubator Project are hereafter discharged.
> 
> - - - end - - -
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept MADlib into the Apache Incubator

[Konstantin Boudnik]

with sister ASF projects. We
> expect this to further reduces the risk of orphaning the product.
> 
> Even in the absence of support by a particular vendor such as Pivotal,
> and in a worst-case scenario where HAWQ and Greenplum Database fail to
> gain traction in OSS, the existence of an established PostgreSQL OSS
> project means there’s will still be a working stack for MADlib.
> 
> === Inexperience with Open Source ===
> MADlib has been an open source project from the outset. All developers
> working on the project (regardless of their employment affiliation)
> did so completely in the open. While the governance model of MADlib
> has been more of a benevolent dictator model, the project has always
> been receptive to accepting contributions from all sources and
> including them in future releases based on thorough code review,
> testing, and compliance with the project’s coding best practices.
> 
> === Homogeneous Developers ===
> While most of the initial committers are employed by Pivotal, there's
> still a healthy level of interest coming from academia. On top of that
> we expect to spark curiosity in sister ASF projects and attract
> developers unaffiliated with Pivotal. Finally, MADlib is being used
> extensively whenever Pivotal engages with customers on data science
> projects. This typically means that the skills remain within a
> customer organization which further increases the chance of turning
> customer data scientists into MADlib contributors.
> 
> === Reliance on Salaried Developers ===
> A large percentage of the contributors are paid to work in the Big
> Data space. While they might wander from their current employers, they
> are unlikely to venture far from their core expertise and thus will
> continue to be engaged with the project regardless of their current
> employers. In addition, the project is still enjoying popularity in
> academic circles and we hope that will help mitigate reliance on
> salaried developers as well.
> 
> === Relationships with Other Apache Products ===
> As mentioned in the Alignment section, MADlib may consider various
> degrees of integration and code exchange with Apache Spark (MLlib),
> Apache Mahout, Apache Hive and Apache Drill projects. We expect
> integration points to be inside and outside the project. We look
> forward to collaborating with these communities as well as other
> communities under the Apache umbrella.
> 
> === An Excessive Fascination with the Apache Brand ===
> While we intend to leverage the Apache "brand" when talking to other
> projects as a testament to our project’s neutrality, we have no plans
> for making use of the Apache brand in press releases nor posting
> billboards advertising acceptance of MADlib into Apache Incubator.
> 
> == Documentation ==
> The documentation is currently available at: 
> https://github.com/madlib/frontpage
> 
> The documentation is currently licensed under 2-clause BSD license.
> 
> == Initial Source ==
> Initial source code is available at:
>* MADlib: https://github.com/madlib/madlib
>* Testsuite: https://github.com/madlib/testsuite
>* Contributors: https://github.com/madlib/contrib
> 
> The code is currently licensed under 2-clause BSD license.
> 
> == Source and Intellectual Property Submission Plan ==
> As soon as MADlib is approved to join the Incubator, the source code
> will be transitioned via the Software Grant Agreement onto ASF
> infrastructure and in turn made available under the Apache License,
> version 2.0.  We know of no legal encumbrances that would inhibit the
> transfer of source code to the ASF.
> 
> == External Dependencies ==
> 
> Runtime dependencies:
>* boost-1.47.0 (Boost Software License)
>* _m_widen_init (MIT for this subcomponent of GCC)
>* python-argparse-1.2.1 (PSF LICENSE AGREEMENT FOR PYTHON 2.7.1)
>* pyyaml-3.10 (MIT license)
>* cern_root-5.34 (LGPL, however this dependency will be removed
> since the 2 cern modules used are being entirely re-written in MADlib)
>* eigen-3.2.2 (Mozilla Public License)
>* pyxb-1.2.4 (Apache license version 2)
>* python (Python Software Foundation License Version 2)
>* mathjax-2.5 (Apache license version 2)
> 
> Build only dependencies:
>* doxypy-0.4.2 (GPL)
>* cmake-2.8.4 (BSD 3-clause License)
>* doxygen >= 1.8.4 (GPL)
>* flex >= 2.5.33 (BSD)
>* bison >= 2.4 (GPL)
>* latex (LaTeX Project Public License)
>* TikZ-UML (no license information)
> 
> Cryptography
>* N/A
> 
> == Required Resources ==
> 
> === Mailing lists ===
>   * priv...@madlib.incubator.apache.org (moderated subscriptions)
>   * comm...@madlib.incubator.apache.org
>   *

Re: September 2015 Report

[Konstantin Boudnik]

I have just updated the podlings.xml to reflect that Ignite has graduated. So
they won't be reporting as a part of Incubator any more.

Thanks,
  Cos

On Sat, Aug 29, 2015 at 08:58AM, jan i wrote:
> Hi.
> 
> I really like our open way of reporting using the wiki but we have a small
> flaw in the procedure.
> 
> The wiki is not the place to report a  section, so I
> will send it to private@i.a.o and hope it will  be included.
> 
> rgds
> jan i.
> 
> 
> On 29 August 2015 at 01:00, Marvin Humphrey  wrote:
> 
> > Greetings, {podling} developers!
> >
> > This is a reminder that your report is due next Wednesday, September
> > 2nd.  Details below.
> >
> > Best,
> >
> > Marvin Humphrey, Report Manager for September, on behalf of the
> > Incubator PMC
> >
> > ---
> >
> > Dear podling,
> >
> > This email was sent by an automated system on behalf of the Apache
> > Incubator PMC. It is an initial reminder to give you plenty of time to
> > prepare your quarterly board report.
> >
> > The board meeting is scheduled for Wed, 16 September 2015, 10:30 am
> > Pacific.  The report for your podling will form a part of the Incubator
> > PMC report. The Incubator PMC requires your report to be submitted 2
> > weeks before the board meeting, to allow sufficient time for review and
> > submission (Wed, September 2nd).
> >
> > Please submit your report with sufficient time to allow the incubator
> > PMC, and subsequently board members to review and digest. Again, the
> > very latest you should submit your report is 2 weeks prior to the board
> > meeting.
> >
> > Thanks,
> >
> > The Apache Incubator PMC
> >
> > Submitting your Report
> >
> > --
> >
> > Your report should contain the following:
> >
> > *   Your project name
> > *   A brief description of your project, which assumes no knowledge of
> > the project or necessarily of its field
> > *   A list of the three most important issues to address in the move
> > towards graduation.
> > *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> > aware of
> > *   How has the community developed since the last report
> > *   How has the project developed since the last report.
> >
> > This should be appended to the Incubator Wiki page at:
> >
> > http://wiki.apache.org/incubator/September2015
> >
> > Note: This is manually populated. You may need to wait a little before
> > this page is created from a template.
> >
> > Mentors
> > ---
> >
> > Mentors should review reports for their project(s) and sign them off on
> > the Incubator wiki page. Signing off reports shows that you are
> > following the project - projects that are not signed may raise alarms
> > for the Incubator PMC.
> >
> > Incubator PMC
> >

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept HAWQ into the Apache Incubator

[Konstantin Boudnik]

We intend to convert that interest directly into
> participation and will be investing in activities to recruit
> additional committers from other companies.
> 
> === Reliance on Salaried Developers ===
> Most of the contributors are paid to work in the Big Data space. While
> they might wander from their current employers, they are unlikely to
> venture far from their core expertise and thus will continue to be
> engaged with the project regardless of their current employers.
> 
> === Relationships with Other Apache Products ===
> As mentioned in the Alignment section, HAWQ may consider various
> degrees of integration and code exchange with Apache Hadoop, Apache
> Spark and Apache Hive projects. We expect integration points to be
> inside and outside the project. We look forward to collaborating with
> these communities as well as other communities under the Apache
> umbrella.
> 
> === An Excessive Fascination with the Apache Brand ===
> While we intend to leverage the Apache ‘branding’ when talking to
> other projects as testament of our project’s ‘neutrality’, we have no
> plans for making use of Apache brand in press releases nor posting
> billboards advertising acceptance of HAWQ into Apache Incubator.
> 
> == Documentation ==
> The documentation is currently available at http://hawq.docs.pivotal.io/
> 
> == Initial Source ==
> Initial source code will be available immediately after Incubator PMC
> approves HAWQ joining the Incubator and will be licensed under the
> Apache License v2.
> 
> == Source and Intellectual Property Submission Plan ==
> As soon as HAWQ is approved to join the Incubator, the source code
> will be transitioned via an exhibit to Pivotal's current Software
> Grant Agreement onto ASF infrastructure and in turn made available
> under the Apache License, version 2.0.  We know of no legal
> encumberments that would inhibit the transfer of source code to the
> ASF.
> 
> == External Dependencies ==
> 
> Runtime dependencies:
>   * gimli (BSD)
>   * openldap (The OpenLDAP Public License)
>   * openssl (OpenSSL License and the Original SSLeay License, BSD style)
>   * proj (MIT)
>   * yaml (Creative Commons Attribution 2.0 License)
>   * python (Python Software Foundation License Version 2)
>   * apr-util (Apache Version 2.0)
>   * bzip2 (BSD-style License)
>   * curl (MIT/X Derivate License)
>   * gperf (GPL Version 3)
>   * protobuf (Google)
>   * libevent (BSD)
>   * json-c (https://github.com/json-c/json-c/blob/master/COPYING)
>   * krb5 (MIT)
>   * pcre (BSD)
>   * libedit (BSD)
>   * libxml2 (MIT)
>   * zlib (Permissive Free Software License)
>   * libgsasl (LGPL Version 2.1)
>   * thrift (Apache Version 2.0)
>   * snappy (Apache Version 2.0 (up to 1.0.1)/New BSD)
>   * libuuid-2.26 (LGPL Version 2)
>   * apache hadoop (Apache Version 2.0)
>   * apache avro (Apache Version 2.0)
>   * glog (BSD)
>   * googlemock (BSD)
> 
> Build only dependencies:
>   * ant (Apache Version 2.0)
>   * maven (Apache Version 2.0)
>   * cmake (BSD)
> 
> Test only dependencies:
>   * googletest (BSD)
> 
> Cryptography N/A
> 
> == Required Resources ==
> 
> === Mailing lists ===
>   * priv...@hawq.incubator.apache.org (moderated subscriptions)
>   * comm...@hawq.incubator.apache.org
>   * d...@hawq.incubator.apache.org
>   * iss...@hawq.incubator.apache.org
>   * u...@hawq.incubator.apache.org
> 
> === Git Repository ===
> https://git-wip-us.apache.org/repos/asf/incubator-hawq.git
> 
> === Issue Tracking ===
> JIRA Project HAWQ (HAWQ)
> 
> === Other Resources ===
> 
> Means of setting up regular builds for HAWQ on builds.apache.org will
> require integration with Docker support.
> 
> == Initial Committers ==
>   * Lirong Jian
>   * Hubert Huan Zhang
>   * Radar Da Lei
>   * Ivan Yanqing Weng
>   * Zhanwei Wang
>   * Yi Jin
>   * Lili Ma
>   * Jiali Yao
>   * Zhenglin Tao
>   * Ruilong Huo
>   * Ming Li
>   * Wen Lin
>   * Lei Chang
>   * Alexander V Denissov
>   * Newton Alex
>   * Oleksandr Diachenko
>   * Jun Aoki
>   * Bhuvnesh Chaudhary
>   * Vineet Goel
>   * Shivram Mani
>   * Noa Horn
>   * Sujeet S Varakhedi
>   * Junwei (Jimmy) Da
>   * Ting (Goden) Yao
>   * Mohammad F (Foyzur) Rahman
>   * Entong Shen
>   * George C Caragea
>   * Amr El-Helw
>   * Mohamed F Soliman
>   * Venkatesh (Venky) Raghavan
>   * Carlos Garcia
>   * Zixi (Jesse) Zhang
>   * Michael P Schubert
>   * C.J. Jameson
>   * Jacob Frank
>   * Ben Calegari
>   * Shoabe Shariff
>   * Rob Day-Reynolds
>   * Mel S Kiyama
>   * Charles Alan Litzell
>   * David Yozie
>   * Ed Espino
>   * Caleb Welton
>   * Pa

Re: [VOTE] Graduate Apache Usergrid from the Incubator

[Konstantin Boudnik]

+1 (binding)

Good luck!
  Cos

On Mon, Aug 10, 2015 at 04:15PM, Dave wrote:
 The Usergrid project has made three releases from the Incubator (1.0.0,
 1.0.1 and 1.0.2), has added multiple and diverse committers, and the
 project has completed all required items on the graduation check-list [1].
 Consensus appears to be ([2] and [3]) that the project is ready to graduate
 and so I'm calling this vote and sharing the Usergrid Top Level Project
 Resolution (see below).
 
 The vote will run for 72 hours, ending 3pm EST Thursday Aug 13, 2015.
 Everyone in the Usergrid and Incubator communities is invited and
 encouraged to vote, although only PPMC votes are binding
 
 [ ] +1 Graduate Apache Usergrid from the Incubator.
 [ ] +0 Don't care.
 [ ] -1 Don't graduate Apache Usergrid from the Incubator because ...
 
 Here's my binding vote: +1.
 
 Thanks,
 Dave
 
 [1] http://incubator.apache.org/projects/usergrid.html
 [2] Dev list discussion:
 http://mail-archives.apache.org/mod_mbox/incubator-usergrid-dev/201507.mbox/%3CCAF1aazBvhYD3ZM_nKDDbrwO%3D4y6d%2BR1nH1M-2FWc9GZNuPtAjw%40mail.gmail.com%3E
 [3] Incubator discussion:
 http://mail-archives.apache.org/mod_mbox/incubator-general/201508.mbox/%3CCAF1aazCBCKNNYGT42%2BuGo%3DAdMb9uLkBrEm04rWj2tPe5LG%2BE9A%40mail.gmail.com%3E
 
 
 Apache Usergrid top-level project resolution:
 
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to the Usergrid BaaS software,
for distribution at no charge to the public.
 
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Usergrid Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further
 
RESOLVED, that the Apache Usergrid Project be and hereby is
responsible for the creation and maintenance of open-source
software related to the Usergrid BaaS software; and be it further
 
RESOLVED, that the office of Vice President, Usergrid be and
hereby is created, the person holding such office to serve at
the direction of the Board of Directors as the chair of the
Apache Usergrid Project, and to have primary responsibility for
management of the projects within the scope of responsibility
of the Apache Usegrid Project; and be it further
 
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Usegrid Project:
 
* Tim Anglade  timangl...@apache.org
* Askhat Asanaliev aasanal...@apache.org
* John D. Amentjohndam...@apache.org
* Ed Anuff edan...@apache.org
* Furkan Bıçak fbi...@apache.org
* Ryan Bridges ry...@apache.org
* Jake Farrell jfarr...@apachge.org
* Scott Ganyo  scottga...@apache.org
* Sungju Jin   sun...@apache.org
* Dave Johnson snoopd...@apache.org
* Alex Karasuluakaras...@apache.org
* Salih Kardan skar...@apache.org
* Jim Jagielskij...@apache.org
* Shaozhuang Liu   st...@apache.org
* Nate McCall  zzn...@apache.org
* John Mcgibbney   lewi...@apache.org
* Alex Muramotoamuram...@apache.org
* Todd Ninetoddn...@apache.org
* Luciano Resende  lrese...@apache.org
* Yiğit Şaplı  yig...@apache.org
* Rod Simpson  rockers...@apache.org
* Jeff Westjeffreyaw...@apache.org
 
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Todd Nine
be appointed to the office of Vice President, Usergrid, to serve
in accordance with and subject to the direction of the Board of
Directors and the Bylaws of the Foundation until death,
resignation, retirement, removal or disqualification, or until
a successor is appointed; and be it further
 
RESOLVED, that the initial Apache Usergrid Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Usegrid podling; and be it further
 
RESOLVED, that all responsibility pertaining to the Apache
Incubator Usergrid podling encumbered upon the Apache Incubator
PMC are hereafter discharged.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Reform of Incubator

[Konstantin Boudnik]

Sorry if it rubs the wrong way. However, we just have seen through the Ignite
discussion (most recent one) the examples where personal expectations were
represented as graduation requirements. It is perhaps in good faith - I am not
questioning the intention. I am saying that when requirements are unclear,
people interpret them based on their own understanding of unwritten Apache
ethos. As Brane called it earlier - confusing opinions and policies. You see
where I am going with this, right?

Cos

On Tue, Aug 04, 2015 at 08:56AM, Julian Hyde wrote:
 Cos,
 
 There is no bureaucratism outbreak. People are not express[ing]
 their expectations as a law-of-the-land. People are trying, in good
 faith, to make sure that decisions are made consistent with the Apache
 ethos. And before you ask, no, that ethos cannot be written down; it
 has to be interpreted via debate. This is what debate sounds like.
 
 Julian
 
 
 On Mon, Aug 3, 2015 at 9:03 PM, Konstantin Boudnik c...@apache.org wrote:
  On Mon, Aug 03, 2015 at 11:36AM, Roman Shaposhnik wrote:
  On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz
  bdelacre...@apache.org wrote:
   On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik ro...@shaposhnik.org 
   wrote:
   ...who else thinks the movement towards empowering
   PPMCs and making IPMC very much like the board makes sense?...
  
   How is that different from the status quo where a podling with active
   mentors can have their releases +1ed by their mentors, requiring
   minimal interaction with the IPMC?
 
  I think it is more of a bias issue. IOW, today it seems that the default 
  bias
  of IPMC is to consider itself a final authority (or a gatekeeper) on 
  podling
  releases. We need to break that bias and make it so that it is truly a 
  safety
  net, rather than a gatekeeper.
 
  IOW, I'd like the release traffic on general@ to ONLY consist of [NOTICE]
  emails, not [VOTE].
 
  We perhaps are observing the well known phenomena called self-selection bias
  [1] And it seems to me that the simplification and better clarification of 
  the
  incubation guidelines might be exactly what's needed to prevent a
  bureaucratism outbreak. As well as the situation when ppl express their
  expectations as a law-of-the-land (even from best intentions).
 
  Cos
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Reform of Incubator

[Konstantin Boudnik]

On Tue, Aug 04, 2015 at 02:50PM, Joe Brockmeier wrote:
 On 08/04/2015 02:45 PM, Konstantin Boudnik wrote:
  Sorry if it rubs the wrong way. However, we just have seen through the 
  Ignite
  discussion (most recent one) the examples where personal expectations were
  represented as graduation requirements. It is perhaps in good faith - I am 
  not
  questioning the intention. I am saying that when requirements are unclear,
  people interpret them based on their own understanding of unwritten Apache
  ethos. As Brane called it earlier - confusing opinions and policies. You 
  see
  where I am going with this, right?
 
 Perhaps I'm unclear on the proposal - but how would that be mitigated by
 this proposal? I understand that it might expose podlings to less of
 this when directed towards the full IPMC for graduation, but how would
 it prevent this if a mentor confuses personal expectations for
 graduation requirements?
 
 Isn't that still a potential issue?

You're right, it still might be an issue. My vision was that with a reduced
involvement of the IPMC namely

  - IPMC delegating more day-to-day oversight of the podlings to the mentors
  - release votes just Cc'ed to general@ instead of an explicit IPMC vote. It
doesn't contradict the requirement of the binding votes, but the primarily
would be coming from mentors, I believe
  - more precise graduation guidelines, eg w/o moot 'diversity'-like points

the environment will be less accommodating for such confusions and would cause
lesser number of complex debates. This, in turn, will make the incubation
process more transparent and less counter-intuitive for newcomers. 

Hopefully it clarifies my point a bit better. What do you think?
  Cos

 I may misunderstand or have lost track of how that's handled in all the
 discussion.



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org