incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From C├ędric Champeau <cedric.champ...@gmail.com>
Subject Re: [VOTE] Drop incubating requirement of Maven artifacts
Date Wed, 04 Jan 2017 08:25:20 GMT
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 <pierre.smits@gmail.com>:

> 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 <http://www.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 <struberg@yahoo.de.invalid>
> 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 <johndament@apache.org>:
> > >
> > > On Tue, Jan 3, 2017 at 8:43 PM Daniel Dekany <ddekany@freemail.hu>
> > 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 for larger established projects like Groovy, but may also
> work
> > >>> against community as it de-emphasises ASF, and outsiders might so
> > easily
> > >>> realise that the community is changing before graduation.
> > >> [snip]
> > >>
> > >> Note that the non-Apache group/name is not meant to be a workaround to
> > >> avoid "-incubating". It's about not burdening the Java ecosystem with
> > >> a groupId change.
> > >>
> > >
> > > Just to point out, again, there are even top level projects that don't
> > > publish under org.apache.  There's no requirement to do so.
> > >
> > >
> > >>
> > >> --
> > >> Thanks,
> > >> Daniel Dekany-incubating
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >> For additional commands, e-mail: general-help@incubator.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message