incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <ro...@shaposhnik.org>
Subject Re: [DISCUSS] Significance of Artifact Names
Date Thu, 05 Jan 2017 02:19:35 GMT
Huge +1 to what Cédric has said.

Thanks,
Roman.

On Wed, Jan 4, 2017 at 6:20 AM, Cédric Champeau
<cedric.champeau@gmail.com> wrote:
> Cross-posting since I missed this topic in the first place. My apologies
> for the duplicate:
>
> 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 6:24 GMT+01:00 Alex Harui <aharui@adobe.com>:
>
>> 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 mind, the -incubating suffix is
>> supposed to help warn the customer or cover the ASFs butt or both.  I
>> don't know if anybody actually points to a source artifact from Maven, but
>> if the downstream user is being careful enough to work from sources, it
>> makes sense to me to put in an additional warning by adding the
>> -incubating suffix to the source package. It says that these source
>> packages are not like other ASF source packages without having to open the
>> package.
>>
>> But for a binary artifact, given that the ASF already thinks it isn't
>> audit-able and thus not an official release, does the customer care that
>> the artifact may not be ASF-grade (especially if the artifacts were
>> already considered open before entering Apache)?  Do they really need
>> early warning?  Would it really affect the ASF if something bad was later
>> found in a binary artifact?
>>
>> IMO, the answer to all 3 questions is no.  I don't know how hard it is to
>> suffix the source artifact with -incubating but not for the binary
>> artifacts.  But if it is hard, could the next version of Maven do it?
>>
>> Also, if someone is concerned enough about the licensing of the artifacts
>> they depend on to go digging through all of the poms of their binary
>> dependencies, wouldn't they check the <license> section of each POM?
>> According to [7] there is a comments section there.  Could incubating
>> podlings be required to make it clear in the <license> section that this
>> thing may not be fully ASF compliant instead of having to add a suffix to
>> the version of their binary artifacts?
>>
>> My 2 cents,
>> -Alex
>>
>> [6] https://www.apache.org/legal/src-headers.html#faq-binaries
>> [7] https://maven.apache.org/pom.html#Licenses
>>
>> On 1/3/17, 7:19 PM, "John D. Ament" <johndament@apache.org> wrote:
>>
>> >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 name and
>> >the standard disclaimer within the documentation or README.
>> >
>> >2. The foundation policy on a valid release [2] seems to indicate that the
>> >elements that make up a valid release includes properly licensed source
>> >code, ICLAs on file, IP clearance and grants.
>> >
>> >3. Back in 2008 [3] it was established that incubator released are
>> >endorsed
>> >while the podlings themselves are not endorsed.  This means that while the
>> >podling may not fully be developed in an open way, all releases produced
>> >are expected to comply with ASF policies.
>> >
>> >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 finalized so that
>> >we're able to provide better guidance to podlings coming in.
>> >
>> >I also think its important to keep our policies and guides as light as
>> >possible.  There shouldn't be a lot different in the incubator than a TLP
>> >would go through, or else this makes the eventual transition to TLP harder
>> >since many things previously done are now different.
>> >
>> >One of the distinguishing marks within the incubator is the use of maven.
>> >The incubator has a best practice that says if your build tool is maven,
>> >if
>> >and when you publish a convenience binary, that convenience binary must
>> >include either incubator or incubating in the version string [4].  Its not
>> >clear why maven is singled out, probably because it was the first of its
>> >kind, other tools didn't exist.  One of the key notes I can find is that
>> >the downstream redistribution channels are operated outside the ASF [5].
>> >So while Maven is an apache project, maven central is not an ASF managed
>> >resource but we are attempting to enforce our internal concerns to an
>> >outside party.
>> >
>> >So I move that we cannot apply our policies on third parties, and
>> >artifacts
>> >distributed in maven central from our release archives need not comply
>> >with
>> >our policies.
>> >
>> >John
>> >
>> >[1]:
>> >http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>> >[2]: http://www.apache.org/dev/release-publishing.html#valid
>> >[3]:
>> >https://lists.apache.org/thread.html/0b6c065a908c5f9ec39fa78c31b39c
>> 83a6fea
>> >29eb34fada0ee070413@1222432864@%3Cgeneral.incubator.apache.org%3E
>> >[4]:
>> >http://incubator.apache.org/guides/release-java.html#best-practice-maven
>> >[5]: http://www.apache.org/dev/release-distribution.html#channels
>>
>>
>> ---------------------------------------------------------------------
>> 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
View raw message