Sounds good to me.

Lars

-------- Weitergeleitete Nachricht --------

Von: Nick Boldt <nboldt@redhat.com>

An: jbosstools-dev@lists.jboss.org <jbosstools-dev@lists.jboss.org>, devtools-devsuite <devtools-devsuite@redhat.com>

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#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

_______________________________________________

jbosstools-dev mailing list

jbosstools-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/jbosstools-dev