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 as solid
> as
> > one might expect (patches
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,
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" between the previous "GitH
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 length
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 to "incubating", I would
> > favor
> > > > a system of marker(s) in
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 (incl legal). So,
> for a
> > > podling rel
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 release standard as
> > TLPs
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 podling release was not a
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. ;-)
>
> Communities are living thing
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 people
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.
https://lists.apache.org/thread.html/15550f5bf62
-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
> the version string of
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
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
[
@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 :
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 'Codehaus').
> So while this w
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 for prime time"?
Fo
+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 the ASF has a status (podling, tlp, attic, etc.) is
-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 labeled as a best practice
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 the ASF has a status (podling, tlp, attic, etc.) is
irrelevant for the code. The code is donated/owned by the ASF, and task
> 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 fo
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 o
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 sa
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 incuba
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
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 availab
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
co
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
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 artif
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 change. Current guide
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 workable
> > solution
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
>
-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 wrote:
>
>
+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 intend
(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 the
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 the
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 to
-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. Its labeled as a best p
+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 vote on a proposed policy
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 >:
> > >
> > > > +1
> > > >
> > > > Note that for Groovy, the source artifact, which
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 is what legal is all
> > > about, contained the -incubating appendix. The Mave
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 m
-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. Current guide at [1]
>
> indic
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 artifacts did not,
> and
> > I think it's a reasonable thin
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 versions of
> Groovy for years, th
+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
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 o
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 ready for prime time"?
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 ma
-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
th
-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 ru
+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 the
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 build
-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 a
> 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 un
-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 throug
+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 labeled as a best practi
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 cod
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 g
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
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
inclu
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
> 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:
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 code requires refactor
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 created before the inc
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 pro
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 talk about the release
-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 importa
-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 discussions
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 manageme
70 matches
Mail list logo