incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: [VOTE] Drop incubating requirement of Maven artifacts
Date Tue, 03 Jan 2017 22:10:24 GMT
+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" <elserj@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<johndament@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<cziegeler@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
>>> cziegeler@apache.org
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
---------------------------------------------------------------------
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