Re: [VOTE] Drop incubating requirement of Maven artifacts

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

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

+1 (binding) Regards JB On 01/04/2017 01:21 AM, 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

Re: [VOTE] Drop incubating requirement of Maven artifacts

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

Re: [DISCUSS] Significance of Artifact Names

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

Re: [DISCUSS] Significance of Artifact Names

John D. Ament wrote: So why am I harping on this problem? The incubator has a series of guides, which are partially treated as policy and partially treated as advice. Many of these guides remain with large notions of being draft only, not finalized, I want to try to get these draft documents

Re: [DISCUSS] Significance of Artifact Names

On Tue, Jan 3, 2017 at 10:57 PM Craig Russell wrote: > I think there is an additional item that falls into the same category. > > What are Apache guidelines/policies regarding maven group ids and java > package names? > > Many projects use org.apache.foo as the group id for

[jira] [Created] (INCUBATOR-145) test

John D. Ament created INCUBATOR-145: --- Summary: test Key: INCUBATOR-145 URL: https://issues.apache.org/jira/browse/INCUBATOR-145 Project: Incubator Issue Type: Task Components:

Re: [DISCUSS] Significance of Artifact Names

I think there is an additional item that falls into the same category. What are Apache guidelines/policies regarding maven group ids and java package names? Many projects use org.apache.foo as the group id for projects and org.apache.foo.subproject.InterfaceName for class names. Others use

[DISCUSS] Significance of Artifact Names

All, This is a follow up to recent threads, purposely made a bit broader to encourage more discussions. First to set down some facts about what's been established: 1. Incubator policy [1] states that a podling's release meets two requirements, include "incubating" in the release archive's file

[jira] [Created] (INCUBATOR-144) Incubator Task

Freddy Barboza created INCUBATOR-144: Summary: Incubator Task Key: INCUBATOR-144 URL: https://issues.apache.org/jira/browse/INCUBATOR-144 Project: Incubator Issue Type: Task

Re: Podling request steps have been updated

Done. I stated that the mentors should do this. I also added a few more services to the other services section. Thanks for taking a look! John On Tue, Jan 3, 2017 at 11:55 AM Jim Apple wrote: > I think it would be good to include that information on the page, perhaps >

[CANCEL] [VOTE] Drop incubating requirement of Maven artifacts

All, Based on the current discussions I'm canceling this vote.. we can follow up in a coming discussion thread. The hope is that we can reach better consensus. John On Mon, Jan 2, 2017 at 12:22 PM John D. Ament wrote: > All, > > I'm calling to vote on a proposed policy

Re: [VOTE] Drop incubating requirement of Maven artifacts

On Tue, Jan 3, 2017 at 8:43 PM Daniel Dekany wrote: > Tuesday, January 3, 2017, 11:10:24 PM, Stian Soiland-Reyes wrote: > > [snip] > > The workaround of publishing binaries without any -incubator/-incubating > > markers by using a non-apache group/name is probably a somewhat

Re: [VOTE] Drop incubating requirement of Maven artifacts

Tuesday, January 3, 2017, 11:10:24 PM, Stian Soiland-Reyes wrote: [snip] > The workaround of publishing binaries without any -incubator/-incubating > markers by using a non-apache group/name is probably a somewhat workable > solution for larger established projects like Groovy, but may also work

[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

Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC5)

Thanks for the feedback, Justin..We are working on rectifying these issues, but want clarification on a couple. On 2016-12-29 17:58 (-0700), Justin Mclean wrote: > Hi, > > -1 (binding) As package names don’t include incubating, release includes > non

Re: [VOTE] Drop incubating requirement of Maven artifacts

-1 (binding) I look at the “-incubating” tag in the same way I do the DISCLAIMER file and the podling website disclaimer — As an indicator and reminder that a release may not be completely clean from a licensing/policy perspective. -Taylor > On Jan 3, 2017, at 4:20 PM, Josh Elser

Re: [VOTE] Drop incubating requirement of Maven artifacts

+0 from me. I have also experienced that developers not very familiar with ASF may interpret -incubator to describe build/code immaturity rather than community/policy immaturity, and thus wait for graduation before considering the code from a software engineering perspective rather than (as

Re: [VOTE] Drop incubating requirement of Maven artifacts

(late to the party) -1 (binding) as an ask to table the VOTE and try to reach some better consensus. I have to agree with Julian that some more discussion may be prudent here. There are definitely two divided camps, both of which bring good points to the table. * Differing policies for

Re: [VOTE] Drop incubating requirement of Maven artifacts

Julian, I respect all opinions :-) I think it would be good for people to continue on the discussions to so we can understand all points of view. The problem with policy is that you're never going to satisfy everyone, and more than anything this seems deadlocked, however we're only a day into

Re: [VOTE] Drop incubating requirement of Maven artifacts

John, I see your points, and hopefully you see mine. I think we can agree on one thing: we have not reached consensus. :) The inconsistency among build tools is a red herring. If we want consistency across build tools (and more importantly across package formats, regardless of the tool used

Re: Podling request steps have been updated

I think it would be good to include that information on the page, perhaps in #8. On Tue, Jan 3, 2017 at 3:25 AM, John D. Ament wrote: > 1. Anyone who is on a PMC. I suspect the actual ACL is committers. For > instance, only members of the Incubator PMC can request repos

[RESULT] [VOTE] Release Apache Juneau 6.0.1-incubating-RC3

After being open for over 72 hours, the vote for releasing Apache Juneau 6.0.1-incubating-RC3 passed with 6 +1s (5 binding) and no 0 or -1. +1s: James Bognar John D Ament (binding) Jochen Wiedmann (binding) Craig L Russell (binding) Stian Soiland-Reyes (binding) Justin Mclean (binding) The issue

Re: [VOTE] Drop incubating requirement of Maven artifacts

-1 for dropping. > On Jan 2, 2017, at 12: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.

Re: [VOTE] Drop incubating requirement of Maven artifacts

+1 (binding) A policy (or rule or whatever it is that creates expectations) which just applies to a single build toolchain does not make any sense at all. So lets trash this. Regards Felix > Am 02.01.2017 um 18:22 schrieb John D. Ament : > > All, > > I'm calling to

Re: [VOTE] Drop incubating requirement of Maven artifacts

On Tue, Jan 3, 2017 at 7:53 AM Romain Manni-Bucau wrote: > 2017-01-03 13:45 GMT+01:00 Cédric Champeau : > > > 2017-01-03 13:41 GMT+01:00 Romain Manni-Bucau : > > > > > 2017-01-03 13:38 GMT+01:00 Cédric Champeau

Re: [VOTE] Drop incubating requirement of Maven artifacts

2017-01-03 13:45 GMT+01:00 Cédric Champeau : > 2017-01-03 13:41 GMT+01:00 Romain Manni-Bucau : > > > 2017-01-03 13:38 GMT+01:00 Cédric Champeau : > > > > > +1 > > > > > > Note that for Groovy, the source artifact, which

Re: [VOTE] Drop incubating requirement of Maven artifacts

James, I don't believe the question is about not using it. It's required on all source releases. The fundamental question at hand is whether that tag should be applied to generated convenience binaries or not. Right now, the incubator website says its only required on binaries if you're using

Re: [VOTE] Drop incubating requirement of Maven artifacts

-1, I like having the indication. I also question why other folks aren't using it or some other flag to indicate that it's an incubating project. On Mon, Jan 2, 2017 at 12:23 PM John D. Ament wrote: > All, > > > > I'm calling to vote on a proposed policy change.

Re: [VOTE] Drop incubating requirement of Maven artifacts

2017-01-03 13:41 GMT+01:00 Romain Manni-Bucau : > 2017-01-03 13:38 GMT+01:00 Cédric Champeau : > > > +1 > > > > Note that for Groovy, the source artifact, which is what legal is all > > about, contained the -incubating appendix. The Maven

Re: [VOTE] Drop incubating requirement of Maven artifacts

2017-01-03 13:38 GMT+01:00 Cédric Champeau : > +1 > > Note that for Groovy, the source artifact, which is what legal is all > about, contained the -incubating appendix. The Maven artifacts did not, and > I think it's a reasonable thing: people were used to stable

Re: [VOTE] Drop incubating requirement of Maven artifacts

+1 Note that for Groovy, the source artifact, which is what legal is all about, contained the -incubating appendix. The Maven artifacts did not, and I think it's a reasonable thing: people were used to stable versions of Groovy for years, there was no reason why a new one wouldn't be. 2017-01-03

Re: [VOTE] Drop incubating requirement of Maven artifacts

Romain Manni-bucau wrote > -1, I think it is important to show that the artifact dependency is not > stable and should be used as such (if the project never graduates, even if > code is very mature then you still get all the troubles you can think > about). > > Question is IMHO the opposite: why

Re: [VOTE] Drop incubating requirement of Maven artifacts

2017-01-03 13:06 GMT+01:00 Guillaume Laforge : > When you say "it denotes a lack of maturity which is exactly the purpose > AFAIK", what do you mean my maturity? > Maturity in terms of how well it follows Apache processes and principles? > Or in terms of "the project is not

Re: [VOTE] Drop incubating requirement of Maven artifacts

When you say "it denotes a lack of maturity which is exactly the purpose AFAIK", what do you mean my maturity? Maturity in terms of how well it follows Apache processes and principles? Or in terms of "the project is not ready for prime time"? For example, for Apache Groovy, the project was very

Re: [VOTE] Drop incubating requirement of Maven artifacts

-1 I use maven all the time and I'd like to know if an artifact was in the incubator or not due to a bunch of reasons listed above. Namely, it might not get out of the incubator and end up else where, incomplete release process and dependencies etc. I would agree with the prior post and suggest

Re: [VOTE] Drop incubating requirement of Maven artifacts

-1, I think it is important to show that the artifact dependency is not stable and should be used as such (if the project never graduates, even if code is very mature then you still get all the troubles you can think about). Question is IMHO the opposite: why others don't follow the -incubating

Re: [VOTE] Drop incubating requirement of Maven artifacts

+1 non-binding If a best practice targets only maven and not the others, wouldn't that be a reason for a podling to consider avoiding using maven to distribute binaries at all? Is it fair for Apache to disadvantage maven that way? Can Apache enforce policies about binaries not released under

Re: [VOTE] Drop incubating requirement of Maven artifacts

Carsten, Julian, I want to reiterate my notes from a prior message [1] in case there is any confusion over the ask. There is a "best practice" around maven specific releases that has been treated as policy, [2]. This best practice for some reason is only applied if you are using the maven

Re: Podling request steps have been updated

1. Anyone who is on a PMC. I suspect the actual ACL is committers. For instance, only members of the Incubator PMC can request repos within the incubator namespace. 2. LDAP. As can be seen with the recent blogs migration, the trend is to move towards the LDAP credentials. There are some