Re: Error For Toree Site Repo svn ci

2016-06-13 Thread Luciano Resende 
Moving to Toree dev (bcc general@a.o)

What svn info returns to you ? Just want to make sure you are using https
which is writable compared to http which is read only.


On Mon, Jun 13, 2016 at 2:12 PM, Corey Stubbs  wrote:

> Hi,
>
> I am trying to update the site for Apache Toree, but am unable to push to
> svn. When I run *svn ci* I see the following error:
>
> svn: E195023: Commit failed (details follow):
> svn: E195023: Changing directory
> '/private/tmp/toree-site/site/assets/image' is forbidden by the server
> svn: E175013: Access to
> '/repos/asf/!svn/txr/1748309-12dl1/incubator/toree/site/assets/image'
> forbidden
> svn: E195023: Your commit message was left in a temporary file:
> svn: E195023:'/private/tmp/toree-site/svn-commit.tmp'
>
>
> The image folder mentioned in the error is new as of my commit. I am new to
> svn so I don't know if I need to update something on the server or not.
>
>
> Kind Regards,
> Corey Stubbs
>



-- 
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: [VOTE] Accept SensSoft into the Apache Incubator WAS Re: [VOTE] Accept

2016-06-13 Thread Mattmann, Chris A (3980) 
+1

Sent from my iPhone

> On Jun 13, 2016, at 4:34 PM, Lewis John Mcgibbney  
> wrote:
> 
> Title here should be [VOTE] Accept SensSoft into the Apache Incubator
> 
> On Mon, Jun 13, 2016 at 10:55 AM, Lewis John Mcgibbney <
> lewis.mcgibb...@gmail.com> wrote:
> 
>> Hi general@,
>> Since I am back from a bit of vacation and it seems the discussion has
>> died down, I am now calling a vote on accepting SensSoft into the Apache
>> Incubator.
>> 
>> For those who are interested the DISCUSS thread can be found at
>> https://s.apache.org/senssoft_discuss
>> 
>> This vote will run for the usual 72 hours.
>> 
>> Please VOTE as follows
>> 
>> [ ] +1 Accept SensSoft into the Apache Incubator
>> [ ] +/-0 Not overly bothered either way
>> [ ] -1 DO NOT accept SensSoft into the Apache Incubator (please state why)
>> 
>> Thanks everyone who contributed to DISCUSS and is able to participate in
>> VOTE
>> 
>> Best
>> Lewis
>> P.S. Here is my +1
>> 
>> #
>> 
>> = SensSoft Proposal =
>> 
>> == Abstract ==
>> The Software as a Sensor™ (SensSoft) Project offers an open-source (ALv2.0)
>> software tool usability testing platform. It includes a number of
>> components that work together to provide a platform for collecting data
>> about user interactions with software tools, as well as archiving,
>> analyzing and visualizing that data. Additional components allow for
>> conducting web-based experiments in order to capture this data within a
>> larger experimental framework for formal user testing. These components
>> currently support Java Script-based web applications, although the schema
>> for “logging” user interactions can support mobile and desktop
>> applications, as well. Collectively, the Software as a Sensor Project
>> provides an open source platform for assessing how users interacted with
>> technology, not just collecting what they interacted with.
>> 
>> == Proposal ==
>> The Software as a Sensor™ Project is a next-generation platform for
>> analyzing how individuals and groups of people make use of software tools
>> to perform tasks or interact with other systems. It is composed of a number
>> of integrated components:
>> * User Analytic Logging Engine (User ALE) refers to a simple Application
>> Program Interface (API) and backend infrastructure. User ALE provides
>> “instrumentation” for software tools, such that each user interaction
>> within the application can be logged, and sent as a JSON message to an
>> Elasticsearch/Logstash/Kibana (Elastic Stack) backend.
>>   * The API provides a robust schema that makes user activities human
>> readable, and provides an interpretive context for understanding that
>> activity’s functional relevance within the application. The schema provides
>> highly granular information best suited for advanced analytics. This
>> hierarchical schema is as follows:
>> * Element Group: App features that share function (e.g., map group)
>> * Element Sub: Specific App feature (e.g., map tiles)
>> * Element Type: Category of feature (e.g., map)
>> * Element ID: [attribute] id
>> * Activity: Human imposed label (e.g., “search”)
>> * Action: Event class (e.g., zoom, hover, click)
>>   * The API can either be manually embedded in the app source code, or
>> implemented automatically by inserting a script tag in the source code.
>>   * Users can either setup up their own Elastic stack instance, or use
>> Vagrant, a virtualization environment, to deploy a fully configured Elastic
>> stack instance to ship and ingest user activity logs and visualize their
>> log data with Kibana.
>>   * RESTful APIs allow other services to access logs directly from
>> Elasticsearch.
>>   * User ALE allows adopters to own the data they collect from users
>> outright, and utilize it as they see fit.
>> * Distill is an analytics stack for processing user activity logs
>> collected through User ALE. Distill is fully implemented in Python,
>> dependent on graph-tool to support graph analytics and other external
>> python libraries to query Elasticsearch. The two principle functions of
>> Distill are segmentation and graph analytics:
>>   * Segmentation allows for partitioning of the available data along
>> multiple axes. Subsets of log data can be selected via their attributes in
>> User ALE (e.g. Element Group or Activity), and by users/sessions.  Distill
>> also has the capability to ingest and segment data by additional attributes
>> collected through other channels (e.g. survey data, demographics).This
>> allows adopters to focus their analysis of log data on precisely the
>> attributes of their app (or users) they care most about.
>>   * Distill’s usage metrics are derived from a probabilistic
>> representation of the time series of users’ interactions with the elements
>> of the application. A directed network is constructed from the
>> representation, and metrics from graph theory (e.g. betweenness centrality,
>> in/out-degree of nodes) are derived from the structu

[VOTE] Accept SensSoft into the Apache Incubator WAS Re: [VOTE] Accept

2016-06-13 Thread Lewis John Mcgibbney 
Title here should be [VOTE] Accept SensSoft into the Apache Incubator

On Mon, Jun 13, 2016 at 10:55 AM, Lewis John Mcgibbney <
lewis.mcgibb...@gmail.com> wrote:

> Hi general@,
> Since I am back from a bit of vacation and it seems the discussion has
> died down, I am now calling a vote on accepting SensSoft into the Apache
> Incubator.
>
> For those who are interested the DISCUSS thread can be found at
> https://s.apache.org/senssoft_discuss
>
> This vote will run for the usual 72 hours.
>
> Please VOTE as follows
>
> [ ] +1 Accept SensSoft into the Apache Incubator
> [ ] +/-0 Not overly bothered either way
> [ ] -1 DO NOT accept SensSoft into the Apache Incubator (please state why)
>
> Thanks everyone who contributed to DISCUSS and is able to participate in
> VOTE
>
> Best
> Lewis
> P.S. Here is my +1
>
> #
>
> = SensSoft Proposal =
>
> == Abstract ==
> The Software as a Sensor™ (SensSoft) Project offers an open-source (ALv2.0)
> software tool usability testing platform. It includes a number of
> components that work together to provide a platform for collecting data
> about user interactions with software tools, as well as archiving,
> analyzing and visualizing that data. Additional components allow for
> conducting web-based experiments in order to capture this data within a
> larger experimental framework for formal user testing. These components
> currently support Java Script-based web applications, although the schema
> for “logging” user interactions can support mobile and desktop
> applications, as well. Collectively, the Software as a Sensor Project
> provides an open source platform for assessing how users interacted with
> technology, not just collecting what they interacted with.
>
> == Proposal ==
> The Software as a Sensor™ Project is a next-generation platform for
> analyzing how individuals and groups of people make use of software tools
> to perform tasks or interact with other systems. It is composed of a number
> of integrated components:
>  * User Analytic Logging Engine (User ALE) refers to a simple Application
> Program Interface (API) and backend infrastructure. User ALE provides
> “instrumentation” for software tools, such that each user interaction
> within the application can be logged, and sent as a JSON message to an
> Elasticsearch/Logstash/Kibana (Elastic Stack) backend.
>* The API provides a robust schema that makes user activities human
> readable, and provides an interpretive context for understanding that
> activity’s functional relevance within the application. The schema provides
> highly granular information best suited for advanced analytics. This
> hierarchical schema is as follows:
>  * Element Group: App features that share function (e.g., map group)
>  * Element Sub: Specific App feature (e.g., map tiles)
>  * Element Type: Category of feature (e.g., map)
>  * Element ID: [attribute] id
>  * Activity: Human imposed label (e.g., “search”)
>  * Action: Event class (e.g., zoom, hover, click)
>* The API can either be manually embedded in the app source code, or
> implemented automatically by inserting a script tag in the source code.
>* Users can either setup up their own Elastic stack instance, or use
> Vagrant, a virtualization environment, to deploy a fully configured Elastic
> stack instance to ship and ingest user activity logs and visualize their
> log data with Kibana.
>* RESTful APIs allow other services to access logs directly from
> Elasticsearch.
>* User ALE allows adopters to own the data they collect from users
> outright, and utilize it as they see fit.
>  * Distill is an analytics stack for processing user activity logs
> collected through User ALE. Distill is fully implemented in Python,
> dependent on graph-tool to support graph analytics and other external
> python libraries to query Elasticsearch. The two principle functions of
> Distill are segmentation and graph analytics:
>* Segmentation allows for partitioning of the available data along
> multiple axes. Subsets of log data can be selected via their attributes in
> User ALE (e.g. Element Group or Activity), and by users/sessions.  Distill
> also has the capability to ingest and segment data by additional attributes
> collected through other channels (e.g. survey data, demographics).This
> allows adopters to focus their analysis of log data on precisely the
> attributes of their app (or users) they care most about.
>* Distill’s usage metrics are derived from a probabilistic
> representation of the time series of users’ interactions with the elements
> of the application. A directed network is constructed from the
> representation, and metrics from graph theory (e.g. betweenness centrality,
> in/out-degree of nodes) are derived from the structure. These metrics
> provide adopters ways of understanding how different facets of the app are
> used together, and they capture canonical usage patterns of their
> application. This br

Error For Toree Site Repo svn ci

2016-06-13 Thread Corey Stubbs 
Hi,

I am trying to update the site for Apache Toree, but am unable to push to
svn. When I run *svn ci* I see the following error:

svn: E195023: Commit failed (details follow):
svn: E195023: Changing directory
'/private/tmp/toree-site/site/assets/image' is forbidden by the server
svn: E175013: Access to
'/repos/asf/!svn/txr/1748309-12dl1/incubator/toree/site/assets/image'
forbidden
svn: E195023: Your commit message was left in a temporary file:
svn: E195023:'/private/tmp/toree-site/svn-commit.tmp'


The image folder mentioned in the error is new as of my commit. I am new to
svn so I don't know if I need to update something on the server or not.


Kind Regards,
Corey Stubbs

Re: [VOTE] Accept

2016-06-13 Thread Mark Thomas 
On 13/06/2016 21:22, james pruett wrote:
> please remove me from this list.

Done.

Given this was your second unsubscribe request for an ASF list today, I
checked all our lists for your address and our records show that this
address is not subscribed to any other ASF lists.

Kind regards,

Mark



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

Re: [VOTE] Accept

2016-06-13 Thread james pruett 
please remove me from this list.


On Mon, Jun 13, 2016 at 3:04 PM, Martin Gainty  wrote:

>
>
> > From: lewis.mcgibb...@gmail.com
> > Date: Mon, 13 Jun 2016 10:55:23 -0700
> > Subject: [VOTE] Accept
> > To: general@incubator.apache.org
> > CC: jpo...@draper.com
> >
> > Hi general@,
> > Since I am back from a bit of vacation and it seems the discussion has
> died
> > down, I am now calling a vote on accepting SensSoft into the Apache
> > Incubator.
> >
> > For those who are interested the DISCUSS thread can be found at
> > https://s.apache.org/senssoft_discuss
> >
> > This vote will run for the usual 72 hours.
> >
> > Please VOTE as follows
> >
> > [ ] +1 Accept SensSoft into the Apache Incubator
> > [ ] +/-0 Not overly bothered either way
> > [ ] -1 DO NOT accept SensSoft into the Apache Incubator (please state
> why)
> >
> > Thanks everyone who contributed to DISCUSS and is able to participate in
> > VOTE
> >
> > Best
> > Lewis
> > P.S. Here is my +1
> MG>any library which seeks to validate JS has my vote consider the
> following>> var arr = [ 0, 1, 2, 3 ];
>
> >> arr["something"] = "aught";
> MG>now  lets consider direct access of one of the values lets say the
> value  3 which we know precedes 'something' index
> MG>var index="something"-1;
> MG>console.log(arr[index]);
> MG>EXCEPTION
> MG>My tried and true RhinoScript would produce exception at the line where
> arr[index] is referenced
> MG>which would force me to implement try/catch in JSMG>try{var index =
> "something" -1;console.log(arr[index]);}catch(e){alert('Which
> exception has been thrown ? message: '+e.message);}MG>any JS component
> library which addresses the above situation would be of immediate help to
> test JS functions
> MG>+1 (Non-Binding)
> > #
> >
> > = SensSoft Proposal =
> >
> > == Abstract ==
> > The Software as a Sensor™ (SensSoft) Project offers an open-source
> (ALv2.0)
> > software tool usability testing platform. It includes a number of
> > components that work together to provide a platform for collecting data
> > about user interactions with software tools, as well as archiving,
> > analyzing and visualizing that data. Additional components allow for
> > conducting web-based experiments in order to capture this data within a
> > larger experimental framework for formal user testing. These components
> > currently support Java Script-based web applications, although the schema
> > for “logging” user interactions can support mobile and desktop
> > applications, as well. Collectively, the Software as a Sensor Project
> > provides an open source platform for assessing how users interacted with
> > technology, not just collecting what they interacted with.
> >
> > == Proposal ==
> > The Software as a Sensor™ Project is a next-generation platform for
> > analyzing how individuals and groups of people make use of software tools
> > to perform tasks or interact with other systems. It is composed of a
> number
> > of integrated components:
> >  * User Analytic Logging Engine (User ALE) refers to a simple Application
> > Program Interface (API) and backend infrastructure. User ALE provides
> > “instrumentation” for software tools, such that each user interaction
> > within the application can be logged, and sent as a JSON message to an
> > Elasticsearch/Logstash/Kibana (Elastic Stack) backend.
> >* The API provides a robust schema that makes user activities human
> > readable, and provides an interpretive context for understanding that
> > activity’s functional relevance within the application. The schema
> provides
> > highly granular information best suited for advanced analytics. This
> > hierarchical schema is as follows:
> >  * Element Group: App features that share function (e.g., map group)
> >  * Element Sub: Specific App feature (e.g., map tiles)
> >  * Element Type: Category of feature (e.g., map)
> >  * Element ID: [attribute] id
> >  * Activity: Human imposed label (e.g., “search”)
> >  * Action: Event class (e.g., zoom, hover, click)
> >* The API can either be manually embedded in the app source code, or
> > implemented automatically by inserting a script tag in the source code.
> >* Users can either setup up their own Elastic stack instance, or use
> > Vagrant, a virtualization environment, to deploy a fully configured
> Elastic
> > stack instance to ship and ingest user activity logs and visualize their
> > log data with Kibana.
> >* RESTful APIs allow other services to access logs directly from
> > Elasticsearch.
> >* User ALE allows adopters to own the data they collect from users
> > outright, and utilize it as they see fit.
> >  * Distill is an analytics stack for processing user activity logs
> > collected through User ALE. Distill is fully implemented in Python,
> > dependent on graph-tool to support graph analytics and other external
> > python libraries to query Elasticsearch. The two principle functions of
> > Distill are segmentatio

RE: [VOTE] Accept

2016-06-13 Thread Martin Gainty 


> From: lewis.mcgibb...@gmail.com
> Date: Mon, 13 Jun 2016 10:55:23 -0700
> Subject: [VOTE] Accept
> To: general@incubator.apache.org
> CC: jpo...@draper.com
> 
> Hi general@,
> Since I am back from a bit of vacation and it seems the discussion has died
> down, I am now calling a vote on accepting SensSoft into the Apache
> Incubator.
> 
> For those who are interested the DISCUSS thread can be found at
> https://s.apache.org/senssoft_discuss
> 
> This vote will run for the usual 72 hours.
> 
> Please VOTE as follows
> 
> [ ] +1 Accept SensSoft into the Apache Incubator
> [ ] +/-0 Not overly bothered either way
> [ ] -1 DO NOT accept SensSoft into the Apache Incubator (please state why)
> 
> Thanks everyone who contributed to DISCUSS and is able to participate in
> VOTE
> 
> Best
> Lewis
> P.S. Here is my +1
MG>any library which seeks to validate JS has my vote consider the following>> 
var arr = [ 0, 1, 2, 3 ];

>> arr["something"] = "aught";
MG>now  lets consider direct access of one of the values lets say the value  3 
which we know precedes 'something' index
MG>var index="something"-1;
MG>console.log(arr[index]);
MG>EXCEPTION
MG>My tried and true RhinoScript would produce exception at the line where 
arr[index] is referenced
MG>which would force me to implement try/catch in JSMG>try{var index = 
"something" -1;console.log(arr[index]);}catch(e){alert('Which exception 
has been thrown ? message: '+e.message);}MG>any JS component library which 
addresses the above situation would be of immediate help to test JS functions
MG>+1 (Non-Binding)
> #
> 
> = SensSoft Proposal =
> 
> == Abstract ==
> The Software as a Sensor™ (SensSoft) Project offers an open-source (ALv2.0)
> software tool usability testing platform. It includes a number of
> components that work together to provide a platform for collecting data
> about user interactions with software tools, as well as archiving,
> analyzing and visualizing that data. Additional components allow for
> conducting web-based experiments in order to capture this data within a
> larger experimental framework for formal user testing. These components
> currently support Java Script-based web applications, although the schema
> for “logging” user interactions can support mobile and desktop
> applications, as well. Collectively, the Software as a Sensor Project
> provides an open source platform for assessing how users interacted with
> technology, not just collecting what they interacted with.
> 
> == Proposal ==
> The Software as a Sensor™ Project is a next-generation platform for
> analyzing how individuals and groups of people make use of software tools
> to perform tasks or interact with other systems. It is composed of a number
> of integrated components:
>  * User Analytic Logging Engine (User ALE) refers to a simple Application
> Program Interface (API) and backend infrastructure. User ALE provides
> “instrumentation” for software tools, such that each user interaction
> within the application can be logged, and sent as a JSON message to an
> Elasticsearch/Logstash/Kibana (Elastic Stack) backend.
>* The API provides a robust schema that makes user activities human
> readable, and provides an interpretive context for understanding that
> activity’s functional relevance within the application. The schema provides
> highly granular information best suited for advanced analytics. This
> hierarchical schema is as follows:
>  * Element Group: App features that share function (e.g., map group)
>  * Element Sub: Specific App feature (e.g., map tiles)
>  * Element Type: Category of feature (e.g., map)
>  * Element ID: [attribute] id
>  * Activity: Human imposed label (e.g., “search”)
>  * Action: Event class (e.g., zoom, hover, click)
>* The API can either be manually embedded in the app source code, or
> implemented automatically by inserting a script tag in the source code.
>* Users can either setup up their own Elastic stack instance, or use
> Vagrant, a virtualization environment, to deploy a fully configured Elastic
> stack instance to ship and ingest user activity logs and visualize their
> log data with Kibana.
>* RESTful APIs allow other services to access logs directly from
> Elasticsearch.
>* User ALE allows adopters to own the data they collect from users
> outright, and utilize it as they see fit.
>  * Distill is an analytics stack for processing user activity logs
> collected through User ALE. Distill is fully implemented in Python,
> dependent on graph-tool to support graph analytics and other external
> python libraries to query Elasticsearch. The two principle functions of
> Distill are segmentation and graph analytics:
>* Segmentation allows for partitioning of the available data along
> multiple axes. Subsets of log data can be selected via their attributes in
> User ALE (e.g. Element Group or Activity), and by users/sessions.  Distill
> also has the capability to ingest a

Re: [VOTE] Release Apache Beam, version 0.1.0-incubating

2016-06-13 Thread Jakob Homan 
+1 (binding)

+ sigs look good
+ LICENSE, NOTICE, DISCLAIMER look good
+ licenses in source and xml files look good.
+ tests compile and pass, mvn package compiles

-Jakob

On 13 June 2016 at 12:13, Julian Hyde  wrote:
>
>> On Jun 13, 2016, at 12:08 PM, Marvin Humphrey  wrote:
>>
>> On Mon, Jun 13, 2016 at 11:37 AM, Julian Hyde  wrote:
>>
>>> But I imported
>>> https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS
>>> 
>>> easily enough.
>>
>> Bundling PGP keys inside a package is worse than worthless -- an attacker can
>> just bundle spoofed keys with a bogus distort!
>
> My mistake — thanks for the correction!
>
> Julian
>
>
> -
> 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] Release Apache Beam, version 0.1.0-incubating

2016-06-13 Thread Jean-Baptiste Onofré 

Hi Julian,

good point for the DISCLAIMER, I will do that.

For rat, rat is part of the release execution: the exclusion is for this 
profile. I will add this as part of pluginManagement.


Regards
JB

On 06/13/2016 08:37 PM, Julian Hyde wrote:

+1 (binding)

Checked hashes, license, notice, disclaimer. Built on JDK 1.8, OS X.

Nice work, and good luck.

Remarks:

0. I noticed .github/PULL_REQUEST_TEMPLATE.md … nice!

1. The DISCLAIMER file is sufficient for the purposes of a source release. But for 
the github audience, reaching https://github.com/apache/incubator-beam 
, there is no disclaimer. I think 
there should be a disclaimer on README.md, and at least the first reference to beam 
should read “Apache Beam (incubating)”.

2. It’s customary (required?) for there to be a KEYS file in 
https://dist.apache.org/repos/dist/dev/incubator/beam/ 
. Maybe include it next 
release? But I imported 
https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS 
 easily 
enough.

3. “mvn apache-rat:check” failed due to DEPENDENCIES and 
.github/PULL_REQUEST_TEMPLATE.md. Please add headers or exclusions next time.

Julian



On Jun 12, 2016, at 11:28 PM, Sergio Fernández  wrote:

+1 (binding)

So far I've checked: signatures and digests, source releases file layouts,
matched git tags and commit ids, incubator suffix and disclaimer, NOTICE
and LICENSE files, license headers (two test files from the Project
Gutenberg don't have it) build sources in a clean environment (Maven 3.3.9,
OpenJDK 1.8.0_91 64-Bit, Debian amd64).

The issue with the "Project Gutenberg license" needs to be clarified, as
Justin already pointed it out. Although license looks to affect only test
resources, this may need legal@apache check.

Good work, guys! Happy to sea Bean moving forward.



On Sun, Jun 12, 2016 at 1:54 AM, Davor Bonaci 
wrote:


Hi everyone,
Here's the first vote for the first release of Apache Beam -- version
0.1.0-incubating!

The complete staging area is available for your review, which includes:
* the official Apache source release to be deployed to dist.apache.org
[1],
and
* all artifacts to be deployed to the Maven Central Repository [2].

This corresponds to the tag "v0.1.0-incubating-RC3" in source control, [3].

The Apache Beam community has unanimously approved this release, [4], [5],
[6].

Please vote as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)

As customary, the vote will be open for at least 72 hours. It is adopted by
a majority approval with at least three PMC affirmative votes. If approved,
we will proceed with the release.

Thanks,
Davor

[1]
https://dist.apache.org/repos/dist/dev/incubator/beam/0.1.0-incubating/RC3/
[2] https://repository.apache.org/content/repositories/orgapachebeam-1002/
[3] https://github.com/apache/incubator-beam/tree/v0.1.0-incubating-RC3
[4]

https://lists.apache.org/thread.html/68bf80b386dde080126b51ddf3497c6801015903a705411d435d64a1@%3Cdev.beam.apache.org%3E
[5]

https://lists.apache.org/thread.html/32c991987e0abf2a09cd8afad472cf02e482af02ac35418ee8731940@%3Cdev.beam.apache.org%3E
[6]

https://lists.apache.org/thread.html/e6ffcba94ef4514e8cf5c6fed39100ee359b954c4876d3275b1bc33a@%3Cdev.beam.apache.org%3E





--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co





--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

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

Re: [VOTE] Release Apache Beam, version 0.1.0-incubating

2016-06-13 Thread Jean-Baptiste Onofré 

Hi Marvin,

thanks for the feedback. I will push the KEYS on dist.a.o.

Regards
JB

On 06/13/2016 09:08 PM, Marvin Humphrey wrote:

On Mon, Jun 13, 2016 at 11:37 AM, Julian Hyde  wrote:


2. It’s customary (required?) for there to be a KEYS file in
https://dist.apache.org/repos/dist/dev/incubator/beam/
. Maybe include it
next release?


The KEYS file is required, by Release Distribution Policy.

   http://www.apache.org/dev/release-distribution#sigs-and-sums

   Projects MUST publish a "KEYS" file in their distribution directory which
   contains all public keys used to sign artifacts.

   Signing keys used at Apache MUST be published in the KEYS file and SHOULD be
   made available through the global public keyserver network. [...]

Since the KEYS file is not part of the artifacts being voted on, there's no
reason to wait to resolve this issue by committing the keys file to the
following location:

   https://dist.apache.org/repos/dist/release/incubator/beam/KEYS


But I imported
https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS

easily enough.


Bundling PGP keys inside a package is worse than worthless -- an attacker can
just bundle spoofed keys with a bogus distro!  Keys need to be made available
from a highly reliable, separate server: Download the main package from a
mirror, get PGP keys from apache.org, pgp.mit.edu, etc. and verify.

The KEYS file within the Beam source tree should be deleted.

(This doesn't block the release.)

Marvin Humphrey

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



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

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

Re: [VOTE] Release Apache Beam, version 0.1.0-incubating

2016-06-13 Thread Julian Hyde 

> On Jun 13, 2016, at 12:08 PM, Marvin Humphrey  wrote:
> 
> On Mon, Jun 13, 2016 at 11:37 AM, Julian Hyde  wrote:
> 
>> But I imported
>> https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS
>> 
>> easily enough.
> 
> Bundling PGP keys inside a package is worse than worthless -- an attacker can
> just bundle spoofed keys with a bogus distort!

My mistake — thanks for the correction!

Julian


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

Re: [VOTE] Release Apache Beam, version 0.1.0-incubating

2016-06-13 Thread Marvin Humphrey 
On Mon, Jun 13, 2016 at 11:37 AM, Julian Hyde  wrote:

> 2. It’s customary (required?) for there to be a KEYS file in
> https://dist.apache.org/repos/dist/dev/incubator/beam/
> . Maybe include it
> next release?

The KEYS file is required, by Release Distribution Policy.

  http://www.apache.org/dev/release-distribution#sigs-and-sums

  Projects MUST publish a "KEYS" file in their distribution directory which
  contains all public keys used to sign artifacts.

  Signing keys used at Apache MUST be published in the KEYS file and SHOULD be
  made available through the global public keyserver network. [...]

Since the KEYS file is not part of the artifacts being voted on, there's no
reason to wait to resolve this issue by committing the keys file to the
following location:

  https://dist.apache.org/repos/dist/release/incubator/beam/KEYS

> But I imported
> https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS
> 
> easily enough.

Bundling PGP keys inside a package is worse than worthless -- an attacker can
just bundle spoofed keys with a bogus distro!  Keys need to be made available
from a highly reliable, separate server: Download the main package from a
mirror, get PGP keys from apache.org, pgp.mit.edu, etc. and verify.

The KEYS file within the Beam source tree should be deleted.

(This doesn't block the release.)

Marvin Humphrey

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

Re: [VOTE] Release Apache Beam, version 0.1.0-incubating

2016-06-13 Thread Seetharam Venkatesh 
The signature checks are fine.

+1 (binding)

Good job folks on your first release.

Thanks!
Venkatesh

On Mon, Jun 13, 2016 at 11:39 AM Julian Hyde  wrote:

> +1 (binding)
>
> Checked hashes, license, notice, disclaimer. Built on JDK 1.8, OS X.
>
> Nice work, and good luck.
>
> Remarks:
>
> 0. I noticed .github/PULL_REQUEST_TEMPLATE.md … nice!
>
> 1. The DISCLAIMER file is sufficient for the purposes of a source release.
> But for the github audience, reaching
> https://github.com/apache/incubator-beam <
> https://github.com/apache/incubator-beam>, there is no disclaimer. I
> think there should be a disclaimer on README.md, and at least the first
> reference to beam should read “Apache Beam (incubating)”.
>
> 2. It’s customary (required?) for there to be a KEYS file in
> https://dist.apache.org/repos/dist/dev/incubator/beam/ <
> https://dist.apache.org/repos/dist/dev/incubator/beam/>. Maybe include it
> next release? But I imported
> https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS <
> https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS>
> easily enough.
>
> 3. “mvn apache-rat:check” failed due to DEPENDENCIES and
> .github/PULL_REQUEST_TEMPLATE.md. Please add headers or exclusions next
> time.
>
> Julian
>
>
> > On Jun 12, 2016, at 11:28 PM, Sergio Fernández 
> wrote:
> >
> > +1 (binding)
> >
> > So far I've checked: signatures and digests, source releases file
> layouts,
> > matched git tags and commit ids, incubator suffix and disclaimer, NOTICE
> > and LICENSE files, license headers (two test files from the Project
> > Gutenberg don't have it) build sources in a clean environment (Maven
> 3.3.9,
> > OpenJDK 1.8.0_91 64-Bit, Debian amd64).
> >
> > The issue with the "Project Gutenberg license" needs to be clarified, as
> > Justin already pointed it out. Although license looks to affect only test
> > resources, this may need legal@apache check.
> >
> > Good work, guys! Happy to sea Bean moving forward.
> >
> >
> >
> > On Sun, Jun 12, 2016 at 1:54 AM, Davor Bonaci 
> > wrote:
> >
> >> Hi everyone,
> >> Here's the first vote for the first release of Apache Beam -- version
> >> 0.1.0-incubating!
> >>
> >> The complete staging area is available for your review, which includes:
> >> * the official Apache source release to be deployed to dist.apache.org
> >> [1],
> >> and
> >> * all artifacts to be deployed to the Maven Central Repository [2].
> >>
> >> This corresponds to the tag "v0.1.0-incubating-RC3" in source control,
> [3].
> >>
> >> The Apache Beam community has unanimously approved this release, [4],
> [5],
> >> [6].
> >>
> >> Please vote as follows:
> >> [ ] +1, Approve the release
> >> [ ] -1, Do not approve the release (please provide specific comments)
> >>
> >> As customary, the vote will be open for at least 72 hours. It is
> adopted by
> >> a majority approval with at least three PMC affirmative votes. If
> approved,
> >> we will proceed with the release.
> >>
> >> Thanks,
> >> Davor
> >>
> >> [1]
> >>
> https://dist.apache.org/repos/dist/dev/incubator/beam/0.1.0-incubating/RC3/
> >> [2]
> https://repository.apache.org/content/repositories/orgapachebeam-1002/
> >> [3] https://github.com/apache/incubator-beam/tree/v0.1.0-incubating-RC3
> >> [4]
> >>
> >>
> https://lists.apache.org/thread.html/68bf80b386dde080126b51ddf3497c6801015903a705411d435d64a1@%3Cdev.beam.apache.org%3E
> >> [5]
> >>
> >>
> https://lists.apache.org/thread.html/32c991987e0abf2a09cd8afad472cf02e482af02ac35418ee8731940@%3Cdev.beam.apache.org%3E
> >> [6]
> >>
> >>
> https://lists.apache.org/thread.html/e6ffcba94ef4514e8cf5c6fed39100ee359b954c4876d3275b1bc33a@%3Cdev.beam.apache.org%3E
> >>
> >
> >
> >
> > --
> > Sergio Fernández
> > Partner Technology Manager
> > Redlink GmbH
> > m: +43 6602747925
> > e: sergio.fernan...@redlink.co
> > w: http://redlink.co
>
>

Re: [VOTE] Release Apache Beam, version 0.1.0-incubating

2016-06-13 Thread Julian Hyde 
+1 (binding) 

Checked hashes, license, notice, disclaimer. Built on JDK 1.8, OS X.

Nice work, and good luck.

Remarks:

0. I noticed .github/PULL_REQUEST_TEMPLATE.md … nice!

1. The DISCLAIMER file is sufficient for the purposes of a source release. But 
for the github audience, reaching https://github.com/apache/incubator-beam 
, there is no disclaimer. I think 
there should be a disclaimer on README.md, and at least the first reference to 
beam should read “Apache Beam (incubating)”.

2. It’s customary (required?) for there to be a KEYS file in 
https://dist.apache.org/repos/dist/dev/incubator/beam/ 
. Maybe include it next 
release? But I imported 
https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS 
 
easily enough.

3. “mvn apache-rat:check” failed due to DEPENDENCIES and 
.github/PULL_REQUEST_TEMPLATE.md. Please add headers or exclusions next time.

Julian


> On Jun 12, 2016, at 11:28 PM, Sergio Fernández  wrote:
> 
> +1 (binding)
> 
> So far I've checked: signatures and digests, source releases file layouts,
> matched git tags and commit ids, incubator suffix and disclaimer, NOTICE
> and LICENSE files, license headers (two test files from the Project
> Gutenberg don't have it) build sources in a clean environment (Maven 3.3.9,
> OpenJDK 1.8.0_91 64-Bit, Debian amd64).
> 
> The issue with the "Project Gutenberg license" needs to be clarified, as
> Justin already pointed it out. Although license looks to affect only test
> resources, this may need legal@apache check.
> 
> Good work, guys! Happy to sea Bean moving forward.
> 
> 
> 
> On Sun, Jun 12, 2016 at 1:54 AM, Davor Bonaci 
> wrote:
> 
>> Hi everyone,
>> Here's the first vote for the first release of Apache Beam -- version
>> 0.1.0-incubating!
>> 
>> The complete staging area is available for your review, which includes:
>> * the official Apache source release to be deployed to dist.apache.org
>> [1],
>> and
>> * all artifacts to be deployed to the Maven Central Repository [2].
>> 
>> This corresponds to the tag "v0.1.0-incubating-RC3" in source control, [3].
>> 
>> The Apache Beam community has unanimously approved this release, [4], [5],
>> [6].
>> 
>> Please vote as follows:
>> [ ] +1, Approve the release
>> [ ] -1, Do not approve the release (please provide specific comments)
>> 
>> As customary, the vote will be open for at least 72 hours. It is adopted by
>> a majority approval with at least three PMC affirmative votes. If approved,
>> we will proceed with the release.
>> 
>> Thanks,
>> Davor
>> 
>> [1]
>> https://dist.apache.org/repos/dist/dev/incubator/beam/0.1.0-incubating/RC3/
>> [2] https://repository.apache.org/content/repositories/orgapachebeam-1002/
>> [3] https://github.com/apache/incubator-beam/tree/v0.1.0-incubating-RC3
>> [4]
>> 
>> https://lists.apache.org/thread.html/68bf80b386dde080126b51ddf3497c6801015903a705411d435d64a1@%3Cdev.beam.apache.org%3E
>> [5]
>> 
>> https://lists.apache.org/thread.html/32c991987e0abf2a09cd8afad472cf02e482af02ac35418ee8731940@%3Cdev.beam.apache.org%3E
>> [6]
>> 
>> https://lists.apache.org/thread.html/e6ffcba94ef4514e8cf5c6fed39100ee359b954c4876d3275b1bc33a@%3Cdev.beam.apache.org%3E
>> 
> 
> 
> 
> -- 
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co

[VOTE] Accept

2016-06-13 Thread Lewis John Mcgibbney 
Hi general@,
Since I am back from a bit of vacation and it seems the discussion has died
down, I am now calling a vote on accepting SensSoft into the Apache
Incubator.

For those who are interested the DISCUSS thread can be found at
https://s.apache.org/senssoft_discuss

This vote will run for the usual 72 hours.

Please VOTE as follows

[ ] +1 Accept SensSoft into the Apache Incubator
[ ] +/-0 Not overly bothered either way
[ ] -1 DO NOT accept SensSoft into the Apache Incubator (please state why)

Thanks everyone who contributed to DISCUSS and is able to participate in
VOTE

Best
Lewis
P.S. Here is my +1

#

= SensSoft Proposal =

== Abstract ==
The Software as a Sensor™ (SensSoft) Project offers an open-source (ALv2.0)
software tool usability testing platform. It includes a number of
components that work together to provide a platform for collecting data
about user interactions with software tools, as well as archiving,
analyzing and visualizing that data. Additional components allow for
conducting web-based experiments in order to capture this data within a
larger experimental framework for formal user testing. These components
currently support Java Script-based web applications, although the schema
for “logging” user interactions can support mobile and desktop
applications, as well. Collectively, the Software as a Sensor Project
provides an open source platform for assessing how users interacted with
technology, not just collecting what they interacted with.

== Proposal ==
The Software as a Sensor™ Project is a next-generation platform for
analyzing how individuals and groups of people make use of software tools
to perform tasks or interact with other systems. It is composed of a number
of integrated components:
 * User Analytic Logging Engine (User ALE) refers to a simple Application
Program Interface (API) and backend infrastructure. User ALE provides
“instrumentation” for software tools, such that each user interaction
within the application can be logged, and sent as a JSON message to an
Elasticsearch/Logstash/Kibana (Elastic Stack) backend.
   * The API provides a robust schema that makes user activities human
readable, and provides an interpretive context for understanding that
activity’s functional relevance within the application. The schema provides
highly granular information best suited for advanced analytics. This
hierarchical schema is as follows:
 * Element Group: App features that share function (e.g., map group)
 * Element Sub: Specific App feature (e.g., map tiles)
 * Element Type: Category of feature (e.g., map)
 * Element ID: [attribute] id
 * Activity: Human imposed label (e.g., “search”)
 * Action: Event class (e.g., zoom, hover, click)
   * The API can either be manually embedded in the app source code, or
implemented automatically by inserting a script tag in the source code.
   * Users can either setup up their own Elastic stack instance, or use
Vagrant, a virtualization environment, to deploy a fully configured Elastic
stack instance to ship and ingest user activity logs and visualize their
log data with Kibana.
   * RESTful APIs allow other services to access logs directly from
Elasticsearch.
   * User ALE allows adopters to own the data they collect from users
outright, and utilize it as they see fit.
 * Distill is an analytics stack for processing user activity logs
collected through User ALE. Distill is fully implemented in Python,
dependent on graph-tool to support graph analytics and other external
python libraries to query Elasticsearch. The two principle functions of
Distill are segmentation and graph analytics:
   * Segmentation allows for partitioning of the available data along
multiple axes. Subsets of log data can be selected via their attributes in
User ALE (e.g. Element Group or Activity), and by users/sessions.  Distill
also has the capability to ingest and segment data by additional attributes
collected through other channels (e.g. survey data, demographics).This
allows adopters to focus their analysis of log data on precisely the
attributes of their app (or users) they care most about.
   * Distill’s usage metrics are derived from a probabilistic
representation of the time series of users’ interactions with the elements
of the application. A directed network is constructed from the
representation, and metrics from graph theory (e.g. betweenness centrality,
in/out-degree of nodes) are derived from the structure. These metrics
provide adopters ways of understanding how different facets of the app are
used together, and they capture canonical usage patterns of their
application. This broad analytic framework provides adopters a way to
develop and utilize their own metrics
 * The Test Application Portal (TAP) provides a single, user-friendly
interface to Software as a Sensor™ Project components, including
visualization functionality for Distill Outputs leveraging Django, React,
and D3.js. It has two key functions: