[Pulp-dev] release process updates

Preethi Thomas pthomas at redhat.com
Thu Jan 19 15:44:09 UTC 2017

On Thu, Jan 19, 2017 at 9:50 AM, Jeremy Audet <jaudet at redhat.com> wrote:

> > I’m not sure I completely understand why we should not be having QE
> verify Refactors. What if we’re worried about introducing regressions with
> a Refactor?
> Consider the ways in which a refactor might unintentionally change Pulp's
> behaviour. A refactor might introduce a race condition, or accidentally
> shadow a variable in a different scope, or introduce a typo that causes
> tracebacks inside a try/except block, or something else. How do you test
> that?
> Refactors are an internal change that should have no visible effect, and I
> think the best way to test them is to just run the test suite we already
> have. It seems more productive for QE to write tests for existing and new
> features and bugs than to guess the ways in which a refactor might
> unintentionally change Pulp.


> > How can we state that the blocker was fixed
> The same way we state that any other bug has been fixed: by marking it as
> MODIFIED. Fixing a bug is different from having QE verify that it's fixed.
> The addition of a "verified" field in redmine would let QE give an explicit
> stamp of approval.

The new "verified" field is what  we decided on in the Release procees
meeting.  This will give QE the ability verify issues post release without
actually changing the status.

> > and in addition what's then the point then to make the issue as blocker
> and fix it in tight deadlines.
> Blocker bugs determine whether or not a release can move forward or not.
> It's purely a developer tool. To be clear, QE currently ignores the
> 'blocker' field. The status quo is to verify all bugs on a best effort
> basis. Releases currently go out the door with un-verified blocker bugs.

One aditoinal point I want to mention here is, if the fix for a blocker or
any issue in a release specifically require QE verification, then those
will be verified either by automation or manually.

> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170119/fab98e9d/attachment.htm>

More information about the Pulp-dev mailing list