[Pulp-dev] release process updates

[Brian Bouterse]

Yes I think it captures the discussion. +1 to all ideas you've written.

[related ideas]
* The release criteria and workflow document is not community visible. Does
it make any sense to move that to the wiki?
* For the two new fields proposed, they should apply to Redmine tracker
types (Story, Issue, and Task but not Refactor). Refactors cannot be
"verified" or "require QE signoff" because by definition they should
perform.
* For mailing list proposals with feedback, what about a time limit.
Perhaps 1 week? If there are no -1s given by Jan 24th, we could consider
this proposal accepted.
* After feedback is given, we should turn these into Redmine tasks
(probably 3 tasks, 1 for each section).

Thanks for sending this out.

-Brian

On Mon, Jan 16, 2017 at 12:53 PM, Jeremy Audet <jaudet at redhat.com> wrote:

> This email is a follow-up to today's "Release process and communication."
> The goal of today's conversation was to improve how the dev and QE teams
> interface. The following proposals were made.
>
> Documentation Improvements
> --------------------------
>
> The Pulp Release Criteria and Workflow
> <https://mojo.redhat.com/docs/DOC-1101802> document appears to contain
> errors:
>
> * The "Y Releases" section states that "Pulp issues addressed by the
> release must be verified." Otherwise, the release is blocked.
> * It is not clear whether blocker bugs require verification.
>
> These errors can be fixed like so:
>
> * State that Y releases may be released even with bugs that haven't been
> verified. This is the same as for Z releases.
> * State that blocker bugs do not require verification.
>
> Verification Tracking Improvements
> ----------------------------------
>
> There should be some way for QE to state that an issue has been verified.
> QE currently does this through the VERIFIED state, but this is problematic:
> issues are changed to a CLOSED state when bugs are released, effectively
> erasing QE's stamp of approval. The proposed solution is to update how
> redmine tracks issues:
>
> * Remove the VERIFIED state from issues.
> * Add a 'verified' field to issues. Let this field be a boolean, and let
> it default to false.
> * Remove references to the VERIFIED state from upstream and downstream
> automation.
> * Remove references to the VERIFIED state from the docs, if present.
>
> Verification Request Improvements
> ---------------------------------
>
> The developers should have some mechanism to require that an issue be
> verified before a release goes out the door. This mechanism should be
> present because most releases are not blocked based on whether or not QE
> has verified an issue. The proposed solution is to let pulp.plan.io track
> this information:
>
> * Add a 'require QE signoff' field to issues. Let this field be a boolean,
> and let it default to false.
> * Expand release announcement emails. Let the emails include a link to a
> pulp.plan.io query that returns all issues requiring QE verification, and
> possibly copy-and-paste this list into the release announcement emails.
>
> -----
>
> Does this capture the actionable topics from today's discussion? Do you
> agree with these proposals, or not? (Even a simple "Yes, and yes." is
> useful.)
>
> —Jeremy
>
> _______________________________________________
> 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/20170116/f58f025a/attachment.htm>