[Pulp-dev] release process updates

[Preethi Thomas]

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

+1

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