[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [adoptium-wg] Adoptium Marketplace Policy
|
On 10/06/2021 15:00, Gil Tene wrote:
Some notes/comments:
1. "Inclusion in the marketplace is open to all members at no cost to
the provider" contradicts the later "Provide evidence that the producer
is a Strategic or Enterprise member of the Adoptium Working Group".
Assuming the latter is correct, should amend the former.
Thank you. Good catch. I have updated the first statement to read
"Inclusion in the marketplace is open to all strategic and enterprise
members at no cost to the provider ..."
2. Marketplace mechanics question/discussion:
[TDLR: I think the marketplace shoudl list download pages and not
binaries, and that we need to push download page management contenst to
the individual distros]
We need to determine if the marketplace will
a) list specific immutable versions of products (via e.g. links to
specific binaries)
The marketplace is intended to showcase the specific immutable versions
that each vendor is promoting, with information about where a
user/script can get it.
or
b) lists product locations that *only* include specific immutable
versions of binaries that meet the marketplace criteria.
While (a) [which is what is currently described, I think], seemingly
keeps the question of "how do we know a location *only* includes
binaries that meet the marketplace criteria, I believe that it is
logistically problematic for multipel reasons:
1. Publication of new binaries: each distro will e.g. need to publish
10s or 100s of new binaries each quarter), and access to of those new
binaries needs to urgently occur once the binaries are first made
publicly visible. It will take us time (probably beyind what we have) to
create a working mechanism that wouild allow marketplace members to
"feed" the markletplace with the information needed to auto-populate the
marketplace entries with no little human intervention.
Agreed. While it would not be invalid to market old binaries, we'd
prefer to feature the latest versions that are being promoted each quarter.
Having the marketplace website and API data-driven rather than manually
updated makes complete sense.
We will also be maintaining a list of all specific runtimes that have
been approved to use the Adoptium brand - we'll need that to protect the
use of the brand.
2. The complexity of the marketplace contents, and the need to present
it and navigate through it:
- For each participating distribution, the number of binaries to
include, navigate through will be large:
- for each "major version" (e.g. Java SE 11) of such a
participating distribution, there will be a large number of
upodate levels [at least one per quarter for most distros], each
with a lage number of individual binaries (e.g. matrices around
target OS/cpu combinations, package and installer types [tar.gz,
zip, dmg, pkg rpm, deb, msi, apk, …], package scope
[jre/jdk/jdk+fx/etc.]),
- some of the "axes" in the matrix may be specific to a
distribution or a version (e.g. some distributions or versions
may only provide jdks, while other may also provide jres, or
jdks packaged with openjfx. e.g. some distributions may provide
aarch32 OpenJDK 8 builds for alpine linux musl libc, while other
may on support x86-64 on glibc platforms).
- Terminology, versioning, naming, branding:
- Each distribution may have existing and somewhat variant
terminology for things like "package", "installer", "target", "OS",
"cpu architecture", "update", "PSU", …
- Each distribution may have existing and variant of grammer/syntax
requirements in describing a specific binary package and the way it
relates to a set of such packages.
- Each distributiion may have existing and variant versioning
schemes (e.g. some distros employ a distro-specific version
structure in addition to the OpenJDK JEP322 version structure, while
others do JEP322-only, and yet others use distro-=specific-only]
- Providing a marketplace browsing mechanism that would navigate all of
these using a common structure, options/columns, terminology, etc. (or
ones that would adjust for each distro's vriant use of these things)
will likely be challenging. While some common denominator may be
constructable over time, we likely don't have the time to get to one
before we want our first MVP marketplace to be up and running.
It will be useful to an end user to be able to select as specifically as
possible. There are examples in the current selection mechanism that
filter the Adopt* builds and will be applied to the Temurin binaries;
and the experience of the foojay disco API to work with.
I think there are big categories that we can get to by the MVP (major
Java API version, CPU architecture, etc) that will allow for some
filtering and browsing specificity. Let's not throw out the idea too
early. Just saying "We hear VendorX has some eligible binaries over
there" isn't very friendly. :-)
I therefore believe that (b) above is the more likely path for a
succesful MVP marketplace in the near term. This (b) option would
involve "trusting" the places that links in the marketplace point to
(e.g. a link to a place where you can get marketplace-criteria-meeting
binaries of VendorX Java SE 11 builds) to "only include" only binaries
that meet the marketplace criteria. We'd need to define what "only
include" means in a way that is reasonable, easy to meet, and fits with
or enables the real-world behaviors for download pages of various
distros. E.g. it is clear that we would want such a place to not mix
marketplace-criteria-meeting binaries with ones that are not (e.g. EA
builds, daily non-TCK-tested builds, non-AQAvit-certified builds) in a
common list. But we would probably be fine with the "place" being part
of or having links to other locations or sites as long as those links do
not imply that those are part of the matkletplace contents.
I think this is fraught with problems, and nearly impossible to police.
As you point out we already need to trust that vendors won't be
deliberately confusing end users by hosting
"marketplace-criteria-meeting" and non-marketplace-criteria-meeting
binaries in a way that is difficult to distinguish.
How do you define the acceptable number of "degrees of separation"
between offerings? Is it ok to have different sections on a single page,
one click away, etc etc.
The only thing we can really control is the Eclipse property, and that
means the Adoptium Marketplace (website and API) and the Adoptium
Trademarks. In practise, that translates to *only listing* those
runtimes that meet our criteria, and *only licencing* use of the
trademarks to runtimes that meet our criteria.
Part of our responsibility is to ensure users are aware that "if it
doesn't carry the Adoptium brand, then it is not an Adoptium quality
runtime".
We might ask/strongly suggest vendors to avoid mixing branded and
unbranded runtimes - I don't see that we could write down a clear
enforceable agreement. As a vendor I'm not going to agree to constraints
on products that don't overlap with Adoptium's area of responsibility.
IMO setting a [policy for what an acceptable "Eclipse Adpotium
Marketplace download page" would be, and allowing marketplace members to
edit those pages as needed, under their control, would be the most
practical way to provide a good marketplace in the near term. Distros
would be responsible for maintaining a separate location for such a
download page (with the contents at that location meeting the criteria
and policies), but will be able to add and remove binaries as needed,
and edit and update the page as needed. If a distro's page somehow
evolves to be "non-compliant" with adoptium marketplace policies, we can
work with the distro to correct that non-compliance ASAP, as an
after-the-fact action. Distros that repeatedly or insistently violate
the polices can be "dealt with" after the fact, but we will
hopefully/presumably not need to deal with that distiuation at all (or
at least extremely rarely).
I am with you in believing that vendors will not "bait and switch" users
looking to download the Adoptium branded runtimes.
Regards,
Tim
On Jun 7, 2021, at 2:25 AM, Tim Ellison <t.p.ellison@xxxxxxxxx
<mailto:t.p.ellison@xxxxxxxxx>> wrote:
Hello Working Group.
The Steering Committee have been working on the policy for including
products in the Adoptium Marketplace.
The attached draft documents capture the description and criteria we
will apply.
The original documents have hyperlinks that don't work well when
exporting to PDF, and there are still a few agreements referred to in
the documents that have yet to be created, but it will give you a good
idea of what is involved.
We hope to have broad participation, and comments and feedback are
most welcome as they are finalized.
Regards,
Tim
<Adoptium Marketplace Policy v0.2.pdf><Adoptium Trademark Guidelines
v0.2.pdf>_______________________________________________
adoptium-wg mailing list
adoptium-wg@xxxxxxxxxxx <mailto:adoptium-wg@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/adoptium-wg
_______________________________________________
adoptium-wg mailing list
adoptium-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/adoptium-wg
