<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>Sounds good to me.</div><div><br></div><div>Lars</div><div><br></div><div><br></div><div>-------- Weitergeleitete Nachricht --------</div><div><b>Von</b>: Nick Boldt <<a href="mailto:Nick%20Boldt%20%3cnboldt@redhat.com%3e">nboldt@redhat.com</a>></div><div><b>An</b>: jbosstools-dev@lists.jboss.org <<a href="mailto:%22jbosstools-dev@lists.jboss.org%22%20%3cjbosstools-dev@lists.jboss.org%3e">jbosstools-dev@lists.jboss.org</a>>, devtools-devsuite <<a href="mailto:devtools-devsuite%20%3cdevtools-devsuite@redhat.com%3e">devtools-devsuite@redhat.com</a>></div><div><b>Betreff</b>: [jbosstools-dev] Proposed new approach to devstudio milestones when blockers/criticals are found: ship with Known Issues</div><div><b>Datum</b>: Thu, 13 Sep 2018 15:48:02 -0400</div><div><br></div><!-- text/html --><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">A couple days ago, the Fuse Tooling team encountered what was at first thought as a blocker, but later downgraded [0].<div><br></div><div>This brought up the issue of what to do when problems are found late in the QE test cycle (3hrs before the usual signoff). </div><div><br></div><div>There are of course 3 options when this happens:</div><div><br></div><div>a) block the release and <b>respin</b>, 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</div><div><br></div><div>b) block the release and <b>DO NOT SHIP</b></div><div><br></div><div>c) release <b>AS IS</b> with note about Known Issues on the project's New & Noteworthy [1] page and on the blog [2].</div><div><br></div><div>[0] <a href="https://issues.jboss.org/browse/FUSETOOLS-2799">https://issues.jboss.org/browse/FUSETOOLS-2799</a></div><div>[1] <a href="http://tools.jboss.org/documentation/whatsnew/jbosstools/4.9.0.AM3.html#fusetools">http://tools.jboss.org/documentation/whatsnew/jbosstools/4.9.0.AM3.html#fusetools</a></div><div>[2] <a href="http://tools.jboss.org/blog/4.9.0.am3.html#fuse-tooling">http://tools.jboss.org/blog/4.9.0.am3.html#fuse-tooling</a></div><div><br></div><div>Along with the new approach to doing fewer milestone releases [3], I'd like to propose that we:</div><div><br></div><div>* stop doing respins UNLESS it's a GA candidate build. </div><div><br></div><div>[3] <a href="https://docs.google.com/document/d/1zmT5OuFJWyYrbg1rr6tJqur6ng4rrglUy2tdJbIuCDg/edit#heading=h.o6074tuk59c9">https://docs.google.com/document/d/1zmT5OuFJWyYrbg1rr6tJqur6ng4rrglUy2tdJbIuCDg/edit#heading=h.o6074tuk59c9</a></div><div><br></div><div>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.</div><div><br></div><div>How do you feel about this approach? </div><div><br></div><div>Nick</div><div><div><br></div><pre>_______________________________________________</pre><pre>jbosstools-dev mailing list</pre><pre><a href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</a></pre><pre><a href="https://lists.jboss.org/mailman/listinfo/jbosstools-dev">https://lists.jboss.org/mailman/listinfo/jbosstools-dev</a></pre></div></div></div></div></div></div></body></html>