>
> 1) Official and Convenience Binaries in any category need to be released
> on the Infra dist.apache.org servers even if they are also available
> through other channels. For example the jars released on maven central
> should be equivalent to those downloaded.


I have a question about what you mean by "equivalent to those downloaded".

Our source releases on dist.a.o differ in structure and completeness from
what is available from Maven Central (MC)

   - Everything that is available on MC can be *derived* from what is
   downloadable from dist.a.o, but not the other way around.
   - Also, what is available from MC includes jars of compiled code
   (binaries) that are not *directly* available from dist.a.o (the user
   would have to compile them).
   - Dist.a.o includes the entire directory structure of the release
   branch, which includes all the dot-config files (.gitignore, .travis.yml,
   etc) as well as the LICENSE, NOTICE files and other stuff.  These are not
   part of what can be downloaded from MC.

If this is what you mean by equivalent, then we are OK.
***
I will fix the "customer" reference.  Thank you!

Lee.

On Mon, Oct 26, 2020 at 2:42 PM Dave Fisher <[email protected]> wrote:

> Hi -
>
> In the maturity model you talk about “customers” in one location. You
> should use the phrase “users”. The community does not have customers even
> though the vendors committers work for may have customers (or students.)
>
> A quick comment on other release venues.
>
> (1) Official and Convenience Binaries in any category need to be released
> on the Infra dist.apache.org servers even if they are also available
> through other channels. For example the jars released on maven central
> should be equivalent to those downloaded.
>
> (2) Docker cases may vary and it’s worth asking Infra about the Apache
> Docker space. Legal has some comments about how to deal with GPL system
> dependencies if you have them.
>
> (3) Anyone in the community may make unofficial releases on their own as
> long as its clear they did not come from the PPMC. This has implications
> about branding the third party may need to use the Foo Powered By Apache
> DataSketches or Bar For Apache DataSketches naming.
>
> Best Regards,
> Dave
>
> On Oct 26, 2020, at 2:22 PM, Jon Malkin <[email protected]> wrote:
>
> We do have a few packages available (and will add more eventually):
> 1. Precompiled .jar files via maven
> 2. The PostgreSQL extension has... I guess a source tarball available
> through pgxn.org
> 3. We really need to add something to pypi eventually. (If anyone wants to
> volunteer to make those binaries, please speak up! If I end up doing it
> it'll just be a source tarball)
>
> And if the server thing I'm playing with ends up being deemed useful
> enough we could end up adding it as a container to docker's repo.
>
>   jon
>
> On Sun, Oct 25, 2020 at 4:13 PM leerho <[email protected]> wrote:
>
>> Folks,
>>
>> You can view the proposed draft of our maturity model at
>> https://datasketches.apache.org/docs/Maturity.html.
>>
>> Please feel free to comment and discuss here any issues you might have
>> with the document along with suggestions on how to improve it.  Completing
>> this is a critical step on our way to graduation.
>>
>> Thank you.
>>
>
>

Reply via email to