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#f... [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/1zmT5OuFJWyYrbg1rr6tJqur6ng4rrglUy2tdJ... 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

Sounds good to me. Lars -------- Weitergeleitete Nachricht -------- *Von*: Nick Boldt <nboldt(a)redhat.com <Nick%20Boldt%20%3cnboldt(a)redhat.com%3e&gt;&gt; *An*: jbosstools-dev(a)lists.jboss.org <jbosstools-dev(a)lists.jboss.org <%22jbosstools-dev@lists.jboss.org%22%20%3cjbosstools-dev(a)lists.jboss.org%3e&gt;&gt;, devtools-devsuite <devtools-devsuite(a)redhat.com <devtools-devsuite%20%3cdevtools-devsuite(a)redhat.com%3e&gt;&gt; *Betreff*: [jbosstools-dev] Proposed new approach to devstudio milestones when blockers/criticals are found: ship with Known Issues *Datum*: Thu, 13 Sep 2018 15:48:02 -0400 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#f... [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/1zmT5OuFJWyYrbg1rr6tJqur6ng4rrglUy2tdJ... 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 _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev