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 > > > > > >
