Re: [CLOSED] Can we push docker images to https://hub.docker.com/u/apache/

[Wang Wei]

Just saw Thejas' email  ([DISCUSS] publishing docker image for podling) on
this ticket.
I am now closing this thread to avoid confusion.

On Thu, Jan 5, 2017 at 2:24 PM, Wang Wei  wrote:

> Hi all,
>
> I am from the incubator-singa project.
> We want to host our docker images under https://hub.docker.com/u/apache/.
> https://issues.apache.org/jira/browse/INFRA-13156
>
> Currently, there is no incubator project hosting docker images under the
> Apache namespace.
> I start this thread to get binding vote for this request.
>
> Thank you!
>
> Best,
> Wei
>
>

[Docker] Can we push docker images to https://hub.docker.com/u/apache/

[Wang Wei]

Hi all,

I am from the incubator-singa project.
We want to host our docker images under https://hub.docker.com/u/apache/.
https://issues.apache.org/jira/browse/INFRA-13156

Currently, there is no incubator project hosting docker images under the
Apache namespace.
I start this thread to get binding vote for this request.

Thank you!

Best,
Wei

[DISCUSS] publishing docker image for podling

[Thejas Nair]

As per Greg Stein's comment in
https://issues.apache.org/jira/browse/INFRA-13156, we haven't had any
podling request for a docker image (aka a "convenience binary") to be
published within Apache's namespace in hub.docker.com .

Starting this thread to see if we should have a vote on for this or we can
get incubator VP approval for this.

Thanks,
Thejas

[jira] [Created] (INCUBATOR-146) Test

[John D. Ament (JIRA)]

John D. Ament created INCUBATOR-146:
---

 Summary: Test
 Key: INCUBATOR-146
 URL: https://issues.apache.org/jira/browse/INCUBATOR-146
 Project: Incubator
  Issue Type: Task
Reporter: John D. Ament
Assignee: John D. Ament
 Attachments: TestingPyramid.jpg

Test



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Write access to January report page

[John D. Ament]

On Wed, Jan 4, 2017 at 11:11 PM David E Jones 
wrote:

> On Wed, 2017-01-04 at 17:13 -0800, Marvin Humphrey wrote:
> > On Wed, Jan 4, 2017 at 4:51 PM, Niclas Hedhman 
> wrote:
> > > Isn't the https://wiki.apache.org/incubator/January2017 supposed to be
> > > editable by Mentors/IPMC members?
> >
> > It's editable by anyone whose wiki username we add to the
> > ContributorsGroup page.  What's your wiki id for
> > wiki.apache.org/incubator?  (Which is distinct from your Apache ID and
> > from logins for other Moin wikis.) I'll add you.
> >
>
> I ran into the same issue trying to sign the Freemarker report, though it
> was setup and worked in the past (like the
> last report 3 months ago).
>
> Could you add my id as well? It is: 'jonesde'
>

Done!


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

Re: Write access to January report page

[David E Jones]

On Wed, 2017-01-04 at 17:13 -0800, Marvin Humphrey wrote:
> On Wed, Jan 4, 2017 at 4:51 PM, Niclas Hedhman  wrote:
> > Isn't the https://wiki.apache.org/incubator/January2017 supposed to be
> > editable by Mentors/IPMC members?
> 
> It's editable by anyone whose wiki username we add to the
> ContributorsGroup page.  What's your wiki id for
> wiki.apache.org/incubator?  (Which is distinct from your Apache ID and
> from logins for other Moin wikis.) I'll add you.
> 

I ran into the same issue trying to sign the Freemarker report, though it was 
setup and worked in the past (like the
last report 3 months ago).

Could you add my id as well? It is: 'jonesde'

Thank you,
-David

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

Re: [DISCUSS] Significance of Artifact Names

[Roman Shaposhnik]

Huge +1 to what Cédric has said.

Thanks,
Roman.

On Wed, Jan 4, 2017 at 6:20 AM, Cédric Champeau
 wrote:
> Cross-posting since I missed this topic in the first place. My apologies
> for the duplicate:
>
> I would argue that one of the Foundation mottos is "community first". In
> that sense, enforcing a policy like that is not thinking about users. It's
> adding a burden they don't care about. I am strongly against anything that
> enforces technical requirements where there shouldn't be. Enforcing Maven
> coordinates, or enforcing a _version string_ is going too far into the
> technical details. There's branding and there's technical. Maven already
> makes the mistake of mixing how you build the project and how you consume
> it, which is the root of a lot of pain. Let's not make the error again at
> the policy level, it's a total non sense.
>
> The Foundation can host a variety of different projects, from new ones
> written in C to "old" ones written in Java, and all the different things we
> can see in our ecosystem: Javascript, Go, ... Enforcing a rule about _how_
> you consume a project, by Maven coordinates or version string is an
> implementation detail. Branding the project is not. In other words, as long
> as your package name, maven artifacts, Docker images, ... do not infringe
> copyright, it's a no brainer. However, the project page *must* state about
> incubating status and *explain* what it means. A *lot* of people don't care
> what *incubating* means in the Foundation sense (and even worse, podling
> can have very negative image). It would have been terrible for Groovy to
> change the way people consume the artifacts, making them think of low
> quality software, because they don't understand what "incubating" mean. To
> me it sounds even worse than "alpha". Since "incubating" is meant towards
> *incubating project in the sense of the Apache community*, it should *only*
> appear where it makes sense: DISCLAIMER, web site, ... That is to say
> everywhere you can give an explanation about its meaning. It should also
> appear in the source package name, because that is what we legally care
> about. But the version *string*, inside the package, is purely, again,
> internal details, just like package name, Maven coordinates, NPM
> coordinates, ... Why would you force me to use a version pattern if what I
> want is the revision hash as the version number? The policy should NOT
> impact how we design software or how we want the design to be. There are
> potential technical issues with putting such a label in a version string
> (OSGi, Jigsaw, dependency resolution with Maven, Ivy or Gradle, ... just to
> name the Java ecosystem), so to me enforcing the policy here is just an
> error.
>
> As for Groovy and the Codehaus package and Maven coordinates, we plan to
> change this in a major, breaking, 3.0 release, not before. Because it would
> be a breaking change, and some dependency management engines, typically,
> are very poor when it comes to dependency substitution, which would add too
> much burden for people to upgrade. We had an agreement with Ben from
> Codehaus to use the name when we joined the ASF.
>
>
>
> 2017-01-04 6:24 GMT+01:00 Alex Harui :
>
>> Sorry for top-posting.
>>
>> It's always been interesting to me that the ASF says that it only releases
>> source code, but still has policy about the contents of convenience
>> binaries such as [6].  So, I suppose the ASF could dictate naming of
>> binary packages.
>>
>> I know very little about Maven, but in my mind, the -incubating suffix is
>> supposed to help warn the customer or cover the ASFs butt or both.  I
>> don't know if anybody actually points to a source artifact from Maven, but
>> if the downstream user is being careful enough to work from sources, it
>> makes sense to me to put in an additional warning by adding the
>> -incubating suffix to the source package. It says that these source
>> packages are not like other ASF source packages without having to open the
>> package.
>>
>> But for a binary artifact, given that the ASF already thinks it isn't
>> audit-able and thus not an official release, does the customer care that
>> the artifact may not be ASF-grade (especially if the artifacts were
>> already considered open before entering Apache)?  Do they really need
>> early warning?  Would it really affect the ASF if something bad was later
>> found in a binary artifact?
>>
>> IMO, the answer to all 3 questions is no.  I don't know how hard it is to
>> suffix the source artifact with -incubating but not for the binary
>> artifacts.  But if it is hard, could the next version of Maven do it?
>>
>> Also, if someone is concerned enough about the licensing of the artifacts
>> they depend on to go digging through all of the poms of their binary
>> dependencies, wouldn't they check the  section of each POM?
>> According to [7] there is a comments section there.  Could incubating
>> podlings be 

Re: Write access to January report page

[Marvin Humphrey]

On Wed, Jan 4, 2017 at 5:42 PM, Niclas Hedhman  wrote:
> My login as "niclas"

Added.

Marvin Humphrey

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

Re: Write access to January report page

[Niclas Hedhman]

My login as "niclas"

On Thu, Jan 5, 2017 at 9:13 AM, Marvin Humphrey 
wrote:

> On Wed, Jan 4, 2017 at 4:51 PM, Niclas Hedhman  wrote:
> > Isn't the https://wiki.apache.org/incubator/January2017 supposed to be
> > editable by Mentors/IPMC members?
>
> It's editable by anyone whose wiki username we add to the
> ContributorsGroup page.  What's your wiki id for
> wiki.apache.org/incubator?  (Which is distinct from your Apache ID and
> from logins for other Moin wikis.) I'll add you.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org  - New Energy for Java

Re: Wiki Contributor

[Marvin Humphrey]

On Wed, Jan 4, 2017 at 4:36 PM, Randall Leeds  wrote:
> Would someone kindly add me as a contributor to the incubator wiki?
>
> My username is RandallLeeds.

Done.

Marvin Humphrey

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

Re: Write access to January report page

[Marvin Humphrey]

On Wed, Jan 4, 2017 at 4:51 PM, Niclas Hedhman  wrote:
> Isn't the https://wiki.apache.org/incubator/January2017 supposed to be
> editable by Mentors/IPMC members?

It's editable by anyone whose wiki username we add to the
ContributorsGroup page.  What's your wiki id for
wiki.apache.org/incubator?  (Which is distinct from your Apache ID and
from logins for other Moin wikis.) I'll add you.

Marvin Humphrey

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

Re: [VOTE] Graduate Apache Ranger Project from the Incubator - Resending with additional mail distro

[Suneel Marthi]

+1 binding

On Wed, Jan 4, 2017 at 5:48 PM, Ramesh Mani  wrote:

> Dear Incubator members,
>
> Apache Ranger Project community has successfully released 0.6.2 version
> and with it there had been a lot of discussion within Apache Ranger
> community to consider graduation to TLP. Apache Ranger entered into
> incubation on 24th July 2014 and from this welcoming community had done a
> tremendous job in resolving various technical hurdles like refactoring the
> project core model to  be service based, adding more Apache Hadoop
> components like Apache YARN, Apache Storm, Apache Kafka, Apache Nifi,
> Apache Ranger KMS into Ranger Authorizing  model for security and making it
> into a core product in the Apache Hadoop security space. PPMC has exhibited
> a clear understanding of this growing apache community by electing  4
> individuals as committers  and  inculding 22 individuals as contributors to
> the Apache Ranger project. PPMC also has done 8 successful releases under
> the guidance of mentors demonstrating their mastery over AFS’s IP policies.
>
> An voting was conducted within Apache Ranger Community to graduate Apache
> Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or
> –1 votes.
> http://mail-archives.apache.org/mod_mbox/incubator-ranger-
> dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E
>
> Apache Ranger Project has shown a great perspective to become a true TLP.
> Following summary on the project reflects its accomplishment.
>
> Please vote on the Project resolution that is found in bottom to graduate
> Apache Ranger Project from Incubator to Top Level Project.
>
> [ ] +1 Graduate Apache Ranger from the Incubator.
> [ ] +0 No opinion
> [ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide
> the reason)
>
> This VOTE will be opened for next 72 hours.
>
> Thanks all Mentors and Apache Ranger Project members for their support and
> contributions.
>
> Here is my vote +1 (binding)
>
> Project Summary:
> =
>
> http://incubator.apache.org/projects/ranger.html
>
> Project website:
> =
>
> http://ranger.incubator.apache.org
>
> Project Documentation:
> ===
>
> http://ranger.incubator.apache.org/index.html
> http://ranger.incubator.apache.org/quick_start_guide.html
> https://cwiki.apache.org/confluence/display/RANGER/Release+Folders
>
> Project maturity Assessment:
> ===
>
> https://cwiki.apache.org/confluence/display/RANGER/
> Apache+Ranger+Project+Ma
> turity+Model
>
> Proposed PMC size: 17
>
> Total number of committers   : 14 members
> Total number of contributors : 22 members
>
> PMC affiliation (* indicated chair)
>
> * Hortonworks (9)
>Privacera (2)
>BlueTalon (1)
>Others(1)
>
> 1802 commits on develop
> 22 contributors across all branches
> Dev list averaged ~50 msgs/month in 2016
> User list averaged ~40 msgs/month in 2016
> 1208 issues created
> 997 issues resolved
>
> Committer’s affiliation:
> ===
> Active:
> Hortonworks
> Talend
> Freestone infotech
> BlueTalon
> eBay
> Others
>
>
> Apache Ranger Top Level Project Resolution:
> 
>
> Establish the Apache Ranger Project
>
> 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 a data management platform That provides real-time, consistent access
> to data-intensive applications throughout widely distributed cloud
> architectures.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Ranger Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED,that the Apache Ranger Project be and hereby is responsible for
> the creation and maintenance of software related to a data management
> platform that provides real-time, consistent access to data-intensive
> applications throughout widely distributed cloud architectures.
>
> RESOLVED, that the office of "Vice President, Apache Ranger" 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 Ranger
> Project, and to have primary responsibility for management of the projects
> within the scope of responsibility of the Apache Ranger 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 Ranger Project:
>
> Alok La
> la...@apache.org
> Alan Gates
> ga...@apache.org
> Balaji Ganesan
> 

Re: [VOTE] Graduate Apache Ranger Project from the Incubator - Resending with additional mail distro

[Chris Nauroth]

+1 (binding)

Chris Nauroth

On Wed, Jan 4, 2017 at 2:48 PM, Ramesh Mani  wrote:

> Dear Incubator members,
>
> Apache Ranger Project community has successfully released 0.6.2 version
> and with it there had been a lot of discussion within Apache Ranger
> community to consider graduation to TLP. Apache Ranger entered into
> incubation on 24th July 2014 and from this welcoming community had done a
> tremendous job in resolving various technical hurdles like refactoring the
> project core model to  be service based, adding more Apache Hadoop
> components like Apache YARN, Apache Storm, Apache Kafka, Apache Nifi,
> Apache Ranger KMS into Ranger Authorizing  model for security and making it
> into a core product in the Apache Hadoop security space. PPMC has exhibited
> a clear understanding of this growing apache community by electing  4
> individuals as committers  and  inculding 22 individuals as contributors to
> the Apache Ranger project. PPMC also has done 8 successful releases under
> the guidance of mentors demonstrating their mastery over AFS’s IP policies.
>
> An voting was conducted within Apache Ranger Community to graduate Apache
> Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or
> –1 votes.
> http://mail-archives.apache.org/mod_mbox/incubator-ranger-
> dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E
>
> Apache Ranger Project has shown a great perspective to become a true TLP.
> Following summary on the project reflects its accomplishment.
>
> Please vote on the Project resolution that is found in bottom to graduate
> Apache Ranger Project from Incubator to Top Level Project.
>
> [ ] +1 Graduate Apache Ranger from the Incubator.
> [ ] +0 No opinion
> [ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide
> the reason)
>
> This VOTE will be opened for next 72 hours.
>
> Thanks all Mentors and Apache Ranger Project members for their support and
> contributions.
>
> Here is my vote +1 (binding)
>
> Project Summary:
> =
>
> http://incubator.apache.org/projects/ranger.html
>
> Project website:
> =
>
> http://ranger.incubator.apache.org
>
> Project Documentation:
> ===
>
> http://ranger.incubator.apache.org/index.html
> http://ranger.incubator.apache.org/quick_start_guide.html
> https://cwiki.apache.org/confluence/display/RANGER/Release+Folders
>
> Project maturity Assessment:
> ===
>
> https://cwiki.apache.org/confluence/display/RANGER/
> Apache+Ranger+Project+Ma
> turity+Model
>
> Proposed PMC size: 17
>
> Total number of committers   : 14 members
> Total number of contributors : 22 members
>
> PMC affiliation (* indicated chair)
>
> * Hortonworks (9)
>Privacera (2)
>BlueTalon (1)
>Others(1)
>
> 1802 commits on develop
> 22 contributors across all branches
> Dev list averaged ~50 msgs/month in 2016
> User list averaged ~40 msgs/month in 2016
> 1208 issues created
> 997 issues resolved
>
> Committer’s affiliation:
> ===
> Active:
> Hortonworks
> Talend
> Freestone infotech
> BlueTalon
> eBay
> Others
>
>
> Apache Ranger Top Level Project Resolution:
> 
>
> Establish the Apache Ranger Project
>
> 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 a data management platform That provides real-time, consistent access
> to data-intensive applications throughout widely distributed cloud
> architectures.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Ranger Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED,that the Apache Ranger Project be and hereby is responsible for
> the creation and maintenance of software related to a data management
> platform that provides real-time, consistent access to data-intensive
> applications throughout widely distributed cloud architectures.
>
> RESOLVED, that the office of "Vice President, Apache Ranger" 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 Ranger
> Project, and to have primary responsibility for management of the projects
> within the scope of responsibility of the Apache Ranger 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 Ranger Project:
>
> Alok La
> la...@apache.org
> Alan Gates
> ga...@apache.org
> Balaji Ganesan
> 

Write access to January report page

[Niclas Hedhman]

Hi,
Isn't the https://wiki.apache.org/incubator/January2017 supposed to be
editable by Mentors/IPMC members?

Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org  - New Energy for Java

Wiki Contributor

[Randall Leeds]

Would someone kindly add me as a contributor to the incubator wiki?

My username is RandallLeeds.

Thank you.

Re: [VOTE] Graduate Apache Ranger Project from the Incubator - Resending with additional mail distro

[Selvamohan Neethiraj]

+1

Thanks a lot Ramesh for your efforts in getting the TLP process nailed down. 
Thanks to all ranger developers/user community for your continued support and 
contribution to the growth of this project. 

Thanks,
Selva- 


On 1/4/17, 5:48 PM, "Ramesh Mani"  wrote:

Dear Incubator members,

Apache Ranger Project community has successfully released 0.6.2 version and 
with it there had been a lot of discussion within Apache Ranger community to 
consider graduation to TLP. Apache Ranger entered into incubation on 24th July 
2014 and from this welcoming community had done a tremendous job in resolving 
various technical hurdles like refactoring the project core model to  be 
service based, adding more Apache Hadoop components like Apache YARN, Apache 
Storm, Apache Kafka, Apache Nifi,  Apache Ranger KMS into Ranger Authorizing  
model for security and making it into a core product in the Apache Hadoop 
security space. PPMC has exhibited a clear understanding of this growing apache 
community by electing  4 individuals as committers  and  inculding 22 
individuals as contributors to the Apache Ranger project. PPMC also has done 8 
successful releases under the guidance of mentors demonstrating their mastery 
over AFS’s IP policies.

An voting was conducted within Apache Ranger Community to graduate Apache 
Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or –1 
votes.

http://mail-archives.apache.org/mod_mbox/incubator-ranger-dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E

Apache Ranger Project has shown a great perspective to become a true TLP. 
Following summary on the project reflects its accomplishment.

Please vote on the Project resolution that is found in bottom to graduate 
Apache Ranger Project from Incubator to Top Level Project.

[ ] +1 Graduate Apache Ranger from the Incubator.
[ ] +0 No opinion
[ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide the 
reason)

This VOTE will be opened for next 72 hours.

Thanks all Mentors and Apache Ranger Project members for their support and 
contributions.

Here is my vote +1 (binding)

Project Summary:
=

http://incubator.apache.org/projects/ranger.html

Project website:
=

http://ranger.incubator.apache.org

Project Documentation:
===

http://ranger.incubator.apache.org/index.html
http://ranger.incubator.apache.org/quick_start_guide.html
https://cwiki.apache.org/confluence/display/RANGER/Release+Folders

Project maturity Assessment:
===

https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+Project+Ma
turity+Model

Proposed PMC size: 17

Total number of committers   : 14 members
Total number of contributors : 22 members

PMC affiliation (* indicated chair)

* Hortonworks (9)
   Privacera (2)
   BlueTalon (1)
   Others(1)

1802 commits on develop
22 contributors across all branches
Dev list averaged ~50 msgs/month in 2016
User list averaged ~40 msgs/month in 2016
1208 issues created
997 issues resolved

Committer’s affiliation:
===
Active:
Hortonworks
Talend
Freestone infotech
BlueTalon
eBay
Others


Apache Ranger Top Level Project Resolution:


Establish the Apache Ranger Project

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 a data management platform That provides real-time, consistent access
to data-intensive applications throughout widely distributed cloud
architectures.

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

RESOLVED,that the Apache Ranger Project be and hereby is responsible for
the creation and maintenance of software related to a data management
platform that provides real-time, consistent access to data-intensive
applications throughout widely distributed cloud architectures.

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

[VOTE] Graduate Apache Ranger Project from the Incubator - Resending with additional mail distro

[Ramesh Mani]

Dear Incubator members,

Apache Ranger Project community has successfully released 0.6.2 version and 
with it there had been a lot of discussion within Apache Ranger community to 
consider graduation to TLP. Apache Ranger entered into incubation on 24th July 
2014 and from this welcoming community had done a tremendous job in resolving 
various technical hurdles like refactoring the project core model to  be 
service based, adding more Apache Hadoop components like Apache YARN, Apache 
Storm, Apache Kafka, Apache Nifi,  Apache Ranger KMS into Ranger Authorizing  
model for security and making it into a core product in the Apache Hadoop 
security space. PPMC has exhibited a clear understanding of this growing apache 
community by electing  4 individuals as committers  and  inculding 22 
individuals as contributors to the Apache Ranger project. PPMC also has done 8 
successful releases under the guidance of mentors demonstrating their mastery 
over AFS’s IP policies.

An voting was conducted within Apache Ranger Community to graduate Apache 
Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or –1 
votes.
http://mail-archives.apache.org/mod_mbox/incubator-ranger-dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E

Apache Ranger Project has shown a great perspective to become a true TLP. 
Following summary on the project reflects its accomplishment.

Please vote on the Project resolution that is found in bottom to graduate 
Apache Ranger Project from Incubator to Top Level Project.

[ ] +1 Graduate Apache Ranger from the Incubator.
[ ] +0 No opinion
[ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide the 
reason)

This VOTE will be opened for next 72 hours.

Thanks all Mentors and Apache Ranger Project members for their support and 
contributions.

Here is my vote +1 (binding)

Project Summary:
=

http://incubator.apache.org/projects/ranger.html

Project website:
=

http://ranger.incubator.apache.org

Project Documentation:
===

http://ranger.incubator.apache.org/index.html
http://ranger.incubator.apache.org/quick_start_guide.html
https://cwiki.apache.org/confluence/display/RANGER/Release+Folders

Project maturity Assessment:
===

https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+Project+Ma
turity+Model

Proposed PMC size: 17

Total number of committers   : 14 members
Total number of contributors : 22 members

PMC affiliation (* indicated chair)

* Hortonworks (9)
   Privacera (2)
   BlueTalon (1)
   Others(1)

1802 commits on develop
22 contributors across all branches
Dev list averaged ~50 msgs/month in 2016
User list averaged ~40 msgs/month in 2016
1208 issues created
997 issues resolved

Committer’s affiliation:
===
Active:
Hortonworks
Talend
Freestone infotech
BlueTalon
eBay
Others


Apache Ranger Top Level Project Resolution:


Establish the Apache Ranger Project

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 a data management platform That provides real-time, consistent access
to data-intensive applications throughout widely distributed cloud
architectures.

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

RESOLVED,that the Apache Ranger Project be and hereby is responsible for
the creation and maintenance of software related to a data management
platform that provides real-time, consistent access to data-intensive
applications throughout widely distributed cloud architectures.

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

Alok La
la...@apache.org
Alan Gates
ga...@apache.org
Balaji Ganesan
bgane...@apache.org
Colm O hEigeartaigh
cohei...@apache.org
Daniel Gruno
rum...@cord.dk
Devaraj Das

Re: [VOTE] Graduate Apache Ranger Project from the Incubator

[Chris Nauroth]

+1 (binding)


Chris Nauroth

On Tue, Jan 3, 2017 at 4:21 PM, Ramesh Mani  wrote:

> Dear Incubator members,
>
> Apache Ranger Project community has successfully released 0.6.2 version
> and with it there had been a lot of discussion within Apache Ranger
> community to consider graduation to TLP. Apache Ranger entered into
> incubation on 24th July 2014 and from this welcoming community had done a
> tremendous job in resolving various technical hurdles like refactoring the
> project core model to  be service based, adding more Apache Hadoop
> components like Apache YARN, Apache Storm, Apache Kafka, Apache Nifi,
> Apache Ranger KMS into Ranger Authorizing  model for security and making it
> into a core product in the Apache Hadoop security space. PPMC has exhibited
> a clear understanding of this growing apache community by electing  4
> individuals as committers  and  inculding 22 individuals as contributors to
> the Apache Ranger project. PPMC also has done 8 successful releases under
> the guidance of mentors demonstrating their mastery over AFS’s IP policies.
>
> An voting was conducted within Apache Ranger Community to graduate Apache
> Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or
> –1 votes.
> http://mail-archives.apache.org/mod_mbox/incubator-ranger-
> dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E
>
> Apache Ranger Project has shown a great perspective to become a true TLP.
> Following summary on the project reflects its accomplishment.
>
> Please vote on the Project resolution that is found in bottom to graduate
> Apache Ranger Project from Incubator to Top Level Project.
>
> [ ] +1 Graduate Apache Ranger from the Incubator.
> [ ] +0 No opinion
> [ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide
> the reason)
>
> This VOTE will be opened for next 72 hours.
>
> Thanks all Mentors and Apache Ranger Project members for their support and
> contributions.
>
> Here is my vote +1 (binding)
>
> Project Summary:
> =
>
> http://incubator.apache.org/projects/ranger.html
>
> Project website:
> =
>
> http://ranger.incubator.apache.org
>
> Project Documentation:
> ===
>
> http://ranger.incubator.apache.org/index.html
> http://ranger.incubator.apache.org/quick_start_guide.html
> https://cwiki.apache.org/confluence/display/RANGER/Release+Folders
>
> Project maturity Assessment:
> ===
>
> https://cwiki.apache.org/confluence/display/RANGER/
> Apache+Ranger+Project+Ma
> turity+Model
>
> Proposed PMC size: 17
>
> Total number of committers   : 14 members
> Total number of contributors : 22 members
>
> PMC affiliation (* indicated chair)
>
> * Hortonworks (9)
>Privacera (2)
>BlueTalon (1)
>Others(1)
>
> 1802 commits on develop
> 22 contributors across all branches
> Dev list averaged ~50 msgs/month in 2016
> User list averaged ~40 msgs/month in 2016
> 1208 issues created
> 997 issues resolved
>
> Committer’s affiliation:
> ===
> Active:
> Hortonworks
> Talend
> Freestone infotech
> BlueTalon
> eBay
> Others
>
>
> Apache Ranger Top Level Project Resolution:
> 
>
> Establish the Apache Ranger Project
>
> 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 a data management platform That provides real-time, consistent access
> to data-intensive applications throughout widely distributed cloud
> architectures.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Ranger Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED,that the Apache Ranger Project be and hereby is responsible for
> the creation and maintenance of software related to a data management
> platform that provides real-time, consistent access to data-intensive
> applications throughout widely distributed cloud architectures.
>
> RESOLVED, that the office of "Vice President, Apache Ranger" 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 Ranger
> Project, and to have primary responsibility for management of the projects
> within the scope of responsibility of the Apache Ranger 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 Ranger Project:
>
> Alok La
> la...@apache.org
> Alan Gates
> ga...@apache.org
> Balaji Ganesan
> 

[CANCEL] [VOTE] Graduate Apache Ranger Project from the Incubator

[Ramesh Mani]

Cancelling this Voting thread as I had to start a new voting thread with all 
the members.

Thanks,
Ramesh

From: Ramesh Mani >
Date: Tuesday, January 3, 2017 at 4:21 PM
To: "general@incubator.apache.org" 
>
Subject: [VOTE] Graduate Apache Ranger Project from the Incubator

Dear Incubator members,

Apache Ranger Project community has successfully released 0.6.2 version and 
with it there had been a lot of discussion within Apache Ranger community to 
consider graduation to TLP. Apache Ranger entered into incubation on 24th July 
2014 and from this welcoming community had done a tremendous job in resolving 
various technical hurdles like refactoring the project core model to  be 
service based, adding more Apache Hadoop components like Apache YARN, Apache 
Storm, Apache Kafka, Apache Nifi,  Apache Ranger KMS into Ranger Authorizing  
model for security and making it into a core product in the Apache Hadoop 
security space. PPMC has exhibited a clear understanding of this growing apache 
community by electing  4 individuals as committers  and  inculding 22 
individuals as contributors to the Apache Ranger project. PPMC also has done 8 
successful releases under the guidance of mentors demonstrating their mastery 
over AFS’s IP policies.

An voting was conducted within Apache Ranger Community to graduate Apache 
Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or –1 
votes.
http://mail-archives.apache.org/mod_mbox/incubator-ranger-dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E

Apache Ranger Project has shown a great perspective to become a true TLP. 
Following summary on the project reflects its accomplishment.

Please vote on the Project resolution that is found in bottom to graduate 
Apache Ranger Project from Incubator to Top Level Project.

[ ] +1 Graduate Apache Ranger from the Incubator.
[ ] +0 No opinion
[ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide the 
reason)

This VOTE will be opened for next 72 hours.

Thanks all Mentors and Apache Ranger Project members for their support and 
contributions.

Here is my vote +1 (binding)

Project Summary:
=

http://incubator.apache.org/projects/ranger.html

Project website:
=

http://ranger.incubator.apache.org

Project Documentation:
===

http://ranger.incubator.apache.org/index.html
http://ranger.incubator.apache.org/quick_start_guide.html
https://cwiki.apache.org/confluence/display/RANGER/Release+Folders

Project maturity Assessment:
===

https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+Project+Ma
turity+Model

Proposed PMC size: 17

Total number of committers   : 14 members
Total number of contributors : 22 members

PMC affiliation (* indicated chair)

* Hortonworks (9)
   Privacera (2)
   BlueTalon (1)
   Others(1)

1802 commits on develop
22 contributors across all branches
Dev list averaged ~50 msgs/month in 2016
User list averaged ~40 msgs/month in 2016
1208 issues created
997 issues resolved

Committer’s affiliation:
===
Active:
Hortonworks
Talend
Freestone infotech
BlueTalon
eBay
Others


Apache Ranger Top Level Project Resolution:


Establish the Apache Ranger Project

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 a data management platform That provides real-time, consistent access
to data-intensive applications throughout widely distributed cloud
architectures.

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

RESOLVED,that the Apache Ranger Project be and hereby is responsible for
the creation and maintenance of software related to a data management
platform that provides real-time, consistent access to data-intensive
applications throughout widely distributed cloud architectures.

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

Alok La

[VOTE] Graduate Apache Ranger Project from the Incubator

[Ramesh Mani]

Dear Incubator members,

Apache Ranger Project community has successfully released 0.6.2 version and 
with it there had been a lot of discussion within Apache Ranger community to 
consider graduation to TLP. Apache Ranger entered into incubation on 24th July 
2014 and from this welcoming community had done a tremendous job in resolving 
various technical hurdles like refactoring the project core model to  be 
service based, adding more Apache Hadoop components like Apache YARN, Apache 
Storm, Apache Kafka, Apache Nifi,  Apache Ranger KMS into Ranger Authorizing  
model for security and making it into a core product in the Apache Hadoop 
security space. PPMC has exhibited a clear understanding of this growing apache 
community by electing  4 individuals as committers  and  inculding 22 
individuals as contributors to the Apache Ranger project. PPMC also has done 8 
successful releases under the guidance of mentors demonstrating their mastery 
over AFS’s IP policies.

An voting was conducted within Apache Ranger Community to graduate Apache 
Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or –1 
votes.
http://mail-archives.apache.org/mod_mbox/incubator-ranger-dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E

Apache Ranger Project has shown a great perspective to become a true TLP. 
Following summary on the project reflects its accomplishment.

Please vote on the Project resolution that is found in bottom to graduate 
Apache Ranger Project from Incubator to Top Level Project.

[ ] +1 Graduate Apache Ranger from the Incubator.
[ ] +0 No opinion
[ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide the 
reason)

This VOTE will be opened for next 72 hours.

Thanks all Mentors and Apache Ranger Project members for their support and 
contributions.

Here is my vote +1 (binding)

Project Summary:
=

http://incubator.apache.org/projects/ranger.html

Project website:
=

http://ranger.incubator.apache.org

Project Documentation:
===

http://ranger.incubator.apache.org/index.html
http://ranger.incubator.apache.org/quick_start_guide.html
https://cwiki.apache.org/confluence/display/RANGER/Release+Folders

Project maturity Assessment:
===

https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+Project+Ma
turity+Model

Proposed PMC size: 17

Total number of committers   : 14 members
Total number of contributors : 22 members

PMC affiliation (* indicated chair)

* Hortonworks (9)
   Privacera (2)
   BlueTalon (1)
   Others(1)

1802 commits on develop
22 contributors across all branches
Dev list averaged ~50 msgs/month in 2016
User list averaged ~40 msgs/month in 2016
1208 issues created
997 issues resolved

Committer’s affiliation:
===
Active:
Hortonworks
Talend
Freestone infotech
BlueTalon
eBay
Others


Apache Ranger Top Level Project Resolution:


Establish the Apache Ranger Project

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 a data management platform That provides real-time, consistent access
to data-intensive applications throughout widely distributed cloud
architectures.

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

RESOLVED,that the Apache Ranger Project be and hereby is responsible for
the creation and maintenance of software related to a data management
platform that provides real-time, consistent access to data-intensive
applications throughout widely distributed cloud architectures.

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

Alok La
la...@apache.org
Alan Gates
ga...@apache.org
Balaji Ganesan
bgane...@apache.org
Colm O hEigeartaigh
cohei...@apache.org
Daniel Gruno
rum...@cord.dk
Devaraj Das

Re: [VOTE] Graduate Apache Ranger Project from the Incubator

[Julian Hyde]

+1 (binding)

Activity on dev looks very healthy, several releases, active
contributors are from a reasonably diverse set of employers.

Good luck!

On Wed, Jan 4, 2017 at 10:53 AM, Roman Shaposhnik  wrote:
> On Tue, Jan 3, 2017 at 4:21 PM, Ramesh Mani  wrote:
>> Dear Incubator members,
>>
>> Apache Ranger Project community has successfully released 0.6.2 version and 
>> with it there had been a lot of discussion within Apache Ranger community to 
>> consider graduation to TLP. Apache Ranger entered into incubation on 24th 
>> July 2014 and from this welcoming community had done a tremendous job in 
>> resolving various technical hurdles like refactoring the project core model 
>> to  be service based, adding more Apache Hadoop components like Apache YARN, 
>> Apache Storm, Apache Kafka, Apache Nifi,  Apache Ranger KMS into Ranger 
>> Authorizing  model for security and making it into a core product in the 
>> Apache Hadoop security space. PPMC has exhibited a clear understanding of 
>> this growing apache community by electing  4 individuals as committers  and  
>> inculding 22 individuals as contributors to the Apache Ranger project. PPMC 
>> also has done 8 successful releases under the guidance of mentors 
>> demonstrating their mastery over AFS’s IP policies.
>>
>> An voting was conducted within Apache Ranger Community to graduate Apache 
>> Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or 
>> –1 votes.
>> http://mail-archives.apache.org/mod_mbox/incubator-ranger-dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E
>>
>> Apache Ranger Project has shown a great perspective to become a true TLP. 
>> Following summary on the project reflects its accomplishment.
>>
>> Please vote on the Project resolution that is found in bottom to graduate 
>> Apache Ranger Project from Incubator to Top Level Project.
>>
>> [ ] +1 Graduate Apache Ranger from the Incubator.
>> [ ] +0 No opinion
>> [ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide the 
>> reason)
>
> +1 (binding)
>
> 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: [VOTE] Graduate Apache Ranger Project from the Incubator

[Roman Shaposhnik]

On Tue, Jan 3, 2017 at 4:21 PM, Ramesh Mani  wrote:
> Dear Incubator members,
>
> Apache Ranger Project community has successfully released 0.6.2 version and 
> with it there had been a lot of discussion within Apache Ranger community to 
> consider graduation to TLP. Apache Ranger entered into incubation on 24th 
> July 2014 and from this welcoming community had done a tremendous job in 
> resolving various technical hurdles like refactoring the project core model 
> to  be service based, adding more Apache Hadoop components like Apache YARN, 
> Apache Storm, Apache Kafka, Apache Nifi,  Apache Ranger KMS into Ranger 
> Authorizing  model for security and making it into a core product in the 
> Apache Hadoop security space. PPMC has exhibited a clear understanding of 
> this growing apache community by electing  4 individuals as committers  and  
> inculding 22 individuals as contributors to the Apache Ranger project. PPMC 
> also has done 8 successful releases under the guidance of mentors 
> demonstrating their mastery over AFS’s IP policies.
>
> An voting was conducted within Apache Ranger Community to graduate Apache 
> Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or 
> –1 votes.
> http://mail-archives.apache.org/mod_mbox/incubator-ranger-dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E
>
> Apache Ranger Project has shown a great perspective to become a true TLP. 
> Following summary on the project reflects its accomplishment.
>
> Please vote on the Project resolution that is found in bottom to graduate 
> Apache Ranger Project from Incubator to Top Level Project.
>
> [ ] +1 Graduate Apache Ranger from the Incubator.
> [ ] +0 No opinion
> [ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide the 
> reason)

+1 (binding)

Thanks,
Roman.

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

Re: [DISCUSS] Significance of Artifact Names

[Cédric Champeau]

Cross-posting since I missed this topic in the first place. My apologies
for the duplicate:

I would argue that one of the Foundation mottos is "community first". In
that sense, enforcing a policy like that is not thinking about users. It's
adding a burden they don't care about. I am strongly against anything that
enforces technical requirements where there shouldn't be. Enforcing Maven
coordinates, or enforcing a _version string_ is going too far into the
technical details. There's branding and there's technical. Maven already
makes the mistake of mixing how you build the project and how you consume
it, which is the root of a lot of pain. Let's not make the error again at
the policy level, it's a total non sense.

The Foundation can host a variety of different projects, from new ones
written in C to "old" ones written in Java, and all the different things we
can see in our ecosystem: Javascript, Go, ... Enforcing a rule about _how_
you consume a project, by Maven coordinates or version string is an
implementation detail. Branding the project is not. In other words, as long
as your package name, maven artifacts, Docker images, ... do not infringe
copyright, it's a no brainer. However, the project page *must* state about
incubating status and *explain* what it means. A *lot* of people don't care
what *incubating* means in the Foundation sense (and even worse, podling
can have very negative image). It would have been terrible for Groovy to
change the way people consume the artifacts, making them think of low
quality software, because they don't understand what "incubating" mean. To
me it sounds even worse than "alpha". Since "incubating" is meant towards
*incubating project in the sense of the Apache community*, it should *only*
appear where it makes sense: DISCLAIMER, web site, ... That is to say
everywhere you can give an explanation about its meaning. It should also
appear in the source package name, because that is what we legally care
about. But the version *string*, inside the package, is purely, again,
internal details, just like package name, Maven coordinates, NPM
coordinates, ... Why would you force me to use a version pattern if what I
want is the revision hash as the version number? The policy should NOT
impact how we design software or how we want the design to be. There are
potential technical issues with putting such a label in a version string
(OSGi, Jigsaw, dependency resolution with Maven, Ivy or Gradle, ... just to
name the Java ecosystem), so to me enforcing the policy here is just an
error.

As for Groovy and the Codehaus package and Maven coordinates, we plan to
change this in a major, breaking, 3.0 release, not before. Because it would
be a breaking change, and some dependency management engines, typically,
are very poor when it comes to dependency substitution, which would add too
much burden for people to upgrade. We had an agreement with Ben from
Codehaus to use the name when we joined the ASF.



2017-01-04 6:24 GMT+01:00 Alex Harui :

> Sorry for top-posting.
>
> It's always been interesting to me that the ASF says that it only releases
> source code, but still has policy about the contents of convenience
> binaries such as [6].  So, I suppose the ASF could dictate naming of
> binary packages.
>
> I know very little about Maven, but in my mind, the -incubating suffix is
> supposed to help warn the customer or cover the ASFs butt or both.  I
> don't know if anybody actually points to a source artifact from Maven, but
> if the downstream user is being careful enough to work from sources, it
> makes sense to me to put in an additional warning by adding the
> -incubating suffix to the source package. It says that these source
> packages are not like other ASF source packages without having to open the
> package.
>
> But for a binary artifact, given that the ASF already thinks it isn't
> audit-able and thus not an official release, does the customer care that
> the artifact may not be ASF-grade (especially if the artifacts were
> already considered open before entering Apache)?  Do they really need
> early warning?  Would it really affect the ASF if something bad was later
> found in a binary artifact?
>
> IMO, the answer to all 3 questions is no.  I don't know how hard it is to
> suffix the source artifact with -incubating but not for the binary
> artifacts.  But if it is hard, could the next version of Maven do it?
>
> Also, if someone is concerned enough about the licensing of the artifacts
> they depend on to go digging through all of the poms of their binary
> dependencies, wouldn't they check the  section of each POM?
> According to [7] there is a comments section there.  Could incubating
> podlings be required to make it clear in the  section that this
> thing may not be fully ASF compliant instead of having to add a suffix to
> the version of their binary artifacts?
>
> My 2 cents,
> -Alex
>
> [6] https://www.apache.org/legal/src-headers.html#faq-binaries
> 

Re: [VOTE] Drop incubating requirement of Maven artifacts

[John D. Ament]

I'll point out that this is a cancel thread..., I'm fine if people want to
continue chatting in here, but I started a new discussion on
https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0fd0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E

I'll try to answer questions I saw pop up

Mark Struberg: No, ignoring commons/log4j for a minute, other projects
continue to work under legacy maven coordinates.  Includes one i already
linked to - groovy, also freemarker, zest/polygene (a project that went
straight to TLP).  There's neither foundation policy nor legal impact by
using other very similar marks, especially when the project's name hasn't
changed.  Publishing under "com.oracle.someProduct" would probably be bad
from a marks standpoint since it shows as property of some other company,
whereas former foundations or completely independent projects.  Plus, the
way maven central works you own the entire tld, except for cases where its
a known third party publisher.  For instance, I own (personally) the domain
name ament.ws and have access to publish under maven coordinates
ws.ament.*.  Github users have to request io.github.themselves manually.  I
assume that something similar exists between the ASF and Sonatype to enable
publishing under org.apache, and ensure that no one else can use org.apache.

Pierre Smits: This is something I expected to be a hot topic.  So while
100% consensus isn't expected, a clear path forward is something to expect,
even if not everyone is happy about the outcome.  FWIW, there seem to be 3
different POVs (that I could identify) on those who were against the idea:

- Those who thought this was dropping -incubating from the Apache release
archive.
- Those who acknowledged that this was maven specific and felt it should
continue as is.
- Those who acknowledged that this was currently maven specific and should
be made broader.

John


On Wed, Jan 4, 2017 at 4:49 AM Martijn Dashorst 
wrote:

> Late to the party, but having a long think about this is sometimes
> beneficial.
>
> +1 to drop the -incubator/-incubating version attachment for any
> artifacts (not just Maven).
>
> My reasoning is the following:
>
> Source code lives longer than any community. Long after a podling has
> gone through the incubator, the code remains. The releases remain. How
> a community conducts itself doesn't reflect on the released code. Code
> just exists.
>
> While it is important for current users coming to a project to know
> the status of the community, does it really matter if the code is in
> incubation or has graduated? Does that matter in 5 years whether the
> code of foo-1.2 was incubating while the community has graduated and
> now resides in the attic?
>
> Releases have a long life. Code has a long life. We shouldn't mix
> timely things like project status with long lived things like
> releases. Websites are examples of timely, short lived documents and
> incubation status is a (relatively) short lived state in the long
> lives of projects. We shouldn't burden the long lived artifacts with
> the orthogonal status of a project.
>
> Martijn
>
>
>
>
>
>
>
> On Mon, Jan 2, 2017 at 6:22 PM, John D. Ament 
> wrote:
> > All,
> >
> > I'm calling to vote on a proposed policy change.  Current guide at [1]
> > indicates that maven artifacts should include incubator (or incubating)
> in
> > the version string of maven artifacts.  Its labeled as a best practice,
> not
> > a requirement and is not a policy followed on other repository management
> > tools (e.g. PyPi).
> >
> > I therefore push forward that the incubator will cease expecting
> java-based
> > projects to publish artifacts with "-incubating" in the version string,
> > with the understanding that:
> >
> > - Incubating is a term used to refer to a project's stability, not a
> > release's stability.  It is generally understood that incubating projects
> > are not necessarily immature, but may have a potential of failing to
> become
> > a TLP.
> > - Podling releases are endorsed, the podling itself is not endorsed.  We
> > will not approve releases that are blatantly against ASF policies.
> >
> >
> > [ ] +1 Drop the -incubator/-incubating expectation of maven projects
> > [ ] +/0
> > [ ] -1 Don't drop because
> >
> >
> > [1]:
> > http://incubator.apache.org/guides/release-java.html#best-practice-maven
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Martijn Dashorst]

Late to the party, but having a long think about this is sometimes beneficial.

+1 to drop the -incubator/-incubating version attachment for any
artifacts (not just Maven).

My reasoning is the following:

Source code lives longer than any community. Long after a podling has
gone through the incubator, the code remains. The releases remain. How
a community conducts itself doesn't reflect on the released code. Code
just exists.

While it is important for current users coming to a project to know
the status of the community, does it really matter if the code is in
incubation or has graduated? Does that matter in 5 years whether the
code of foo-1.2 was incubating while the community has graduated and
now resides in the attic?

Releases have a long life. Code has a long life. We shouldn't mix
timely things like project status with long lived things like
releases. Websites are examples of timely, short lived documents and
incubation status is a (relatively) short lived state in the long
lives of projects. We shouldn't burden the long lived artifacts with
the orthogonal status of a project.

Martijn







On Mon, Jan 2, 2017 at 6:22 PM, John D. Ament  wrote:
> All,
>
> I'm calling to vote on a proposed policy change.  Current guide at [1]
> indicates that maven artifacts should include incubator (or incubating) in
> the version string of maven artifacts.  Its labeled as a best practice, not
> a requirement and is not a policy followed on other repository management
> tools (e.g. PyPi).
>
> I therefore push forward that the incubator will cease expecting java-based
> projects to publish artifacts with "-incubating" in the version string,
> with the understanding that:
>
> - Incubating is a term used to refer to a project's stability, not a
> release's stability.  It is generally understood that incubating projects
> are not necessarily immature, but may have a potential of failing to become
> a TLP.
> - Podling releases are endorsed, the podling itself is not endorsed.  We
> will not approve releases that are blatantly against ASF policies.
>
>
> [ ] +1 Drop the -incubator/-incubating expectation of maven projects
> [ ] +/0
> [ ] -1 Don't drop because
>
>
> [1]:
> http://incubator.apache.org/guides/release-java.html#best-practice-maven



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Jochen Theodorou]

On 04.01.2017 07:28, Mark Struberg wrote:
[...]

I'm a bit surprised that groovy still uses the org.codehaus groupId, but I 
guess they have a deal with Ben (the former owner and thus (former?) copyright 
holder of 'Codehaus').
So while this will work for now I guess that even groovy will move to 
org.apache.groovy in the long term (maybe with a new major version).


A new major version is a big thing for Groovy, but yes. In our view it 
is the only realistic way, since people can expect breaking changes 
between major versions and that includes in our view package names as 
well as group ids.



It's not a big deal YET, but http://codehaus.org is not reachable anymore. And 
if anyone buys this domain he will have a much better position regarding 
trademarks than we do.
What if someone buys the codehaus.org domain and publishes own artifacts under 
org.codehaus.groovy? Can we even prevent someone else to e.g publish 
org.codehaus.groovyng artifacts?


Assume we change and 2 months later somebody does that? How is the 
situation then any better?


Actually I wonder if Ben would donate the domain to the ASF...

bye Jochen

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

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Greg Stein]

Below, explains my own views on the version string (and other labels and
points to mention "-incubating"), and is why I gave a +1 to John's vote.
Less invasion.

Re: package names. Apache Subversion introduced new org.apache packages in
its new release, and left it's old org.tigris packages available for
backwards compat. Both are shims to expose our C libraries into Java, so
that approach may have been easier for us, compared to Apache Groovy's
situation.

On Jan 4, 2017 02:25, "Cédric Champeau"  wrote:

> I would argue that one of the Foundation mottos is "community first". In
> that sense, enforcing a policy like that is not thinking about users. It's
> adding a burden they don't care about. I am strongly against anything that
> enforces technical requirements where there shouldn't be. Enforcing Maven
> coordinates, or enforcing a _version string_ is going too far into the
> technical details. There's branding and there's technical. Maven already
> makes the mistake of mixing how you build the project and how you consume
> it, which is the root of a lot of pain. Let's not make the error again at
> the policy level, it's a total non sense.
>
> The Foundation can host a variety of different projects, from new ones
> written in C to "old" ones written in Java, and all the different things we
> can see in our ecosystem: Javascript, Go, ... Enforcing a rule about _how_
> you consume a project, by Maven coordinates or version string is an
> implementation detail. Branding the project is not. In other words, as long
> as your package name, maven artifacts, Docker images, ... do not infringe
> copyright, it's a no brainer. However, the project page *must* state about
> incubating status and *explain* what it means. A *lot* of people don't care
> what *incubating* means in the Foundation sense (and even worse, podling
> can have very negative image). It would have been terrible for Groovy to
> change the way people consume the artifacts, making them think of low
> quality software, because they don't understand what "incubating" mean. To
> me it sounds even worse than "alpha". Since "incubating" is meant towards
> *incubating project in the sense of the Apache community*, it should *only*
> appear where it makes sense: DISCLAIMER, web site, ... That is to say
> everywhere you can give an explanation about its meaning. It should also
> appear in the source package name, because that is what we legally care
> about. But the version *string*, inside the package, is purely, again,
> internal details, just like package name, Maven coordinates, NPM
> coordinates, ... Why would you force me to use a version pattern if what I
> want is the revision hash as the version number? The policy should NOT
> impact how we design software or how we want the design to be. There are
> potential technical issues with putting such a label in a version string
> (OSGi, Jigsaw, dependency resolution with Maven, Ivy or Gradle, ... just to
> name the Java ecosystem), so to me enforcing the policy here is just an
> error.
>
> As for Groovy and the Codehaus package and Maven coordinates, we plan to
> change this in a major, breaking, 3.0 release, not before. Because it would
> be a breaking change, and some dependency management engines, typically,
> are very poor when it comes to dependency substitution, which would add too
> much burden for people to upgrade. We had an agreement with Ben from
> Codehaus to use the name when we joined the ASF.
>
>
> 2017-01-04 8:51 GMT+01:00 Pierre Smits :
>
> > John,
> >
> > I guess the discussion will go on, every time the topic will be brought
> > forward to the public mailings lists. Conducting politics is part of the
> > human nature. Keeping the discussion going will have the Incubator
> project
> > running in circles. Calling a vote on a procedural change and reporting
> the
> > result will help the project.
> >
> > Not everything needs unanimous consent. A simple majority suffices to
> > establish a direction until the next vote on the same subject.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Wed, Jan 4, 2017 at 7:28 AM, Mark Struberg  >
> > wrote:
> >
> > > I guess you are talking about log4j/log4j or the various commons-*
> > > groupIds?
> > > This is true, but for completness sake I want to point out that there
> is
> > a
> > > difference to use a different _unused_ groupId vs using a _foreign_
> one.
> > >
> > > I guess everyone would agree that the ASF does not like to publish
> > > artifacts with a com.oracle groupId, right?
> > >
> > > I'm a bit surprised that groovy still uses the org.codehaus groupId,
> but
> > I
> > > guess they have a deal with Ben (the former owner and thus (former?)
> > > copyright holder of 'Codehaus').
> > > So while this will 

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Cédric Champeau]

I would argue that one of the Foundation mottos is "community first". In
that sense, enforcing a policy like that is not thinking about users. It's
adding a burden they don't care about. I am strongly against anything that
enforces technical requirements where there shouldn't be. Enforcing Maven
coordinates, or enforcing a _version string_ is going too far into the
technical details. There's branding and there's technical. Maven already
makes the mistake of mixing how you build the project and how you consume
it, which is the root of a lot of pain. Let's not make the error again at
the policy level, it's a total non sense.

The Foundation can host a variety of different projects, from new ones
written in C to "old" ones written in Java, and all the different things we
can see in our ecosystem: Javascript, Go, ... Enforcing a rule about _how_
you consume a project, by Maven coordinates or version string is an
implementation detail. Branding the project is not. In other words, as long
as your package name, maven artifacts, Docker images, ... do not infringe
copyright, it's a no brainer. However, the project page *must* state about
incubating status and *explain* what it means. A *lot* of people don't care
what *incubating* means in the Foundation sense (and even worse, podling
can have very negative image). It would have been terrible for Groovy to
change the way people consume the artifacts, making them think of low
quality software, because they don't understand what "incubating" mean. To
me it sounds even worse than "alpha". Since "incubating" is meant towards
*incubating project in the sense of the Apache community*, it should *only*
appear where it makes sense: DISCLAIMER, web site, ... That is to say
everywhere you can give an explanation about its meaning. It should also
appear in the source package name, because that is what we legally care
about. But the version *string*, inside the package, is purely, again,
internal details, just like package name, Maven coordinates, NPM
coordinates, ... Why would you force me to use a version pattern if what I
want is the revision hash as the version number? The policy should NOT
impact how we design software or how we want the design to be. There are
potential technical issues with putting such a label in a version string
(OSGi, Jigsaw, dependency resolution with Maven, Ivy or Gradle, ... just to
name the Java ecosystem), so to me enforcing the policy here is just an
error.

As for Groovy and the Codehaus package and Maven coordinates, we plan to
change this in a major, breaking, 3.0 release, not before. Because it would
be a breaking change, and some dependency management engines, typically,
are very poor when it comes to dependency substitution, which would add too
much burden for people to upgrade. We had an agreement with Ben from
Codehaus to use the name when we joined the ASF.


2017-01-04 8:51 GMT+01:00 Pierre Smits :

> John,
>
> I guess the discussion will go on, every time the topic will be brought
> forward to the public mailings lists. Conducting politics is part of the
> human nature. Keeping the discussion going will have the Incubator project
> running in circles. Calling a vote on a procedural change and reporting the
> result will help the project.
>
> Not everything needs unanimous consent. A simple majority suffices to
> establish a direction until the next vote on the same subject.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Jan 4, 2017 at 7:28 AM, Mark Struberg 
> wrote:
>
> > I guess you are talking about log4j/log4j or the various commons-*
> > groupIds?
> > This is true, but for completness sake I want to point out that there is
> a
> > difference to use a different _unused_ groupId vs using a _foreign_ one.
> >
> > I guess everyone would agree that the ASF does not like to publish
> > artifacts with a com.oracle groupId, right?
> >
> > I'm a bit surprised that groovy still uses the org.codehaus groupId, but
> I
> > guess they have a deal with Ben (the former owner and thus (former?)
> > copyright holder of 'Codehaus').
> > So while this will work for now I guess that even groovy will move to
> > org.apache.groovy in the long term (maybe with a new major version).
> >
> > It's not a big deal YET, but http://codehaus.org is not reachable
> > anymore. And if anyone buys this domain he will have a much better
> position
> > regarding trademarks than we do.
> > What if someone buys the codehaus.org domain and publishes own artifacts
> > under org.codehaus.groovy? Can we even prevent someone else to e.g
> publish
> > org.codehaus.groovyng artifacts?
> >
> > LieGrue,
> > strub
> >
> > > Am 04.01.2017 um 02:49 schrieb John D. Ament :
> > >
> > > On Tue, Jan 3, 2017 at 8:43 PM Daniel Dekany 
> > wrote:
> > >
> > 

Re: [VOTE] Graduate Apache Ranger Project from the Incubator

[Mark Struberg]

+1 (binding)

LieGrue,
strub


> Am 04.01.2017 um 01:21 schrieb Ramesh Mani :
> 
> Dear Incubator members,
> 
> Apache Ranger Project community has successfully released 0.6.2 version and 
> with it there had been a lot of discussion within Apache Ranger community to 
> consider graduation to TLP. Apache Ranger entered into incubation on 24th 
> July 2014 and from this welcoming community had done a tremendous job in 
> resolving various technical hurdles like refactoring the project core model 
> to  be service based, adding more Apache Hadoop components like Apache YARN, 
> Apache Storm, Apache Kafka, Apache Nifi,  Apache Ranger KMS into Ranger 
> Authorizing  model for security and making it into a core product in the 
> Apache Hadoop security space. PPMC has exhibited a clear understanding of 
> this growing apache community by electing  4 individuals as committers  and  
> inculding 22 individuals as contributors to the Apache Ranger project. PPMC 
> also has done 8 successful releases under the guidance of mentors 
> demonstrating their mastery over AFS’s IP policies.
> 
> An voting was conducted within Apache Ranger Community to graduate Apache 
> Ranger Project to Top Level Project. Vote passed with 16 +1 votes , no 0 or 
> –1 votes.
> http://mail-archives.apache.org/mod_mbox/incubator-ranger-dev/201612.mbox/%3CD479D4C8.11E4E%25rmani%40hortonworks.com%3E
> 
> Apache Ranger Project has shown a great perspective to become a true TLP. 
> Following summary on the project reflects its accomplishment.
> 
> Please vote on the Project resolution that is found in bottom to graduate 
> Apache Ranger Project from Incubator to Top Level Project.
> 
> [ ] +1 Graduate Apache Ranger from the Incubator.
> [ ] +0 No opinion
> [ ] -1 Don't graduate Apache Ranger from the Incubator ( please provide the 
> reason)
> 
> This VOTE will be opened for next 72 hours.
> 
> Thanks all Mentors and Apache Ranger Project members for their support and 
> contributions.
> 
> Here is my vote +1 (binding)
> 
> Project Summary:
> =
> 
> http://incubator.apache.org/projects/ranger.html
> 
> Project website:
> =
> 
> http://ranger.incubator.apache.org
> 
> Project Documentation:
> ===
> 
> http://ranger.incubator.apache.org/index.html
> http://ranger.incubator.apache.org/quick_start_guide.html
> https://cwiki.apache.org/confluence/display/RANGER/Release+Folders
> 
> Project maturity Assessment:
> ===
> 
> https://cwiki.apache.org/confluence/display/RANGER/Apache+Ranger+Project+Ma
> turity+Model
> 
> Proposed PMC size: 17
> 
> Total number of committers   : 14 members
> Total number of contributors : 22 members
> 
> PMC affiliation (* indicated chair)
> 
> * Hortonworks (9)
>   Privacera (2)
>   BlueTalon (1)
>   Others(1)
> 
> 1802 commits on develop
> 22 contributors across all branches
> Dev list averaged ~50 msgs/month in 2016
> User list averaged ~40 msgs/month in 2016
> 1208 issues created
> 997 issues resolved
> 
> Committer’s affiliation:
> ===
> Active:
>Hortonworks
>Talend
>Freestone infotech
>BlueTalon
>eBay
>Others
> 
> 
> Apache Ranger Top Level Project Resolution:
> 
> 
> Establish the Apache Ranger Project
> 
> 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 a data management platform That provides real-time, consistent access
> to data-intensive applications throughout widely distributed cloud
> architectures.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Ranger Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
> 
> RESOLVED,that the Apache Ranger Project be and hereby is responsible for
> the creation and maintenance of software related to a data management
> platform that provides real-time, consistent access to data-intensive
> applications throughout widely distributed cloud architectures.
> 
> RESOLVED, that the office of "Vice President, Apache Ranger" 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 Ranger
> Project, and to have primary responsibility for management of the projects
> within the scope of responsibility of the Apache Ranger 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 Ranger Project:
> 
> Alok La
> la...@apache.org
> Alan Gates
>