incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: [VOTE] Drop incubating requirement of Maven artifacts
Date Wed, 04 Jan 2017 09:28:51 GMT
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 available for
backwards compat. Both are shims to expose our C libraries into Java, so
that approach may have been easier for us, compared to Apache Groovy's
situation.

On Jan 4, 2017 02:25, "C├ędric Champeau" <cedric.champeau@gmail.com> wrote:

> 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