Re: [eclipse-pmc] regressions, releases and all the rest

["Daniel Megert" <daniel_megert@xxxxxxxxxx>]

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
regression.

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*
jokingly:

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,
Stephan
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-pmc