|Re: [eclipse.org-planning-council] [tools-pmc] [cross-project-issues-dev] SimRel 2018-09 Release Candidate 2 (RC2) staging repo is complete|
I tend to agree.
The overhead of a respin involves many people. We're also getting very close to the time when mirrors need to be in place, so if a significant number activities are going to drag out to the end of the day on Monday, that's definitely not a good thing. I suppose the mirrors would catch up within a day...
For me this is issue is a -1.
On 14.09.2018 20:39, Frederic Gurr wrote:
Hi, Respins should be exceptional and done only in cases of blocking issues that affect a lot of users and can't be handled with a workaround. According to Mickael Istrias post, this does not seem to be the case here. I fear it could set a bad precedent as "oh well, we can always do a respin". ;) And the next release is only 13 weeks away... Obviously, I will accept the Planning Councils decision either way. Regards, Fred On 14.09.2018 16:34, Nick Boldt wrote:As a Planning Council member I'd say if webmasters, simrel, and EPP people can contain the change, then a respin is acceptable. If not, then I would publish a Known Defect / New & Noteworthy doc somewhere (linked from the simrel release announcement page(s)) which tells people how to get the repaired version of Corrosion from its nightly/snapshot/CI site. That way the effort for the fix is on the Corrosion team, not the webmasters/simrel/EPP folks. OTOH, since this is the *first simrel release after Photon*... does it set a bad precedent / create bad PR if the simrel & EPP packages are *not 100% awesome on GA day*? If so, then maybe the respin is better than a KD/N&N doc. Adding PC to cc: for discussion & action. Nick On Fri, Sep 14, 2018 at 6:29 AM Mickael Istria <mistria@xxxxxxxxxx <mailto:mistria@xxxxxxxxxx>> wrote: Hi PMC, Corrosion suffers from a blocking issue: https://github.com/eclipse/corrosion/issues/131 which was included in the build that's in SimRel. It seems like we'd be able to fix it promptly. So if it's easy and not controversial, we'd appreciate if a respin can happen. But if it's too hard, Corrosion is a low popularity plugin, I expect that most installation come from marketplace (Where we can publish a newer version including the patch whenever we want) or by downloading the zip (which represents 0.5% of all downloads). Also, I believe Corrosion is not business-critical to us as maintainers.The impact of this bug will be bad, for sure, but maybe not bad enough... Affected people will be mostly those who have already an EPP package installed and run an upgrade against newer SimRel. However, IIRC, this process is disabled by default. Should we trigger a respin request process, or just live with a broken Corrosion in SimRel or ... ? -- Mickael Istria Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/> developer, for Red Hat Developers <https://developers.redhat.com/> _______________________________________________ tools-pmc mailing list tools-pmc@xxxxxxxxxxx <mailto:tools-pmc@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/tools-pmc -- Nick Boldt Principal Software Engineer, RHCSA Productization Lead :: JBoss Tools & Dev Studio IM: @nickboldt / @nboldt / http://nick.divbyzero.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> @ @redhatnews <https://twitter.com/redhatnews> Red Hat <https://www.facebook.com/RedHatInc> <https://www.facebook.com/RedHatInc> “The Only Thing That Is Constant Is Change” - Heraclitus _______________________________________________ eclipse.org-planning-council mailing list eclipse.org-planning-council@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
Back to the top