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.