[Pulp-dev] release process updates
bbouters at redhat.com
Wed Jan 18 18:23:15 UTC 2017
Yes, that is my understanding.
On Wed, Jan 18, 2017 at 12:39 PM, Ina Panova <ipanova at redhat.com> wrote:
> Do i understand correctly that blocker bugs will not be verified by
> default, unless we would set "require QE signoff" to True?
> Ina Panova
> Software Engineer| Pulp| Red Hat Inc.
> "Do not go where the path may lead,
> go instead where there is no path and leave a trail."
> On Mon, Jan 16, 2017 at 8:35 PM, Brian Bouterse <bbouters at redhat.com>
>> 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
>> * 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.
>> 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
>>> * 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
>>> * 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
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev