I'll assume unless someone speak up with a -1 or other objection that this
is the plan moving forward.
On Fri, Sep 14, 2018 at 2:21 AM Lars Heinemann <lheinema(a)redhat.com> wrote:
Sounds good to me.
-------- Weitergeleitete Nachricht --------
*Von*: Nick Boldt <nboldt(a)redhat.com
*An*: jbosstools-dev(a)lists.jboss.org <jbosstools-dev(a)lists.jboss.org
*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 .
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  page and on the blog .
Along with the new approach to doing fewer milestone releases , I'd
like to propose that we:
* stop doing respins UNLESS it's a GA candidate build.
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
How do you feel about this approach?
jbosstools-dev mailing list
Principal Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews>
“The Only Thing That Is Constant Is Change” - Heraclitus