Huge +1 to what Cédric has said. Thanks, Roman.
On Wed, Jan 4, 2017 at 6:20 AM, Cédric Champeau <cedric.champ...@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 <aha...@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" <johndam...@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-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
