[ANNOUNCE] Apache Apex Malhar Release 3.2.0-incubating released

[Thomas Weise]

The Apache Apex community is pleased to announce release 3.2.0-incubating
of the Malhar Library.

Changes:
https://github.com/apache/incubator-apex-malhar/blob/v3.2.0-incubating/CHANGELOG.md

Apache Apex is an enterprise grade native YARN big data-in-motion platform
that unifies stream processing as well as batch processing. Apex was built
for scalability and low-latency processing, high availability and
operability.

Apache Apex is Java based and strives to ease application development on a
platform that takes care of aspects such as stateful fault tolerance,
partitioning, processing guarantees, buffering and synchronization,
auto-scaling etc. Apex comes with Malhar, a rich library of pre-built
operators, including adapters that integrate with existing technologies as
sources and destinations, like message buses, databases, files or social
media feeds.

The source release can be found at:

http://www.apache.org/dyn/closer.lua/incubator/apex/malhar/v3.2.0-incubating/malhar-3.2.0-incubating-source-release.tar.gz

or visit:

http://apex.incubator.apache.org/downloads.html

We welcome your help and feedback. For more information on the project and
how to get involved, visit our website at:

http://apex.incubator.apache.org/

Regards,
The Apache Apex community


Disclaimer:
Apache Apex is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the Apache Incubator PMC.
Incubation is required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making
process
have stabilized in a manner consistent with other successful ASF projects.
While incubation status is not necessarily a reflection of the completeness
or stability of the code, it does indicate that the project has yet to be
fully endorsed by the ASF.

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

[Chris Nauroth]

Some projects use the git Signed-off-by field in the commit log to
differentiate the author from the reviewer.

--Chris Nauroth




On 11/19/15, 10:58 AM, "Ralph Goers"  wrote:

>And there is another problem I have. Maybe it isn¹t true of all projects,
>but the one I am involved with says the author can¹t commit his own code.
>So the commit logs will not reflect who actually authored the code but
>who reviewed it. 
>
>I could probably tolerate RTC if I had to have the commit somewhere it
>could be reviewed, I had to wait for the review and fix any defects and
>then could commit the code myself (ideally even if no one actually
>reviewed it). That process isn¹t really much different than what I do for
>my larger commits anyway. But just submitting something for review and
>then hoping someone reviews it and then hoping someone commits it takes
>all the joy out of it for me.
>
>Ralph
>
>> On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
>> 
>> 
>> Sure, that's a big problem with some RTC workflows. Using gerrit or
>>github
>> PRs makes the flow much easier -- for a trivial or small patch, the sort
>> that a "drive-by" contributor typically contributes, there probably
>>won't
>> be any review comments. So, they just push the patch for review, and
>>they
>> can be out of the loop for the rest of it. If the patch requires small
>> revisions (eg addressing a typo or something) I think it's fine for the
>> reviewer to just make the change themselves and commit on behalf of the
>> original author to avoid the issue you've raised. Most RTC workflows
>>permit
>> this kind of thing in my experience.
>
>
>
>-
>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

Spark-Kernel naming & mentors

[David Fallside]

There seems to be a consensus here that the Spark-Kernel name should change, and
so I think the Spark-Kernel team can generate a new name that does not contain
"Spark" or "Kernel". This will ensure it is not perceived as necessarily being a
core part of Spark or as having a primary association with Jupyter or Notebooks.
It also sounds like we should create a new name before entering incubation to
minimize expectations during incubation and to ensure nothing gets baked into
class hierarchies and the like.
With regard mentors, the project would be very well served by the three people
who have offered -- Julien, Hitesh, and Reynold -- thank you!
David

Re: [graduation] Maturity model-based assessment of Groovy for its graduation

[Bertrand Delacretaz]

Hi,

On Thu, Oct 15, 2015 at 5:46 AM, Bertrand Delacretaz
 wrote:
> FYI I have started an experiment at
> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
> using our maturity model to evaluate Groovy...

Groovy graduated now and doesn't have a good place to keep that
document, so I'm pasting it below in case other podlings want to use
it as an example.

It will also stay at

https://github.com/apache/incubator-groovy/blob/576b3c5d6a7022ac4a8df1ef118666456ce627fb/MATURITY.adoc

-Bertrand

 GROOVY MATURITY *

= Groovy Podling Maturity Assessment

== Overview

This is an assessment of the Groovy podling's maturity, meant to help inform
the decision (of the mentors, community, Incubator PMC and ASF Board of
Directors) to graduate it as a top-level Apache project.

It is based on the ASF project maturity model at
https://community.apache.org/apache-way/apache-project-maturity-model.html

Maintaining such a file is a new, experimental idea as part of the continuous
improvement of the ASF incubation process. Groovy is the first podling where
that happens.

== Status of this document
All open items resolved, ready for PPMC approval voting.

== Overall assessment
All the below items are marked OK, Groovy looks ready to graduate,
discussions and votes
are ongoing on the project's dev list as I write this (October 2015).

== Maturity model assessment
Mentors and community members are encouraged to contribute to this
and comment on it.

=== Code

 CD10
_The project produces Open Source software, for distribution to the
public at no charge._

OK: of course.

 CD20
_The project's code is easily discoverable and publicly accessible._

OK: http://groovy-lang.org/ (see CO10) includes a "fork me on Github" banner.

 CD30
_The code can be built in a reproducible way using widely available
standard tools._

OK: the build uses Gradle and continuous integration is used.

 CD40
_The full history of the project's code is available via a source code
control system, in a way that allows any released version to be
recreated._

OK: Using Git, main repository at
https://git-wip-us.apache.org/repos/asf/incubator-groovy.git, releases
are cut
from that repository.

 CD50
_The provenance of each line of code is established via the source
code control system, in a reliable way based on strong authentication
of the committer.
When third-party contributions are committed, commit messages provide
reliable information about the code provenance._

OK, see CD40

=== Licenses and Copyright

 LC10
_The code is released under the Apache License, version 2._0._

OK, LICENSE file has been accepted in release votes.

 LC20
_Libraries that are mandatory dependencies of the project's code do
not create more restrictions than the Apache License does._

OK: The list of dependencies at
https://wiki.apache.org/incubator/GroovyProposal has been verified
when entering incubation.

The current dependency licenses (including build, runtime and optional
dependencies) are found at
https://github.com/apache/incubator-groovy/tree/master/licenses

Assembling the licenses depending on the artifacts is done here:
https://github.com/apache/incubator-groovy/blob/master/gradle/assemble.gradle
so that the various artifacts get their correct sets of licenses.

Release reviews have not shown any incompatible licenses.

 LC30
_The libraries mentioned in LC20 are available as Open Source software._

OK, see LC20

 LC40
_Committers are bound by an Individual Contributor Agreement (the
"Apache iCLA") that defines which code they are allowed to commit and
how they need to identify code that is not their own._

OK, all committers have iCLAs on file.

 LC50
_The copyright ownership of everything that the project produces is
clearly defined and documented._

OK, obvious for an ASF project.

=== Releases

 RE10
_Releases consist of source code, distributed using standard and open
archive formats that are expected to stay readable in the long term._

OK, verified in release votes.

 RE20
_Releases are approved by the project's PMC (see CS10), in order to
make them an act of the Foundation._

OK, releases have been voted by the Incubator PMC.

 RE30
_Releases are signed and/or distributed along with digests that can be
reliably used to validate the downloaded archives._

OK, verified in release votes.

 RE40
_Convenience binaries can be distributed alongside source code but
they are not Apache Releases -- they are just a convenience provided
with no guarantee._

OK: 
https://dist.apache.org/repos/dist/release/incubator/groovy/2.4.5-incubating/
for example clearly differentiates
between source releases and distributions.

=== Quality

 QU10
_The project is open and honest about the quality of its code. Various
levels of quality and maturity for various modules are natural and
acceptable as long as they are clearly communicated._

OK, Groovy has a long history of being a 

Re: [DISCUSS] S2Graph Incubator Proposal

[Stack]

On Wed, Nov 18, 2015 at 5:04 PM, Hyunsik Choi  wrote:

> Thank you very much Stack! It definitely looks better than just wiki.
> It would be helpful to improve the proposal.
>
>
To be clear, proposal needs to be on the wiki. I just moved it over so I
could show my edits as 'suggested' rather than change the original. Take
whatever edits you think improve the proposal and then apply them to the
wiki.
St.Ack




> Best regards,
> Hyunsik
>
> On Tue, Nov 17, 2015 at 10:20 PM, Stack  wrote:
> > Glad to see s2graph being put up as an incubator project.
> >
> > Here [1] are some suggested edits to try and help strengthen the proposal
> > before it goes up for a vote. Hopefully they help.
> >
> > St.Ack
> > 1.
> >
> https://docs.google.com/document/d/19iNc0u_-9ogb0kDC-WnLoWWg9J_LFeuSGB8GF_rQfEs/edit?usp=sharing
> >
> > On Tue, Nov 17, 2015 at 3:59 PM, Hyunsik Choi 
> wrote:
> >
> >> Thank you Henry. Yes, we already had enough time to discuss the
> >> S2Graph proposal. I'll make a vote thread soon.
> >>
> >> Best regards,
> >> Hyunsik
> >>
> >> On Tue, Nov 17, 2015 at 2:22 PM, Henry Saputra  >
> >> wrote:
> >> > Looks like we have positive responses. I think it is time for VOTE
> >> thread :)
> >> >
> >> > On Friday, November 6, 2015, Hyunsik Choi  wrote:
> >> >
> >> >> Hi folks,
> >> >>
> >> >> We would like to start a discussion on S2Graph as an incubation
> project.
> >> >>
> >> >> S2Graph is a distributed and scalable OLTP graph database built on
> >> >> HBase. It provides interactive queries for vertex/edge/sub-graphs on
> >> >> extremely large graph data sets as well as insertion and update
> >> >> operations.
> >> >>
> >> >> S2Graph was already introduced in Apache BigData and HBaseCon this
> year.
> >> >>
> >> >> The proposal is available at :
> >> >> https://wiki.apache.org/incubator/S2GraphProposal
> >> >>
> >> >> We are looking forward to any feedback. In addition, we are looking
> >> >> for volunteers as mentors.
> >> >>
> >> >> Best regards,
> >> >> Hyunsik
> >> >>
> >> >> -
> >> >> 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: RTC vs CTR (was: Concerning Sentry...)

[Ralph Goers]

And there is another problem I have. Maybe it isn’t true of all projects, but 
the one I am involved with says the author can’t commit his own code. So the 
commit logs will not reflect who actually authored the code but who reviewed 
it. 

I could probably tolerate RTC if I had to have the commit somewhere it could be 
reviewed, I had to wait for the review and fix any defects and then could 
commit the code myself (ideally even if no one actually reviewed it). That 
process isn’t really much different than what I do for my larger commits 
anyway. But just submitting something for review and then hoping someone 
reviews it and then hoping someone commits it takes all the joy out of it for 
me.

Ralph

> On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
> 
> 
> Sure, that's a big problem with some RTC workflows. Using gerrit or github
> PRs makes the flow much easier -- for a trivial or small patch, the sort
> that a "drive-by" contributor typically contributes, there probably won't
> be any review comments. So, they just push the patch for review, and they
> can be out of the loop for the rest of it. If the patch requires small
> revisions (eg addressing a typo or something) I think it's fine for the
> reviewer to just make the change themselves and commit on behalf of the
> original author to avoid the issue you've raised. Most RTC workflows permit
> this kind of thing in my experience.



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

Re: [VOTE] Release Apache Myriad 0.1.0 (incubating)

[Santosh Marella]

Thanks Justin and John for trying out the RC and providing feedback.

We'll prepare a new RC with the changes you suggested, call for a PPMC vote
and submit the RC for IPMC voting.

Regards,
Santosh

On Wed, Nov 18, 2015 at 5:00 PM, John D. Ament 
wrote:

> Could you include some build instructions? Got this error trying ./gradlew
> build
>
> Could not resolve all dependencies for configuration
> ':myriad-scheduler:compile'.
>
> > Could not find zookeeper-tests.jar
> (org.apache.zookeeper:zookeeper:3.4.6).
>
>   Searched in the following locations:
>
>
>
> file:/Users/johnament/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar
>
>
>
> On Mon, Nov 16, 2015 at 8:48 PM Santosh Marella 
> wrote:
>
> > Hi,
> >
> > The Apache Myriad community has voted on and approved a proposal to
> release
> > Apache Myriad 0.1.0-incubating.
> >
> > Vote call:
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-myriad-dev/201511.mbox/%3CCAGim3%2B2fFCE4LC7HpNPtg5r7_01sFzkfLsyGaLvXcV%2B6f-_CRg%40mail.gmail.com%3E
> >
> > Vote result:
> > 3 binding +1 votes
> > 4 non-binding +1 votes
> > No -1 votes
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-myriad-dev/201511.mbox/%3CCAGim3+3BSP=o1ZoJZq3mau-nFd7CGP1y+mRE9cOdXKpPAm=e...@mail.gmail.com%3E
> >
> > Release Notes:
> > https://cwiki.apache.org/confluence/display/MYRIAD/Release+Notes
> >
> > The commit to be voted upon is tagged with "myriad-0.1.0-incubating-rc2"
> > and is available here:
> >
> >
> https://git1-us-west.apache.org/repos/asf/incubator-myriad/repo?p=incubator-myriad.git;a=commit;h=fb93291e9377cccf625bed93a9ad1ae1c4b76529
> >
> > The artifacts to be voted upon are located below. Please note that this
> is
> > a source release:
> >
> >
> https://dist.apache.org/repos/dist/dev/incubator/myriad/myriad-0.1.0-incubating-rc2/
> >
> > Release artifacts are signed with the following key:
> > https://people.apache.org/keys/committer/smarella.asc
> >
> > We request the permission of IPMC to publish the above release candidate
> as
> > Apache Myriad 0.1.0-incubating. Please try out the package and vote.
> >
> > The vote is open for a minimum of 72 hours or until the necessary number
> of
> > votes (3 binding +1s) is reached.
> >
> > [ ] +1 Release this package as Apache Myriad 0.1.0-incubating
> > [ ]  0 I don't feel strongly about it, but I'm okay with the release
> > [ ] -1 Do not release this package because...
> >
> > Please add (binding) if your vote is binding.
> >
> > Thanks,
> > Santosh
> > (On behalf of Apache Myriad PPMC)
> >
>

Re: Project Website Template

[Luciano Resende]

On Sat, Nov 7, 2015 at 6:40 PM, Luciano Resende 
wrote:

>
>
>
> On Sat, Nov 7, 2015 at 7:35 PM, Julian Hyde  wrote:
>
>> +1
>>
>> I had the same thought when I built Calcite’s site based on jekyll
>> (actually cloned from Orc’s site). Thanks for making this template — I’m
>> sure it will be helpful to new projects.
>>
>> We should make it clear that it is optional, of course. But when Calcite
>> entered the incubator there were entirely too many choices (and
>> opportunities to make mistakes). The whole svnpubsub vs cms question, for
>> instance, delayed our web site by about 6 months because we weren’t sure
>> whether we could backtrack once we had made a decision. So I think it would
>> be useful if there were some default choices to get incubator projects off
>> and running quickly.
>>
>
> Exactly, it will be optional, and the goal is to document exactly what a
> new project (and sometimes a completely new community) needs to do to get
> the website up and running, including the whole workflow, and what to
> request from infra.
>
>
>>
>> I also think it would be useful to provide a template for maven/java
>> based projects. There would be a pom.xml, module/pom.xml and
>> module/org/apache/foo/Foo.java, and just enough content in the pom.xml to
>> be able to make a release by typing “mvn release:prepare … mvn
>> release:perform”. If anyone is interested I’ll do it.
>>
>
> I believe this is already available if your "parent pom" inherit from
> "apache pom".
> See: http://svn.apache.org/repos/asf/maven/pom/tags/apache-17/
>
>
>>
>> Luciano, Did you have a place in mind to put your template site? I think
>> it would need to be in an apache project, not in github, so that any
>> podling can import it without worrying about IP contamination.
>>
>>
> I was thinking on a git repository owned by incubator. It would be
> mirrored in github mostly for the simplification of collaboration via PR.
>
> When a new projects comes in, it would request a new website git as a fork
> from the template, so that in the future it would be able to cherry-pick
> enhancements or fixes from upstream.
>
>
>> Julian
>>
>>
>>
> Thoughts ?
>
>
>

The strawman of the template is available in the newly created git
repository
https://git-wip-us.apache.org/repos/asf/apache-website-template.git

I am using it to actually create the SystemML podling, so you can see a
live example of the results at
http://systemml.apache.org/

I'll start to document how to go about forking and using the template for a
new podling.

Suggestions, PRs, etc are welcome

-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: Project Website Template

[Julian Hyde]

> On Nov 19, 2015, at 5:42 PM, Luciano Resende  wrote:
> 
> The strawman of the template is available in the newly created git
> repository
> https://git-wip-us.apache.org/repos/asf/apache-website-template.git


And mirrored at https://github.com/apache/apache-website-template 
, I see. It could use 
LICENSE and NOTICE files (including appropriate remarks about the included 
non-ASL files), a README, and headers on all files. I’ll start creating PRs at 
github.

Julian

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

[Greg Stein]

Trick question, as I'd never work under that model :-)

Apache Subversion is CTR, with a very low bar to get commit access to
portions of the tree or a branch (only PMC members get access to whole
tree, so we grant full access and PMC membership simultaneously). We don't
need a fancy label for "contributor who is a committer" because such a
concept is anathema to the Subversion community's peer respect model.

On Thu, Nov 19, 2015 at 6:38 PM, Ralph Goers 
wrote:

> Greg, which of these do you use when the “contributor” is a committer?
> Remember the model here is that the author is never allowed to commit their
> own code.
>
> Ralph
>
> > On Nov 19, 2015, at 3:10 PM, Greg Stein  wrote:
> >
> > The Apache Subversion project does something similar:
> >
> >
> http://subversion.apache.org/docs/community-guide/conventions.html#crediting
> >
> > We have a tool ("contribulyzer") that analyzes them. It's pretty neat.
> > On Nov 19, 2015 1:57 PM, "Chris Nauroth" 
> wrote:
> >
> >> Some projects use the git Signed-off-by field in the commit log to
> >> differentiate the author from the reviewer.
> >>
> >> --Chris Nauroth
> >>
> >>
> >>
> >>
> >> On 11/19/15, 10:58 AM, "Ralph Goers" 
> wrote:
> >>
> >>> And there is another problem I have. Maybe it isn¹t true of all
> projects,
> >>> but the one I am involved with says the author can¹t commit his own
> code.
> >>> So the commit logs will not reflect who actually authored the code but
> >>> who reviewed it.
> >>>
> >>> I could probably tolerate RTC if I had to have the commit somewhere it
> >>> could be reviewed, I had to wait for the review and fix any defects and
> >>> then could commit the code myself (ideally even if no one actually
> >>> reviewed it). That process isn¹t really much different than what I do
> for
> >>> my larger commits anyway. But just submitting something for review and
> >>> then hoping someone reviews it and then hoping someone commits it takes
> >>> all the joy out of it for me.
> >>>
> >>> Ralph
> >>>
>  On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
> 
> 
>  Sure, that's a big problem with some RTC workflows. Using gerrit or
>  github
>  PRs makes the flow much easier -- for a trivial or small patch, the
> sort
>  that a "drive-by" contributor typically contributes, there probably
>  won't
>  be any review comments. So, they just push the patch for review, and
>  they
>  can be out of the loop for the rest of it. If the patch requires small
>  revisions (eg addressing a typo or something) I think it's fine for
> the
>  reviewer to just make the change themselves and commit on behalf of
> the
>  original author to avoid the issue you've raised. Most RTC workflows
>  permit
>  this kind of thing in my experience.
> >>>
> >>>
> >>>
> >>> -
> >>> 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] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)

[Justin Mclean]

Hi,

> 1. HP donated the Trafodion code to Apache several months ago.  We have gone
> through all the legal steps to get the code donated.  As part of this
> process we removed all the HP copyrights except for our test files and
> documentation.  Do we have to remove all the Copyrights in order to release
> in Apache?

My understanding If the code was donated to the ASF it’s now copyright the ASF 
not HP.

>  Is including HP in the NOTICE/LICENSE file adequate?

Yes that's needed as well. [1]

> 2. A conscious decision was made to add the latest Apache license to files
> that have existing licenses. So now multiple licenses are showing up.

Each file should have a single license header showing who owns the copyright. 
BTW rat doesn’t pick up on this.

>  The original license came when the code was first used by the product.

If the code come from another project then HP probably didn't own the 
copyright. If the original code is Apache licensed then you usually don’t need 
to add anything to LICENSE [2], but if the software where it come from has a 
NOTICE file you may need to add something to your NOTICE files [2]. all other 
permissive licenses need to be added to LICENSE [3].

> 3.   We have followed the instructions detailed in [8] but it looks like we
> are missing a mention of this in our README file.

I’m not familiar with the process but you might want to look at what the HTTP 
project does in their README [2].

> 4.  We do have permission to use the photos in [13] [14].  Is there
> something we need to do to indicate this somewhere?

From the original people who took the photos? (Just because they were in the 
donation from HP doesn’t mean you have permission to use and distribute them.) 
Both of the photos look professional to me. How are they licensed? Does the 
photos metadata include license or copyright information? Usually that info 
would go in LICENSE. 

> 5. You mentioned that we may be too generous in excluding files for our RAT
> test. 

Just because of the number of issues it may be that you’re not checking all the 
files you shod be. I didn’t look in detail.

> 6. Justin, can we get accessibility to some of the scripts you ran to check
> for these incompatibilities? 

Noting fancy script wise just rat and this:

find . -type f -exec grep “XXX" {} \; -print

Where XXX is “Copyright”, “ MIT “, “BSD”, “GPL” etc. Sometimes I pipe to a 
couple of grep -v ’s to reduce the noise.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#mod-notice
2. http://www.apache.org/dev/licensing-howto.html#alv2-dep
3. http://www.apache.org/dev/licensing-howto.html#permissive-deps
3. https://github.com/apache/httpd/blob/trunk/README


-
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...)

[Ralph Goers]

Greg, which of these do you use when the “contributor” is a committer? Remember 
the model here is that the author is never allowed to commit their own code.

Ralph

> On Nov 19, 2015, at 3:10 PM, Greg Stein  wrote:
> 
> The Apache Subversion project does something similar:
> 
> http://subversion.apache.org/docs/community-guide/conventions.html#crediting
> 
> We have a tool ("contribulyzer") that analyzes them. It's pretty neat.
> On Nov 19, 2015 1:57 PM, "Chris Nauroth"  wrote:
> 
>> Some projects use the git Signed-off-by field in the commit log to
>> differentiate the author from the reviewer.
>> 
>> --Chris Nauroth
>> 
>> 
>> 
>> 
>> On 11/19/15, 10:58 AM, "Ralph Goers"  wrote:
>> 
>>> And there is another problem I have. Maybe it isn¹t true of all projects,
>>> but the one I am involved with says the author can¹t commit his own code.
>>> So the commit logs will not reflect who actually authored the code but
>>> who reviewed it.
>>> 
>>> I could probably tolerate RTC if I had to have the commit somewhere it
>>> could be reviewed, I had to wait for the review and fix any defects and
>>> then could commit the code myself (ideally even if no one actually
>>> reviewed it). That process isn¹t really much different than what I do for
>>> my larger commits anyway. But just submitting something for review and
>>> then hoping someone reviews it and then hoping someone commits it takes
>>> all the joy out of it for me.
>>> 
>>> Ralph
>>> 
 On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
 
 
 Sure, that's a big problem with some RTC workflows. Using gerrit or
 github
 PRs makes the flow much easier -- for a trivial or small patch, the sort
 that a "drive-by" contributor typically contributes, there probably
 won't
 be any review comments. So, they just push the patch for review, and
 they
 can be out of the loop for the rest of it. If the patch requires small
 revisions (eg addressing a typo or something) I think it's fine for the
 reviewer to just make the change themselves and commit on behalf of the
 original author to avoid the issue you've raised. Most RTC workflows
 permit
 this kind of thing in my experience.
>>> 
>>> 
>>> 
>>> -
>>> 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: Kalumet retirement steps

[Hadrian Zbarcea]

I think the rest of the contributions come from Olivier Lamy another ASFer.

+1 to your your proposal for a resolution.

Cheers,
Hadrian

On 11/19/2015 04:21 PM, Marvin Humphrey wrote:

Thanks for speaking up, folks.

Based on the information in this thread, I plan to resolve the
copyright issue on Kalumet's podling status page with a resolution
date of today.

Technically, I have only received reassurances that the codebase is
"almost exclusively" work that originates with one individual who has
an ICLA on file; what we really need to know in order to check that
box is that *all* of the code without exception is OK.

If anyone objects to resolving the copyright issue, either because
they are aware of actual uncleared code within Kalumet's repo, or
because they are uncomfortable with my assumption that all the code is
clear, please say so.

Marvin Humphrey

On Thu, Nov 19, 2015 at 5:09 AM, Jean-Baptiste Onofré  wrote:

Hi Hadrian and Marvin,

I replied on the kalumet mailing list.

It's not a problem at all that the Kalumet's code remain on svn.

Sorry for the delay guys.

Regards
JB


On 11/19/2015 05:44 AM, Hadrian Zbarcea wrote:


Hi Marvin,

As far as I remember, Kalumet is almost exclusively the work of JB
Onofre who is an ASF member, therefore I don't see a problem.

That said I think it's best to wait a bit and let JB speak up. I cc'ed
him, just to make sure he notices this thread.

Cheers,
Hadrian

On 11/18/2015 05:29 PM, Marvin Humphrey wrote:


On Sun, Nov 15, 2015 at 6:56 PM, Marvin Humphrey
 wrote:


The copyright checkbox for Kalumet is marked with a question mark,
which I
interpret as "not checked off":

  http://incubator.apache.org/projects/kalumet#Copyright

A successful incubating release would have settled the issue, but I
did some
research and it seems that while the Kalumet podling attempted an
incubating
release of their 0.6 branch, it doesn't look like it was ever officially
completed.

If the copyright status cannot be resolved, I will have to delete
`trunk`,
`tags`, and `branches` from
.

Can someone provide a definitive answer on whether it is OK for
Kalumet's code
to remain visible in svn?



I'll give this a couple more days.  If no one has spoken up by then, I
will proceed with deleting the code from svn.

Marvin Humphrey

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



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

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



-
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: Spark-Kernel naming & mentors

[Luciano Resende]

On Thu, Nov 19, 2015 at 11:59 AM, David Fallside  wrote:

> There seems to be a consensus here that the Spark-Kernel name should
> change, and
> so I think the Spark-Kernel team can generate a new name that does not
> contain
> "Spark" or "Kernel". This will ensure it is not perceived as necessarily
> being a
> core part of Spark or as having a primary association with Jupyter or
> Notebooks.
> It also sounds like we should create a new name before entering incubation
> to
> minimize expectations during incubation and to ensure nothing gets baked
> into
> class hierarchies and the like.
> With regard mentors, the project would be very well served by the three
> people
> who have offered -- Julien, Hitesh, and Reynold -- thank you!
> David


+1

-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: Kalumet retirement steps

[Marvin Humphrey]

Thanks for speaking up, folks.

Based on the information in this thread, I plan to resolve the
copyright issue on Kalumet's podling status page with a resolution
date of today.

Technically, I have only received reassurances that the codebase is
"almost exclusively" work that originates with one individual who has
an ICLA on file; what we really need to know in order to check that
box is that *all* of the code without exception is OK.

If anyone objects to resolving the copyright issue, either because
they are aware of actual uncleared code within Kalumet's repo, or
because they are uncomfortable with my assumption that all the code is
clear, please say so.

Marvin Humphrey

On Thu, Nov 19, 2015 at 5:09 AM, Jean-Baptiste Onofré  wrote:
> Hi Hadrian and Marvin,
>
> I replied on the kalumet mailing list.
>
> It's not a problem at all that the Kalumet's code remain on svn.
>
> Sorry for the delay guys.
>
> Regards
> JB
>
>
> On 11/19/2015 05:44 AM, Hadrian Zbarcea wrote:
>>
>> Hi Marvin,
>>
>> As far as I remember, Kalumet is almost exclusively the work of JB
>> Onofre who is an ASF member, therefore I don't see a problem.
>>
>> That said I think it's best to wait a bit and let JB speak up. I cc'ed
>> him, just to make sure he notices this thread.
>>
>> Cheers,
>> Hadrian
>>
>> On 11/18/2015 05:29 PM, Marvin Humphrey wrote:
>>>
>>> On Sun, Nov 15, 2015 at 6:56 PM, Marvin Humphrey
>>>  wrote:
>>>
 The copyright checkbox for Kalumet is marked with a question mark,
 which I
 interpret as "not checked off":

  http://incubator.apache.org/projects/kalumet#Copyright

 A successful incubating release would have settled the issue, but I
 did some
 research and it seems that while the Kalumet podling attempted an
 incubating
 release of their 0.6 branch, it doesn't look like it was ever officially
 completed.

 If the copyright status cannot be resolved, I will have to delete
 `trunk`,
 `tags`, and `branches` from
 .

 Can someone provide a definitive answer on whether it is OK for
 Kalumet's code
 to remain visible in svn?
>>>
>>>
>>> I'll give this a couple more days.  If no one has spoken up by then, I
>>> will proceed with deleting the code from svn.
>>>
>>> Marvin Humphrey
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
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...)

[Greg Stein]

The Apache Subversion project does something similar:

http://subversion.apache.org/docs/community-guide/conventions.html#crediting

We have a tool ("contribulyzer") that analyzes them. It's pretty neat.
On Nov 19, 2015 1:57 PM, "Chris Nauroth"  wrote:

> Some projects use the git Signed-off-by field in the commit log to
> differentiate the author from the reviewer.
>
> --Chris Nauroth
>
>
>
>
> On 11/19/15, 10:58 AM, "Ralph Goers"  wrote:
>
> >And there is another problem I have. Maybe it isn¹t true of all projects,
> >but the one I am involved with says the author can¹t commit his own code.
> >So the commit logs will not reflect who actually authored the code but
> >who reviewed it.
> >
> >I could probably tolerate RTC if I had to have the commit somewhere it
> >could be reviewed, I had to wait for the review and fix any defects and
> >then could commit the code myself (ideally even if no one actually
> >reviewed it). That process isn¹t really much different than what I do for
> >my larger commits anyway. But just submitting something for review and
> >then hoping someone reviews it and then hoping someone commits it takes
> >all the joy out of it for me.
> >
> >Ralph
> >
> >> On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
> >>
> >>
> >> Sure, that's a big problem with some RTC workflows. Using gerrit or
> >>github
> >> PRs makes the flow much easier -- for a trivial or small patch, the sort
> >> that a "drive-by" contributor typically contributes, there probably
> >>won't
> >> be any review comments. So, they just push the patch for review, and
> >>they
> >> can be out of the loop for the rest of it. If the patch requires small
> >> revisions (eg addressing a typo or something) I think it's fine for the
> >> reviewer to just make the change themselves and commit on behalf of the
> >> original author to avoid the issue you've raised. Most RTC workflows
> >>permit
> >> this kind of thing in my experience.
> >
> >
> >
> >-
> >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

RE: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)

[Roberta Marton]

Thanks Justin for your comprehensive review of the release artifacts and
valuable comments.   And thanks Steve for your comment that indicates the
importance of getting provenance correct.

We are committed to getting the release package correct along with all the
provenance issues. This is the first time we are releasing and were
expecting some issues.  A lot of time and effort has been spent getting your
source package to work in the Apache infrastructure.

We will look at the provenance issues you mentioned and figure out how best
to address them.

There are a few questions that we have based on the comments we received so
far:

1. HP donated the Trafodion code to Apache several months ago.  We have gone
through all the legal steps to get the code donated.  As part of this
process we removed all the HP copyrights except for our test files and
documentation.  Do we have to remove all the Copyrights in order to release
in Apache?  Is including HP in the NOTICE/LICENSE file adequate?

2. A conscious decision was made to add the latest Apache license to files
that have existing licenses. So now multiple licenses are showing up.  Is
this something we should not be doing?  The original license came when the
code was first used by the product.

3.   We have followed the instructions detailed in [8] but it looks like we
are missing a mention of this in our README file.  We will add appropriate
information as the rules apply, for example - " This distribution includes
cryptographic software. The country in which you currently reside may have
restrictions on the import, possession, use, and/or re-export to another
country, ..."

4.  We do have permission to use the photos in [13] [14].  Is there
something we need to do to indicate this somewhere?

5. You mentioned that we may be too generous in excluding files for our RAT
test.  We did include in the RAT_README file an explanation of the exception
and why. If there are specific explanations in RAT_README.txt that are not
ok , we can look at each one on  a case by case basis.

We based RAT exceptions by looking at other apache products and as described
http://apache.org/legal/src-headers.html#faq-exceptions:

The RAT_README.txt file contains explanations on how we clearly cannot add
copyright info to :
•   generated files
•   configuration files
•   testware  expected files
•   source/testware  that were downloaded from elsewhere that contain
their own copyright info in the same directory.

However, it looks like we missed adding some of the items in our LICENSE
file.

6. Justin, can we get accessibility to some of the scripts you ran to check
for these incompatibilities?  This will give our next release a better
chance of succeeding.

Again, thanks for taking the time to provide this valuable feedback

   Regards,
   Roberta

-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Wednesday, November 18, 2015 6:29 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating
(RC4)

Hi,

Sorry -1 Due to license and copyright issues and possible crypto issue.

I checked:
- artefact contains incubating
- signature and hashes good
- DISCLAIMER exists
- LICENSE is missing a couple of things/has a few issues
- NOTICE is good but may be missing thing form other Apache bundled software
- rat exclusions bay be a bit wide
- no unexpected binaries in release
- while most source file have Apache headers there are serval issues with
copyright owners and multiple headers in files
- didn’t compile as the build process looks rather difficult

If OpenSSL is being bundled has this process been followed? [8] I’m not
familiar with the process and it may not apply here. Can someone who more
familiar with this please comment.

LICENSE issues:
- License implies that all BSD licensed software is "Copyright (c)
2008-2010, Allan Jardine” which is not the case. Each piece of licensed
software will have it’s own owner.
- missing MIT licensed Asciidoctor [1]
- Jquery UI is MIT licensed not BSD [2]
- missing MIT license MooTools Framework [3]
- missing BSD style OpenSSL license [4]
- missing MIT JavaScript InfoVis Toolkit license [5]
- missing MIT JQuery license [6]
- And while the code under [7] is MIT it's not copyright SpryMedia Ltd
- missing license for CSS Document by Codify Design Studio [15] How is this
file  licensed?

Also this file [9] is marked as copyright ASF but contains  other possible
copyright owners:

Re: [VOTE] Retire Corinthia

[Marvin Humphrey]

On Sun, Nov 15, 2015 at 7:01 PM, Marvin Humphrey  wrote:

> [ ] +1 to retire Corinthia from the Incubator
> [ ] -1 to keep Corinthia in the Incubator

The VOTE passes with +1 votes from the following IPMC members:

  Roman Shaposhnik
  Ted Dunning
  Greg Stein
  Henry Saputra
  Bertrand Delacretaz
  Joe Brockmeier
  Konstantin Boudnik
  Sergio Fernández
  Danese Cooper

Best wishes to the Corinthia podling's contributors.

I will attend to the administrative details of Corinthia's retirement.

Marvin Humphrey

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

Re: [DISCUSS] S2Graph Incubator Proposal

[Hyunsik Choi]

Thank you Stack for your kind work. I just understood. I will improve
the proposal from your suggestion.

Best regards,
Hyunsik

On Thu, Nov 19, 2015 at 11:35 AM, Stack  wrote:
> On Wed, Nov 18, 2015 at 5:04 PM, Hyunsik Choi  wrote:
>
>> Thank you very much Stack! It definitely looks better than just wiki.
>> It would be helpful to improve the proposal.
>>
>>
> To be clear, proposal needs to be on the wiki. I just moved it over so I
> could show my edits as 'suggested' rather than change the original. Take
> whatever edits you think improve the proposal and then apply them to the
> wiki.
> St.Ack
>
>
>
>
>> Best regards,
>> Hyunsik
>>
>> On Tue, Nov 17, 2015 at 10:20 PM, Stack  wrote:
>> > Glad to see s2graph being put up as an incubator project.
>> >
>> > Here [1] are some suggested edits to try and help strengthen the proposal
>> > before it goes up for a vote. Hopefully they help.
>> >
>> > St.Ack
>> > 1.
>> >
>> https://docs.google.com/document/d/19iNc0u_-9ogb0kDC-WnLoWWg9J_LFeuSGB8GF_rQfEs/edit?usp=sharing
>> >
>> > On Tue, Nov 17, 2015 at 3:59 PM, Hyunsik Choi 
>> wrote:
>> >
>> >> Thank you Henry. Yes, we already had enough time to discuss the
>> >> S2Graph proposal. I'll make a vote thread soon.
>> >>
>> >> Best regards,
>> >> Hyunsik
>> >>
>> >> On Tue, Nov 17, 2015 at 2:22 PM, Henry Saputra > >
>> >> wrote:
>> >> > Looks like we have positive responses. I think it is time for VOTE
>> >> thread :)
>> >> >
>> >> > On Friday, November 6, 2015, Hyunsik Choi  wrote:
>> >> >
>> >> >> Hi folks,
>> >> >>
>> >> >> We would like to start a discussion on S2Graph as an incubation
>> project.
>> >> >>
>> >> >> S2Graph is a distributed and scalable OLTP graph database built on
>> >> >> HBase. It provides interactive queries for vertex/edge/sub-graphs on
>> >> >> extremely large graph data sets as well as insertion and update
>> >> >> operations.
>> >> >>
>> >> >> S2Graph was already introduced in Apache BigData and HBaseCon this
>> year.
>> >> >>
>> >> >> The proposal is available at :
>> >> >> https://wiki.apache.org/incubator/S2GraphProposal
>> >> >>
>> >> >> We are looking forward to any feedback. In addition, we are looking
>> >> >> for volunteers as mentors.
>> >> >>
>> >> >> Best regards,
>> >> >> Hyunsik
>> >> >>
>> >> >> -
>> >> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> >> >> 
>> >> >> For additional commands, e-mail: general-h...@incubator.apache.org
>> >> >> 
>> >> >>
>> >> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> >> For additional commands, e-mail: general-h...@incubator.apache.org
>> >>
>> >>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

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

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

[Greg Stein]

On Thu, Nov 19, 2015 at 8:10 PM, Ralph Goers 
wrote:
>...

> of people wanting to join. I am sure this is going to be a controversial
> statement, but I have noticed that the projects that I’ve seen do this
> often have a fair number of committers who are paid to work on the project
> by their employer and I have to admit that I have wondered if these
> projects do this actually want to limit participation.
>

Yeup. And this kind of monkey business is why the Board specifically
requires PMCs to document their additions. A static PMC membership may be a
sign of exclusion. This kind of behavior is why the Board has completely
emptied two PMCs in the Foundation's history, and made them regrow
themselves organically.

As I said at the start of this thread: RTC is a mechanism for control, not
for managing "complex projects".

Cheers,
-g

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

[Ralph Goers]

Yes, it was a trick question. But it proves my point. I can’t imagine a world 
where someone would refuse to participate in a project because it was CTR, but 
in my view this variation of RTC definitely limits the number of people wanting 
to join. I am sure this is going to be a controversial statement, but I have 
noticed that the projects that I’ve seen do this often have a fair number of 
committers who are paid to work on the project by their employer and I have to 
admit that I have wondered if these projects do this actually want to limit 
participation.

Ralph

> On Nov 19, 2015, at 6:05 PM, Greg Stein  wrote:
> 
> Trick question, as I'd never work under that model :-)
> 
> Apache Subversion is CTR, with a very low bar to get commit access to
> portions of the tree or a branch (only PMC members get access to whole
> tree, so we grant full access and PMC membership simultaneously). We don't
> need a fancy label for "contributor who is a committer" because such a
> concept is anathema to the Subversion community's peer respect model.
> 
> On Thu, Nov 19, 2015 at 6:38 PM, Ralph Goers 
> wrote:
> 
>> Greg, which of these do you use when the “contributor” is a committer?
>> Remember the model here is that the author is never allowed to commit their
>> own code.



-
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...)

[Greg Stein]

Todd: as Ross notes, your three points about code reviews in a CTR project
are quite valid, and match accepted engineering practices.

What I haven't seen is an explanation why a committer must be treated the
same as a drive-by. Both are subject to requiring "permission"[1] to make
even the simplest of changes under RTC. Even worse, from else-thread, it
sounds like under your control scheme, you don't even allow the committer
to apply their own change [after review]. A committer can give a binding +1
to somebody else's work. But they aren't trusted to give that to their own
work. Just like a drive-by contributor can't be trusted.

-g

[1] thanks to Upayavira for capturing the essence of RTC: it is a
"permission" mechanism for control.

On Wed, Nov 18, 2015 at 3:16 AM, Ross Gardler 
wrote:

> Interesting, Todd, can you identify which of your three arguments for CTR
> are not present in RTC.
>
> Ross
>
> -Original Message-
> From: Todd Lipcon [mailto:t...@cloudera.com]
> Sent: Tuesday, November 17, 2015 11:23 PM
> To: general@incubator.apache.org
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> On Tue, Nov 17, 2015 at 11:12 PM, Greg Stein  wrote:
>
> > On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon  wrote:
> > >...
> >
> > > I think it's a _plus_ that contributors and committers contribute
> > > code in the same way -- it's more of a level playing field for new
> > > people contributing to the project.
> > >
> >
> > "level playing field"?? seriously??
> >
> > I find no logical or valid reasoning to drag committers down to the
> > same level as drive-by contributors.
> >
>
> I gave the logical and valid reasoning in previous posts in this thread:
> 1) no matter how seasoned a committer you are, you might make mistakes
> which are easily caught in code review
> 2) no matter how good you are at coding, your code might not make sense to
> a second pair of eyes, who can ask you to improve comments or docs
> 3) no matter if your code is perfect, the act of another person reading
> your code builds shared ownership over the code, thus alleviating
> bus-factor issues and improving the general feeling of a cohesive community
> developing a single project instead of a loose coalition of people with
> their own fiefdoms.
>
> I believe this to be generally accepted in the software engineering
> community. I don't know practices at every company, but I know at least
> that most of the well-regarded technology companies I've met with have some
> form of pre-commit review, and certainly many highly adopted open source
> projects as well (especially in infrastructure software).
>
> Either a high percentage of the world does this for "no logical or valid
> reason" or this is just a matter of opinion, and like I said, we can agree
> to disagree.
>
> -Todd
>

Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)

[Justin Mclean]

Hi,

> As for #4 - the pictures were taken by someone in our organization.  I will
> tell him that they look professional -:) They are not licensed or anything, 
> just personal photos.

If they are fine with them being distributed then that's all good IMO. You may 
want to add something in LICENSE.

> Since you seem to knowledgeable on License issues.  You mentioned that #11
> references Open Software Foundation.  In my research this is managed by a
> GNU license.

The GPL is not a licence that’s comparable with Apache software [1] so if they 
are GPL licensed then yes they would be to be removed / replaced with something 
else.

Files in question:
./core/sql/common/from_GB2312.c
./core/sql/common/multi-byte.h
./win-odbc64/sql/common/from_GB2312.c
./win-odbc64/sql/common/multi-byte.h

(may be others)

Looking at the file it mentions “OSF/1”. It's been a couple years since I used 
DEC Alpha’s :-)  It’s not clear to me how those files are licensed they may or 
may not be GPL.  But they shouldn’t have an Apache header if they are not 
Apache licensed.

I also noticed this file:
/core/sql/common/swsprintf.cpp

Which is "Copyright (c) 1990 The Regents of the University of California.” and 
looks to be BSD licensed. Again it shouldn't have an Apache license header and 
would this would also need to be added to LICENSE.

Do you know the provenance of all the files in /core/sql/common?

Sorry but it look like the rabbit hole gets a bit deeper. When I was doing some 
checks I may of missed some things. Searching a bit further I can see code that 
is:
Copyright (C) 1995-1998 Eric Young (e...@cryptsoft.com)
Copyright (c) 1998, 1999 Thai Open Source Software Centre Ltd
Copyright (c) 1997-1999 Compaq Computer Corporation.  All Rights Reserved.
Copyright (c) 1997-2007, Damian Conway C<<  >>
Copyright Transaction Processing Performance Council

And from a few spot checks an Apache headers has been incorrectly added to some 
of these files.

This file for instance:
./core/sqf/export/lib/Parse/RecDescent.pm

Is probably under the perl artistic license which may cause further 
complications. [2]

Thanks,
Justin

1. http://www.apache.org/legal/resolved.html#category-x
2. https://issues.apache.org/jira/browse/LEGAL-86
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)

[Alex Harui]

On 11/19/15, 7:56 PM, "Justin Mclean"  wrote:

>Hi,
>
>Thanks for the clarification.
>
>> The ASF politely requests that contributors remove copyright notices
>>from
>> individual files.  There are a variety of reasons for this request[2].
>
>I assume you mean their own copyright notices you can’t remove other
>peoples right?
>
>Any advice in what to do in this case? By my count there are 50+
>different copyright message in this code base.

AIUI, if these files are listed in the SGA, there must be a paper trail of
the copyright owner giving permission for them to be donated.  Otherwise,
they should be treated as third-party, the SGA may require amending as
well.

-Alex


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

Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)

[Justin Mclean]

Hi,

Thanks for the clarification.

> The ASF politely requests that contributors remove copyright notices from
> individual files.  There are a variety of reasons for this request[2].

I assume you mean their own copyright notices you can’t remove other peoples 
right?

Any advice in what to do in this case? By my count there are 50+ different 
copyright message in this code base.

Thanks,
Justin


-
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...)

[Ralph Goers]

None of your statements below are any different between RTC or CTR. The only 
time it makes aa difference is if no one does reviews.  My feeling is that a 
community that insists on RTC believes that code will not be reviewed unless 
committers are forced to do it.

All I can say, is that for me personally I have found the process of having to 
create a patch, submit a code review, wait for the review and participate in 
it, then wait for the commit to be onerous enough that I just don’t bother.  As 
I said, in a CTR community there are many times where branches are created and 
the code is reviewed there before being merged because the authors believe the 
code is significant enough to require it.  The author is then the one who 
merges the branch once the reviews are complete.  To be perfectly honest, this 
pretty much exactly matches the way software is created in the development team 
I work with in the $day$ job too.

Ralph

> On Nov 18, 2015, at 12:22 AM, Todd Lipcon  wrote:
> 
> I gave the logical and valid reasoning in previous posts in this thread:
> 1) no matter how seasoned a committer you are, you might make mistakes
> which are easily caught in code review
> 2) no matter how good you are at coding, your code might not make sense to
> a second pair of eyes, who can ask you to improve comments or docs
> 3) no matter if your code is perfect, the act of another person reading
> your code builds shared ownership over the code, thus alleviating
> bus-factor issues and improving the general feeling of a cohesive community
> developing a single project instead of a loose coalition of people with
> their own fiefdoms.
> 
> I believe this to be generally accepted in the software engineering
> community. I don't know practices at every company, but I know at least
> that most of the well-regarded technology companies I've met with have some
> form of pre-commit review, and certainly many highly adopted open source
> projects as well (especially in infrastructure software).
> 
> Either a high percentage of the world does this for "no logical or valid
> reason" or this is just a matter of opinion, and like I said, we can agree
> to disagree.
> 
> -Todd



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

RE: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)

[Roberta Marton]

Thanks for your quick answers.

As for #4 - the pictures were taken by someone in our organization.  I will
tell him that they look professional -:)
They are not licensed or anything, just personal photos

Since you seem to knowledgeable on License issues.  You mentioned that #11
references Open Software Foundation.  In my research this is managed by a
GNU license.  However, it looks Apache has restrictions on using these types
of licenses - http://www.apache.org/licenses/GPL-compatibility.html.  If
this is true, would this mean we can't include this file in our source
distribution?

Roberta

-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Thursday, November 19, 2015 5:51 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating
(RC4)

Hi,

> 1. HP donated the Trafodion code to Apache several months ago.  We
> have gone through all the legal steps to get the code donated.  As
> part of this process we removed all the HP copyrights except for our
> test files and documentation.  Do we have to remove all the Copyrights
> in order to release in Apache?

My understanding If the code was donated to the ASF it’s now copyright the
ASF not HP.

>  Is including HP in the NOTICE/LICENSE file adequate?

Yes that's needed as well. [1]

> 2. A conscious decision was made to add the latest Apache license to
> files that have existing licenses. So now multiple licenses are showing
> up.

Each file should have a single license header showing who owns the
copyright. BTW rat doesn’t pick up on this.

>  The original license came when the code was first used by the product.

If the code come from another project then HP probably didn't own the
copyright. If the original code is Apache licensed then you usually don’t
need to add anything to LICENSE [2], but if the software where it come from
has a NOTICE file you may need to add something to your NOTICE files [2].
all other permissive licenses need to be added to LICENSE [3].

> 3.   We have followed the instructions detailed in [8] but it looks like
> we
> are missing a mention of this in our README file.

I’m not familiar with the process but you might want to look at what the
HTTP project does in their README [2].

> 4.  We do have permission to use the photos in [13] [14].  Is there
> something we need to do to indicate this somewhere?

>From the original people who took the photos? (Just because they were in the
donation from HP doesn’t mean you have permission to use and distribute
them.) Both of the photos look professional to me. How are they licensed?
Does the photos metadata include license or copyright information? Usually
that info would go in LICENSE.

> 5. You mentioned that we may be too generous in excluding files for
> our RAT test.

Just because of the number of issues it may be that you’re not checking all
the files you shod be. I didn’t look in detail.

> 6. Justin, can we get accessibility to some of the scripts you ran to
> check for these incompatibilities?

Noting fancy script wise just rat and this:

find . -type f -exec grep “XXX" {} \; -print

Where XXX is “Copyright”, “ MIT “, “BSD”, “GPL” etc. Sometimes I pipe to a
couple of grep -v ’s to reduce the noise.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#mod-notice
2. http://www.apache.org/dev/licensing-howto.html#alv2-dep
3. http://www.apache.org/dev/licensing-howto.html#permissive-deps
3. https://github.com/apache/httpd/blob/trunk/README


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

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

Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)

[Alex Harui]

On 11/19/15, 7:42 PM, "Justin Mclean"  wrote:

>Hi,
>
>> As for #4 - the pictures were taken by someone in our organization.  I
>>will
>> tell him that they look professional -:) They are not licensed or
>>anything, just personal photos.
>
>If they are fine with them being distributed then that's all good IMO.
>You may want to add something in LICENSE.

And you may want/need official documentation that is ok for them to be
distributed.  And maybe even under what license and whether they are
contributing/licensing the photos to Apache.

True story:  Person C writes some code.  Company M acquires Person C and
his code.  A team is formed, more code is added.  Company A acquires
Company M.  Even more code is added.  Person C leaves Company A.  Company
A decides to donate all of that code to the ASF.  OMG! The acquisition
agreement for Person C and his code only licensed the code to Company M,
it did not explicitly grant the right to re-license that code to the ASF!
Hunt down person C and get signed agreement that Company A can re-license
Person C's code.  OMG!  Person C's copyright notices are still in the
files!  Person C is not a committer so he can't move the copyrights to
NOTICE.  Must ask person C for written permission to do so.

AIUI, if I take a photo as part of my job, maybe to create some test
media, my employee agreement says that my employer has copyright of that
work.  But if I bring in a photo from one of my trips, I probably own
copyright.  I can say my company can use it, but the terms are not clear.
It might be ok since our test media is in-house, but do I want it in an
ASF repo where everyone else can copy it and modify it?  What if people
start adding mustaches to my wedding photos!  And technically, since I own
that photo, the software grant cannot license it to the ASF, and since I
did not explicitly assign an ASF-compatible license to it, the ASF can't
just use it.  The template for adding something to LICENSE includes the
license it is under.

So, if this is a personal photo, I think you have the following choices:
1) Ignore me, since really, it is a lot of hassle, and what is the
likelihood something bad will happen?
2) Have the photographer send an email to your dev@ list saying that it is
under (choose an ASF-compatible license)
3) (Optional) Further have the photographer add in the email that they
donate/license the photos to the ASF.  This is optional because you can
always treat the photos as 3rd-party.
4) Replace the photos.

I don't know how strict the ASF wants to be on things like test media
photos.  If you choose #1, I won't know about it unless it gets brought up
on this list.  I'm just offering up what I've learned from several
software grants and IP clearances.

My mental model is that every contribution/pixel/line-of-code is
owned/copyrighted by some person or entity under some license (or no
license in which case no permissions have been granted).  The ASF further
wants explicit permission from the owner for every
contribution/pixel/line-of-code that is considered part of an ASF
project's source.  Even if a line of code from outside the ASF is already
under the Apache License, the ASF considers it third-party without such
permission.  You can bundle it in your releases, but it needs to be called
out in LICENSE since its owners may have other rules on how modifications
get back to the master copy.

Of course, IANAL, and most certainly could be wrong.

-Alex

Re: Apache Metrics, Not Apache Humans

[Rich Bowen]

On 11/18/2015 06:28 PM, Louis Suárez-Potts wrote:
> PS Alas, "scores" are chalked against the manager of communities who
> fails to satisfy the beany needs of misguided marketing. (Beany
> needs=bean counter needs.)

We should have a support group.

-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

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

Re: Kalumet retirement steps

[Jean-Baptiste Onofré]

Hi Hadrian and Marvin,

I replied on the kalumet mailing list.

It's not a problem at all that the Kalumet's code remain on svn.

Sorry for the delay guys.

Regards
JB

On 11/19/2015 05:44 AM, Hadrian Zbarcea wrote:

Hi Marvin,

As far as I remember, Kalumet is almost exclusively the work of JB
Onofre who is an ASF member, therefore I don't see a problem.

That said I think it's best to wait a bit and let JB speak up. I cc'ed
him, just to make sure he notices this thread.

Cheers,
Hadrian

On 11/18/2015 05:29 PM, Marvin Humphrey wrote:

On Sun, Nov 15, 2015 at 6:56 PM, Marvin Humphrey
 wrote:


The copyright checkbox for Kalumet is marked with a question mark,
which I
interpret as "not checked off":

 http://incubator.apache.org/projects/kalumet#Copyright

A successful incubating release would have settled the issue, but I
did some
research and it seems that while the Kalumet podling attempted an
incubating
release of their 0.6 branch, it doesn't look like it was ever officially
completed.

If the copyright status cannot be resolved, I will have to delete
`trunk`,
`tags`, and `branches` from
.

Can someone provide a definitive answer on whether it is OK for
Kalumet's code
to remain visible in svn?


I'll give this a couple more days.  If no one has spoken up by then, I
will proceed with deleting the code from svn.

Marvin Humphrey

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



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

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

Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)

[Steve Loughran]

> On 19 Nov 2015, at 02:28, Justin Mclean  wrote:
> 
> 10], copyright Open Software Foundation e.g. [11]


That taints so much of the HP C++ codebase. Someone I know was working on the 
unix JVM and was in the graphics code, where he came across bits of the font 
stuff which he'd written himself for OSF/Motif about 10+ years earlier; it's 
the tainting of that bit of code which may have lead to the rendering on 
openjdk being so worse than oracle JDK for a long time: too much cut and paste 
consortium code without provenance management.

-
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...)

[Todd Lipcon]

On Thu, Nov 19, 2015 at 8:16 AM, Ralph Goers 
wrote:

> None of your statements below are any different between RTC or CTR. The
> only time it makes aa difference is if no one does reviews.  My feeling is
> that a community that insists on RTC believes that code will not be
> reviewed unless committers are forced to do it.
>

Yep, that's my assumption. It's much more fun to write code than review it,
so "forcing" people to do it is a good idea. The other worry is that, in a
large community of developers, an implicit "people probably read the
commits as they come in" doesn't scale. Should every person read every
commit? Probably not. How do you know if someone else has already read the
commit, or signed up to do so? What if it takes you a few days to get
around to reviewing something, and by that point there are already a bunch
more patches stacked up on top making it impossible to revert or difficult
to modify? Who's in charge of fixing the bugs or issues in a post-commit
review?

I'm sure it works fine for many communities (I use CTR on some internal
infrastructure within small teams where bugs are less costly and the rate
of development is slow). But it doesn't work for all.


>
> All I can say, is that for me personally I have found the process of
> having to create a patch, submit a code review, wait for the review and
> participate in it, then wait for the commit to be onerous enough that I
> just don’t bother.


Sure, that's a big problem with some RTC workflows. Using gerrit or github
PRs makes the flow much easier -- for a trivial or small patch, the sort
that a "drive-by" contributor typically contributes, there probably won't
be any review comments. So, they just push the patch for review, and they
can be out of the loop for the rest of it. If the patch requires small
revisions (eg addressing a typo or something) I think it's fine for the
reviewer to just make the change themselves and commit on behalf of the
original author to avoid the issue you've raised. Most RTC workflows permit
this kind of thing in my experience.


> As I said, in a CTR community there are many times where branches are
> created and the code is reviewed there before being merged because the
> authors believe the code is significant enough to require it.


Amusingly enough, the RTC communities I'm a part of do the opposite: you
can make a branch which operates under CTR, so long as it's reviewed
sufficiently prior to its merge into trunk. This is great for rapid
development and prototyping when a small number of contributors are working
together on a new project.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: [DISCUSS] OpenMiracl for Incubation

[Gregory Chase]

Having been through this twice now with "Pivotal GemFire" begatting "Apache
Geode" and "Pivotal HAWQ" becoming "Apache HAWQ"

If the current owner intends to allow infringement on the MIRACL brand as a
policy by any user of Apache Miracl, then that should be ok.  In effect
they will be putting "MIRACL" into the public domain.

If the owner intends to license "MIRACL" for Apache's use only - how does
this extend to Apache's users?

For my company, we decided it was better to ensure the commercial
distribution and the Apache projects did not infringe on each others
brands.  And we have done both approaches:  suggest a new brand for Apache,
and give an existing brand to Apache and rebrand the commercial
distribution.

-Greg

On Wed, Nov 18, 2015 at 6:34 PM, Nick Kew  wrote:

> On Wed, 2015-11-18 at 08:48 +0900, Brian Spector wrote:
> > Hi Alex, thank you for the suggestion, but from our point of view, as I
> > outlined below, we would disadvantage the project as a whole by not
> having
> > the MIRACL name in it.
> >
> > At the same time, I completely understand the concern that a company who
> > creates a product based on OpenMiracl might feel themselves disadvantaged
> > by having to state an attribution 'based on Apache OpenMiracl' while
> > MIRACL, the company, sells a product called Datacenter Cryptosystem will
> > also say 'based on Apache OpenMiracl'. We get that.
>
> If folks are uneasy about OpenMiracl, how far does that extend?
> Would (for example) a name taking the "Mira" stem be sufficiently
> distinct for those expressing concerns here?  For example,
> Mirabile (Latin pronunciation) kind-of offers an element of
> historic continuity through the linguistic association with
> the miracle.
>
> --
> Nick Kew
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Greg Chase

Director of Big Data Communities
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/

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

[Greg Stein]

On Thu, Nov 19, 2015 at 11:10 AM, Todd Lipcon  wrote:

> On Thu, Nov 19, 2015 at 8:16 AM, Ralph Goers 
> wrote:
>
> > None of your statements below are any different between RTC or CTR. The
> > only time it makes aa difference is if no one does reviews.  My feeling
> is
> > that a community that insists on RTC believes that code will not be
> > reviewed unless committers are forced to do it.
> >
>
> Yep, that's my assumption. It's much more fun to write code than review it,
> so "forcing" people to do it is a good idea. The other worry is that, in a
>

And there it is. Forcing behavior. I knew it, and said so at the beginning
of this thread:

"I have always found the "complex project" to merely be an excuse for
control/no-trust."


-g

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

[Alex Harui]

Sorry for extending the thread, but now I'm curious...

On 11/19/15, 9:10 AM, "Todd Lipcon"  wrote:
>I'm sure it works fine for many communities (I use CTR on some internal
>infrastructure within small teams where bugs are less costly and the rate
>of development is slow). But it doesn't work for all.

>
>> As I said, in a CTR community there are many times where branches are
>> created and the code is reviewed there before being merged because the
>> authors believe the code is significant enough to require it.
>
>
>Amusingly enough, the RTC communities I'm a part of do the opposite: you
>can make a branch which operates under CTR, so long as it's reviewed
>sufficiently prior to its merge into trunk. This is great for rapid
>development and prototyping when a small number of contributors are
>working
>together on a new project.

I'm curious to know, for the RTC communities, what percentage of
contributions come from folks who aren't contributing as part of their day
job?  If I only had opportunities to contribute after work, I would
gravitate to CTR communities.

I keep drawing the analogy of Apache communities to these community
house-building projects.  I'll bet that some aspects of the house are
built by professionals volunteering their time and checked by other
professionals volunteering their time, but lots of pieces can be done by
enthusiasts.  The higher the minimum time and energy required of the
enthusiast, the fewer I would expect there to be.  I've been under the
impression that Apache has a bias towards communities of enthusiasts,
otherwise you really have a consortium.

-Alex

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

[Ross Gardler]

Todd asks "How do you know if someone else has already read the commit" - I 
don't care. Just as people writing code can make mistakes, so can people who 
review code. For this reason if *I* care about *that* commit I will review it 
in detail - regardless of RTC or CTR. 

The more people who follow that rule the more eyes there are on the commit. I 
trust my fellow community members to do the right thing.

RTC provides no added value for me personally since the amount of work for *me* 
is the same - I need to review every commit I care about.

Ross

-Original Message-
From: Todd Lipcon [mailto:t...@cloudera.com] 
Sent: Thursday, November 19, 2015 9:11 AM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

On Thu, Nov 19, 2015 at 8:16 AM, Ralph Goers 
wrote:

> None of your statements below are any different between RTC or CTR. 
> The only time it makes aa difference is if no one does reviews.  My 
> feeling is that a community that insists on RTC believes that code 
> will not be reviewed unless committers are forced to do it.
>

Yep, that's my assumption. It's much more fun to write code than review it, so 
"forcing" people to do it is a good idea. The other worry is that, in a large 
community of developers, an implicit "people probably read the commits as they 
come in" doesn't scale. Should every person read every commit? Probably not. 
How do you know if someone else has already read the commit, or signed up to do 
so? What if it takes you a few days to get around to reviewing something, and 
by that point there are already a bunch more patches stacked up on top making 
it impossible to revert or difficult to modify? Who's in charge of fixing the 
bugs or issues in a post-commit review?

I'm sure it works fine for many communities (I use CTR on some internal 
infrastructure within small teams where bugs are less costly and the rate of 
development is slow). But it doesn't work for all.


>
> All I can say, is that for me personally I have found the process of 
> having to create a patch, submit a code review, wait for the review 
> and participate in it, then wait for the commit to be onerous enough 
> that I just don’t bother.


Sure, that's a big problem with some RTC workflows. Using gerrit or github PRs 
makes the flow much easier -- for a trivial or small patch, the sort that a 
"drive-by" contributor typically contributes, there probably won't be any 
review comments. So, they just push the patch for review, and they can be out 
of the loop for the rest of it. If the patch requires small revisions (eg 
addressing a typo or something) I think it's fine for the reviewer to just make 
the change themselves and commit on behalf of the original author to avoid the 
issue you've raised. Most RTC workflows permit this kind of thing in my 
experience.


> As I said, in a CTR community there are many times where branches are 
> created and the code is reviewed there before being merged because the 
> authors believe the code is significant enough to require it.


Amusingly enough, the RTC communities I'm a part of do the opposite: you can 
make a branch which operates under CTR, so long as it's reviewed sufficiently 
prior to its merge into trunk. This is great for rapid development and 
prototyping when a small number of contributors are working together on a new 
project.

-Todd
--
Todd Lipcon
Software Engineer, Cloudera