+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 intended) legal perspective.
This probably stems from a misunderstanding that Apache is focused on high quality software and a belief that code (rather than a community) is in the incubator to harden it's quality. I am not sure how we can improve on this; particularly as you hint these developers don't look further than the version number and might not even have visited the podlings Apache homepage before dismissing the -incubating releases. We could change our descriptions of the incubator.apache.org site to better reflect that we generally tend to adapt existing project rather than being a starting ground for new initiatives (although that still happens) - yet this would probably not be sufficient to change those misunderstandings. I do however see the legal reasoning for -incubating, in particular as IPMC might allow releases that include sources or dependencies in a grey zone license/IP-wise, which would otherwise not be permitted or expected from an ASF release. Therefore, downstream consumers who care sufficiently about this should be able to see a clear distinction between pre- and post-graduation artifacts, in particular for binaries. For Maven it made sense to put this as "-incubating" in <version> rather than change groupId, which can cause conflicts post graduation. What is best practice for other systems must be figured out separately; not just ignored. 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. That the current policy is Maven-centric is not perfect, I think we should require a similar "incubator" marker also for other distribution mechanisms like Ruby Gems, at least if they include "apache" in their names/grouping. On 3 Jan 2017 9:20 pm, "Josh Elser" <els...@apache.org> wrote: (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 the languages/tools of products that podlings create (maven projects vs. python/ruby projects). Julian states this very well. * A clear definition of what the IPMC thinks "x.y.z-incubating" should mean and some better public-facing docs on what "incubating releases" actually mean. - Groovy is a great, recent example. They were a very "mature" software project, but still were "immature" in the terms of an ASF community (purely speaking of them as being a podling, not a TLP). Personally, if I see the -incubating suffix on a version, I can recognize that the *community* is the thing at risk. However, I can also see how those less affiliated with the incubator could interpret it as "software quality". John states this very well in the VOTE text itself -- it leaves me wondering if we couldn't just be more clear out of the gates. I also need to re-read the original thread from freemarker (no [DISCUSS] in the subject and the holidays kept me from reading it closely) to think about the original stated problem some more. - Josh Julian Hyde wrote: > 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 to build them), let’s first figure out > what we want, and apply this to all build tools. > > Julian > > > On Jan 3, 2017, at 3:34 AM, John D. Ament<johndam...@apache.org> wrote: >> >> 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 build tool. E.g. >> published python packages, ruby gems do not have this requirement. The >> purpose of this thread is to realign maven specific releases with the >> other >> convenience binaries published by podlings. >> >> This is not intended to drop the -incubator/-incubating tag applied to >> source releases. It was however established in 2008 [3] that releases >> published by the incubator were endorsed, the -incubator/incubating tag >> was >> to imply that the project itself was not considered stable and could go >> away. >> >> John >> >> [1]: >> https://lists.apache.org/thread.html/c6daddf2d564685acdcd14a >> 876bebf392b25c268905b353e36b3cac5@%3Cgeneral.incubator.apache.org%3E >> [2]: >> http://incubator.apache.org/guides/release-java.html#best-practice-maven >> [3]: >> https://lists.apache.org/thread.html/0b6c065a908c5f9ec39fa78 >> c31b39c83a6fea29eb34fada0ee070413@1222432864@%3Cgeneral.incu >> bator.apache.org%3E >> >> >> On Tue, Jan 3, 2017 at 1:47 AM Carsten Ziegeler<cziege...@apache.org> >> wrote: >> >> -1 >>> >>> I followed the "other thread" but it's still unclear to me what real >>> problem this tries to solve. >>> As others noted, there should be an indicator whether this is already an >>> official Apache project or in the incubator and adding it to the version >>> information is the solution with causes the least amount of pain for >>> users. It's a simple marker, clearly visible for any user. >>> And once the project is out of the incubator, users simply need to >>> update to a new version - something which they would do anyway. >>> >>> Carsten >>> >>> 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. Its labeled as a best practice, >>>> >>> not >>> >>>> a requirement and is not a policy followed on other repository >>>> management >>>> tools (e.g. PyPi). >>>> >>>> I therefore push forward that the incubator will cease expecting >>>> >>> java-based >>> >>>> projects to publish artifacts with "-incubating" in the version string, >>>> with the understanding that: >>>> >>>> - Incubating is a term used to refer to a project's stability, not a >>>> release's stability. It is generally understood that incubating >>>> projects >>>> are not necessarily immature, but may have a potential of failing to >>>> >>> become >>> >>>> a TLP. >>>> - Podling releases are endorsed, the podling itself is not endorsed. We >>>> will not approve releases that are blatantly against ASF policies. >>>> >>>> >>>> [ ] +1 Drop the -incubator/-incubating expectation of maven projects >>>> [ ] +/0 >>>> [ ] -1 Don't drop because.... >>>> >>>> >>>> [1]: >>>> http://incubator.apache.org/guides/release-java.html#best-pr >>>> actice-maven >>>> >>>> >>> >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> cziege...@apache.org >>> >>> --------------------------------------------------------------------- >>> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
