[ANNOUNCE] Apache Slider 0.70.1-incubating release

2015-03-30 Thread Gour Saha
The Apache Slider team is proud to announce Apache Slider incubation release 
version 0.70.1-incubating.

Apache Slider (incubating) is a YARN application which deploys existing 
distributed applications on YARN, monitors them, and makes them larger or 
smaller as desired - even while the application is running.

The release artifacts are available at:
http://www.apache.org/dyn/closer.cgi/incubator/slider/0.70.1-incubating/

To use these artifacts, please use the following documentation:
http://slider.incubator.apache.org/docs/getting_started.html

We would like to thank all the contributors that made the release possible.

Regards,
The Slider Team



Re: junior Mentor request advice from senior Mentor.

2015-03-30 Thread Marvin Humphrey
On Mon, Mar 30, 2015 at 3:31 PM, Konstantin Boudnik c...@apache.org wrote:

 Not sure what are the licenses of the libs in question, so please refer to
 http://www.apache.org/legal/resolved.html if in doubt.

*   zlib1 -- Zlib license
*   libxml2  -- MIT license
*   GNU libiconv -- LGPL
*   SDL -- Zlib license
*   SDL_Image -- Zlib license

 And Brane's suggestion
 would work in any case, even with (L)GPL bits. Hosting it outside and letting
 developers/users to pull them in on their own is pretty much bullet-proof.

It's not quite bulletproof in the case of libraries. Optional LGPL
libraries and GPL build tools, yes.  Optional GPL libraries, it
depends. Mandatory GPL or LGPL library dependencies are probably
trouble.

Marvin Humphrey

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



Re: junior Mentor request advice from senior Mentor.

2015-03-30 Thread Konstantin Boudnik
On Sun, Mar 29, 2015 at 01:10PM, Branko Čibej wrote:
 On 22.03.2015 09:05, jan i wrote:
  Hi.
 
  Sorry could not resist the subject line, but fact is I need a good advice.
  I know our rulebook about including 3rd party libraries, but rules are open
  to interpretation, and since I am involved in the development I consider my
  opinion for biased.
 
  In Corinthia we depend on the following third party libraries (currently
  not in repo):
  zlib1
  libxml2
  iconv
  SDL
  SDL_Image.
 
  The first 3 ones are not available precompiled for windows 64bit (at least
  not from a trustworthy source), so we need to make it available.
 
  I see 3 options:
  1) Ask developers to download and build by them self (sadly enough they
  also need to setup the vcxproj file)
  2) one PPMC (in this case me) precompilles all libs, make them available as
  a zip on minotaur,
  which of course is a trusted source, but somewhat ackward to the project.
  3) the sources are added to the repo, in a designated directory and
  integrated in our build system.
 
  I would prefer to suggest 3), but I want to be absolutely sure, that we do
  it the right way.
  I would suggest:
  a) put a README, for each downloaded lib, with the original URL and version
  b) add the licenses to the LICENSE file
  c) copy the README into NOTICES
  d) In the first commit, make a commit text like the README.
  e) Make the missing bits for a 64bit version, and integrate in our build
  system.
 
  Would that be a good solution to the problem, or do you have other ideas or
  corrections ?
 
  My goal here is, to make the right decision up front, and not when we have
  cut a release.
 
 Write a script that downloads the supported versions and include the
 necessary vcxproj files in your source distribution. I believe msbuild
 can download stuff, so you may even be able to automate the download
 from the project file.

Not sure what are the licenses of the libs in question, so please refer to
http://www.apache.org/legal/resolved.html if in doubt. And Brane's suggestion
would work in any case, even with (L)GPL bits. Hosting it outside and letting
developers/users to pull them in on their own is pretty much bullet-proof.

Cos


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



[VOTE] Release Apache Ignite (Incubating) 1.0

2015-03-30 Thread Dmitriy Setrakyan
Hello,

The Apache Ignite PPMC voted to release Apache Ignite (incubating) 1.0.

We now request the IPMC to vote on the release.

Here is the PPMC voting result form Apache Ignite IPMC (note that 2 votes
are from the IPMC members)

2 +1 (IPMC)
5 +1 (PPMC)

The dev list voting thread:
http://s.apache.org/N5N

All release artifacts have been uploaded here:
http://people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/

Please start voting.

+1 - to accept Apache Ignite (incubating) 1.0 release
0 - don't care either way
-1 - DO NOT accept Apache Ignite (incubating) 1.0 release (explain why)


Re: ASFIncubator now managed via TweetDeck

2015-03-30 Thread David Nalley

 The above makes a really nice, security-conscious scheme
 that I would love to champion among various PMCs
 and suggest that we document it as part of our social
 media guidelines. The only open question in my mind
 is who (and by extension what email address) should
 the master ASFxxx account be associated with. I see
 two alternatives here:
 * ASF Infra team collectively owns it
 * Whoever controls @TheASF owns it


Neither IMO.
Infra doesn't want it (and we will politely decline if asked to manage
your social media creds). And burdening Sally, Jim, Joe, etc with
scores of projects credentials isn't going to scale well.

If I were to define it, Make the address for the account
private@$foo.a.o (CloudStack uses an alias that forwards to
private@cs.a.o IIRC) I would say turn on MFA for the account  (device
held by the chair or his designee) keep the override codes encrypted
to multiple PMC members in the projects private svn tree (and open to
add more PMC members at their request). That gives the PMC the ability
to override if someone disappears or goes off the tracks. Federating
access is easy with Tweetdeck or Hootsuite - securing the account
becomes a lot easier as well.

--David

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



Re: [VOTE] Release Apache Ignite (Incubating) 1.0

2015-03-30 Thread P. Taylor Goetz
A few notes that come to mind:

- In the VOTE RESULT, it helps if you can name who voted.
- Can you include the git commit SHA of what is being voted on? As well as a 
link?
- I see the KEYS file is in the upload directory, but again, a direct link 
would help.

I don’t think any of the above would/should block a release. I only point them 
out because it makes reviewing a release more difficult.

Getting people to review a release can be hard. The easier you make it to 
review a release, the better your chance of getting the requisite binding +1 
votes.

-Taylor

On Mar 30, 2015, at 9:38 PM, Dmitriy Setrakyan dsetrak...@apache.org wrote:

 Hello,
 
 The Apache Ignite PPMC voted to release Apache Ignite (incubating) 1.0.
 
 We now request the IPMC to vote on the release.
 
 Here is the PPMC voting result form Apache Ignite IPMC (note that 2 votes
 are from the IPMC members)
 
 2 +1 (IPMC)
 5 +1 (PPMC)
 
 The dev list voting thread:
 http://s.apache.org/N5N
 
 All release artifacts have been uploaded here:
 http://people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/
 
 Please start voting.
 
 +1 - to accept Apache Ignite (incubating) 1.0 release
 0 - don't care either way
 -1 - DO NOT accept Apache Ignite (incubating) 1.0 release (explain why)



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [VOTE] Release Apache Ignite (Incubating) 1.0

2015-03-30 Thread P. Taylor Goetz
+1

After some digging, the PPMC VOTE looks good. 

-Taylor

On Mar 31, 2015, at 1:01 AM, P. Taylor Goetz ptgo...@gmail.com wrote:

 A few notes that come to mind:
 
 - In the VOTE RESULT, it helps if you can name who voted.
 - Can you include the git commit SHA of what is being voted on? As well as a 
 link?
 - I see the KEYS file is in the upload directory, but again, a direct link 
 would help.
 
 I don’t think any of the above would/should block a release. I only point 
 them out because it makes reviewing a release more difficult.
 
 Getting people to review a release can be hard. The easier you make it to 
 review a release, the better your chance of getting the requisite binding +1 
 votes.
 
 -Taylor
 
 On Mar 30, 2015, at 9:38 PM, Dmitriy Setrakyan dsetrak...@apache.org wrote:
 
 Hello,
 
 The Apache Ignite PPMC voted to release Apache Ignite (incubating) 1.0.
 
 We now request the IPMC to vote on the release.
 
 Here is the PPMC voting result form Apache Ignite IPMC (note that 2 votes
 are from the IPMC members)
 
 2 +1 (IPMC)
 5 +1 (PPMC)
 
 The dev list voting thread:
 http://s.apache.org/N5N
 
 All release artifacts have been uploaded here:
 http://people.apache.org/~dsetrakyan/incubator-ignite-1.0.0/
 
 Please start voting.
 
 +1 - to accept Apache Ignite (incubating) 1.0 release
 0 - don't care either way
 -1 - DO NOT accept Apache Ignite (incubating) 1.0 release (explain why)
 



signature.asc
Description: Message signed with OpenPGP using GPGMail