Re: [DISCUSS] Significance of Artifact Names

[Paul King]

+1  from me too.

For Groovy, we had a discussion internally and with our mentors. The
src archive and website disclaimer seemed to be the things that were
cared about from a legal point of view and so that is what we renamed.

For us, "convenience binaries" were something that should be
convenient for our users, otherwise they'd be called "inconvenience
binaries". :-)

For us, this seemed to be the right way to treat our community while
still keeping the legal audit/requirements there for anyone caring
about the official release. From where I sit it seems to be a "have
your cake and eat it too" situation to say that you don't care about
"convenience binaries" but "kind of" do care about some technical
aspects of there naming.

Cheers, Paul.


On Thu, Jan 5, 2017 at 12:19 PM, Roman Shaposhnik  wrote:
> Huge +1 to what Cédric has said.
>
> Thanks,
> Roman.
>
> On Wed, Jan 4, 2017 at 6:20 AM, Cédric Champeau
>  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 :
>>
>>> 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 

Re: [DISCUSS] Significance of Artifact Names

[Roman Shaposhnik]

Huge +1 to what Cédric has said.

Thanks,
Roman.

On Wed, Jan 4, 2017 at 6:20 AM, Cédric Champeau
 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 :
>
>> 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  section of each POM?
>> According to [7] there is a comments section there.  Could incubating
>> podlings be 

Re: [DISCUSS] Significance of Artifact Names

[Cédric Champeau]

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 :

> 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  section of each POM?
> According to [7] there is a comments section there.  Could incubating
> podlings be required to make it clear in the  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
> 

Re: [DISCUSS] Significance of Artifact Names

[Alex Harui]

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  section of each POM?
According to [7] there is a comments section there.  Could incubating
podlings be required to make it clear in the  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"  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/0b6c065a908c5f9ec39fa78c31b39c83a6fea
>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: 

Re: [DISCUSS] Significance of Artifact Names

[Josh Elser]

John D. Ament wrote:

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.


+1 just to echo that this is a great exercise that you've taken up :)


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.


Agreed that it's strange for Maven to be treated differently. Do we have 
any other systems in which artifacts are automatically promoted to 
non-ASF controlled entities as a part of an ASF release? Does anyone 
have examples handy of where this is done manually? I haven't been 
involved in any project that does either.


I can see value in denoting that projects are incubating at the ASF when 
people aren't acquiring them from dist.a.o (or the project's website). 
Craig's point is really good though too -- there *is* no policy which 
defines what the GAV or java package needs to be for ASF projects. 
Source releases (and convenience binaries) should already be shipped 
with the DISCLAIMER, so is the -incubating really telling people 
anything new?


My gut reaction is "no". Thus, -incubating is duplicative of the 
information already captured and unnecessary.


This intentionally avoids asking the question about the value in 
downstream users "knowing" what the incubator is, what podlings are, and 
the difference between podlings and TLPs are. I think we first need to 
decide if dropping the '-incubator' makes a release not obviously from a 
podling.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Significance of Artifact Names

[John D. Ament]

On Tue, Jan 3, 2017 at 10:57 PM Craig Russell  wrote:

> I think there is an additional item that falls into the same category.
>
> What are Apache guidelines/policies regarding maven group ids and java
> package names?
>
> Many projects use org.apache.foo as the group id for projects and
> org.apache.foo.subproject.InterfaceName for class names.
>
> Others use naked foo as high level package names and org.foo as group ids.
>
> I think there may be a difference based on whether the project is intended
> for use as an API or as an executable. Possibly also whether the project
> had a large user community before coming to Apache.
>
> I don’t know that the incubator or Apache has ever had a discussion on
> this topic, and it seems relevant. If not, please disregard and I’ll raise
> it in another thread.
>

I think its relevant, however its outside the scope of the incubator to
figure that one out (in my opinion).  I would imagine similar problems
exist for .NET, Go, Scala, Ruby, Python.

John


>
> Craig
>
> > On Jan 3, 2017, at 7:19 PM, John D. Ament  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/0b6c065a908c5f9ec39fa78c31b39c83a6fea29eb34fada0ee070413@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
>
> Craig Russell
> papa...@gmail.com
>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Significance of Artifact Names

[Craig Russell]

I think there is an additional item that falls into the same category.

What are Apache guidelines/policies regarding maven group ids and java package 
names?

Many projects use org.apache.foo as the group id for projects and 
org.apache.foo.subproject.InterfaceName for class names. 

Others use naked foo as high level package names and org.foo as group ids. 

I think there may be a difference based on whether the project is intended for 
use as an API or as an executable. Possibly also whether the project had a 
large user community before coming to Apache.

I don’t know that the incubator or Apache has ever had a discussion on this 
topic, and it seems relevant. If not, please disregard and I’ll raise it in 
another thread.

Craig

> On Jan 3, 2017, at 7:19 PM, John D. Ament  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/0b6c065a908c5f9ec39fa78c31b39c83a6fea29eb34fada0ee070413@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

Craig Russell
papa...@gmail.com




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[DISCUSS] Significance of Artifact Names

[John D. Ament]

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/0b6c065a908c5f9ec39fa78c31b39c83a6fea29eb34fada0ee070413@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