Thanks, Jason.. I'll look into that. +1 on Dave's comments -- the process shouldn't be that heavy-weight. Yes -- there *should* be Jira tickets for anything not trivial, but should be at the discretion of the PR reviewer whether to request it or not..
-dan On Wed, Jul 19, 2017 at 7:55 AM, Jason Tucker <[email protected]> wrote: > Re: the github PR trigger thing > > It looks like those hooks are available: > https://blogs.apache.org/infra/entry/github_pull_request_builds_now > > Here's an example of it being used by the kafka project: > > https://github.com/apache/kafka/pull/3546 > > Once those status checks are being returned, then the status gates can be > turned on under branch protection. > > __Jason > > On Tue, Jul 18, 2017 at 10:33 PM, Dave Neuman <[email protected]> wrote: > >> I personally don't think that we should require a Jira for every single >> PR. I think blanket statements like "you must create a Jira ticket for >> each PR", while made with good intentions, are too hard to enforce, don't >> take every situation into account, and are sometimes a deterrent to new >> contributors. If Joe somebody from the internet wants to submit a PR, we >> should welcome it and not say "we are not accepting this without first >> creating a Jira account and then creating a Jira ticket". >> >> The changelog thing is a real problem. We had a plan to have an >> auto-generated changelog, but that was reliant on us moving to full github >> which we haven't done yet. I think maybe the changelog conversation might >> need to be re-visited. >> >> Have you taken a look at our contributing guide[1] on github? It already >> outlines a lot of the things you are proposing here and I think its the >> best place to have our PR requirements. >> >> I like Jason's idea, though not sure if it is possible. >> >> [1] >> https://github.com/apache/incubator-trafficcontrol/blob/ >> master/CONTRIBUTING.md >> >> Thanks, >> Dave >> >> On Tue, Jul 18, 2017 at 8:08 PM, Jason Tucker <[email protected]> >> wrote: >> >> > 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 >> > > >> > >>
