Re: Post mortem request for the handling of the Corinthia podling (was Re: FYI, I have subscribed to this list and to your private list)

[Rob Vesse]

Just wanted to reply to one specific point:

On 15/01/2016 14:55, "Peter Kelly"  wrote:

>I felt were unreasonable - the inability to accept pull requests from
>anyone without first asking them to sign a CLA

Who in particular told you this?  I occasionally see communities operating
under this misguided assumption and it frustrates me and I try and correct
it whenever I see this

The Apache License contains Clause 5 (Submission of Contributions) which
says the following:

"Unless You explicitly state otherwise, any Contribution intentionally
submitted for inclusion in the Work by You to the Licensor shall be under
the terms and conditions of this License, without any additional terms or
conditions. Notwithstanding the above, nothing herein shall supersede or
modify the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions."


So basically anything anyone that intentionally submits something to your
project for inclusion (and it's pretty clear that a pull request is an
intentional submission) then it is fair game for inclusion in an Apache
Licensed project without the need for any separate agreement.

Now for large contributions (where large is arbitrarily defined by the
accepting community) there may be a desire to always get a CLA but it is a
fallacy to say that a ICLA is always required.

As a corollary if someone is making large contributions they should be a
candidate for committer and/or PMC status and if they were to be granted
committer status then the ASF requires they have a ICLA on file

Rob





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

Re: [VOTE] Accept Milagro into the Incubator

[Rob Vesse]

+1 (binding)

Good luck

Rob

On 15/12/2015 08:56, "Nick Kew"  wrote:

>I should like to call a vote to accept Milagro into
>the Incubator.  The full proposal is available at
>https://wiki.apache.org/incubator/MilagroProposal
>as well as below.
>
>Note that the project was first discussed here under
>the name OpenMiracl.  The adoption of the Milagro name
>is a response to that discussion.
>
>[ ] +1 Accept Milagro into the Apache Incubator
>[ ] 0
>[ ] -1 Do not accept Milagro into the Apache Incubator ...
>
>The vote remains open until at least the end of the week.
>
>For myself:
>[*] +1 Accept Milagro into the Apache Incubator
>
>
>= Project Proposal: Milagro =
>== Abstract ==
>Milagro is a distributed cryptosystem for cloud computing. Its purpose
>is to provide an open source alternative to proprietary key management
>and certificate backed cryptosystems used for secure communication and
>authentication. The adoption of Milagro will create a secure, free, open
>source alternative to monolithic certificate authorities and eliminate
>single points of failure.
>
>== Background ==
>The Cloud Computing industry is using 40-year-old cryptographic
>algorithms and infrastructure, invented for a different era when
>client-server computing was the dominant paradigm. At the heart of it,
>is the continued reliance on outdated, and problematic, monolithic
>cryptographic trust hierarchies such as commercial certificate
>authorities.
>
>A number of factors are aligning to make this the right time to bring
>forth an alternative to the Internet's continued reliance on PKI.
>
>The Cloud Infrastructure as a Service (IaaS) industry as a whole
>encounters friction bringing the largest customers in regulated
>industries onto their platforms because issues of cryptographic trust,
>data residency, and data governance prevent total adoption among
>regulated industries.
>
>Devops teams tasked with running an IaaS provider's datacenter
>automation encounter challenges scaling and automating data center
>operations when confronted with the complexities of running encryption,
>certificate and key management infrastructures built for a client-server
>era.
>
>Enterprises in regulated industries find challenges to transform
>entirely into digital businesses because the economics of cloud
>computing are unavailable to them.
>
>Despite the astounding growth of cloud infrastructure as a service
>platforms over the last few years, full adoption by organizations with
>stringent data security requirements won’t be achieved until these
>fundamental capability issues get resolved.
>
>Lastly, the Internet as a whole is suffering from an erosion of trust
>following incidents with commercial certificate authorities industry,
>i.e., compromised root keys, and failures in due diligence issuing real
>domain certificates.
>
>Indeed, mass surveillance, a lack of easy end-user encryption, a growing
>demand for key escrow under legal oversight, and general certificate
>authority security concerns create the question: How appropriate is the
>continued dependency on PKI when the goal is to advance the benefits of
>cloud computing across the technology landscape?
>
>Netcraft is the industry standard for monitoring Active TLS
>certificates. In May 2015, they stated that “Although the global [TLS]
>ecosystem is competitive, it is dominated by a handful of major CAs —
>three certificate authorities (Symantec, Comodo, Godaddy) account for
>three-quarters of all issued [TLS] certificates on public-facing web
>servers.”
>
>The Internet Security Research Group's (ISRG) "Let's Encrypt" initiative
>aims to make Secure Sockets Layer/Transport Layer Security (SSL/TLS)
>certificates available for free in an automated fashion. This a step in
>the right direction, in that it removes the risk of profit before
>ethics. The real issue, which is one entity acts as a monolithic trust
>hierarchy, is not addressed. The monolithic trust hierarchy is a
>fundamental design flaw within PKI itself.
>
>The rate of attacks against certificate authorities seems to be
>[increasing](http://wiki.cacert.org/Risk/History) as the obvious single
>point of compromise design inherent to PKI is becoming a more popular
>route to carry out attacks.
>
>== Proposal ==
>Milagro is an open source, pairing-based cryptographic platform to solve
>key management, secure communications, data governance and compliance
>issues that are challenging Cloud Providers and their customers.
>
>It does this without the need for certificate authorities, putting into
>place a new category of service providers called Distributed Trust
>Authorities (D-TA's).
>
>The M-Pin protocol, and its existing open-source MIRACL implementation
>on which Milagro will build, are already in use by Experian, NTT, Odin,
>Gov.UK and are being rolled out at scale for zero password multi-factor
>authentication and certificate-less HTTPS / secure channel.
>
>It is proposed that Milagro enter incubation at Apache.  At the 

Re: Websites at podling.apache.org

[Rob Vesse]

Niall

Thanks for digging up the reference

I knew INFRA had made the change for a reason but couldn't remember the
reasoning

Rob

On 01/12/2015 16:18, "Niall Pemberton"  wrote:

>On Tue, Dec 1, 2015 at 4:46 AM, Marvin Humphrey 
>wrote:
>
>> Greets,
>>
>> It seems that podling websites are available at both these URL patterns:
>>
>>   http://podling.incubator.apache.org
>>   http://podling.apache.org
>>
>> See for example:
>>
>>   http://systemml.apache.org/
>>   http://systemml.incubator.apache.org/
>>   http://mynewt.apache.org/
>>   http://mynewt.incubator.apache.org/
>>
>> I believe that resolving podling.apache.org is a mistake based on the
>> following pages:
>>
>>   http://incubator.apache.org/guides/sites
>>   http://incubator.apache.org/guides/branding
>>
>>
>See http://markmail.org/message/l4khtbfgq7b72hsw
>
>Niall
>
>
>> Shall we ask Infra to install 302 redirects?
>>
>> Marvin Humphrey
>>
>> -
>> 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: Websites at podling.apache.org

[Rob Vesse]

I seem to remember that INFRA used to do redirects but decided to stop
doing them because it made the transition to TLP easier for podlings post
graduation because their "final" URL was active from as soon as they start
(assuming they don't name change during incubation)

Pretty much any of the current crop of podlings can be resolved via
podling.apache.org AFAICT

e.g.

http://eagle.apache.org

This does look to be at odds with the branding requirements but provided
that the podling is following other requirements e.g. clear use of
Incubating in the name, incubation disclaimer etc I don't see that the
IPMC necessarily needs to continue enforcing the subdomain requirement?

Rob

On 01/12/2015 07:21, "Sergio Fernández" 
wrote:

>They used to have a redirects. But you' re right, looks like not
>anymore...
>So we should ask INFRA to get a 307 resolving the TLP domains.
>
>On Tue, Dec 1, 2015 at 5:46 AM, Marvin Humphrey 
>wrote:
>
>> Greets,
>>
>> It seems that podling websites are available at both these URL patterns:
>>
>>   http://podling.incubator.apache.org
>>   http://podling.apache.org
>>
>> See for example:
>>
>>   http://systemml.apache.org/
>>   http://systemml.incubator.apache.org/
>>   http://mynewt.apache.org/
>>   http://mynewt.incubator.apache.org/
>>
>> I believe that resolving podling.apache.org is a mistake based on the
>> following pages:
>>
>>   http://incubator.apache.org/guides/sites
>>   http://incubator.apache.org/guides/branding
>>
>> Shall we ask Infra to install 302 redirects?
>>
>> Marvin Humphrey
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>
>
>-- 
>Sergio Fernández
>Partner Technology Manager
>Redlink GmbH
>m: +43 6602747925
>e: sergio.fernan...@redlink.co
>w: http://redlink.co





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

Re: [VOTE] Accept Kudu into the Apache Incubator

[Rob Vesse]

+1 (binding)

Rob

On 24/11/2015 19:32, "Todd Lipcon"  wrote:

>Hi all,
>
>Discussion on the [DISCUSS] thread seems to have wound down, so I'd like
>to
>call a VOTE on acceptance of Kudu into the ASF Incubator. The proposal is
>pasted below and also available on the wiki at:
>https://wiki.apache.org/incubator/KuduProposal
>
>The proposal is unchanged since the original version, except for the
>addition of Carl Steinbach as a Mentor.
>
>Please cast your votes:
>
>[] +1, accept Kudu into the Incubator
>[] +/-0, positive/negative non-counted expression of feelings
>[] -1, do not accept Kudu into the incubator (please state reasoning)
>
>Given the US holiday this week, I imagine many folks are traveling or
>otherwise offline. So, let's run the vote for a full week rather than the
>traditional 72 hours. Unless the IPMC objects to the extended voting
>period, the vote will close on Tues, Dec 1st at noon PST.
>
>Thanks
>-Todd
>-
>
>= Kudu Proposal =
>
>== Abstract ==
>
>Kudu is a distributed columnar storage engine built for the Apache Hadoop
>ecosystem.
>
>== Proposal ==
>
>Kudu is an open source storage engine for structured data which supports
>low-latency random access together with efficient analytical access
>patterns. Kudu distributes data using horizontal partitioning and
>replicates each partition using Raft consensus, providing low
>mean-time-to-recovery and low tail latencies. Kudu is designed within the
>context of the Apache Hadoop ecosystem and supports many integrations with
>other data analytics projects both inside and outside of the Apache
>Software Foundation.
>
>
>
>We propose to incubate Kudu as a project of the Apache Software
>Foundation.
>
>== Background ==
>
>In recent years, explosive growth in the amount of data being generated
>and
>captured by enterprises has resulted in the rapid adoption of open source
>technology which is able to store massive data sets at scale and at low
>cost. In particular, the Apache Hadoop ecosystem has become a focal point
>for such “big data” workloads, because many traditional open source
>database systems have lagged in offering a scalable alternative.
>
>
>
>Structured storage in the Hadoop ecosystem has typically been achieved in
>two ways: for static data sets, data is typically stored on Apache HDFS
>using binary data formats such as Apache Avro or Apache Parquet. However,
>neither HDFS nor these formats has any provision for updating individual
>records, or for efficient random access. Mutable data sets are typically
>stored in semi-structured stores such as Apache HBase or Apache Cassandra.
>These systems allow for low-latency record-level reads and writes, but lag
>far behind the static file formats in terms of sequential read throughput
>for applications such as SQL-based analytics or machine learning.
>
>
>
>Kudu is a new storage system designed and implemented from the ground up
>to
>fill this gap between high-throughput sequential-access storage systems
>such as HDFS and low-latency random-access systems such as HBase or
>Cassandra. While these existing systems continue to hold advantages in
>some
>situations, Kudu offers a “happy medium” alternative that can dramatically
>simplify the architecture of many common workloads. In particular, Kudu
>offers a simple API for row-level inserts, updates, and deletes, while
>providing table scans at throughputs similar to Parquet, a commonly-used
>columnar format for static data.
>
>
>
>More information on Kudu can be found at the existing open source project
>website: http://getkudu.io and in particular in the Kudu white-paper PDF:
>http://getkudu.io/kudu.pdf from which the above was excerpted.
>
>== Rationale ==
>
>As described above, Kudu fills an important gap in the open source storage
>ecosystem. After our initial open source project release in September
>2015,
>we have seen a great amount of interest across a diverse set of users and
>companies. We believe that, as a storage system, it is critical to build
>an
>equally diverse set of contributors in the development community. Our
>experiences as committers and PMC members on other Apache projects have
>taught us the value of diverse communities in ensuring both longevity and
>high quality for such foundational systems.
>
>== Initial Goals ==
>
> * Move the existing codebase, website, documentation, and mailing lists
>to
>Apache-hosted infrastructure
> * Work with the infrastructure team to implement and approve our code
>review, build, and testing workflows in the context of the ASF
> * Incremental development and releases per Apache guidelines
>
>== Current Status ==
>
> Releases 
>
>Kudu has undergone one public release, tagged here
>https://github.com/cloudera/kudu/tree/kudu0.5.0-release
>
>This initial release was not performed in the typical ASF fashion -- no
>source tarball was released, but rather only convenience binaries made
>available in Cloudera’s repositories. We will adopt 

Re: [VOTE] Accept S2Graph into Apache Incubation

[Rob Vesse]

+1 (binding)

Good luck

Rob

On 24/11/2015 00:53, "Hyunsik Choi"  wrote:

>Hello folks,
>
>Thanks for all the feedback on the S2Graph Proposal.
>
>I would like to call for a [VOTE] on S2Graph joining the ASF as an
>incubation project.
>
>The vote is open for at least 72 hours:
>
>[ ] +1 accept S2Graph in the Incubator
>[ ] ±0
>[ ] -1 (please give reason)
>
>S2Graph provides a scalable distributed graph database engine over a
>key/value store such as HBase. S2Graph provides a fully asynchronous
>API to manipulate data as a property graph model and fast
>breadth-first-search queries over the graph. S2Graph is designed for
>OLTP-like workloads on graph data sets instead of batch processing,
>and it also provides INSERT/UPDATE operations on them.
>
>The proposal is available on the wiki here:
>https://wiki.apache.org/incubator/S2GraphProposal
>
>Best regards,
>Hyunsik
>
>
>
>--
>--
>= S2Graph Proposal =
>
>== Abstract ==
>S2Graph is a distributed and scalable OLTP graph database built on
>Apache HBase to support fast traversal of extremely large graphs.
>
>== Proposal ==
>S2Graph provides a scalable distributed graph database engine over a
>key/value store such as HBase. S2Graph provides a fully asynchronous
>API to manipulate data as a property graph model and fast
>breadth-first-search queries over the graph. S2Graph is designed for
>OLTP-like workloads on graph data sets instead of batch processing.
>Also, S2Graph provides INSERT/UPDATE operations. Its name 'S2Graph' is
>an abbreviated word of '''S'''uper '''S'''imple '''Graph''' Database.
>
>Here are additional materials to introduce S2Graph.
> * HBaseCon 2015 - http://www.slideshare.net/HBaseCon/use-cases-session-5
> * Apache: Big Data 2015 -
>http://schd.ws/hosted_files/apachebigdata2015/06/s2graph_apache_con.pdf
>
>== Background ==
>S2Graph initially started as an internal project at Kakao.com to
>efficiently store user relations and user activities as one large
>graph and to provide a unified query interface to traverse the graph.
>It was open sourced on Github about a 3 months ago in June 2015.
>
>Over time, S2Graph using HBase as the storage tier has begun by
>adapted into various applications, such as messaging, social feeds,
>and realtime recommendations at Kakao.
>
>Users can benefit by using S2Graph`s generalized high level graph
>abstraction API instead of querying via low-level key/value APIs, just
>as Apache Phoenix provides a SQL layer over HBase.
>
>== Rationale ==
>Graph data (highly interconnected data) is very abundant and important
>these days. When users have a multitude of relationships, each with
>complex properties associated with them, a graph model is more
>intuitive and efficient than tabular formats (RDBMS).
>
>There are many ASF projects that provide SQL tiers, but there is no
>ASF projects that provide a scalable graph layer on top of the
>existing hadoop ecosystem. When graph data grows to the trillion edge
>scale, the process of traversing takes a long time and can be costly.
>However, with the benefit of HBase`s scalable architecture, S2Graph
>can traverse large graphs in a breadth-first-search manner
>efficiently.
>
>S2Graph also interoperates with several existing Apache projects
>(HBase, Apache Spark) to provide means of merging real time events and
>batch processed data using the property graph data model.
>
>Many developers run their own domain specific API servers to serve
>their data products, but a graph model is general and the S2Graph API
>fully supports traversal of the graph, so it can be used as a scalable
>general purpose API serving layer for various domains. As long as data
>can be modeled as graph, then users can avoid tedious work developing
>customized API servers if they use S2Graph.
>
>== Initial Goals ==
>The initial goals will be to move the existing codebase to Apache and
>integrate with the Apache development process. Once this is
>accomplished, we plan for incremental development and releases that
>follow the Apache guidelines.
>
>== Current Status ==
>
>=== Meritocracy ===
>S2Graph operated on meritocratic principles from the get go.
>Currently, all the discussions pertaining to S2Graph development are
>public on Github. The current incubation proposal includes the major
>code contributors to S2Graph. Several additional people have worked on
>the S2graph codebase for industry use cases and would be interested in
>becoming committers. We are starting with a small committer group and
>we plan to add additional committers following an open merit-based
>decision process during the incubation phase.
>
>=== Community ===
>We have already begun building a community but at this time the
>community consists only of S2Graph developers – all Kakao employees –
>and prospective users. S2Graph seeks to develop developer and user
>communities during incubation.
>
>=== Core Developers ===
>S2Graph is 

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

[Rob Vesse]

On 17/11/2015 08:20, "Greg Stein"  wrote:

>On Tue, Nov 17, 2015 at 1:53 AM, 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".
>>
>
>People should be trusted to ask for help/review when necessary. CTR trusts
>people to commit changes they feel are right, but it also trusts them to
>stop and ask for a preliminary review when they feel/know they're deep
>into
>the tricky code.
>
>RTC never trusts people with the easy changes. It believes all changes are
>equal, assumes all changes are beyond the abilities of individuals, and
>all
>committers are incapable of self-reflection. That each and every change
>must be scrutinized by others for approval.
>
>Ted's phrase "I trust you to help me make things better" is not unique to
>RTC. Both CTR and RTC have that "R" in them for review, to ensure the code
>can always be improved.
>
>If I join a CTR community, then I know that I can go around improving
>comments, docstrings, and minor code cleanups. That is a solid
>contribution
>that every project would love to have. If I join an RTC community, I'm not
>trusted to do any of that. There is no other explanation. None of that has
>to do with "complexity". It is simply control and exclusion of my
>desire/interest to contribute. To keep the mantle of development within a
>select set of people who decided to exert this tactic over their codebase.
>
>-g

We're veering dangerously off into religious debate territory here but I
think this is a great explanation of the fundamentals of CTR which is
personally my preferred model

The other aspect of trust in the CTR model that we haven't really
mentioned is that in a CTR community you also trust that when you do
commit stuff without prior review that others will review it after the
fact.  On CTR projects I'm involved in myself and others do read through
the commits list traffic and can and do flag things for further discussion
and review when we feel they need it.  So there is a more equal trust
relationship, you trust me to commit things without prior review and I
trust you to review them afterwards as needed.  Additionally you trust me
to know when to ask for a prior review.  In RTC it seems like an unequal
trust relationship, I have to trust you to review my code because you
don't trust me to commit it myself.

Of course the counterpoint to this argument is that in a RTC community you
typically grant commit privileges much sooner and trust people to get
reviews whereas in a CTR community you often make new people work via RTC
for a while before you trust them enough to grant them commit privileges.

It feels like part of the problem is that RTC vs CTR very much blurs the
line between a community and a technical decision.  Supporters of CTR like
myself tend to feel that CTR is ultimately about community I.e. that
assuming trust helps build a healthier community.  On the other hand the
arguments for RTC often seem to come from the standpoint of it being a
technical decision e.g. the complexity and committer fallibility arguments
already expressed in this thread and seem IMO to boil down to the idea
that RTC builds better code.

The Apache way is often defined as "community over code" hence when I tend
to default to CTR however I don't see RTC as being harmful to community I
just feel like it produces a different kind of community.  The ASF is a
big umbrella and whichever side of the debate a community comes down on
there is room for them at the ASF.

Probably the key takeaway from this thread should be that we should trust
podlings (and TLPs) to have the RTC vs CTR debate within their own
communities and allow them to decide what works best for them as a
community without an outside body like the Incubator mandating one or the
other.  Clearly during the Incubation phase mentors and interested parties
can and will participate in that debate and outline the various arguments
as we've been doing here but the ultimate decision should lie with those
in the community.

Rob





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

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

[Rob Vesse]

On 17/11/2015 16:50, "Steve Loughran"  wrote:

>If someone were to have some metrics of projects, the state of
>patches/pull requests would be a key issue.

https://github.com/rvesse/gh-pr-stats

Given a GitHub project generates statistics about the state of the Pull
Requests in the project e.g.

./pr-stats apache hadoop

Fairly basic tool but should give you enough to gauge where things are

Rob





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

Re: IP clearance for properly licensed code

[Rob Vesse]

You are quite right

Apache projects can incorporate code under suitable licenses provided that
they properly attribute it in their NOTICE and LICENSE files.  Exact
requirements will depend on the license under which the external source
code is incorporated.

For a simple case like this it would most likely just require placing some
text like the following into the LICENSE file:

---
The following code/components are under a Foo License

[Foo License text]
---

Essentially all copyright owners of the code original to the incoming
project need to provide CLAs and/or SGAs as appropriate and any external
code incorporated into the code base needs to be under Apache compatible
licenses and appropriately attributed

Rob

On 09/11/2015 18:11, "Todd Lipcon"  wrote:

>Hi all,
>
>Another hopefully simple question:
>
>The Mentor guide contains the following text:
>
>>
>> Existing codebases need to be imported through the standard IP clearance
>> process. This means that a Software Grant Agreement (SGA
>> ) or Contributor License
>> Agreement (CLA ) need to be
>> submitted for all copyright owners. This process may take a while so it
>>is
>> best to start as soon as the podling is accepted.
>
>
>How does this rule apply to sections of code that are released publicly
>under a suitable license (eg Apache/BSD/MIT) but were originally written
>from a different context? For example, I am working on an incubation
>proposal for a project that includes portions of code copied from the
>Chromium open source project, which is released under a BSD license but
>holds a copyright notice by "The Chromium Authors". It's unlikely that
>these authors would submit the appropriate paperwork to the ASF.
>
>Assuming that the imported project retains the notice of the original
>copyright, and the commits which import the code suitably track the
>provenance of the code, my understanding is this is acceptable under the
>licenses and foundation policy. However, the text in the mentor guide
>seems
>to indicate otherwise.
>
>Thanks
>Todd





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

Re: CommonsRDF petering out

[Rob Vesse]

On 03/11/2015 01:08, "Ted Dunning"  wrote:

>Looking at the email archives just now, it looks to me like commons RDF is
>finding it difficult to build a community and maintain any serious
>momentum.  Seeing only a few emails or commits for months on end raises
>red
>flags to me.  A project that peters out at Apache is likely to have
>petered
>out anyway, however, so I don't see much for the original folks to worry
>about.

Yep that's my interpretation of the project at the moment as well

Have a draft email to the community sitting in my Drafts folder on this
very note which I really should get around to sending

Thanks for reminding me,

Rob





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

[Rob Vesse]

Various comments inline:

On 15/09/2015 03:41, "Marko Rodriguez"  wrote:

>Hi,
>
>> Thanks for making a clear statement because it lets me focus on the
>> question that may be central to this discussion: can you tell us why
>> did you guys decided to join ASF in the first place? This is not a
>>baited
>> question: I'm genuinely curious about what kind of expectations did
>> you have when joining and what did you want to achieve?
>> 
>> Because, you see, a project that's part of the foundation can't simply
>> be just 'using' the foundation, it actually has to become part of the
>> foundation, in my mind.
>
>For me personally, I wanted TinkerPop to be apart of Apache because no
>one has won a lawsuit against Apache and I wanted that protecting me and
>my code as an open source software developer.
>---

Well AFAIK no-one has actually gone so far as to prosecute a lawsuit
against Apache so this may have been a poor motivator

I'll assume that what you actually meant that you wanted the legal
protection of the foundation (or more specifically if memory serves some
of your larger corporate users wanted this and pointed you towards the ASF)

>
>
>>> I don't expect the users of TinkerPop to have to write my code, they
>>>are
>>> there to use it.
>> 
>> Well, that a bit black-n-white. Certainly folks who don't want to write
>> TinkerPop code can't be forcefully compelled to do so. Yet, somehow,
>> the way you phrased it makes me suspect that you see it as a firewall
>> between the two communities of users vs. developers. Am I reading
>> this wrong?
>
>99.% of people using TinkerPop are not submitting bug reports,
>pull requests, ideas, community "votes" on directions, @Deprecation
>decisions, etc. I do not have any fantasies that these people should
>participate in a bi-directional engagement with TinkerPop. Why should
>they, they are using the software to solve their particular problems and
>could care less about the "TinkerPop community" as long as those releases
>(bug fixes/optimizations/features) keep coming.

The community is not defined purely as those who actively participate in
what you might call development activities.  It is also the people who ask
questions on your user list, StackOverflow etc, the people who build other
projects on top of your project and create an ecosystem, evangelists who
talk about Tinkerpop or the cool stuff they've done with it at meet-ups,
conferences etc.  Many of these people will never write a drop of code for
Tinkerpop itself but it doesn't stop them being part of your community.
Whether they care about the wider community is also irrelevant, if they
participate in the ecosystem they are part of your community which the
Tinkerpop PMC exists to promote and serve.

IMO If you are defining community as only developers then you've kinda
missed the point of community

>---
>
>
>> 
>>> If I'm not delivering software in a timely manner,
>> 
>> *you* (as in Marko Rodriguez) are not delivering software. Your entire
>> development community does. It is a subtle but important distinction
>> that goes to heart of the Apache Governance model: we don't allow
>> BDFLs. Anyone who's part of your community can propose a release
>> at any time.
>
>No, I deliver software. Likewise, other committers on TinkerPop are
>delivering software. Every piece of code written TinkerPop is not an
>exercise in pair programming. Its "I'm going to knock X, Y, Z out… give
>me 24 hours before touching that module on master/." To which people
>typically reply: "Sweet. Good luck and thanks for taking the reigns on
>that one." So, I go about delivering -- and I do it on time, documented,
>and tested. Why, cause I wear the TinkerPop hat and if I'm say I'm
>TinkerPop, guess what --- you are going to witness me Tinker that Pop.
>There is no "Marko, you said would work on that…can you please get it
>done? Please… Comon… At least respond to my emails."  And I don't use the
>"I volunteer" excuse as a way of getting out of having to do things I
>implicitly promise to do. If I wear that hat, I do the job the hat
>entails. And guess what, I'm not "busy" either.

Implying that other people are not busy is not helpful and is simply
insulting other volunteers time.  You are fortunate enough to get paid by
your employer to work pretty much full time on Tinkerpop judging by your
activity on the project.  Most people here (including myself) have day
jobs where contributing to Apache projects is only a tiny part of their
paid time (if they get any at all)

If all you are doing is writing code then you aren't building a
sustainable community, believe me I've spent years delivering code only to
result in completely non-viable communities.  There is a reason that the
Apache matra is "community over code".  In projects I participate in most
of the PMC don't actively write code and spend far more time guiding the
community and 

Re: [VOTE] Accept Rya into the Apache Incubator

[Rob Vesse]

+1

On 14/09/2015 16:17, "Adam Fuchs"  wrote:

>Thanks again for the healthy discussion on Rya. With that, I would like to
>call a VOTE for accepting Rya as a new incubator project.
>
>The proposal text is included below, and is posted on the wiki here:
>https://wiki.apache.org/incubator/RyaProposal
>
>The discussion thread on Rya starts here:
>http://mail-archives.apache.org/mod_mbox/incubator-general/201509.mbox/%3C
>CALt5_xJKtRcUr3WGjfrY77DYWF0-8DWi%3DzyS7hrMFTg%2BYAORjQ%40mail.gmail.com%3
>E
>
>The vote will be open until Thu Sep 17 15:15:00 UTC 2015.
>
>[ ] +1 accept Rya in the Incubator
>[ ] ±0
>[ ] -1 because...
>
>Thanks,
>Adam
>
>
>= Rya Proposal =
>== Abstract ==
>Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
>supports SPARQL queries.
>
>== Proposal ==
>Rya is a scalable RDF data management system built on top of Accumulo. Rya
>uses novel storage methods, indexing schemes, and query processing
>techniques that scale to billions of triples across multiple nodes. Rya
>provides fast and easy access to the data through SPARQL, a conventional
>query mechanism for RDF data.
>
>== Background ==
>RDF is a World Wide Web Consortium (W3C) standard used in describing
>resources on the Web. The smallest data unit is a triple consisting of
>subject, predicate, and object. Using this framework, it is very easy to
>describe any resource, not just Web related. For example, if you want to
>say that Alice is a professor, you can represent this as an RDF triple
>like
>(Alice, rdf:type, Professor). In general, RDF is an open world framework
>that allows anyone to make any statement about any resource, which makes
>it
> a popular choice for expressing a large variety of data.
>
>RDF is used in conjunction with the Web Ontology Language (OWL). OWL is a
>framework for describing models or ontologies for RDF. It defines
>concepts,
>relationships, and/or structure of RDF documents. These models can be used
>to 'reason/infer' information about entities within a given domain. For
>example, you can express that a Professor is a sub class of Faculty,
>(Professor, rdfs:subClassOf, Faculty) and knowing that (Alice, rdf:type,
>Professor), it can be inferred that (Alice, rdf:type, Faculty).
>
>SPARQL is an RDF query language. Similar with SQL, SPARQL has SELECT and
>WHERE clauses; however, it is based on querying and retrieving RDF
>triples.
>
>Work on Rya, a large scale distributed system for  storing and querying
>RDF
>data, started in 2010.
>
>== Rationale ==
>With the increase in data size, there is a need for scalable systems for
>storing and retrieving RDF data in a cluster of nodes. We believe that Rya
>can fulfill that role. We expect that communities within government,
>health
>care, finance, and others who generate large amounts of RDF data will be
>most interested in this project.
>
>From its inception, the project operated with an Apache-style license, but
>it was open to mostly US government-related projects only. We believe that
>having the project and the development open for all will benefit both the
>project and the interested communities.
>
>== Current Status ==
>The project source code and documentation are currently hosted in a
>private
>repository on Github. New users are added to the repository upon request.
>
>=== Meritocracy ===
>Meritocracy is the model that we currently follow, and we want to build a
>larger and more diverse developer community by becoming an Apache project.
>
>=== Community ===
>Rya has being building a community of users and developers for the past 3
>years. There is currently an active workgroup with monthly meetings and
>the
>number of participants in the meeting is increasing.
>
>=== Core Developers ===
>The core developers are a diverse group of people who are either
>government
>employees or former / current government contractors from different
>companies.
>
>=== Alignment ===
>Rya is built on top of Accumulo, an Apache project.
>
>== Known Risks ==
>=== Orphaned Products ===
>There is a very small risk of becoming orphaned. The current contributors
>are strongly committed to the project, there is a large enough number of
>developers interested in contributing to the project, and we believe that
>the support for the project will continue to grow from the interested
>communities.
>
>=== Inexperience with Open Source ===
>The initial committers have various degrees of experience with open source
>projects - from very new to experienced. This project was open source
>within government from the beginning. We are aware that it will be
>different and more difficult functioning in a real open source
>environment.
>We are enthusiastic and committed to learning the Apache way and being
>successful in operating under Apache's development process.
>
>=== Homogenous Developers ===
>The current list of developers form a heterogeneous group, with people for
>academia, government, and industry, collaborating from distributed
>geographic locations. 

Re: [DISCUSS] Rya Incubator Proposal

[Rob Vesse]

Interesting proposal

As someone already involved with other open source RDF projects both
inside and outside Apache it would be nice to add to the Relationships
with Other Apache Products a bit about what (if anything) you expect the
relationship to other RDF related Apache projects (Jena, Clerezza,
Stanbol, Marmotta, Commons RDF (incubating)) to be?

Apache is about community over code and so never mandates any particular
technical choices (that is always up to the individual communities) but it
would be useful to understand if you see any overlap with existing
projects or any collaboration oppurtunities.  The latter are particular
interesting because one way you can help grow a new community is by
attracting interested users in pre-existing communities who want to work
on the specific problems you are aiming to tackle where their existing
options don't address the problems while your approach does.

It would also be nice to see some discussion in that section about things
like versioning of your major dependencies.  In particular you build on
Accumulo so do you require specific version(s) thereof (since they appear
to maintain 3 release lines currently) or simply require a version with a
specific subset of Accumulo functionality?  How (if at all) does this
translate into risks in terms of adoption, community traction etc e.g.
what happens if you rely on version X and the Accumulo community abandons
that in favour of version Y or if you rely on a specific experimental
feature that never makes it into Accumulo releases?

Also it would be nice if the external dependencies section properly linked
to relevant web pages as right now it has several dead links and in some
cases outdated naming.  For example by Open RDF I assume you mean OpenRDF
Sesame which now lives at rdf4j.org (though I'll admit to not
understanding what I'm supposed to call it anymore either!)

Similarly the documentation section mentions papers but doesn't provide
links, while both can be found online easily enough it would be nice to
add the links in

Regards,

Rob

On 03/09/2015 14:03, "Adina Crainiceanu"  wrote:

>Hi,
>
>We would like to start a discussion on accepting Rya, a scalable RDF data
>management system built on top of Accumulo. into Apache Incubator.
>
>The proposal is available online at
>https://wiki.apache.org/incubator/RyaProposal and also at the end of this
>email.
>
>We are looking for additional mentors to help us with the project. Any
>advice and help will be appreciated.
>
>Thank you very much,
>Adina
>
>
>
>= Rya Proposal =
>
>== Abstract ==
>
>Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
>supports SPARQL queries.
>
>== Proposal ==
>
>Rya is a scalable RDF data management system built on top of Accumulo. Rya
>uses novel storage methods, indexing schemes, and query processing
>techniques that scale to billions of triples across multiple nodes. Rya
>provides fast and easy access to the data through SPARQL, a conventional
>query mechanism for RDF data.
>
>== Background ==
>
>RDF is a World Wide Web Consortium (W3C) standard used in describing
>resources on the Web. The smallest data unit is a triple consisting of
>subject, predicate, and object. Using this framework, it is very easy to
>describe any resource, not just Web related. For example, if you want to
>say that Alice is a professor, you can represent this as an RDF triple
>like
>(Alice, rdf:type, Professor). In general, RDF is an open world framework
>that allows anyone to make any statement about any resource, which makes
>it
> a popular choice for expressing a large variety of data.
>
>RDF is used in conjunction with the Web Ontology Language (OWL). OWL is a
>framework for describing models or ontologies for RDF. It defines
>concepts,
>relationships, and/or structure of RDF documents. These models can be used
>to 'reason/infer' information about entities within a given domain. For
>example, you can express that a Professor is a sub class of Faculty,
>(Professor, rdfs:subClassOf, Faculty) and knowing that (Alice, rdf:type,
>Professor), it can be inferred that (Alice, rdf:type, Faculty).
>
>SPARQL is an RDF query language. Similar with SQL, SPARQL has SELECT and
>WHERE clauses; however, it is based on querying and retrieving RDF
>triples.
>
>Work on Rya, a large scale distributed system for  storing and querying
>RDF
>data, started in 2010.
>
>== Rationale ==
>
>With the increase in data size, there is a need for scalable systems for
>storing and retrieving RDF data in a cluster of nodes. We believe that Rya
>can fulfil that role. We expect that communities within government, health
>care, finance, and others who generate large amounts of RDF data will be
>most interested in this project.
>
>From its inception, the project operated with an Apache-style license, but
>it was open to mostly US government-related projects only. We believe that
>having the project and the development open for all will benefit both the

Re: [DISCUSS] Apex Incubation Proposal

[Rob Vesse]

Not really an issue

JIRA allows a lot of flexibility in the configuration of Versions (I.e.
the version strings are free text) so you could easily have Apex x.y.z
and Malhar x.y.z as separate versions under a single JIRA key.  It just
needs the community managing the JIRA to be careful about ensuring issues
are tagged with the correct Affects and Fix Versions as necessary

We've used this workflow for years in the Jena project and not had an
issue with it.

Of course the community may prefer to have separate JIRA keys as appears
to be the case here in which case I see no reason not to allow them that
and there are other precedents for that (e.g. Apache Commons)

Rob

On 11/08/2015 18:03, Chris Nauroth cnaur...@hortonworks.com wrote:

One thing to consider is that release version numbers are tied to specific
JIRA projects.  If the intention is for Apex and Malhar version numbers to
be independent, then using a single JIRA project could introduce some risk
of confusion if an Apex version number accidentally gets applied to a
Malhar issue.  It might necessitate prefixing the version numbers with
apex- and malhar- to differentiate.

Based on that, I have a slight preference for separate JIRA projects.
However, I don't object to using a single unified JIRA project if others
feel strongly about it.

--Chris Nauroth




On 8/11/15, 8:23 AM, Amol Kekre a...@datatorrent.com wrote:

Ted,
I agree that repo is more critical than jira instance. I am taking up
your
suggesstion with folks and should get back soon.

Thks
Amol

On Tue, Aug 11, 2015 at 3:48 AM, Ted Dunning ted.dunn...@gmail.com
wrote:


 I personally see far less reason for separate JIRA instances than git
 repos. Having all jiras under APEX seems a good choice.

 Sent from my iPhone

  On Aug 11, 2015, at 2:32, Bertrand Delacretaz
bdelacre...@apache.org
 wrote:
 
  As for JIRA, I would apply the same rule, so APX-CORE and APX-MHAR
maybe.

 -
 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: [VOTE] Graduate Ignite from the Incubator

[Rob Vesse]

+1 (binding)

Rob

On 28/07/2015 21:03, Konstantin Boudnik c...@apache.org wrote:

Following discussions [1],[2] about its current status, the Ignite
community
has voted [3] to graduate from the Incubator. The vote passed [4] with 14
(non-binding) +1s:

   1.  Yakov Zhdanov (PPMC)
   2.  Gianfranco Murador (PPMC)
   3.  Ira Vasilinets (PPMC)
   4.  Nikolai Tichinov (PPMC)
   5.  Semyon Boikov (PPMC)
   6.  Sergi Vladykin (PPMC)
   7.  Alexey Goncharuk (PPMC)
   8.  Ognen Duzlevski (PPMC)
   9.  Valentin Kulichenko (PPMC)
   10. Nikita Ivanov (PPMC)
   11. Dmitriy Setrakyan (PPMC)
   12. Andrey Novikov (Committer)
   13. Alexey Kuznetsov (Committer)
   14. Milap Wadwa

The Ignite community has:
* completed all required paperwork:
https://incubator.apache.org/projects/ignite.html
* completed multiple releases (1.0, 1.1, 1.2, 1.3)
* completed the name check procedure:
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-58
* opened and worked on 1,150+ JIRAs:

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=
hidejqlQuery=project+%3D+IGNITE
* voted in multiple new committers/PPMC members

Therefore, I'm calling a VOTE to graduate Ignite with the following Board
resolution. The VOTE will run 72 hours, ending Friday July 31st 2 PM PST.

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

Regards,
Cos

[1] http://markmail.org/message/5fvca3vr6tkk5q4h
[2] http://markmail.org/message/uotzsecmwbiuhgjy
[3] http://markmail.org/message/fzslacsyxlvm3mwm
[4] http://markmail.org/message/i2mxhgfchlwi34ko

 Apache Ignite graduation resolution draft

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 delivering an In-Memory Data Fabric - a high-performance,
integrated
and distributed in-memory platform for computing and transacting on
large-scale data sets in real-time

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

RESOLVED, that the Apache Ignite Project be and hereby is responsible
for
the creation and maintenance of software related to the automated and
managed flow of information between systems and be it further

RESOLVED, that the office of Vice President, Apache Ignite 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 Ignite Project, and
to
have primary responsibility for management of the projects within the
scope of responsibility of the Apache Ignite 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 Ignite
Project:

Semyon Boikov (sboi...@apache.org)
Konstantin Boudnik (c...@apache.org)
Branko Čibej (br...@apache.org)
Ognen Duzlevski (mak...@apache.org)
Sergey Evdokimov (sevdoki...@apache.org)
Alexey Goncharuk (agoncha...@apache.org)
Nikita Ivanov (nivano...@apache.org)
Sergey Khisamov (s...@apache.org)
Valentin Kulichenko (vkuliche...@apache.org)
Alexey Kuznetsov (akuznet...@apache.org)
Gianfranco Murador (mura...@apache.org)
Andrey Novikov (anovi...@apache.org)
Vladimir Ozerov (voze...@apache.org)
Dmitriy Setrakyan (dsetrak...@apache.org)
Roman Shaposhnik (r...@apache.org)
Ilya Sterin (iste...@apache.org)
Nikolai Tikhonov (ntikho...@apache.org)
Irina Vasilinets (ivasilin...@apache.org)
Anton Vinogradov (a...@apache.org)
Sergey Vladykin (svlady...@apache.org)
Evans Ye (evan...@apache.org)
Yakov Zhdanov (yzhda...@apache.org)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Dmitriy Setrakyan be
appointed to the office of Vice President, Apache Ignite, 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 Ignite Project be and hereby is tasked with
the
migration and rationalization of the Apache Incubator Ignite podling;
and
be it further

RESOLVED, that all responsibilities pertaining to the Apache Incubator
Ignite 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] Release Apache Brooklyn 0.7.0-incubating [rc1]

[Rob Vesse]

No such requirement actually exists

Jena graduated in April 2012 and because of our backwards compatibility
requirements the package names for existing code have until very recently
remained the same (though new code developed at Apache has used
org.apache.jena where possible)

Now we are finally making a new major release and don't need to provide
backwards compatibility we are finally updating package names to be
org.apache.jena based

Rob

On 22/07/2015 15:21, Cédric Champeau cedric.champ...@gmail.com wrote:

 * renaming of packages from brooklyn.* to org.apache.brooklyn.* will be
 required for graduation, I strongly encourage that step to be taken
care of
 in the next release.

Where is such a requirement described? As far as I understand, package
names are best suited if they start with org.apache.*, but it's not a
strong requirement. If it is, then it would basically mean that Groovy
(the podling I am member of) would never go out of incubation, because
of our binary backwards compatibility requirements.

-
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] Communicating intent around non-release, downstream integration binary artifacts

[Rob Vesse]

On 24/06/2015 18:02, Markus Weimer mar...@weimo.de wrote:

 Personally I think the policy should be clarified such that nightly
builds
 MUST only live on ASF infrastructure (whether that be the Nexus
SNAPSHOTs
 repo, committer web space etc).  As soon as you start putting them on
 external services like DockerHub then they are potentially widely
visible
 to the general public.

This is very tricky for projects outside the Java ecosystem. For .NET,
NuGet is the established way to get packages, and the ASF doesn't
provide a NuGet repository in the same way it does provide Maven
repositories.

Sontatype Nexus Professional 2 onwards (which the ASF runs) supports NuGet
repositories so if ASF projects wanted to use that capability to
distribute pre-release builds then they should start a discussion with
infrastructure

http://books.sonatype.com/nexus-book/reference/nuget.html


NuGet is just one example, each of the major language ecosystems now
offers at least one (binary) artifact and dependency management
approach. Following through on the above would mean either an incredible
workload for the ASF to support it all, the exclusion of whole languages
from ASF projects or treating some as second class citizens because
their nightly builds wouldn't be testable. Neither of those strike me as
great results.

Good points, ultimately I think I did not express what I meant precisely
enough

Nightly builds generated by a project e.g. by a projects nightly build job
on Jenkins MUST live on ASF Infrastructure

If there is sufficient mass of projects needing a specific kind of
repository service available that isn't currently then there is nothing
stopping those projects from starting the appropriate discussions with
Infra as to whether such a service could be provided

OTOH individuals are free to do whatever they want without their ASF hats
on and publish their own personal nightly builds wherever and however they
want provided that they appropriately distinguish them from ASF actions
and releases.  However if individuals start publishing stuff to popular
public central repository services then clearly there is a danger of
confusion as to the source of the package(s).

Rob


Markus

-
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] Communicating intent around non-release, downstream integration binary artifacts

[Rob Vesse]

On 24/06/2015 04:12, Justin Erenkrantz justin.erenkra...@gmail.com on
behalf of jus...@erenkrantz.com wrote:

On Tue, Jun 23, 2015 at 10:48 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:
 On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:
 There is nothing preventing clearly identifiable non-release artifacts
 available to the general public. Many projects make automated nightly
builds available for example.

 This! Honestly this has always been my personal interpretation of the
policy
 (although now that I'm re-reading it I see how it could be interpreted
in a
 radically different way).

 IOW, I've been mentoring a lot of poddlings and advising them that as
 long as they go out of their way to label 'nightly' artifacts as NON
RELEASE,
 DON'T TRY IT AT HOME, DANGER!!! it is ok to make them available to
 general public (*). I have always though that, for example, -SNAPSHOT
version
 designation is enough to communicate that  type of intent. Same as
 SNAPSHOT/NONRELEASE tag on Docker image, etc.

I agree.  As long as the version designation of the artifact includes
-SNAPSHOT or -DEV or whatever, I think that's sufficient to qualify as
a clearly identifiable non-release artifact.

FWIW, httpd always had nightly tarballs available for consumption and
testing.

I do think that the threshold is that it needs to come from an
automated process blessed by the [P]PMC.  If it requires a human to
publish the nightly into the distribution channel, then I think
that's probably where the line gets crossed and our voting rules
apply.

Nightly builds shouldn't be easily found - except deep inside
developer-facing documentations.  All obvious materials should point
at the official, blessed releases.  But, it's important to provide a
channel for downstream people to test trunk/master/develop (whatever
shiny name the project calls it).

+1

Personally I think the policy should be clarified such that nightly builds
MUST only live on ASF infrastructure (whether that be the Nexus SNAPSHOTs
repo, committer web space etc).  As soon as you start putting them on
external services like DockerHub then they are potentially widely visible
to the general public.

Going back to the example of libraries published as Maven artifacts for
those projects already publishing SNAPSHOTs these only get published to
the Apache Nexus server (repository.apache.org) and are not synced to
Maven central.  People who want to consume those artifacts have to
explicitly configure their Maven setup to enable Apache SNAPSHOTs.  For me
this is a sufficient barrier to distinguish between developers and
users.

FWIW if someone has made the effort to join the mailing list and report a
bug which we then want to ask them to test a fix for then they are clearly
in the developer category (or more accurately they are a contributor) and
I would have no problem to pointing them to the nightly builds so they
could do this.

However putting stuff out there on an external hosting service that is
widely accessible seems to go against the spirit (and likely the letter)
of the policy

Rob


In today's day and age, producing Docker-like thingys is akin to
producing RPMs.  I won't go into why I think the centralized Docker
Hub is a huge mistake - it's simply how you consume Docker thingys.  I
do wish that we could point folks at a specific Docker registries (a
la an apt or yum repos), but having a single global registry is how
Docker, Inc. apparently thinks that it'll justify its valuations.
Sigh.

Cheers.  -- justin

-
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: Serveral legal question about donating project to Apache?

[Rob Vesse]

Answers inline, please be aware IANAL so these answers are no substitute
for getting advice from a real lawyer

On 17/06/2015 17:12, 封仲淹(纪君祥) zhongyan.f...@alibaba-inc.com wrote:

Hi 

 

May I ask several question about donating projects to Apache?

Any help are appreciated. Thanks in advance.

As we all know, the Apache is the most important open source community,
there are so many great projects such as Tomcat, Hadoop, Hbase, Zookeeper
etc.  It is proud of joining these great projects.

We also want to donate some of our good open source projects to ASF, but
we
are a litter worry about the legal issue. I don’t know what’s the impact
of intelligent Properties after donation, Could anyone give me some
guideline or several documents ? Thanks

Firstly please note that the Apache Software Foundation (ASF) does not
accept arbitrary donations, all incoming projects need to be go through
the Incubation Process:

http://incubator.apache.org/incubation/Process_Description.html

The first stage of which is starting a discussion on the
general@incubator.apache.org list to discuss your proposed donations.

A key criteria that the Incubator uses is that there must be a willingness
to build a open community around a project.  If your intent is merely to
open source a project or leverage the Apache brand with your company
retaining control then your project is unlikely to be accepted by the ASF
and you may be better simply posting it on GitHub and having the
discussion with the Incubator Community will help you figure out what the
best path is for your projects.


 

(1) Trademark

Will the project trademark belong to ASF or still be our company’s after
donation? Can we still use the old project trademark.

Trademarks would be transferred to ASF as part of the donation and become
ASF trademarks, your company can use Apache trademarks in certain ways per
the ASF trademarks policy:

http://www.apache.org/foundation/marks/faq/

If you are currently marketing these products commercially then this would
likely require some changes to how you market and brand your products.

 

 

(2) Patent

We have own several patent on these open source projects, if we donate
these
project, what’s the patent going on. Does we give up all patent claim?

No you don't give up the claims BUT per Clause 3. Grant of Patent License
in the Apache License 2.0 contributors grant a license to all downstream
users of the project to any applicable patents:

http://www.apache.org/licenses/LICENSE-2.0#patent


 

(3) Agreement

Which agreements should we sign? Right now, we need sign
http://www.apache.org/licenses/cla-corporate.txt Corporate CLA and
http://www.apache.org/licenses/software-grant.txt Software Grant
Agreement
(SGA). Is there any other agreement should we sign?

To donate a project then you would have to sign the SGA

The Corporate CLA is an optional document typically used when you employ
people who contribute to Apache projects and your companies IP policies
would usually assign IP in any work employees do to the company




 

(4) Who own the source code?

Does the code belong to ASF or still be our company?

 

The ASF owns the copyright for the collective work

Individual contributors retain copyright to their individual contributions
(note that contributions are not necessarily just code), through Clause 2
Grant of Copyright License of the Apache License 2.0 the contributors
grant a copyright license to all downstream users of the code:

http://www.apache.org/licenses/LICENSE-2.0#copyright

Hope this helps,

Rob


 

 

Thanks in advance.

Longda

 






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

Can we teach brand management/vendor neutrality better?

[Rob Vesse]

All

Over the past few months there have been several occasions where I've
given podlings/recently graduated PMCs a gentle nudge about brand
enforcement and vendor neutrality issues.  In all cases the projects have
responded positively and appropriately to these nudges and taken the
necessary actions to rectify the problems going forward.

However my general experience of the podlings I've been involved
with/follow is that with Incubation we primarily focus on teaching people
about how to make a IP clean release and teaching the Apache Way around
releases, voting, meritocracy etc while not doing so much on teaching PMCs
about their other responsibilities such as enforcing their project brand
and acting in a vendor neutral manner.

There is already some great documentation and policies on this stuff at
the ASF such as:

* http://incubator.apache.org/guides/branding.html
http://incubator.apache.org/guides/branding.htmlhttp://www.apache.org/foun
dation/marks/
* http://www.apache.org/foundation/marks/
http://incubator.apache.org/guides/branding.htmlhttp://www.apache.org/foun
dation/marks/
* http://www.apache.org/foundation/marks/pmcs.html
* http://www.apache.org/foundation/marks/responsibility.html
* http://www.apache.org/foundation/marks/socialmedia

But if we say Go read this I don't see that podling members will
necessarily go and do so (other than in a perfunctory manner).

Shane Curcuru (VP, Brand Management) has a nice slide deck on this from
ApacheCon which presents the key points of those policies in an easier to
digest form:

http://www.slideshare.net/shanecurcuru/supporting-apache-brands-while-makin
g-a-profit-v20b


Though again it is a case of go read this

Maybe go read this and nudging podlings when they get it wrong is the
best we can do in this area but I'd love to know if people have any ideas
of how we could do this better?

Rob





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

Re: Question about Apache's voting procedures

[Rob Vesse]

Answers inline:

On 13/05/2015 14:24, Stefan Reich
stefan.reich.maker.of@googlemail.com wrote:

Hi again!

I was silent because I am thinking... :) (Also I am making releases of my
software.)

I am trying to understand Apache.

Take a look at community.apache.org - there is a lot of good introductory
material there


It seems the voting processes are of big importance. I would like to know
who exactly gets to vote. All members of a mailing list? If yes, it seems
like an easily manipulatable process...

Anyone who participates in the community is invited to vote, votes are
held on the mailing list so in practise this is the portion of the
community on the mailing list

For some procedural votes e.g. releases which are a legal act of the
foundation for which the PMC takes responsibility then there is the notion
of binding versus non-binding votes

See http://www.apache.org/foundation/voting.html for more information

How would you expect someone to manipulate this?


Also, who is officially the copyright owner on the Apache products?
Because
that is a tremendous power position it seems to me.

The Apache License (http://www.apache.org/licenses/LICENSE-2.0) includes
explicit terms for this in Clause 2

Essentially in non-lawyer speak:

- Contributors retain the copyright to their contribution
- Contributors grant a copyright license to all downstream users of their
contributions that permits redistribution, modification, sub licensing etc

Rob


All the best,
Stefan





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

Re: Helping Neo4j Release an Apache2 API for Apache Projects

[Rob Vesse]

On 30/04/2015 00:24, Niclas Hedhman nic...@hedhman.org wrote:

But may I suggest the other way around??  Can't Neo4j have a Tinkerpop
module at their end, which Tinkerpop advertise to be available for those
that can live with the GPL/AGPL limitations? That would make this a
non-issue, and IIUIC fits well within the conceptuals of Tinkerpop.

+1 

I also thinks there is a vendor neutrality argument to be made here as well


Tinkerpop already expects vendors other than Neo4j to provide their own
implementations themselves so why should the project support a specific
vendors implementation as part of the core?  Is this not favouring one
vendor over another?

If Neo4j provides the implementation they can do so under whatever license
terms they prefer and Apache Tinkerpop does not have to worry about this

Rob





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

Re: [VOTE] Accept Geode into the Apache Incubator

[Rob Vesse]

+1 (binding)

Rob

On 19/04/2015 22:46, Roman Shaposhnik r...@apache.org wrote:

Following the discussion earlier in the thread:
   http://s.apache.org/Oxt

I would like to call a VOTE for accepting Geode
as a new incubator project.

The proposal is available at:
https://wiki.apache.org/incubator/GeodeProposal
and is also included at the bottom of this email.

Vote is open until at least Sunday, 26 April 2015, 23:59:00 PST

 [ ] +1 accept Geode in the Incubator
 [ ] ±0
 [ ] -1 because...

Thanks,
Roman.

== Abstract ==
Geode is a data management platform that provides real-time,
consistent access to data-intensive applications throughout widely
distributed cloud architectures.

Geode pools memory (along with CPU, network and optionally local disk)
across multiple processes to manage application objects and behavior.
It uses dynamic replication and data partitioning techniques for high
availability, improved performance, scalability, and fault tolerance.
Geode is both a distributed data container and an in-memory data
management system providing reliable asynchronous event notifications
and guaranteed message delivery.

== Proposal ==
The goal of this proposal is to bring the core of Pivotal Software,
Inc.’s (Pivotal) Pivotal GemFireⓇ codebase into the Apache Software
Foundation (ASF) in order to build a vibrant, diverse and
self-governed open source community around the technology. Pivotal
will continue to market and sell Pivotal GemFire based on Geode. Geode
and Pivotal GemFire will be managed separately. This proposal covers
the Geode source code (mainly written in Java), Geode documentation
and other materials currently available on GitHub.

While Geode is our primary choice for a name of the project, in order
to facilitate PODLINGNAMESEARCH we have come up with two alternatives:
  * Haptic
  * FIG

== Background ==
GemFire is an extremely mature and robust product that can trace its
legacy all the way back to one of the first Object Databases for
Smalltalk: GemStone. The GemFire code base has been maintained by the
same group of engineers as a closed source project. Because of that,
even though the engineers behind GemFire are the de-facto knowledge
leaders for distributed in-memory management, they have had little
exposure to the open source governance process.The original
company developing GemStone and GemFire was acquired by VMWare in 2010
and later spun off as part of Pivotal Software in 2013. Today GemFire
is used by over 600 enterprise customers. An example deployment
includes China National Railways that uses Pivotal GemFire to run
railway ticketing for the entire country of China with a 10 node
cluster that manages 2 gigabytes hot data in memory, and 10 backup
nodes for high availability and elastic scale.

== Rationale ==
Modern-day data management architectures require a robust in-memory
data grid solution to handle a variety of use cases, ranging from
enterprise-wide caching to real-time transactional applications at
scale. In addition, as memory size and network bandwidth growth
continues to outpace those of disk, the importance of managing large
pools of RAM at scale increases. It is essential to innovate at the
same pace and Pivotal strongly believes that in the Big Data space,
this can be optimally achieved through a vibrant, diverse,
self-governed community collectively innovating around a single
codebase while at the same time cross-pollinating with various other
data management communities. ASF is the ideal place to meet these
ambitious goals.

== Initial Goals ==
Our initial goals are to bring Geode into the ASF, transition internal
engineering processes into the open, and foster a collaborative
development model according to the Apache Way. Pivotal plans to
develop new functionality in an open, community-driven way. To get
there, the existing internal build, test and release processes will be
refactored to support open development.

== Current Status ==
Currently, the project code base is licensed for evaluation purposes
and is available for download from Pivotal.io
(https://network.pivotal.io/products/project-geode). The documentation
and wiki pages are available as public GitHub repositories under
Project Geode organization on GitHub
(https://github.com/project-geode). Although Pivotal GemFire was
developed as a proprietary, closed-source product, the internal
engineering practices adopted by the development team lend themselves
well to an open, collaborative and meritocratic environment.

The Pivotal GemFire team has always focused on building a robust end
user community of paying and non-paying customers. The existing
documentation along with StackOverflow and other similar forums are
expected to facilitate conversions between our existing users so as to
transform them into an active community of Geode members, stakeholders
and developers.

=== Meritocracy ===
Our proposed list of initial committers include the current GemFire
RD team, Pivotal Field Engineers, and 

Re: [VOTE] Accept Groovy into the Apache Incubator

[Rob Vesse]

+1 (binding)

Rob

On 19/03/2015 08:20, Benedikt Ritter brit...@apache.org wrote:

+1 non-binding

2015-03-19 9:07 GMT+01:00 Romain Manni-Bucau rmannibu...@gmail.com:

 +1
  Le 19 mars 2015 09:07, Ashish paliwalash...@gmail.com a écrit :

  +1 non-binding
 
  On Thu, Mar 19, 2015 at 12:25 PM, Roman Shaposhnik r...@apache.org
 wrote:
   Following the discussion earlier in the thread:
  http://s.apache.org/KWE
  
   I would like to call a VOTE for accepting Groovy
   as a new incubator project.
  
   The proposal is available at:
   https://wiki.apache.org/incubator/GroovyProposal
   and is also included at the bottom of this email.
  
   Vote is open until at least Saturday, 21st March 2015, 23:59:00 PST
  
[ ] +1 accept Groovy in the Incubator
[ ] ±0
[ ] -1 because...
  
   Thanks,
   Roman.
  
   == Abstract ==
   Groovy is an object-oriented programming language for the Java
   platform. It is a language with features similar to those of Python,
   Ruby, Java, Perl, and Smalltalk.
   Groovy, if accepted by Incubator, will be a first major programming
   language developed under the umbrella of Apache Software Foundation.
  
   == Proposal ==
   Groovy is a programming language for the Java platform. It is a
   primarily dynamic language with features similar to those of Python,
   Ruby, Perl, and Smalltalk. It also has optional static type checking
   and static compilation facilities. It can be used as a scripting
   language for the Java Platform or to write complete applications, is
   compiled to Java Virtual Machine (JVM) bytecode, and interoperates
   with other Java code and libraries. Groovy uses a Java-like
   curly-bracket syntax. Most Java code is also syntactically valid
   Groovy, although semantics may be different. Groovy has long been
   developed under an Apache License v2.0 under an open governance
   community management process. However, so far Groovy has been a
   project mostly sponsored by a single company. This proposal aims at
   bringing Groovy community under the umbrella of the Apache Software
   Foundation.
  
   It must be explicitly noted, that a few sister projects such as
Groovy
   Eclipse and others (some of them hosted under
   https://github.com/groovy and listed at
   http://groovy-lang.org/ecosystem.html) are not covered by this
   proposal. It is possible that these other projects will be joining
ASF
   either independently or as sub-projects of Apache Groovy in the
   future. For now, we are only proposing groovy-core.
  
   == Background ==
   Groovy 1.0 was released on January 2, 2007, and Groovy 2.0 in July,
   2012. Groovy 2.5 is planned for release in 2015. Groovy 3.0 is
planned
   for release in 2016, with support for a new Meta Object Protocol.
   Since version 2, Groovy can also be compiled statically, offering
type
   inference and performance very close to that of Java. Groovy 2.4
will
   be the last major release under Pivotal Software's sponsorship,
which
   is scheduled to end on March 31, 2015.
  
   == Rationale ==
   Groovy is a pretty mature language. After 12 years of development,
it
   has grown from being primarily a dynamic scripting language on the
JVM
   to an optionally statically compiled language allowing the same
   performance level as Java applications. With the release of Groovy
   2.4, the language targets the largest pool of mobile developers with
   native Android support. Groovy has been integrated in a large number
   of applications, including well known open-source projects like
   Jenkins, Gradle, ElasticSearch, Spring and more.
  
   There are multiple alternative languages on the JVM: Scala, Clojure,
   Ceylon, Kotlin, JRuby, Golo and others but Groovy is the only one
   which has proved to be very easy to integrate with Java in both
ways:
   Groovy code using Java code, but also Java code using Groovy code.
   Groovy even provides a joint compiler which allows interdependent
Java
   and Groovy classes to compile together. Groovy also supports dynamic
   code generation, that is to say classes at runtime, making it a
   perfect fit for scripting. With a very lightweight and malleable
   syntax, it is also easy to build internal Domain Specific Languages
   (DSLs) which integrate smoothly within applications.
  
   Groovy provides a number of unique features, like builders (Java 8
has
   lambdas but still has syntactic overhead and no notion of delegate),
   AST transformations (compile-time metaprogramming) or type checking
   extensions (which allows the developer to bring the compiler to
levels
   of type checking and type inference that go far beyond what other
   languages do). Groovy also provides powerful integration options and
   customizations which set it apart from other languages. Groovy is
also
   unique in the way it allows the developer to choose between various
   paradigms without compromise: functional vs object-oriented,
   statically compiled vs dynamic, scripting vs applications, etc.

Re: [VOTE] Accept CommonsRDF into the Apache Incubator

[Rob Vesse]

+1

Rob

On 27/02/2015 19:19, Lewis John Mcgibbney lewis.mcgibb...@gmail.com
wrote:

Hi general@,

Over the last while a number of individuals have been putting together a
proposal and gathering interest in proposing Commons RDF for acceptance
into the Apache Incubator. Having worked our way through the Incubator
documentation checklists -
http://incubator.apache.org/guides/proposal.html#formulating, we are now
brining this proposal back to the general@ list.

Commons RDF is a set of interfaces for the RDF 1.1 concepts that can be
used to expose common RDF-1.1 concepts using common Java interfaces. The
current CommondRDFProposal document can be found at -
https://wiki.apache.org/incubator/CommonsRDFProposal

This thread is therefore aimed at obtaining general consensus from the
incubator community on whether the proposal document is suitable and
whether the project as described should begin an incubation period at
Apache.

The VOTE is therefore as follows

[ ] +1 I am happy with Commons RDF entering incubation
[ ] +0/-0 I am neither yay or nay
[ ] -1 I am not happy with this proposal because

The VOTE will be open for at least 72 hours.

p.s. Here is my +1 PPMC binding

-- 
*Lewis*





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

Re: [VOTE] Accept Myriad into the Apache Incubator

[Rob Vesse]

+1 (binding)

Rob

On 22/02/2015 05:34, Adam Bordelon a...@mesosphere.io wrote:

Hello friends,

After receiving a positive response on the discussion thread, and even a
new Mentor (Luciano), I would like to call a VOTE to accept Myriad into
the
Apache Incubator. I will end the vote after 7 days.

https://wiki.apache.org/incubator/MyriadProposal?action=recallrev=7

[ ] +1 Accept Myriad into the Incubator
[ ] +0 Don’t care.
[ ] -1 Don’t accept Myriad into the Incubator because..

I am clearly a +1.

Thanks,
-Adam-
me@apache





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

Re: [DISCUSS] Commons RDF to join the Apache Incubator

[Rob Vesse]

Marvin

Yes I would be willing to be a mentor for this podling if there isn't
sufficient volunteers and they would be willing to have me

I agree that there is a tendency then to make the podling Jena heavy but I
have had zero involvement in the Commons RDF effort to date and the API
they are talking about currently is at a level of a stack that I have
historically contributed nothing to nor do I particularly use so hopefully
I would be seen as relatively neutral.  To be honest I wouldn't have the
bandwidth to get actively involved in the code  design) efforts (nor do I
particularly want to) and thus would only want to be a mentor.

As you said this would probably be a relatively easy mentoring gig with
most of the effort being around just keeping an eye on the community to
sign off and comment on reports and to review release as and when they
come around.

Rob

On 10/02/2015 20:31, Marvin Humphrey mar...@rectangular.com wrote:

On Tue, Feb 10, 2015 at 7:21 AM, Stian Soiland-Reyes st...@apache.org
wrote:

 The natural path to Apache Commons Sandbox has been studied, but we
 think that in this phase of the project, which focuses on the API
 design and actively involves the developers of existing toolkits, it
 is better to have a more focused community and infrastructure. Rather
 than a new Top-Level Project, the goal is still to graduate as part of
 Apache Commons, that is when API has achieve the required maturity and
 the project goes into maintenance mode.

If Commons is OK with this, I imagine this is a fine plan -- good enough
for
entering incubation.

I also think it would be OK for the project to decide it wants to become a
TLP.  Whether the project joins Commons or becomes its own TLP won't
impact
the number of people qualified to work on it.  Some Apache TLPs are
effectively in maintenance mode and have very low activity, but still
have PMC
members willing to answer user questions, make security releases and file
still here quarterly reports.  That seems like a legitimate aspiration
for
this project.

A potential Jena destination also seems as though it would have certain
advantages, though my naive speculation is that it might be sub-optimal in
terms of providing neutral territory for negotiating a common API for
Jena and
Sesame.

In any case it seems likely that if the project achieves its design goal,
there will be people willing to work on it as long as both Jena and Sesame
remain viable.  That makes it different from other potential maintenance
mode TLPs which are in danger of stagnation because they cannot renew
their
communities.

Is that take roughly accurate, Sergio et al?

 === Mailing lists ===

  * commons-rdf-dev
  * commons-rdf-commits

Those sound like final mailing lists rather than Incubator ones.  I might
have
expected these instead:

d...@commons-rdf.incubator.apache.org
comm...@commons-rdf.incubator.apache.org

Do you expect to keep separate mailing lists after graduation, or will
traffic
be shunted onto existing Commons mailing list like d...@commons.apache.org
and
comm...@commons.apache.org?

  * Sergio Fernández (wikier dot apache dot org)
  * Andy Seaborne (andy dot apache dot org)
  * Peter Ansell (ansell dot apache dot org)
  * Stian Soiland-Reyes (stain at apache dot org)
  * Reto Gmür (reto at apache dot org)

Lots of Apache experience in this group.  Four are PMC members of at
least one
Apache project.  Andy and Reto are ASF Members.  Andy and Sergio are both
IPMC
members.  Stian is a core contributor of the Taverna podling.

You probably haven't been getting much feedback because there's a lot
going on
in the Incubator right now and everybody figures that with a group like
that
you're in good shape. :)

=== Champion ===

 * TBD

The Champion's main work is to help formulate the proposal.  That work is
essentially done -- so it doesn't matter too much who takes that role,
now.
Are Andy and Reto opting out out as a gesture of openness to Sesame?

 === Nominated Mentors ===

  * Benedikt Ritter (britter at apache dot org)
  * TBD

Benedikt is a member of the Commons PMC, but he's not a member of the
IPMC nor
an Apache Member -- so although Commons input is important, unfortunately
it's
not a valid nomination.

I'd nudge newly elected IPMC member Rob Vesse, but maybe the roster is
already
Jena-heavy?

Marvin Humphrey

-
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: Draft Report February 2015 - please review

[Rob Vesse]

+1 to jan's comments

Ideally you should not be carrying out votes for code changes unless you
can't progress without it.  In some Apache projects I've participated in I
don't think we've ever held a formal vote on code changes.  It's fairly
common to informally use +1/0/-1 to expression opinions as part of our
design discussions but we haven't ever had the need to call a formal vote.

You should always be trying to have discussions first and come to a
consensus such that you can just go ahead with the proposed changes.  In
the event that someone votes -1 then that should be treated as a veto and
you need to go back to the drawing board and/or discuss further until
their concerns are addressed and the -1 is withdrawn

http://apache.org/foundation/voting.html#votes-on-code-modification

If your community is small then hopefully it should be easy to reach a
consensus

Rob

On 10/02/2015 11:26, jan i j...@apache.org wrote:

On 10 February 2015 at 11:44, Gianmarco De Francisci Morales 
g...@apache.org wrote:

 Hi,

 I can reply about SAMOA.
 We want to create bylaws because the default voting process for code
 changes in Apache is too strict for us (3 +1 binding votes).
 Being a small community, we felt that we needed a lower bar to move
faster.
 My understanding is that we need bylaws to specify that, but maybe I
missed
 something and I'm happy to be corrected.


You do not need bylaws for that, all you need is a discussion among the
PMCs and a mail thread that shows consensus. The (P)PMC can make its own
rules,
as long as it is discussed and consensus is reached (of course the few
Incubator and ASF rules cannot be overwritten).

Especially for small communities code  changes need to be flexible. I am
however not sure why think 3 +1 is needed for a code change,
can it be you mix release vote with code changes ?

In incubator you do need 3 +1 votes from IPMC to cut a release and of
course consensus in the PPMC, but that is not something the project can
overwrite
with bylaws.

rgds
jan i.





 Cheers,

 --
 Gianmarco

 On 10 February 2015 at 00:35, Marvin Humphrey mar...@rectangular.com
 wrote:

  Hello, Incubator community,
 
  As discussed in a recent thread on Mentoring, the draft report email
  provides
  an opportunity for cross-cutting feedback.  So here goes!
 
  The top-level report was not yet complete when the draft was sent out
 (and
  what sections were there I wrote), so I have nothing to say about
that.
  But I
  have some comments in response to the podling reports for Droids,
HTrace,
  Ripple, SAMOA, and Sirona which I hope will prove constructive.
 
   
   Droids
  
   Droids aims to be an intelligent standalone robot framework that
allows
  to
   create and extend existing droids (robots).
  
   Droids has been incubating since 2008-10-09.
  
   Three most important issues to address in the move towards
graduation:
  
 1. Activity
 2. Name Search
  
   Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to
be
   aware of?
  
 None.
  
 We need to continue the name search. Branding has replied to the
 issue
  and
 provided additional searches that need to performed. It is hoped
that
 these can be finished in the new couple weeks.
  
   How has the community developed since the last report?
  
 No change.
  
   How has the project developed since the last report?
  
 No change.
  
   Date of last release:
  
 2012-10-15
  
   When were the last committers or PMC members elected?
  
 2012-05-07
  
  
   Signed-off-by:
  
 [ ](droids) Thorsten Scherler
 [x](droids) Richard Frovarp
  
   Shepherd/Mentor notes:
  
  
  
  
 
  It's my understanding that Droids is basically a mature product with
no
  pressing need for further development, not unlike some dormant Apache
 TLPs
  who
  neverthess still have PMC members hanging around able to make releases
 and
  respond to user inquiries.
 
  I think the greater IPMC ought to stay aware, though, that Droids has
 very,
  very low activity: 3 dev list emails in the last quarter (39 in the
  last year), no user list, and no commits since April 2013.  The only
 thing
  between Droids and retirement is our deference to Richard and
Thorsten.
  They
  form the potential core of a community, but it has yet to develop in 6
  years
  of incubation.
 
   
   HTrace
  
   HTrace is a tracing framework intended for use with distributed
systems
   written in java.
  
   HTrace has been incubating since 2014-11.
  
   Three most important issues to address in the move towards
graduation:
  
 1. Continue to grow the HTrace community
 2. Continue to develop and release stable HTrace incubating
artifacts
 3. Continue to explore the integration of the HTrace framework
into
  other
Apache products
  
   Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to
be
   aware of?
  
 Around January 20th HTrace successfully made the first 

Re: CCLA's and SGA's

[Rob Vesse]

There is a case where an CCLA can cover for an SGA

If a company donates code to an existing project where the developers of
the incoming contributions already have ICLAs and the company has signed
CCLA for those contributors that were already in effect at the time the
contributions were originally developed then in one previous case I've
seen it be agreed that an SGA was unnecessary.  For example see this
legal-discuss thread:

http://s.apache.org/YPe

Rob

On 08/02/2015 18:10, Roman Shaposhnik ro...@shaposhnik.org wrote:

On Sun, Feb 8, 2015 at 6:09 PM, John D. Ament johndam...@apache.org
wrote:
 And specifically, is there ever a case where a CCLA can cover for a SGA?

I would seriously doubt it.

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: Podling Name Searches

[Rob Vesse]

One option would be to get the company involved to donate the trademark,
if you check with trademarks@a.o then I am pretty sure that has happened
in the past and they can likely guide you on procedures for this

Your wording implies that perhaps this isn't an option in this particular
podlings case?

Rob

On 25/01/2015 06:45, Branko Čibej br...@apache.org wrote:

On 25.01.2015 14:08, John D. Ament wrote:
 All,

 If a podling had its name and codebase donated from a company, which had
 already secured rights to the name,

The term secured rights is a bit misleading. Even if they have a
registered trademark, that's no guarantee that it doesn't infringe on
anything, especially in a different jurisdiction.

 what is required in the podling name search?

IMO, same as always. There's no reason for the ASF to implicitly trust
corporate lawyers. We should always look for names that are globally
unambiguous.

-- Brane


-
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

When is an ICLA needed?

[Rob Vesse]

All

I keep an eye on the Lucene.Net TLP since I use it in some of my other
projects and after a long hiatus the activity in that community has picked
up considerably.  However there is one thing that has caught my eye that
they've been doing recently which I'm not sure is strictly necessary.  I
noticed that as they've been recruiting new contributors (not committers)
for their porting efforts they've been asking these contributors to sign
the ICLA before they will accept a pull request.

My understanding was always that the ICLA is only required if you are a
committer though may still be desirable for larger contributions, quoting
from http://www.apache.org/licenses/#clas -

The ASF desires that all contributors of ideas, code, or documentation to
the Apache projects complete, sign, and submit (via postal mail, fax or
email) an Individual Contributor License Agreement
http://www.apache.org/licenses/icla.txt (1) (CLA) [ PDF form
http://www.apache.org/licenses/icla.pdf ]. The purpose of this agreement
is to clearly define the terms under which intellectual property has been
contributed to the ASF and thereby allow us to defend the project should
there be a legal dispute regarding the software at some future time. A
signed CLA is required to be on file before an individual is given commit
rights to an ASF project.

Note the use of the word desires here, only committers are required to
have an agreement on file.  Contributors can always make contributions
without one since the Apache License explicitly has a clause that covers
this (http://www.apache.org/licenses/LICENSE-2.0#contributions).

Actual committers still have to merge and push the pull requests made by
contributors to the ASF repos so from an ASF perspective the provenance of
the contributions is OK since we know they were pushed by a committer
(though obviously committers still need to be reviewing the contributions
to check for any possible IP violations)

Is my understanding on this right?

If so I shall be pinging their dev list to remind them of this since IMO
they are putting a potentially unnecessary hurdle in front of new
contributors.

Additionally they don't appear to have offered committership/PMC
membership to any of these new people who have signed ICLAs and whose pull
requests are getting merged so I will be pinging the list to remind them
about this regardless.  I've seen that there are several people who've
made considerable sustained contributions which in any other ASF project
I've been involved in would have earned them sufficient merit to be
offered at least committership (if not PMC membership) by now.

Regards,

Rob





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

Re: Incubating with Apache Commons as champion?

[Rob Vesse]

Stian

If a community made predominantly of existing Apache committers (or
containing a strong core of) already exists and this would be a small self
contained module as part of Apache Commons then why does the Incubator
need be involved at all?

Why can this not just be submitted directly to Apache Commons via the IP
Clearance procedure (http://incubator.apache.org/ip-clearance/index.html)?
 

Commons already allows any ASF committer to commit so the existing
community can continue working on the code just fine.  The only sticking
point would be once Commons-RDF wants to release in which case you'd
likely need to canvas the larger commons community for votes until such
time as the Commons-RDF committers have earned sufficient merit to be
offered PMC membership

On the other hand does Commons-RDF necessarily need to come to the ASF at
all?  If it is a small self-contained interface module that will remain
stable what does it gain (other than brand association) by coming to the
ASF?

Rob

On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote:

The discussion on dev@commons about coming-to-Apache Commons-RDF
(https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a
temporary mailing list like rdf@commons as it is seen t be splitting
Apache Commons as a project - the ideal committer on Apache Commons is
caring about all its components (avoiding the Jakarta pitfalls).


We had not considered becoming a TLP as once the API (mainly a set of
interfaces) is settled, by then it will probably be pretty much a
quiet project except the odd maintenance patch - and also by being a
common component of several RDF projects within Apache, its best home
then would be under Commons (presumably with most of the original
committers still involved).


However the large traffic of dev@commons (~400/month) about all the
other components can be a problem for trying to engage the non-Apache
community around commons-rdf while we flesh out the API. (This has
currently been done solely through Github issues, pull requests, and
watching the project).

In a way we are limited by the technology of the Apache mailing lists.
(I know, I know...).

(I mentioned gitlab.com )


The suggestion is that Commons-RDF could be a incubator project, but
with a projected path to become part of the Apache Commons instead of
a TLP.  (I believe this path has not happened before)


So this would be using the old structure of having a champion of
Apache Commons - could this be a workable incubator project?

In a way it would be incubating just the code until API maturity
rather than the community or Apache Way as both of those already
exist.

In such an (old skool) setup, would it be the Commons PMC /
dev@commons who would vote over the incubating releases?

Once graduating it would just become a component under Apache
Commons and the community would just be dev@commons where the
committers would already be members - the dev@rdf.incubator list would
simply close.

.. and where would mentors come from? Would existing committers from
those other Apache projects (Jena, Marmotta, Clerezza) be enough - or
should it be someone from IMPC or from dev@commons?


See 
http://mail-archives.apache.org/mod_mbox/commons-dev/201501.mbox/%3CCAB917
RLJE%2BgFEpw%3Dyp-c-HpXEnvL12JZLLpc4wphGyjGH_6%3D9Q%40mail.gmail.com%3E
for the whole threads :)


-- Forwarded message --
From: Stian Soiland-Reyes st...@apache.org
Date: 20 January 2015 at 14:06
Subject: Re: [DISCUSS][RDF] Separate mailing list for Commons RDF
To: Commons Developers List d...@commons.apache.org


Agree that maybe the the Incubator with a projected path to the
Commons could be a workable middle ground while Commons-RDF is still
incubating code-wise (but not community or Apache Way-wise).

No earlier project has gone through this route
(https://incubator.apache.org/projects/ ) - this would reuse the
deprecated Champion project to be Apache Commons instead of
Incubator PMC in this case.

Such a proposal has some good features - I presume commons-rdf
releases would still be voted over (and thus involve) the Commons PMC
and dev@commons  (as they would after graduating).

As an API, then Commons-RDF should not be considered stable while
being in 0.x.x-incubating anyway.



On 20 January 2015 at 13:58, Torsten Curdt tcu...@vafer.org wrote:
  There are several ASF projects in the
 RDF space.  They have been through the incubator.  Please do talk to
those
 projects if you have concerns.

 I am sorry - but how are those projects relevant in this case?

 And what's so bad about the incubator? You could (maybe) later on come
 to Commons.

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


--
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

-- 
Stian Soiland-Reyes
Apache Taverna (incubating)

Re: Incubating with Apache Commons as champion?

[Rob Vesse]

Agreed

The point that I was trying to make is that if those involved already
understand the Apache Way going through Incubation for the sake of it
seems a pointless exercise especially when the legal/IP aspects of things
can be handled in other fashions.  If you are in a position to simply
contribute the code directly to the TLP you expect it to live under and
the TLP in question is receptive to that then it is a viable option to
consider.

I'm not saying that Incubation shouldn't happen but that you should
consider if it actually brings the project in question any tangible
benefits.

There seems to be an assumption that coming through the Incubator is the
how you would grow the community but that activity is perfectly capable of
happening in the context of a TLP.  One of the key activities of the PMC
should be to continually try and bring in new members of the community
over time so that the project they are charged with managing does not
stagnate.

It's worth remembering that the Incubator itself does not provide much in
the way of help in terms of growing communities since that is something
that really only the incubating projects themselves can do.

Rob

On 20/01/2015 16:04, Stian Soiland-Reyes st...@apache.org wrote:

Just because a lot of Apache committers are involved and could put
things right into another project (or even propose a new TLP directly)
doesn't mean it happens.

https://wiki.apache.org/incubator/BeanShellProposal was voted -1 in
the incubator because it had many Apache folks already and didn't need
to learn anything. Yet the project didn't move into Apache - perhaps
because it didn't have any pressure or framework to go through the
Incubator process?

(It now lives semi-dormantly as an Apache Extras thing at
https://code.google.com/a/apache-extras.org/p/beanshell/ - I joined
recently and it is slowly awakening :) )


I think the incubator should be open also for a group of experienced
Apache folks - although their needs would be different, e.g. more of a
focus on the project goals and growing their community, and not so
much worry about IP issues, licenses and build/release procedures.


On 20 January 2015 at 15:08, Rob Vesse rve...@dotnetrdf.org wrote:
 Stian

 If a community made predominantly of existing Apache committers (or
 containing a strong core of) already exists and this would be a small
self
 contained module as part of Apache Commons then why does the Incubator
 need be involved at all?

 Why can this not just be submitted directly to Apache Commons via the IP
 Clearance procedure
(http://incubator.apache.org/ip-clearance/index.html)?


 Commons already allows any ASF committer to commit so the existing
 community can continue working on the code just fine.  The only sticking
 point would be once Commons-RDF wants to release in which case you'd
 likely need to canvas the larger commons community for votes until such
 time as the Commons-RDF committers have earned sufficient merit to be
 offered PMC membership

 On the other hand does Commons-RDF necessarily need to come to the ASF
at
 all?  If it is a small self-contained interface module that will remain
 stable what does it gain (other than brand association) by coming to the
 ASF?

 Rob

 On 20/01/2015 14:28, Stian Soiland-Reyes st...@apache.org wrote:

The discussion on dev@commons about coming-to-Apache Commons-RDF
(https://github.com/commons-rdf/commons-rdf/) seems to be rejecting a
temporary mailing list like rdf@commons as it is seen t be splitting
Apache Commons as a project - the ideal committer on Apache Commons is
caring about all its components (avoiding the Jakarta pitfalls).


We had not considered becoming a TLP as once the API (mainly a set of
interfaces) is settled, by then it will probably be pretty much a
quiet project except the odd maintenance patch - and also by being a
common component of several RDF projects within Apache, its best home
then would be under Commons (presumably with most of the original
committers still involved).


However the large traffic of dev@commons (~400/month) about all the
other components can be a problem for trying to engage the non-Apache
community around commons-rdf while we flesh out the API. (This has
currently been done solely through Github issues, pull requests, and
watching the project).

In a way we are limited by the technology of the Apache mailing lists.
(I know, I know...).

(I mentioned gitlab.com )


The suggestion is that Commons-RDF could be a incubator project, but
with a projected path to become part of the Apache Commons instead of
a TLP.  (I believe this path has not happened before)


So this would be using the old structure of having a champion of
Apache Commons - could this be a workable incubator project?

In a way it would be incubating just the code until API maturity
rather than the community or Apache Way as both of those already
exist.

In such an (old skool) setup, would it be the Commons PMC /
dev@commons who would vote over

Re: [Proposal] TinkerPop: A Graph Computing Framework

[Rob Vesse]

To clarify on Daniel's comments this does not mean that pull requests
cannot be merged

You can have Infra set up ASF integration with GitHub such that pull
requests trigger emails to your projects dev list, those emails contain
instructions on how to pull and merge the request into your local ASF
based working copy.  You then simply push to the ASF repo and if you've
said Closes #1 (or whatever the exact wording is - again the email tells
you) then the pull request is automatically closed over on GitHub

See 
https://blogs.apache.org/infra/entry/improved_integration_between_apache_an
d

As for moving other infrastructure the Jena project (which I am involved
in) went through a similar exercise of migrating large amounts of external
infrastructure to the ASF when moving to the ASF and the Jena project.
Yes it was painful for a time but it is worth doing and as others have
pointed out there are sound reasons behind it.

It is really not that hard to migrate a mailing list from one platform to
another in our experience.  In the Jena project we kept the external
mailing lists open for the first 6 months or so and just sent regular
reminders asking people to move to the ASF mailing lists.  After that
period we closed the external list to new subscriptions and continued
sending the regular reminders for another 6 months or so, after that we
closed the external list entirely to new posts so it served only as a
historical archive.  Over time this allowed us to gracefully migrate users
to the new infrastructure by giving them plenty of notice and information
about what was happening and this didn't require huge amounts of effort on
our part.

Rob

On 18/12/2014 16:36, Daniel Gruno humbed...@apache.org wrote:


On 2014-12-18 17:28, Sam Ruby wrote:
 On 12/18/2014 11:16 AM, Marko Rodriguez wrote:
 Hello Jake,

 When talking with Sam Ruby (cc:d) we voiced our concerns about moving
 all of our infrastructure over to The Apache Foundation. In particular,
 our GitHub presence and our public user-mailing list (i.e. tech support
 mailing list). I have articulated our concerns in the freshly updated
 proposal.

 https://wiki.apache.org/incubator/TinkerPopProposal
 Please see W. Mailing Lists, Y. Git Repository, and X. Subversion
 Directory.

 Sam Ruby had stated that using GitHub for source control is an accepted
 practice now.

 Let's split that into two pieces.

 Git is a DVCS, which means that it can be at multiple places. Using
 git for source control is an accepted practice at the ASF now.  GitHub
 can be one of the places.

 From the ASF perspective, GitHub is a mirror.  From GitHub's
 perspective, the ASF is a mirror.
No, from GitHub's perspective, ASF is the canonical source. There is no
way to twist this into anything else.
It says right on every single Apache GitHub mirror that it is Mirrored
from http://git.apache.org/...;.

You cannot merge pull requests from GitHub via GitHub, that's simply not
going to work, and it should be plenty clear to everyone by now why that
is the case.

With regards,
Daniel.

 None of this means that you can't use pull requests.  Examples:

 https://github.com/apache/spark/pulls
 https://github.com/deltacloud/deltacloud-core/pulls
 https://github.com/apache/camel/pulls

 (These just happen to be the top three hits on a Google search for
 apache github pull requests).

 We can (though would prefer not to) move our issue
 tracking to JIRA. Again, we have all been using GitHub issue tracking
 for 5 years and are comfortable with its interface. Likewise, we can
 (though would prefer not to), move our user mailing list to Apache's
 mail list system. If a distinction is made between user mailing list
 (tech support) and contributor mailing list (governance), we can (and
 would prefer) to move over our TinkerPop Contributors mailing list to
 ASF as this is where all the legal/political/governance discussion
occur
 and should be under the purview of ASF.

 The current tinkerpop mailing lists are indeed quite active.  I
 believe it would be possible for an ASF mailing list to be subscribed
 to each of these and satisfy ASF requirements in this manner.

 Thoughts?,
 Marko.

 - Sam Ruby

 http://markorodriguez.com

 On Dec 17, 2014, at 7:42 PM, Jake Farrell jfarr...@apache.org
 mailto:jfarr...@apache.org wrote:

 Hey Marko
 Thank you for posting the proposal to the wiki. The proposal has the
 requested infra for issues, wiki, mailing lists, and scm all still at
 github. These sections will have to be edited to bring everything
 over to
 ASF hardware. Please take a look at other proposals listed for an
 idea and
 if you have any questions please let us know

 Thanks
 -Jake

 On Wed, Dec 17, 2014 at 7:56 PM, Marko Rodriguez okramma...@gmail.com
 mailto:okramma...@gmail.com
 wrote:

 Hello everyone,

 I have put the proposal on the wiki page.

 https://wiki.apache.org/incubator/TinkerPopProposal

 As requested by Roman, I updated the Affiliations section. Note that
I
 would love to tweak more but 

Re: [PROPOSAL] Apache Argus Proposal

[Rob Vesse]

Interesting proposal, it seems like the core technology being described
has a lot in common with Apache Shiro

Has collaboration with that community been considered whether just in
terms of reusing existing Shiro components wherever possible or something
deeper e.g. inviting Shiro developers to help bootstrap the community?

Rob

On 15/07/2014 03:16, Selvamohan Neethiraj sneethi...@hortonworks.com
wrote:

Apache Argus Proposal (http://wiki.apache.org/incubator/ArgusProposal)

== Abstract ==

Argus is a framework to enable, monitor and manage comprehensive data
security across the Hadoop platform.

The name “Argus” is derived from Argus Panoptes, a 100-eyed giant in
Greek mythology, endowed with a role to keep “an eye” open and be an
effective watchman at all times.

== Background ==

The vision with Argus is to provide comprehensive security across the
Apache Hadoop ecosystem. With the advent of  Apache YARN, the Hadoop
platform can now support a true data lake architecture. Enterprises can
potentially run multiple workloads, in a multi tenant environment. Data
security within Hadoop needs to evolve to support multiple use cases for
data access, while also providing a framework for central administration
of security policies and monitoring of user access.

XA Secure, a Hadoop security focused startup, developed the initial
technology behind Argus. XA Secure was acquired by Hortonworks, which now
is contributing the technology to the open source community to extend and
innovate.

== Rationale ==

Many of the projects in the Hadoop ecosystem have their own
authentication, authorization, and auditing components. There are no
central administration and auditing capabilities. We are looking to
address these enterprises security needs of central administration and
comprehensive security through the Argus project.
Our initial focus would be around authorization and auditing, the longer
term vision would be to tie all aspects around data security within the
Hadoop platform. 

== Proposal Details ==

The vision of Argus is to enable comprehensive data security across the
Hadoop platform. The goal is provide a single user interface or API to
manage security policies, monitor user access and policy changes history.
The framework would work with individual components in enforcing these
policies and in capturing relevant audit information.
Initial Goals
   1.  Donate the Argus source code and documentation to the Apache 
 Software
Foundation
   2.  Setup and standardize the open governance of the Argus project
   3.  Build a user and developer community
   4.  Deeper Integration with Hadoop Platform
   a.  Enable integration with Apache Storm, Apache Knox and 
 Apache Falcon
for authorization and auditing
   5.  Configurable centralized storage of audit data into HDFS
   6.  Enable framework to be run in both Linux and Windows 
 environments
   7.  Rationalize install procedure, making it easier for enterprises 
 to
deploy

== Longer Term Goals ==

In longer term, Argus should provide a comprehensive security framework
for Hadoop platform components, covering the following
   1.  Centralized security administration to manage all security 
 related
tasks in a central UI
   2.  Fine grained authorization to do a specific action and/or 
 operation
with Hadoop component/tool and managed through a central administration
tool
   a.  Standardize authorization method across all Hadoop 
 components
   b.  Enhanced support for different authorization methods - 
 Role based
access control, attribute based access control etc
   c.  Enable tag based global policies
   3.  Centralize auditing of user access and administrative actions
(security related) within all the components of Hadoop

== Current Status ==

Argus’ technology is currently being used by enterprises and is under
active development.

The key components of Argus are:
   •   Enterprise Security Administration Portal
   ◦   A Java Web Application, designed for administration of 
 security
policies from a single location for the entire hadoop cluster (and even
multiple hadoop clusters)
   •   Security Agents
   ◦   A light-weight Java Agent, which will be embedded into 
 the hadoop
component (e.g. Hive, HBase and Hadoop) as an authorization provider to
enforce the security policies and also collect access events/logs.
   •   User/Group Synchronizer Module
   ◦   A standalone daemon which allows the user/group 
 information to be
synched from the enterprise user repositories like LDAP/AD to Argus local
database. This user/group information in Argus local database will help
the security policy administrators
   ▪   to define security policies by  selecting 
 users/groups from a
drop-down box (instead of typing their name/group in a 

Re: [DISCUSS] Incubator exit criteria

[Rob Vesse]

On 09/07/2014 09:12, Chris Douglas cdoug...@apache.org wrote:

On Wed, Jul 9, 2014 at 12:23 AM, Roman Shaposhnik r...@apache.org wrote:
 Again, why would code lose users? Remember we're talking
 about a situation of no releases here. Presumably those
 users who are comfortable building from the repo would
 just keep doing so. And since there was no release,
 what else is out there for us to worry about?

IIRC there may be implications for licensing if someone is literally
pulling code out of trunk and distributing it. Without a release, the
PMC hasn't represented that the artifact is kosher. For release tags,
this is true.

I assume Roman is talking about an external user not someone acting for
the PPMC here?

IANAL but my two cents:

Users always have the option of pulling from source code and building
whether we are talking about podlings or top level projects.  The ASF
makes it clear that source control does not constitute a release and so
does not have the legal assurances that users can expect from an official
ASF release.  However by virtue of being open source we provide the means
for users to do this if they so wish.

If people are choosing to use/redistribute code that they have taken from
our source control then they are assuming any legal risks, people doing
this likely have much more liberal licensing policies or don't care

If a PPMC member was pulling from source and distributing outside the ASF
then that would be much more murky as to who they are acting for and may
indeed have legal implications for the ASF

Rob





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

Re: [RESULT][VOTE] IP Clearance for Apache Jena Hadoop RDF Tools donation from Cray

[Rob Vesse]

With no objections the vote passes by lazy consensus

Thanks,

Rob

On 22/05/2014 12:12, Rob Vesse rve...@dotnetrdf.org wrote:

Cray is proposing to donate a set of libraries called Hadoop RDF Tools to
the Apache Jena project - the details of the code base can be viewed at
https://issues.apache.org/jira/browse/JENA-666 and the current state of
the
code for donation can be viewed at
https://svn.apache.org/viewvc/jena/Experimental/hadoop-rdf/

The IP clearance steps carried out for this code can be viewed at
https://incubator.apache.org/ip-clearance/jena-hadoop-rdf-tools.html

The Jena PMC has voted to approve this donation and the result email can
be
seen at 

Please vote to approve this contribution. Lazy consensus applies. If no -1
votes are cast within the next 72 hours, the vote passes.

Thanks,

Rob









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

[VOTE] IP Clearance for Apache Jena Hadoop RDF Tools donation from Cray

[Rob Vesse]

Cray is proposing to donate a set of libraries called Hadoop RDF Tools to
the Apache Jena project - the details of the code base can be viewed at
https://issues.apache.org/jira/browse/JENA-666 and the current state of the
code for donation can be viewed at
https://svn.apache.org/viewvc/jena/Experimental/hadoop-rdf/

The IP clearance steps carried out for this code can be viewed at
https://incubator.apache.org/ip-clearance/jena-hadoop-rdf-tools.html

The Jena PMC has voted to approve this donation and the result email can be
seen at 

Please vote to approve this contribution. Lazy consensus applies. If no -1
votes are cast within the next 72 hours, the vote passes.

Thanks,

Rob

Is a Software Grant Agreement always needed for IP Clearance?

[Rob Vesse]

Hi All

I¹m in the process of carrying out IP Clearance for some code developed
outside of the ASF that my employer (Cray) has now agreed to contribute to
the Apache Jena project where I am a committer and PMC member.

In this case the software was developed entirely by myself though obviously
Cray holds the copyright.  I have an ICLA on file for myself and Cray filed
a CCLA for me when I originally joined the Apache Jena project as a
committer and PMC member.  In this scenario is a SGA actually needed to
carry out IP Clearance of the contributed code or are the existing ICLA and
CCLA sufficient?

Thanks,

Rob Vesse

Re: [DISCUSS] Proposal for a Black Duck POC

[Rob Vesse]

Roman

Black Duck software certainly have a useful platform though it would be
useful to know what they are considering using for the POC.

Personally I¹ve used their Protex software and I can state from experience
that it is quite a time consuming and thankless process to work through IP
Clearance with it having done this several times over the past couple of
years with pieces of code developed at my employer and then open sourced.

I would certainly recommend trying a POC but I¹m not sure it is
necessarily something you¹d want to impose on all incoming projects in the
long term.

Some info on Protex:

My main concerns are that Protex while very useful is somewhat dumb
primarily due to the quality of its knowledge base.  For those who aren¹t
aware essentially the tool scans the code looking for files that have
³signatures² that match other open source/proprietary code in the
knowledge base.  The open source code is scraped from all sorts of public
sites like SourceForge, GitHub, BitBucket etc.  For each match that occurs
someone has to review the match and then they can indicate whether to
exclude that match I.e. it was a false positive or to accept that match
and attribute it appropriately.

This is great in principle because it easily spots obvious plagiarism when
it occurs.  The problem from my point of view is that the false positive
rate is very high and then you have to go through all the matches and
manually state whether they are valid/invalid.  This ends up being very
time consuming because for each match on your code you have to review all
the possible matches to see if there actually is a genuine match and if
not then go through a process of telling the tool

This is where the knowledge base starts to hurt you, there are lots of
projects out there which check in everything including things like
auto-generated IDE project files, build tool reports, VCS ignore files etc
which tend to have very high similarity and get flagged up as false
positives constantly.  Ideally Apache projects won¹t themselves be
checking these things in so the chances of these getting flagged should be
low.

As a more practical example I had a recent case where I was working
through an analysis on some Hadoop related code my company is considering
open sourcing which is primarily a collection of implementations of
InputFormat and OutputFormat.  A good number of our code files were
flagged as potential matches and when reviewed the only similarity was
that we had the same set of imports as many other Hadoop ecosystem
projects.  This is of course exacerbated by the fact that many developers
use IDEs which organise their imports!  So I had to spend several hours
checking each file and ticking boxes in Protex to say that this was
original code and not plagiarised.

I would definitely recommend carrying out a POC and seeing what people
make of it but be aware that it can be a painful and time consuming
process.

If the tool is indeed Protex then being familiar with it I would be
willing to help out with a POC

Cheers,

Rob

On 31/03/2014 01:52, Roman Shaposhnik r...@apache.org wrote:

Hi!

a few recent discussions around IP management
in the Incubator have lead to an interesting dialogue
between the fine folks from Black Duck Software and
yours truly.

The main ides here is that, perhaps, Black Duck
services can be as helpful to the open source
communities as the ones provided by the likes
of free Coverity scans.

Of course, the best way to assess how much value
this potential collaboration can bring to the ASF
projects is to run a POC and see for ourselves.
Also, I think, if there's a single place in the ASF that
would benefit the most from additional pair of eyes
looking for potential IP related issues that would be
incubating projects.

Hence, I'd like to propose that we do just that: run
a POC on a couple of projects identified by the
Incubator community. I will be the central contact
person for this, but I'd very much appreciate folks
volunteering to help.

This thread aims at three things:
1. collecting general feedback on whether
this is a good or bad idea.

2. folks volunteering to help with the POC
(if needed).

3. folk suggesting Incubator projects
for the first POC that we run with Black Duck.

Please share your thoughts and feedback!

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: Github pull request hooks

[Rob Vesse]

Sergio

You have to manually edit a file in the private committers area of the
Apache SVN repo. The specific file you need to edit and how to edit it was
detailed in an email from Noah Slater that went out on the committers@a.o
list on 20th January.  It's a private list so I am avoiding mentioning
specific details on a public list.

Once you add the mapping it takes a while for Infra to get round to
updating the organisation but it will eventually happen.

Also I found that in order for my Apache commits in the GitHub mirrors of
Apache repositories to which I contribute to show up on my personal
profile I had to add my Apache email as an email address to my GitHub
profile

Rob

On 10/02/2014 15:03, Sergio Fernández
sergio.fernan...@salzburgresearch.at wrote:

BTW, where is the mapping file between asf ids and github ones?
I've seen some members of the apache organization there, but it looks
there were manually added or so.
Thanks!

On 10/02/14 16:01, Sergio Fernández wrote:
 On 10/02/14 14:49, Daniel Gruno wrote:
 I would suggest you create a new JIRA ticket with this _wish_ and label
 is as Git+Wilderness, and I'll try to figure out whether we can support
 this or not.

 I'd prefer it does not create new issues in Jira.

 What currently it does, post a comment if any issue is referenced, is
 enough. See for example:

 
https://issues.apache.org/jira/browse/INFRA-7289?focusedCommentId=1389662
6page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#c
omment-13896626



-- 
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernan...@salzburgresearch.at
http://www.salzburgresearch.at

-
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: Instead of a Bill how about a Booklet? (was Re: [DISCUSS] PodlingBillOfRights)

[Rob Vesse]

+1

Having also come to Apache by joining a now graduated podling (Apache
Jena) I like the idea of a What to expect document and agree with pretty
much everything that you lay out here.  I think people outside of Apache
often don't appreciate how a volunteer organization operates and many of
your points describe this in terms new folks can understand, as you
highlight Apache is not that different from many other organizations in
many respects.


I would suggest maybe adding a further point emphasizing the time aspect
you raised in your previous email

4A) Don't forget that people here are geographically distributed and may
be in very different timezones.  There may be a significant lag between
sending a communication and the intended recipient(s) even reading it, yet
alone having the time to actually act upon it.  A communication sent first
thing in the morning in your timezone may arrive in the middle of the
night for the recipient(s) so be prepared to wait for a response.

I think those of us who work in the US or for multi-national companies get
used to dealing with timezones and tend to forget that a lot of people
come from countries where there is only one timezone.

Rob

On 6/20/13 9:22 AM, Alex Harui aha...@adobe.com wrote:

Hi,  As a newbie, I've generally quietly watched from the sidelines, but
now I'm jumping in.

+1 about expectations vs rights.  In fact, it occurred to me that a
booklet or pamphlet more like the What to expect whenŠ book would be
better.  IMO, correctly set expectations make for happier people.  Here is
my draft of  What to expect when you enter the Apache Incubator.

1)  Apache is staffed by volunteers, and a few paid, but overworked IT
folks known as Infra.  As such, there is a very good chance that you will
get different answers from different respondents, and responses may be
delayed.  This is not like your paid corporate job where there is
administration and infrastructure whose mind-share is fully dedicated to
serving you.
2) Apache has been around long enough and is large enough to have its own
culture, with its own societal rules and tribal history.   Lots of it is
written down, but it is hard to find.  Try to remember the last time you
started at a new company or team or club and how, even though there were
documents to read, there was always important stuff that you had to learn
some other way.  Apache is no different, but with volunteers, even less is
written down, and people's recollections of history can vary widely and
nobody is paid to serve your needs except Infra which is overloaded.
3) Some folks are quiet, some are noisy, some complain, some are
optimistic.  If you've worked on a large team, you've probably found this
to be true on that team as well.  Success usually comes from finding out
which folks you deal with are of which personality type, and how best to
work with those people.
4) Often you just have to be patient.  Pick your battles.  Prioritize your
needs.  Ask politely once for really important things, then plead again a
few days later.
5) Learn how to use an internet search engine.  Try to find information
before you ask.  The results may be hard to understand or confusing and be
careful about reading snippets without taking in some of the larger
context.  But then your question will be better defined.  Bonus if you can
quote a web page as part of your question.
6) Some folks want there to be a bill of rights, but you don't have any
rights because there are no authority figures at Apache to enforce those
rights.  Any violations have to be dealt with socially.  You can seek
help from the IPMC or even the board, but even they are volunteers and
will try to address the problem socially as well.  You can expect and
demand respectful discourse, but sometimes tempers will boil over.  That
happens in many workplaces, homes and other gatherings of people.  Expect
it here as well, even more so sometimes, as there are relatively few
face-to-face encounters to encourage civility and limit chances of
mis-interpretation.
7) Your mentors may get too busy to follow the details of activity in your
podling.  Use the [MENTOR] tag in the subject to try to catch their
attention.  Escalate to the Incubator IPMC if they still don't have time
to respond.
8) Embrace diversity.  Every podling is a little bit different and your
new podling may not exactly match up against existing documentation or
prior history.  Ask for guidance, keep in mind that answers may vary, and
make your decision keeping these things in mind.
A) The primary goal is to cover your and Apache's butt legally.  This may
require you to change build scripts and release packages in  a way that is
painful for you and your customers.
B) Apache only officially releases source code.  This may be a pain point
for any existing customers used to downloading binary packages.
C) At Apache, open source isn't just about making released source code
available.  It is about trying to get the community involved early 

Incubator Write Access

[Rob Vesse]

Could someone please grant me write access to the Incubator wiki

My username is RobVesse

Thanks,

Rob

Re: Instead of a Bill how about a Booklet? (was Re: [DISCUSS] PodlingBillOfRights)

[Rob Vesse]

I have written up the suggestions so far into a wiki page

https://wiki.apache.org/incubator/WhatToExpect

The content is pretty much what has been included in this thread
reorganized with a few minor grammar tweaks here and there.

If people like this notion feel free to edit the page or continue
discussing here

Rob


On 6/20/13 12:22 PM, Upayavira u...@odoko.co.uk wrote:

11. In certain circumstances, there are specific people charged with
certain responsibilities. Over time you can expect to learn who they
are, and where they hang out. Your mentor should be able to guide you
while you do learn. If, for whatever reason, they are unable or
unwilling to, you can ask on the incubator general list. If the optic is
too sensitive to discuss in public (eg a potential committer) you may
contact the incubator ombudsman at x...@apache.org.

Upayavira

On Thu, Jun 20, 2013, at 05:40 PM, Rob Vesse wrote:
 +1
 
 Having also come to Apache by joining a now graduated podling (Apache
 Jena) I like the idea of a What to expect document and agree with
 pretty
 much everything that you lay out here.  I think people outside of Apache
 often don't appreciate how a volunteer organization operates and many of
 your points describe this in terms new folks can understand, as you
 highlight Apache is not that different from many other organizations in
 many respects.
 
 
 I would suggest maybe adding a further point emphasizing the time aspect
 you raised in your previous email
 
 4A) Don't forget that people here are geographically distributed and may
 be in very different timezones.  There may be a significant lag between
 sending a communication and the intended recipient(s) even reading it,
 yet
 alone having the time to actually act upon it.  A communication sent
 first
 thing in the morning in your timezone may arrive in the middle of the
 night for the recipient(s) so be prepared to wait for a response.
 
 I think those of us who work in the US or for multi-national companies
 get
 used to dealing with timezones and tend to forget that a lot of people
 come from countries where there is only one timezone.
 
 Rob
 
 On 6/20/13 9:22 AM, Alex Harui aha...@adobe.com wrote:
 
 Hi,  As a newbie, I've generally quietly watched from the sidelines,
but
 now I'm jumping in.
 
 +1 about expectations vs rights.  In fact, it occurred to me that a
 booklet or pamphlet more like the What to expect whenŠ book would be
 better.  IMO, correctly set expectations make for happier people.
Here is
 my draft of  What to expect when you enter the Apache Incubator.
 
 1)  Apache is staffed by volunteers, and a few paid, but overworked IT
 folks known as Infra.  As such, there is a very good chance that you
will
 get different answers from different respondents, and responses may be
 delayed.  This is not like your paid corporate job where there is
 administration and infrastructure whose mind-share is fully dedicated
to
 serving you.
 2) Apache has been around long enough and is large enough to have its
own
 culture, with its own societal rules and tribal history.   Lots of it
is
 written down, but it is hard to find.  Try to remember the last time
you
 started at a new company or team or club and how, even though there
were
 documents to read, there was always important stuff that you had to
learn
 some other way.  Apache is no different, but with volunteers, even
less is
 written down, and people's recollections of history can vary widely and
 nobody is paid to serve your needs except Infra which is overloaded.
 3) Some folks are quiet, some are noisy, some complain, some are
 optimistic.  If you've worked on a large team, you've probably found
this
 to be true on that team as well.  Success usually comes from finding
out
 which folks you deal with are of which personality type, and how best
to
 work with those people.
 4) Often you just have to be patient.  Pick your battles.  Prioritize
your
 needs.  Ask politely once for really important things, then plead
again a
 few days later.
 5) Learn how to use an internet search engine.  Try to find information
 before you ask.  The results may be hard to understand or confusing
and be
 careful about reading snippets without taking in some of the larger
 context.  But then your question will be better defined.  Bonus if you
can
 quote a web page as part of your question.
 6) Some folks want there to be a bill of rights, but you don't have
any
 rights because there are no authority figures at Apache to enforce
those
 rights.  Any violations have to be dealt with socially.  You can
seek
 help from the IPMC or even the board, but even they are volunteers and
 will try to address the problem socially as well.  You can expect and
 demand respectful discourse, but sometimes tempers will boil over.
That
 happens in many workplaces, homes and other gatherings of people.
Expect
 it here as well, even more so sometimes, as there are relatively few
 face-to-face encounters to encourage civility and limit

Re: [PROPOSAL] OData Proposal for Incubator

[Rob Vesse]

Stephan

What overlap (if any) do you see with the existing Marmotta podling?

They are building out an implementation of the Linked Data Platform which
is a ongoing W3C standardization effort
(http://www.w3.org/2012/ldp/wiki/Main_Page) and can be thought of as a
more RDF/Semantic Web centric alternative to the MS/Oasis OData standard.

Rob


On 6/17/13 8:35 AM, Klevenz, Stephan stephan.klev...@sap.com wrote:

Dear ASF members,

We would like to propose the OData project to the Incubator.

The OData Proposal is available at:
https://wiki.apache.org/incubator/ODataProposal

We welcome your feedback and suggestions.

Thanks!

Stephan Klevenz



= Apache OData =

=== Abstract ===

Apache OData is a generic Java language implementation of the OData 2.0
specification which will serve as a code base for the upcoming OASIS
OData specification.

=== Proposal ===

The Open Data Protocol (OData) [1] is a Web protocol for querying and
updating data that provides a way to unlock your data and free it from
silos that exist in applications today. OData does this by applying and
building upon Web technologies such as HTTP, Atom Publishing Protocol
(AtomPub) and JSON to provide access to information from a variety of
applications, services, and stores.

The Apache OData is a library which enables developers to implement OData
producers and OData consumers. Basic principles of the library are to
provide an OData 2.0 specification compliant OData Library, enhancements
shall be possible in a compatible manner, have a clear separation between
Core and API, to provide an option to build extensions on top. This
library should be base for implementing future releases of the
specification.

=== Background ===

OData was originally developed by Microsoft and is released in a version
2.0 under an Open Specification Promise [2]. A lot of companies did show
interests in this protocol, used it in products and gave feedback back to
Microsoft. This joined effort resulted in a new release OData 3.0 in
2012, this version became the basis for the OASIS technical committee [3]
which is currently working on a new version of the specification. This
OASIS standard release is expected this year.

The initial Java code of this project was developed by a development team
that had already experience with other OData 2.0 and 3.0 implementations
at SAP AG. The current code base implements OData 2.0 and because of this
version is widely used it is a good starting point to build an open
source community for the OData standard.

The current code also comes up with an implementation of an OData sample
service. On the one side this is an example for users which want to use
the library to expose their own data and on the other side it illustrates
how implemented features work.

Additionally, the code base includes an extension which is called JPA
processor. With this extension it is easy to expose any JPA persistence
model via OData protocol without a lot of coding.

=== Rationale ===

More software vendors moving to OData means more choice for customers who
will be able to use different implementations. For the standard to
succeed, however, ensuring interoperability is paramount: in order to
manage an ever growing context and leverage the enormous portability and
interoperability issues that a globally adopted standard brings, it is
necessary to think about how to make the related ecosystem healthy and
sustainable. Successful modern standards are driven by:

 * Clear documentation, built iteratively with continuous feedback from
stakeholders
 * A clearly defined compatibility process, enforced by tools that allow
to gauge how implementations can be compatible and interoperable
 * Accurate compliance criteria, documented in writing as well as in
actual testing code that measure how tools and libraries are able to
interoperate
 * A sample implementation to clear up potential doubts and ensure that
the standard can actually be implemented in real life scenarios

The above mentioned pieces are able to make the development activity,
towards an OData implementation, easier and more successful. Having an
healthy ecosystem will ensure a smoother implementation process, more
compliant products, and ultimately, a wider adoption of the standard.

The OData ecosystem has been successful in creating and documenting early
versions of the standard, yet it might potentially lack two very
important aspects, that is a exhaustive implementation of the complete
protocol that can be used productively and to ensure interoperability. As
much as such artifacts can be developed independently by any OData
proponent, the value of having a neutral party as a steward of actual
code is to be considered. The Apache Software Foundation has been playing
this kind of role for many years, and can provide the perfect environment
to foster contributions on the OData theme with a great amount of
expertise.

=== Initial Goals ===

 * Implement OData 2.0, make it final and mature
 * Start