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 <gun...@wagenknecht.org> To: Cross project issues <cross-project-issues-dev@eclipse.org> 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-boun...@eclipse.org > On Jan 29, 2020, at 12:44, Sebastian Zarnekow <sebastian.zarne...@gmail.com> 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 gun...@wagenknecht.org, https://urldefense.proofpoint.com/v2/url?u=http-3A__guw.io_&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=gvjVJO_4vPGdQd5qd7faqgcZ7fijaZLH5AOhgMIxHo4&s=_kiNEH3ULUUBSDzu__Ty4CmyUAgPSaI4zQBPvOcsAqA&e= _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org 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@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
