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
+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
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
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
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
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
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:
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
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
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
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
>
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
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
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
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
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
-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
+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
(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
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
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
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
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
-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.
+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
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
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
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
-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.
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
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
+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
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
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
-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
-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
+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
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
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
40 matches
Mail list logo