| Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks |
_______________________________________________On Wed, Jan 29, 2020 at 8:06 PM Daniel Megert <daniel_megert@xxxxxxxxxx> wrote: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.IMHO EPP (incl. SimRel) shouldn't be mixed with Planning Council - it should be governed as every other project. Planning Council should be more of a cross project collaboration place. I would also question the need for Strategic members and PMCs having a vote on EPP (even less being in the leadership) unless the member in question actually does something in the EPP project.As much as this might sound like blasphemy we will fail to attract people taking over some duties if there are multiple abstract bodies dictating what/how to be done. I know that I (personally) for sure would not sign up in such a case. Having people that actually know what/how/why is done or at least are interested in helping some area would be more than welcome but having people from a PMC that failed to do proper release for couple of years or just being appointed by some company seems pointless. And my Planning Council experience shows that such people never actually attended even less discussed anything at the meetings and this makes me even more convinced that giving every strategic member and PMC EPP leadership would be totally wrong move.
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
_______________________________________________
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
--Alexander KurtakovRed Hat Eclipse Team
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
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.