Hi all, +1 for going back to annual releases.
I am very glad about the Jiro change, though. The work done by Ed M is very appreciated. Ideally, the different checks (e.g. licenses) could be automated to prevent degradation of SimRel quality. This would also raise awareness immensely as following all discussions is a little too much for me, personally — I select what to read according to title. Best regards, Matthias -- Matthias Wienand B.Sc. Softwaretechnik Software Engineer Telefon: +49 231 9860 202 Telefax: +49 231 9860 211 Mobil: +49 176 248 950 82 matthias.wien...@itemis.de http://www.xing.com/profile/Matthias_Wienand2 http://www.itemis.de itemis AG Niederlassung Lünen Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Abdelghani El-Kacimi Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino > Am 29.01.2020 um 10:10 schrieb Ed Willink <e...@willink.me.uk>: > > Hi > > I share Ed and Christian's concerns, and as I wrote earlier the original > purpose of SimRel was to provide a coherent synchronized release across all > active projects. The quarterly SimRel has totally undermined that because > many projects cannot support the faster cadence. Personally, it means that I > just chuck out my auto-tested builds without manual verification. Diligent > checks that I used to perform annually have gone out the window. I used to > use perhaps every other 6 weekly milestone for my personal development > resulting in many regression bugs getting fixed pre-release. Now the > regressions get detected after release; it is all much much too fast. The > final platform RC is done almost before some projects have started on their > first RC. The only things that can get fixed are panics and just look at the > number of RC3 respin discussions we now have to have because of the > unreasonable speed; in the past RC3 and RC4 were available. > > Let's go back to annual SimRels that provide a coherent best endeavours > release that users can be confident of enhancing by taking on board service > releases. No longer a brand new different selection of novel bugs every > quarter. > > If projects want to do quarterly intermediate releases, fine, they are > intermediate releases. Until such time as the high speed community steps up > and commits the resources to support it, why does the rest of Eclipse have to > suffer? > > The timing of the annual release should be aligned to offer a useable rather > than experimental latest-Java experience. > > (When I advocate annual SimRels, that does not mean I endorse EPPs. > Personally I only use the base Eclipse SDK ZIP, project ZIPs where available > and the SimRel P2 as a last resort. I can easily live without EPPs, but a > synchronized SimRel P2 is critical.) > > (As a modelling developer I might be expected to use the Modeling EPP, but > sadly I find that although ridiculously bloated, it lacks important projects > and includes one project that I find detrimental to my UX.) > > Regards > > Ed Willink > > On 29/01/2020 08:21, Dietrich, Christian wrote: >> Hi all, >> >> I personally share Ed's concerns about the direction the Eclipse >> SimRel is thrifting. Maintaining 4 Releases a Year in a quite involved >> project like Xtext with many dependencies was a lot of work. Also the >> move to the new Cloud based Jenkins infrastructure ate a lot of >> resources at the Xtext team last year. Resources that we won't have >> this year. Thus is see this a burden for many smaller and less >> resourced projects. I am not sure if a pull approach would solve this >> problem as there still needs to be common ground for projects that >> need to depend on each other. No EMF would mean no Platform, Xtext, >> OCL etc. >> >> ~Christian >> _______________________________________________ >> 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
_______________________________________________ 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
