[Pulp-dev] release process updates

Brian Bouterse 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?
>
>
>
>
> --------
> Regards,
>
> 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>
> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20170118/8c20050b/attachment.htm>


More information about the Pulp-dev mailing list