Re: [VOTE] Apache Spark for the Incubator

2013-06-10 Thread Joe Brockmeier
On Sat, Jun 8, 2013, at 12:34 AM, Mattmann, Chris A (398J) wrote:
 [ ] +1 Accept Spark into the Apache Incubator.
 [ ] +0 Don't care.
 [ ] -1 Don't accept Spark into the Apache Incubator because..

+1 (binding)

Best,

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



Re: [PROPOSAL] Apache Spark for the Incubator

2013-06-10 Thread Mohammad Nour El-Din
Hi Marvin


On Sun, Jun 9, 2013 at 5:15 AM, Marvin Humphrey mar...@rectangular.comwrote:

 On Sat, Jun 8, 2013 at 4:55 PM, Mattmann, Chris A (398J)
 chris.a.mattm...@jpl.nasa.gov wrote:
  Note: we discussed adding Roman before the VOTE and it was
  fine with the incoming Spark community, so Roman is now on
  the wiki for the proposal.
 
  In case this changes anyone's VOTE on the VOTE thread, feel
  free to speak up or change your VOTE. Otherwise, nothing else
  to see here folks.

 +1 for the original proposal.

 +0.9 for the new proposal.

 Yes, I expect you to tally my vote that way.  :)

 Next time, please be more careful when starting a VOTE and please don't
 change
 the proposal text in the middle of a vote.  Personnel issues in proposals
 have
 caused significant problems in the past.  That's unlikely to happen in this
 case, but I want to register my protest now because it might save us
 hundreds
 or thousands of emails in the future.


This is *not* a [VOTE] yet, this is a [PROPOSAL] in which case the proposal
can be updated and enhanced if required. So allow me to disagree about what
you replied regarding *not to make changes to the proposal in such phase*



 Good luck, Spark!

 Marvin Humphrey

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




-- 
Thanks
- Mohammad Nour

Life is like riding a bicycle. To keep your balance you must keep moving
- Albert Einstein


Removed HCatalog from board report

2013-06-10 Thread Alan Gates
As HCatalog has graduated I removed it from the June2013 board report wiki.  I 
know I need to get it removed from all the appropriate places so it quits 
getting included in the reports.  It's on my todo list.

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



Re: Error collecting infrastructure for Openmeetings

2013-06-10 Thread Alexei Fedotov
Answering a personal request on general@ usage:

1) we discovered from our internal discussions that the topic is sensitive
and want to be transparent with our intentions to collect user data;
2) we want to know more about Apache ways of addressing the problem;
3) we have not got any answer from legal@ and infra@ in this thread, thus I
believe this may be more a cultural issue than a legal or technical issue;
the incubator is a culture-spreading entity;
4) finally addressing general@ may be my mistake.

I still will be grateful if anyone shares their experience on best
practices on how to collect user errors to improve product quality.
10.06.2013 12:05 пользователь Alexei Fedotov alexei.fedo...@gmail.com
написал:

 [added general@ for vivid discussion]

 Hello Sebastian,

 I'm glad that the statement that this infrastructure is needed is not
 questioned.

 We technically can use either CGI script, or existing Confluence API.
 The intention for using Google Analytics is minimum effort. AFAIK,
 many Apache projects do use Google Analytics already.

 The goal for the request is to avoid inventing a project-wide policy
 where foundation-wide policy is needed.

 With best regards, Alexei

 --
 With best regards / с наилучшими пожеланиями,
 Alexei Fedotov / Алексей Федотов,
 http://dataved.ru/
 +7 916 562 8095


 On Mon, Jun 10, 2013 at 7:03 AM, seba.wag...@gmail.com
 seba.wag...@gmail.com wrote:
  Hi Alexei,
 
  what about a simple CGI script that takes the input and send an email to
 the
  mailing list?
  I think some more simple approach would do the same and does not have
 such a
  deep impact on the whole infrastructure. Some legal and privacy aspects
 are
  still tbc.
 
  However no matter what we do it is unlikely that including the actual UA
  code or any kind of real pwd / hash in a release is a good idea. It is
 quite
  easy to manipulate that.
 
  Also the question rises if the OpenMeetings server is in a public
 network at
  all. Just sending request blindly without knowing if they ever reach
 their
  destination is kind of odd.
 
  It should be some subscribe mechanism where an OpenMeetings admin can
  activate the error collecting. The activation could then subscribe and
 load
  a hash that will auth that server for error collecting.
 
  If you put that activation in the installer with appropriate
 explenations I
  think it has better chances to find a wider positive reaction in devs and
  users.
 
  Maybe it would be enough to give some kind of more general feedback from
  @legal and @infra and we can then in the OpenMeetings PMC create a more
  detailed spec of that component.
 
  @legal: Do you have general constraints regarding error collecting ?
 
  @infra: What kind of advices can you give us? I guess some CGI scripts
 are
  not that big deal. Is there any process who would review and activate /
 make
  them executable?
 
  Thanks,
  Sebastian
 
  Am 06.06.2013 19:38 schrieb Alexei Fedotov alexei.fedo...@gmail.com:
 
  [added Shane for reputation issues]
 
  Hello, Infra and Legal folks,
 
  We ask you for advice on the automated error collection
  infrastructure. Any helpful ideas are appreciated.
 
  1. Our users are tainted with iphones and other reliable and fancy
  staff. They start wanting openmeetings to work reliably. This makes us
  think of a global error collecting infrastructure to plan important
  bug fixes. Here is an example by Firefox [1].
 
  We believe collecting user errors is generally ok if proper
  preparations are made. Is it generally possible to implement error
  collecting infrastructure as a part of Apache project? If not, we can
  try to do it as a commercial company, yet Firefox example shows a
  non-commercial org can be behind that error collection.
 
  2. Could we use Google Analytics to store collected errors? The
  general Apache practice is to use Apache infrastructure. Google
  Analytics allows us storing 50 mln. events for free. The comparable
  thing won't be free for Apache for sure.
 
  Once can use JIRA, or Confluence via API, this will be a heavy load.
  Are you ok with using third party for storing error  environment
  messages and associated risks?
 
  The code we are talking about is below:
 try {
 _gaq = _gaq || [];
 _gaq.push(['_setAccount', 'UA-13024987-1']); // PMC id
 _gaq.push(['_trackPageview']);
 _gaq.push(['_trackEvent', 'Openmeetings client error',
  message, '', 0, true]);
 } catch (exception) {
 alert(exception);
 }
 
  3. Is it ok for PMC to share Google Analytics id? Should we use some
  Apache Id instead?
 
  4. Which preparations should be done to start this error collection
  service in the next release?
 
  4.1. Is it ok just to semi-silently mention in release notes, that
  errors are automatically sent to the (Google) server right now?
  4.2. Or should we explicitly notify each new user that the errors are
  now to be 

[VOTE] Release Apache Mesos 0.12.0-incubating (RC1)

2013-06-10 Thread Benjamin Mahler
Please vote on releasing the following candidate as Apache Mesos
(incubating) version 0.12.0. This will be the fourth incubator release for
Mesos in Apache.

The candidate for Mesos 0.12.0-incubating release is available at:
http://people.apache.org/~bmahler/mesos-0.12.0-incubating-RC1/mesos-0.12.0-incubating.tar.gz

The tag to be voted on is 0.12.0-rc1:
https://git-wip-us.apache.org/repos/asf?p=incubator-mesos.git;a=tag;h=57d7b9719dce662881b162eba10b5765a807d53c

The MD5 checksum of the tarball can be found at:
http://people.apache.org/~bmahler/mesos-0.12.0-incubating-RC1/mesos-0.12.0-incubating.tar.gz.md5

The signature of the tarball can be found at:
http://people.apache.org/~bmahler/mesos-0.12.0-incubating-RC1/mesos-0.12.0-incubating.tar.gz.asc

PGP key used to sign the release:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD0BEBB95D141A5B6

Please vote on releasing this package as Apache Mesos 0.12.0-incubating!

The vote is open until Thursday, June 13th at 00:00 UTC and passes if
a majority
of at least 3 +1 IPMC votes are cast.

[ ] +1 Release this package as Apache Mesos 0.12.0-incubating
[ ] -1 Do not release this package because ...

To learn more about Apache Mesos, please see
http://incubator.apache.org/mesos.


Re: [VOTE] Apache Spark for the Incubator

2013-06-10 Thread Tim Williams
+1

--tim

On Sat, Jun 8, 2013 at 1:34 AM, Mattmann, Chris A (398J)
chris.a.mattm...@jpl.nasa.gov wrote:
 Hi Folks,

 OK discussion has died down, time to VOTE to accept Spark into the
 Apache Incubator. I'll let the VOTE run for at least a week.

 So far I've heard +1s from the following folks, so no need for them
 to VOTE again unless they want to change their VOTE:

 +1

 Chris Mattmann*
 Konstantin Boudnik
 Henry Saputra*
 Reynold Xin
 Pei Chen
 Roman Shaposhnik*
 Suresh Marru*

 * -indicates IPMC

 [ ] +1 Accept Spark into the Apache Incubator.
 [ ] +0 Don't care.
 [ ] -1 Don't accept Spark into the Apache Incubator because..

 Proposal text is below.

 === Abstract ===
 Spark is an open source system for large-scale data analysis on clusters.

 === Proposal ===
 Spark is an open source system for fast and flexible large-scale data
 analysis. Spark provides a general purpose runtime that supports
 low-latency execution in several forms. These include interactive
 exploration of very large datasets, near real-time stream processing, and
 ad-hoc SQL analytics (through higher layer extensions). Spark interfaces
 with HDFS, HBase, Cassandra and several other storage storage layers, and
 exposes APIs in Scala, Java and Python.
 Background
 Spark started as U.C. Berkeley research project, designed to efficiently
 run machine learning algorithms on large datasets. Over time, it has
 evolved into a general computing engine as outlined above. Spark¹s
 developer community has also grown to include additional institutions,
 such as universities, research labs, and corporations. Funding has been
 provided by various institutions including the U.S. National Science
 Foundation, DARPA, and a number of industry sponsors. See:
 https://amplab.cs.berkeley.edu/sponsors/ for full details.

 === Rationale ===
 As the number of contributors to Spark has grown, we have sought for a
 long-term home for the project, and we believe the Apache foundation would
 be a great fit. Spark is a natural fit for the Apache foundation: Spark
 already interoperates with several existing Apache projects (HDFS, HBase,
 Hive, Cassandra, Avro and Flume to name a few). The Spark team is familiar
 with the Apache process and and subscribes to the Apache mission - the
 team includes multiple Apache committers already. Finally, joining Apache
 will help coordinate the development effort of the growing number of
 organizations which contribute to Spark.

 == Initial Goals ==
 The initial goals will most likely be to move the existing codebase to
 Apache and integrate with the Apache development process. Furthermore, we
 plan for incremental development, and releases along with the Apache
 guidelines.

 === Current Status ===
 == Meritocracy ==
 The Spark project already operates on meritocratic principles. Today,
 Spark has several developers and has accepted multiple major patches from
 outside of U.C. Berkeley. While this process has remained mostly informal
 (we do not have an official committer list), an implicit organization
 exists in which individuals who contribute major components act as
 maintainers for those modules. If accepted, the Spark project would
 include several of these participants as committers from the onset. We
 will work to identify all committers and PPMC members for the project and
 to operate under the ASF meritocratic principles.

 === Community ===
 Acceptance into the Apache foundation would bolster the already strong
 user and developer community around Spark. That community includes dozens
 of contributors from several institutions, a meetup group with several
 hundred members, and an active mailing list composed of hundreds of users.
 Core Developers
 The core developers of our project are listed in our contributors and
 initial PPMC below. Though many exist at UC Berkeley, there is a
 representative cross sampling of other organizations including Quantifind,
 Microsoft, Yahoo!, ClearStory Data, Bizo, Intel, Tagged and Webtrends.


 === Alignment ===
 Our proposed effort aligns with several ongoing BIGDATA and U.S. National
 priority funding interests including the NSF and its Expeditions program,
 and the DARPA XDATA project. Our industry partners and collaborators are
 well aligned with our code base.

 There are also a number of related Apache projects and dependencies, that
 will be mentioned in the Relationships with Other Apache products section.

 == Known Risks ==

 === Orphaned Products ===
 Given the current level of investment in Spark - the risk of the project
 being abandoned is minimal. There are several constituents who are highly
 incentivized to continue development. The U.C. Berkeley AMPLab relies on
 Spark as a platform for a large number of long-term research projects.
 Several companies have build verticalized products which are tightly
 dependent on Spark. Other companies have devoted significant internal
 infrastructure investment in Spark.

 === Inexperience with Open Source ===
 Spark 

Re: [VOTE] Release Apache Mesos 0.12.0-incubating (RC1)

2013-06-10 Thread Benjamin Mahler
Correction on the tag link:
https://git-wip-us.apache.org/repos/asf?p=incubator-mesos.git;a=tag;h=5332ade3c403b4d9fcdcd9194ee86d3fa99eca17


On Mon, Jun 10, 2013 at 5:05 PM, Benjamin Mahler
benjamin.mah...@gmail.comwrote:

 Please vote on releasing the following candidate as Apache Mesos
 (incubating) version 0.12.0. This will be the fourth incubator release
 for Mesos in Apache.

 The candidate for Mesos 0.12.0-incubating release is available at:

 http://people.apache.org/~bmahler/mesos-0.12.0-incubating-RC1/mesos-0.12.0-incubating.tar.gz

 The tag to be voted on is 0.12.0-rc1:

 https://git-wip-us.apache.org/repos/asf?p=incubator-mesos.git;a=tag;h=57d7b9719dce662881b162eba10b5765a807d53c

 The MD5 checksum of the tarball can be found at:

 http://people.apache.org/~bmahler/mesos-0.12.0-incubating-RC1/mesos-0.12.0-incubating.tar.gz.md5

 The signature of the tarball can be found at:

 http://people.apache.org/~bmahler/mesos-0.12.0-incubating-RC1/mesos-0.12.0-incubating.tar.gz.asc

 PGP key used to sign the release:
 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD0BEBB95D141A5B6

 Please vote on releasing this package as Apache Mesos 0.12.0-incubating!

 The vote is open until Thursday, June 13th at 00:00 UTC and passes if a 
 majority
 of at least 3 +1 IPMC votes are cast.

 [ ] +1 Release this package as Apache Mesos 0.12.0-incubating
 [ ] -1 Do not release this package because ...

 To learn more about Apache Mesos, please see
 http://incubator.apache.org/mesos.