Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

["Daniel Megert" <daniel_megert@xxxxxxxxxx>]

I'm -1 to change
the release schedule. Yes, there are probably more bugs but there are also
more features *and* bug fixes that our users get more frequently.

One important
thing that was not mentioned so far is the role of the Planning Council
where the stakeholders (strategic members and PMCs) discuss and decide
on the schedule. This can for sure not go to EPP unless the current council
is part of the EPP leadership.

For me the thing
we must preserve is the p2 repo and the installer. Package are also nice/useful
but not my top priority.

Dani



From:
       Gunnar
Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
To:
       Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:
       29.01.2020
15:25
Subject:
       [EXTERNAL]
Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the    
   Tracks
Sent
by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

---

> On Jan 29, 2020, at 12:44, Sebastian
Zarnekow <sebastian.zarnekow@xxxxxxxxx> wrote:
> 
> But in general, the current release cadence puts too much of a burden
on the shoulders of all maintainers.


As a project lead contributed to the train in the past and as a package
maintainer, I truly disagree with the "too much of a burden"
claim being raised here. Once you got all the things in place and compliant
I don't ever recall it being a problem to put out new bits. 98% of it was
automated anyway. It was push on Jenkins. The other 2% was bureaucracy
in the portal.


> Platform and JDT used to be rock solid with the annual releases. Now
we see more releases but also more bugs and complains from users as far
as I can tell. Most of the people that I'm talking too are no longer confident
in the quality of the release. For them it's nowadays a tradeoff between
the bugs the suffer from and know of vs the bugs they will suffer from
but don't know yet.

There is some truth here but it really isn't that bad. I'd like to raise
two things on the positive side, though.

1. The quality is in my subjective impression on par with - if not better
- than the six-weeks milestone releases Eclipse had previously.
2. I don't have to wait for a full year till I'm able to consume a fix.

Yes, I do face a few bugs. Some of them are annoying. But I'd challenge
if they are really a result of the faster release cadence *or* a result
of funding downsizing in involved development teams.


> > Also annual releases will resurrect a number of "service
releases" with all the effort required,
> 
> And with the quality gains. Exactly.

You will only see quality gains *if* the projects are willing to invest
into maintaining a service branch. I have the impression that it's easier
for the active projects to simply fix things in main/master and don't worry
about back porting (which can double work).


In the past the SimRel had its clear purpose. It was a big win for the
Foundation to be able to coordinate releases across its projects. It really
made us look big in terms of numbers and successful (year over year at
the same time, no delays). It came with a ton of bureaucracy. IBM thankfully
dedicated full-time employees to creating and maintaining the SimRel.

I think it was already a risky decision to continue business as usual when
the only FTE retired. There is a staffing issue at hand. I don't get the
proposal of going back to one release per year. What is the solution if
SimRel rans into a staffing issue again? One release every four years?
I think a first step is to admit that we cannot maintain the existing process.
There simply isn't enough funding.

We have to allow and ask the question - is it time to end the SimRel?

FWIW, as a package maintainer I don't care if I consume things from a central
aggregated repository or from multiple sources. I maintain an EPP package
as well as an internal distribution. Especially with the later I learned
that the value of consuming things from the SimRel train repo is lower
than I thought. Some SimRel participating projects publish updates more
frequently to their own p2 repos. Some projects continue to think that
only one certified version of Apache HttpClient, Guava, SLF4J, Commons
Logging, whatever can be shipped with their release. SimRel never solved
that. Things got much easier once I stop putting third party plug-ins into
feature.xml files and started letting p2 figure it out. Works great and
dramatically reduced the burden to adopt to any new Eclipse release.

-Gunnar

-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev