RFR: [8u] JDK-8225121 Set JDK_UPDATE_VERSION, JDK_BUILD_NUMBER and MILESTONE to correct values by default

[Andrew Hughes]

Returning to this issue as it's still in my bug queue.

On 03:33 Wed 12 Jun     , Gil Tene wrote:
> Wait, if I read this right, the proposed changes will:
> A) make what used to default to “-internal” now default to “-ea” instead.
> B) make what used to default to “-internal” now default to nothing (i.e. fcs) in certain
>     (quarterly release) versions of the source.
> 
> If so, I don’t see how this is a good thing. I think it will only serve to exacerbate the
> sort of problem you are trying to solve.
> 
> IMO "-internal" is much more appropriate and scary (in a good way) default tag than
> "-ea" is for what people might randomly build against some random version of sources
> 'that they got, using the latest version of glibc on their latest and greatest desktop setup.
> 
> More importantly "-internal" is absolutely the appropriate tag for the thing that comes
> out of me downloading the released sources and building them on my desktop today,
> with my own hacked version of glibc and associated headers, using my private version
> of gcc, with warnings and some annoying errors turned off for expediency. The result
> of doing that (right now) shows 1.8.0-internal. That is as it should be.
>

But there's also nothing to stop you setting the milestone to fcs for
that exact same setup. A build calling itself 1.8.0-internal, 1.8.0-ea
or just 1.8.0 doesn't tell you anything about the system on which it
was built.

Indeed, this very issue arises because the tendency for downstream
consumers who aren't familiar with the oddities of the OpenJDK build
(and it is odd compared to many other FOSS projects) is to find some
configuration that works and then leave it at that.

There seems to be an expectation in this discussion that someone
building OpenJDK is following development, uses source tree checkouts
and knows what's a released version and what isn't. That isn't
generally true.  I still think it shouldn't be necessary for someone
downloading a source release to tell the source release what it is.

> I’m all for ways to make it more clear that the non-released stuff is EA (and should be
> tagged as such if built to be shared with others), but I don't think we should break the
> well established developer workflows and the existing safeguards against creating
> unintentionally-tagged-as-something-consumable things in order to do so.
>

Then what do you suggest?

I don't see how this breaks any workflow where the developer is
already explicitly setting either ea or fcs.

The very problem that this discussion arose from shows that these existing
safeguards don't work.

> IMO "fcs" should *never* show up as a milestone value in the checked-in version of
> any files. Using it in a build should be an intentional act, meant to to put that milestone
> on a build, in that specific build environment, and not something we encourage
> happening "by accident" on every developer desktop around the world that happens
> to download the sources. The thing being built from those sources on some random
> setup may be very far from the thing you'd want to tag as "fcs" (and may fail many tests)
> and there are many new failure scenarios and bad build leakage issues we will create
> if we make this the default tag for builds from quarterly released sources…

The fundamental disagreement here seems to be that you see what is
being released as being a build. However, what we release is primarily
source code which is then built by a variety of downstream consumers.

By the logic expressed above, it seems we should not even be tagging
the repositories with a GA version, because whether something is GA or
not is determined not by the source code, but only by the source code
in some "specific build environment".

This seems to run counter to the very conception of a FOSS project where
the release material is the source code. I'm not aware of glibc or gcc's
final release status being determined by a build in a specific build
environment and I don't think this should be true of OpenJDK either.

> 
> We've had a working flow for a decade+ now, and many different good builds that use
> that flow. It tags builds as dangerous by default. It relies on internal builds (and their build
> environment) being stabilized, tested, and sanity checked before any "for external
> consumption" tag is placed on the output of the "now we really mean it" build that we
> produce in the same environment, and repeat the tests on.
> 
> Let's not break that well established flow.
>

Again, there is nothing in the build to enforce such a workflow. The
testing Oracle may do before declaring a release GA is different to
the testing Red Hat may do, for example (and there are plenty of
occasions when we have found GA builds with breakage)

> If we want to *add* an additional, harder to remove "EA" tag (so that it will show both
>  -internal and the ea thing, and that even with an fcs milestone it will still show EA
> unless it was removed (or was not there because the sources are form an actual
> release), I'd be supportive. But taking off the belt and suspenders (removing the
> default "-internal") and cutting a little into the break lines (making fcs default in
> released source versions) because we think the drivers of these build scripts are
> experienced enough to run with scissors is something that should be done only
> after a lot of more sober introspection and sleeping on things.
>

This seems little more than derogratory to those who spend many hours
building OpenJDK, so it is available for people to use, without them
having to do so themselves.

It is a simple fact that, with a FOSS project, someone can take the
source code and do whatever they want with it. They can label it
how they want. They can build it with whatever flags they choose.
Indeed, that is freedom 1 of the four essential freedoms [0].

I would prefer that we encourage people with trust and help them to do
the right thing out of the box, rather than assuming they are
miscreants who needed to be forceably stopped from doing bad things.

> — Gil.
> 

[0] https://www.gnu.org/philosophy/free-sw.html
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222