[jbosstools-dev] Proposed new approach to devstudio milestones when blockers/criticals are found: ship with Known Issues

[Nick Boldt]

A couple days ago, the Fuse Tooling team encountered what was at first
thought as a blocker, but later downgraded [0].

This brought up the issue of what to do when problems are found late in the
QE test cycle (3hrs before the usual signoff).

There are of course 3 options when this happens:

a) block the release and *respin*, then wait 4-6 hrs for new bits, and some
number of hours for QE to review & approve the changed build. Release ends
up being delayed by a day or two

b) block the release and *DO NOT SHIP*

c) release *AS IS* with note about Known Issues on the project's New &
Noteworthy [1] page and on the blog [2].

[0] https://issues.jboss.org/browse/FUSETOOLS-2799
[1]
http://tools.jboss.org/documentation/whatsnew/jbosstools/4.9.0.AM3.html#fusetools
[2] http://tools.jboss.org/blog/4.9.0.am3.html#fuse-tooling

Along with the new approach to doing fewer milestone releases [3], I'd like
to propose that we:

* stop doing respins UNLESS it's a GA candidate build.

[3]
https://docs.google.com/document/d/1zmT5OuFJWyYrbg1rr6tJqur6ng4rrglUy2tdJbIuCDg/edit#heading=h.o6074tuk59c9

So, for an AMx milestone build, we should mostly do option c (ship w/ a
note), unless the milestone is REALLY unusable, in which case option b
would apply.

How do you feel about this approach?

Nick

-- 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20180913/211e9a91/attachment.html