Do you know if the the apache jenkins instance supports PR-triggered
builds? If so, then repo branches can be protected so that PRs can only be
merged if the build status is successful. Might be a good safeguard to have
in place, if we have the ability to enable it on the jenkins side.

__Jason

On Wed, Jul 19, 2017 at 12:19 AM, Gelinas, Derek <[email protected]>
wrote:

> As the project grows in complexity and the speed of updates, we're finding
> a real need for changelogs and a reduction in the number of commits.  At
> this time, creating a changelog over even a short period of time is a
> tedious and time consuming activity, and it is making even incremental
> updates difficult for us here at Comcast.
>
> I would like to propose the following:
>
>
>   *   Each PR must have a linked jira issue.  This is as simple as
> creating the ticket and then adding [TC-XXX] to the beginning of the PR
> title.  The jira ticket title should briefly describe the fix or new
> feature in a manner which lends itself to inclusion in a changelog.
>   *   Large changes should have as much information as possible about the
> nature of the change and how this change affects the system.
>   *   Testing should be done on all changes before the PR is submitted!
> Please do not submit anything that has not been fully tested, regardless of
> how simple or obvious it may seem.  You are the first line of defense
> against bugs!  If the work is not yet complete, be sure to add [WIP] to the
> title of the PR.
>   *   Commits should be squashed as much as possible before the PR is
> submitted.  27 commits for minor changes make review and later analysis
> very difficult.  Commit messages should be descriptive so it is clear what
> was changed.
>   *   New features or changes to functionality should include
> documentation changes whenever possible.
>   *   Integration testing should be included whenever possible - we now
> have automated integration testing, so this is another valuable method to
> isolate bugs before they hit the field.
>   *   When in doubt, be clear about what you are doing!
>
> I would also like to propose that if these requirements are not met
> without specific reasoning, PRs should be rejected until they are corrected.
>
> Derek
>

Reply via email to