Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] [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:

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.



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.


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: 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 <>
    developer, for Red Hat Developers <>
    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


Nick Boldt

Principal Software Engineer, RHCSA

Productization Lead :: JBoss Tools & Dev Studio

IM: @nickboldt / @nboldt /


@ @redhatnews <>     Red Hat

“The Only Thing That Is Constant Is Change” - Heraclitus

_______________________________________________ mailing list

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