Re: Release Process [was: [VOTE] Drop incubating requirement of Maven artifacts]

On Sun, Jan 8, 2017 at 7:26 PM, John D. Ament wrote: > On Sun, Jan 8, 2017 at 6:55 PM Niclas Hedhman wrote: > > > Yes, I think we all hear your "frustration" that the process is not as > > streamlined as it perhaps could, nor that the documentation is

Re: Release Process [was: [VOTE] Drop incubating requirement of Maven artifacts]

On 09.01.2017 00:54, Niclas Hedhman wrote: [...] Probably after our next release, we will publish reusable Gradle components for the Apache release process for other Gradle based projects to benefit from. We'll see exactly how we do this. In Groovy we are working on something gradle based too,

Re: Release Process [was: [VOTE] Drop incubating requirement of Maven artifacts]

On Sun, Jan 8, 2017 at 6:55 PM Niclas Hedhman wrote: > Yes, I think we all hear your "frustration" that the process is not as > streamlined as it perhaps could, nor that the documentation is as solid as > one might expect (patches are welcome) > > The underlying "issue"

Release Process [was: [VOTE] Drop incubating requirement of Maven artifacts]

Yes, I think we all hear your "frustration" that the process is not as streamlined as it perhaps could, nor that the documentation is as solid as one might expect (patches are welcome) The underlying "issue" between the previous "GitHub/Maven releases" and "Apache releases" was discussed at

Re: [VOTE] Drop incubating requirement of Maven artifacts

On Sat, Jan 7, 2017 at 9:42 AM, John D. Ament wrote: > On Sat, Jan 7, 2017 at 9:23 AM Niclas Hedhman wrote: > > > On Sat, Jan 7, 2017 at 9:36 PM, John D. Ament > > wrote: > > > > > > So, instead of tying the "incubating" marker

Re: [VOTE] Drop incubating requirement of Maven artifacts

On Sat, Jan 7, 2017 at 9:23 AM Niclas Hedhman wrote: > On Sat, Jan 7, 2017 at 9:36 PM, John D. Ament > wrote: > > > > So, instead of tying the "incubating" marker to "incubating", I would > favor > > > a system of marker(s) indicating the code maturity

Re: [VOTE] Drop incubating requirement of Maven artifacts

On Sat, Jan 7, 2017 at 9:36 PM, John D. Ament wrote: > > So, instead of tying the "incubating" marker to "incubating", I would favor > > a system of marker(s) indicating the code maturity (incl legal). So, for a > > podling release to be 1.2.3 (a la Groovy), the same

Re: [VOTE] Drop incubating requirement of Maven artifacts

Niclas, I wanted to read through your notes pretty in depth before responding. On Thu, Jan 5, 2017 at 7:37 PM Niclas Hedhman wrote: > Coming late to the party... > > This has been discussed, and contentious, since "forever". A long time ago, > there was a notion that a

Re: [VOTE] Drop incubating requirement of Maven artifacts

Hi Niclas, You Saïd it correctly It is an education program. Best regards, Pierre On Saturday, January 7, 2017, Niclas Hedhman wrote: > Pierre, > Where can I download or "consume" a project community? I would like to have > a local copy of it, right here. ;-) > >

Re: [VOTE] Drop incubating requirement of Maven artifacts

Pierre, Where can I download or "consume" a project community? I would like to have a local copy of it, right here. ;-) Communities are living things, people, and not an immutable release artifact. Incubation is not a release process, it is effectively an education program for inexperienced

Re: [VOTE] Drop incubating requirement of Maven artifacts

Jochen, On Fri, Jan 6, 2017 at 3:56 PM Jochen Wiedmann wrote: > -1 > > Because I fail to see a problem with the current policy. > I'll point out this has already been canceled. I'd ask you to bring your questions to the related discuss thread.

Re: [VOTE] Drop incubating requirement of Maven artifacts

-1 Because I fail to see a problem with the current policy. 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

Re: [VOTE] Drop incubating requirement of Maven artifacts

Nicolas, all, Despite your believes, you do release communities. Because the community is the incubating project. Only after the community meets the criteria of graduation a proposal is submitted, seconded by the IPMC and reviewed by the board. The community works the code during incubation until

Re: [VOTE] Drop incubating requirement of Maven artifacts

On 06.01.2017 17:32, Wade Chandler wrote: [] It's not a big deal YET, but http://codehaus.org is not reachable anymore. yes, Ben told me he does not want to give the domain away right now. When the time comes, he will think about donating it to the ASF. when this will be I do not know

Re: [VOTE] Drop incubating requirement of Maven artifacts

@wade it would be better to continue the discussion in the discuss vote, rather than this vote which has been cancelled. See https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0fd0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E 2017-01-06 17:32 GMT+01:00 Wade Chandler

Re: [VOTE] Drop incubating requirement of Maven artifacts

On Jan 4, 2017 4:46 AM, "Jochen Theodorou" wrote: 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

Re: [VOTE] Drop incubating requirement of Maven artifacts

On Jan 3, 2017 7:06 AM, "Guillaume Laforge" wrote: 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

Re: [VOTE] Drop incubating requirement of Maven artifacts

+1 On Fri, Jan 6, 2017 at 4:05 PM, Wade Chandler wrote: > On Jan 2, 2017 7:53 PM, "Pierre Smits" wrote: > > > +1 Drop the -incubator/-incubating expectation of maven projects > > It is not the code that is incubating. > > Whether a project of

Re: [VOTE] Drop incubating requirement of Maven artifacts

-1 Ralph > On Jan 2, 2017, at 10:22 AM, 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

Re: [VOTE] Drop incubating requirement of Maven artifacts

> I would favor a system of marker(s) indicating the code maturity (incl legal) There is no standard afaik to indicate legal or community 'maturity'. It would be something for a (RDF) vocabulary for artifacts to be adopted industry wide. Right now none of the Maven coordinates are a good fit

Re: [VOTE] Drop incubating requirement of Maven artifacts

Coming late to the party... This has been discussed, and contentious, since "forever". A long time ago, there was a notion that a podling release was not an ASF release (which was the main reason for the "incubating" marker in all release and support artifacts. But that pendulum has swung in the

Re: [VOTE] Drop incubating requirement of Maven artifacts

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

Re: [VOTE] Drop incubating requirement of Maven artifacts

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

Re: [VOTE] Drop incubating requirement of Maven artifacts

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

Re: [VOTE] Drop incubating requirement of Maven artifacts

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

Re: [VOTE] Drop incubating requirement of Maven artifacts

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

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

[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

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: [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: [VOTE] Drop incubating requirement of Maven artifacts

-1 I followed the "other thread" but it's still unclear to me what real problem this tries to solve. As others noted, there should be an indicator whether this is already an official Apache project or in the incubator and adding it to the version information is the solution with causes the least

Re: [VOTE] Drop incubating requirement of Maven artifacts

> Though I feel the pain for existing projects such as Groovy and > Freemarker, they are not typical. What percentage of active incubating projects had "a track record of high-quality releases before entering incubation"? - To

Re: [VOTE] Drop incubating requirement of Maven artifacts

-1 A release by an incubator project, even an established one (by which I mean, one that has a community and a track record of high-quality releases before entering incubation), is "less than" a release by full Apache project: not necessarily in terms of quality, but in terms of having been

Re: [VOTE] Drop incubating requirement of Maven artifacts

+1 (binding) On Mon, Jan 2, 2017 at 11:22 AM, 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

Re: [VOTE] Drop incubating requirement of Maven artifacts

First of all: this vote is turning into a discussion that should happen in a separate thread +1 Drop the -incubator/-incubating expectation of maven projects It is not the code that is incubating. Whether a project of the ASF has a status (podling, tlp, attic, etc.) is irrelevant for the

Re: [VOTE] Drop incubating requirement of Maven artifacts

This vote doesn't allow voters to differentiate projects that start their life in the Incubator from those coming to the Incubator after already widely used. So the voter can only allow omitting "-incubating" for all *kind* of incubating projects or for none of them, hence I guess people tends to

Re: [VOTE] Drop incubating requirement of Maven artifacts

Thanks for the details and explanation John. As far as the source artifacts contains -incubating, it's fine for me. I still think that -incubating on the Maven central artifact coordinates is interesting, however, if removing it allows us to "align" all artifacts format resulting to different

Re: [VOTE] Drop incubating requirement of Maven artifacts

The average is currently 2 years (give or take). Just to level set. I find it interesting that you mention Groovy in your response Mark. Did you know that Groovy interpreted the policy the way this vote is trying to formalize the policy, and the artifacts published to maven central did not

Re: [VOTE] Drop incubating requirement of Maven artifacts

Groovy is a pretty big project and managed to get through incubation in 8 months: http://incubator.apache.org/projects/groovy.html But I agree that many projects take longer. Sometimes (as with BatchEE) it's pure laziness to not yet have pushed it 'over the line' though :) LieGrue, strub > Am

Re: [VOTE] Drop incubating requirement of Maven artifacts

> If a project is well setup and mature then it should do incubation in under 6 > months, isn't? Are you sure? What does the CDF of incubation time look like? How many finish in 6 months? Beam just graduated in 10 months, and several people on this list seemed to call it a model of incubation:

Re: [VOTE] Drop incubating requirement of Maven artifacts

Sure, I will. Thanks. Regards JB On 01/02/2017 07:39 PM, John D. Ament wrote: Can you bring this up on the relevant discussion thread? On Jan 2, 2017 13:14, "Jean-Baptiste Onofré" wrote: By legal, I mean that some files may not contain required headers, or part of the

Re: [VOTE] Drop incubating requirement of Maven artifacts

Can you bring this up on the relevant discussion thread? On Jan 2, 2017 13:14, "Jean-Baptiste Onofré" wrote: > By legal, I mean that some files may not contain required headers, or part > of the code requires refactoring because it belongs to a non active > developer (code

Re: [VOTE] Drop incubating requirement of Maven artifacts

By legal, I mean that some files may not contain required headers, or part of the code requires refactoring because it belongs to a non active developer (code created before the incubation) or the Software Grant Agreement is not yet signed for instance. I think during the first steps of the

Re: [VOTE] Drop incubating requirement of Maven artifacts

JB Can you clarify what you mean by legal here? On Jan 2, 2017 13:05, "Jean-Baptiste Onofré" wrote: -1 I understand your point, but, even if it's not in the version, having a keyword that the project is still in incubation is important (from a legal perspective, I don't

Re: [VOTE] Drop incubating requirement of Maven artifacts

-1 I understand your point, but, even if it's not in the version, having a keyword that the project is still in incubation is important (from a legal perspective, I don't talk about the release itself). In the version, artifactId or classifier don't matter, however, having this flag is

Re: [VOTE] Drop incubating requirement of Maven artifacts

-1 It makes it clear that those artifacts are not yet stable ASF projects yet (legally + community). If a project is well setup and mature then it should do incubation in under 6 months, isn't? Any for any other project I find it quite ok to know what you get. Please also check the

[VOTE] Drop incubating requirement of Maven artifacts

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