On Jun 10, 2021, at 9:09 AM, Tim Ellison <t.p.ellison@xxxxxxxxx> wrote:
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.
This may be a key point, and which way we go on the rest of the marketplace probably hinges on it...
Rather than worry about vendors deliberately confusing end users, I think that after-the-fact "policing" (as opposed to ahead-of-update verification by Eclipse) will be fairly easy here, if we state and
keep up to date a clear policy to police to. I don't really worry about "cheating" being a problem, and believe that the actual members listing on the marketplace will be motivated to maintain their individual adoptium-marketplace-download-landing page in
good order. Innocent mistakes may (and likely will) happen, but those can be quickly corrected if they do. Deliberate and ongoing abuse, if that ever happens, can be dealt with offline, without requiring technical process details.
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.
A key thing here is that I think each distro listed should provide a landing page meant specifically for the adoptium marketplace (as opposed to marketplace pointing to a generic download page that is
useful for other purposes). This allows us to make policy statements about that distro-provided landing page that in no way restrict what the distro owner or vendor can do elsewhere in their sites.
Here are some high level expectations (I don't want to use the word "policy" too early) I would have for a distro-provided adoptium-marketplace-downloads-page:
- I would want the distro-provided adoptium-marketplace-downloads-page to identify itself as being specific to the adoptium marketplace. E.g. visibly use "Adoptium Marketplace"
or some such wording in the headers. It can say many other things too, but the fact that the page is meant to show adoptium-marketplace binaries should be clear, and not a hidden footnote.
- Only adoptium-marketplace-eligible binaries should be listed on the page in question. No scrolling, no other sections, and no menu selections "within the page" should lead to binaries that are not adoptium-marketplace-eligible.
- *If* the page includes (or links to pages that include) instructions for automation or installation steps (e.g. how to set up a repo-based download), those should only cover adoptium-marketplace-eligible
binaries. If there are repos involved, the repos described should only contain adoptium-marketplace-eligible binaries. [specifically: repos that also contain other things, like EA or daily builds, should be separate repos that are not described or referred
to in the adoptium-marketplace-downloads-page].
- It is fine for there to be links to other pages, and it is fine for other pages that readers may end up navigating to to include other binaries. Following links will be "leaving the adoptium-marketplace-specific
download page", and we don't have to stop that from happening. We just don't want other pages you link to appear to be adoptium marketplace download pages when they are not.
(There are probably additional expectations needed that I haven't listed here).
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.
I worry that if we translate this to "only direct links to individual runtime binaries" it will make the marketplace "not that useful".
The licensing of the AQAvit mark is separate from the marketplace listing and marketplace structure. Being in the marketplace requires multiple things: membership, TCK testing, AQAvit certification. In
my approach, all binaries that appear in "adoptium-marketplace-specific download pages" linked to from the marketplace, and supplied by individual distros, will need to meet all those requirements.
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.
That's what makes me hope that after-the-fact "policing" will be very practical here, allowing us to avoid the friction of before-the-fact validation and of common-denominator download page structures.
