[Pulp-dev] release process updates

[Ina Panova]

I personally would be -1 then( to this point ),  because if we state that
we cannot make release with blokers opened,  that would be not really wise
to make the actual release without their verification. How can we state
that the blocker was fixed and in addition what's then the point then to
make the issue as blocker and fix it in tight deadlines.
I think all blocker bugs should be verified by default, and other bugs just
when there's flag set by devs.

18 янв. 2017 г. 19:23 пользователь "Brian Bouterse" <bbouters at redhat.com>
написал:

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/acb7a79a/attachment.htm>