Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-pmc] regressions, releases and all the rest

Hi Stephan

We started to discuss this in our last call on Tuesday. As we understand it, there are two different topics mentioned.

First, it is about service releases and perceived release quality. From the PMC standpoint the main change with the quarterly release compared to service releases is the way it is communicated to developers and users. It explicitly mentions that it is a new release which can contain new features and APIs. This however is not new and was already the case with the service releases, though we acknowledge that this is likely more common now than in the past..Everyone is still adjusting to the new model, and it also means for committers to be more careful when committing and reviewing stuff for the release. Some in the PMC claim that for them, the quality of the quarterly release actually increased because more people worked on it compared to the service release. Is the "regression" part/impression a general one or more towards JDT (Core)? Besides the quarterly release, there's always the possibility to update to an I-build or milestone (which also provides EPPs) that contains the critical fix(es). JDT also delivered some critical fixes via the Marketplace entry for Java 12. We can definitely continue with that for JDT.

The second topic is towards JEPs, JSRs and how Java evolves. For the JEPs the only thing JDT can do is actively participate in the discussions early. Unfortunately, as you know, JDT's manpower is just good enough to consider the possible candidates for the next Java release and those candidates are often confirmed very late in the game. This is really a sad story as we all know. For Java 13 there's not even one JEP target or even proposed to target and the plan is to go into rampdown phase one on June 13. Unfortunately, this is nothing the PMC or anyone at the Eclipse Foundation can help with. Manoj is representing us in the release JSR and tries his best. The part where the Eclipse Foundation and other JSR voters can take influence is when it comes to the vote of a JSR. As you can remember the initial JSR with modularity got rejected which resulted in a delay of the corresponding release.

If there is something concrete that you would like us to do, we would be happy to try our best to help.

Your PMC

From:        Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
To:        pmc <eclipse-pmc@xxxxxxxxxxx>
Date:        16.05.2019 15:19
Subject:        [eclipse-pmc] regressions, releases and all the rest
Sent by:        eclipse-pmc-bounces@xxxxxxxxxxx

Dear PMC,

please bear with me while this post meanders through several meta levels:

You may be aware that recent releases had bugs which were classified by some
users as blockers. While we ask them please wait for the next release, some are
loosing confidence that the next release will not introduce another blocking

Obviously, it's no fun to discuss the absence of pure bug-fix service releases
in each and every bug report. So in one bug I mentioned to the reporter, that
those are not decisions made by individual committers, but in the end it's (so I
think) the Planning Council. After I told him he'd have to convince the PC, I
noticed that I myself could not find any channel for addressing the PC, lest a
channel open to all.

Then I asked on the PC wiki talk page, just to learn that my request should go
through my PMC. So here I am (with a request which is actually an implicit
request from several bug reporters).

To illustrate the tone in those bug discussions, let me just pick one quote that
is only slightly harsher than many others: "surely someone should get fired!".

I'm writing the following detour neither completely seriously, nor *purely*

Maybe, the first who should get fired is me. Why? One of those evil bugs was
found by me just in time for fixing it in 2019-03, but I didn't.

Why didn't I? It occurred in an area where I had just given up on the goal of a
correct implementation. That area is the implementation of JEP 247: "Compile for
Older Platform Versions". For implementing the compiler option --release we need
to interpret a file called ct.sym, but the format of that file is (a)
undocumented and (b) unstable, i.e., changing between releases without notice.

So maybe, the one who should get fired is one of the people responsible for JEP
247, which in my book is a failed specification attempt (which get's me about as
angry as our bugs anger our users).

No, I don't want to personally lead either discussion: I realize that I have no
power to enforce implementability of specifications that we need to implement.
Nor do I want to *lead* the discussion about bug-fix service releases at
Eclipse. I just want to share my observations, which indicate that both are
relevant topics. I'll leave it to the PMC's discretion to either discuss or
forward to some other body.

best regards,
eclipse-pmc mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top