> 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, http://guw.io/ _______________________________________________ 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
