Skip to content

Instantly share code, notes, and snippets.

@jakebrinkmann

jakebrinkmann/.gitattributes

Forked from Lordnibbler/pull-request-template.md
Last active February 21, 2020 16:54
Show Gist options
  • Save jakebrinkmann/dec832bc74c127ac8319dd2d6e9c34f9 to your computer and use it in GitHub Desktop.
Save jakebrinkmann/dec832bc74c127ac8319dd2d6e9c34f9 to your computer and use it in GitHub Desktop.
Download ZIP
Sample Pull Request Template (⚡VIEW RAW FOR HIDDEN COMMENTS⚡)
Raw
.gitattributes
/CHANGELOG merge=union
Raw
CHANGELOG.md

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog and this project adheres to Semantic Versioning.

[1.4.0] - 2019-09-17

This version contains 99 contributions from 11 contributors. There are 94 files changed; 9,453 insertions; and 6,121 deletions.

Attention: Pilosa 1.4.0 changes the way that integer fields are stored. The upgrade from old format to new is handled automatically, however you will not be able to downgrade to 1.3 should you wish to do so. We always recommend taking a backup of your Pilosa data directory before upgrading Pilosa, but doubly so with this release.

Added

  • Update "Getting Started" documentation (#2028)
  • Add ability to disable tracing and use nopTracer (#2029)
  • Add test for no containers (#2016)
  • Add naive implementations of Roaring and fuzz test (#2023)
  • Add fuzzing code and readme.md to explain the fuzzer (#2004)
  • Add MinRow and MaxRow calls (#1983)
  • Add Prometheus stats backend (#1992)
  • Add extra tracing spans and metadata (#1939)
  • Add more Debugf() statements to the holder open process (#1950)
  • Add ability to post schema using holder.applySchema (#1956)

Changed

  • Update CircleCI build with Go 1.13 and run enterprise tests (#2064)
  • Update Alpine to 3.9.4 in Dockerfile (#2001)
  • Add Prometheus tests, refactor http stats as middleware, minor fixes (#1994)
  • Add confirmation logic to catch false nodeLeave events (#1993)
  • Improve TopN() errors (#1978)
  • Make integer fields unbounded by using sign+magnitude representation (#1902)
  • Simplify contributing instructions by removing weird upstream thing (#1966)

Fixed

  • Default BSI base value to min, max, or 0 depending on the min/max range (#2050)
  • Add worker pool for query processing (#2034)
  • Move Range deprecation message to higher level (#2033)
  • Use lock in view.deleteFragment while altering fragments (#2026)
  • Fix malformed offset bug in readOffsets and readWithRuns (#2021)
  • Fix various container iteration bugs in Roaring (#2019)
  • Fix malformed bitmap handling (#2017)
  • Fix fuzzer errors in roaring (#2012)
  • Save all state files atomically to avoid corruption (#2000)
  • Fix slice container updates (#1997)
  • Fix out of bounds panic to show error (#1975)
  • Fix error message returned by regex on field and index names (#1973)
  • Fix filter calls in GroupBy not being translated (#1970)
  • Fix TranslateFile behavior when reopened (#1954)
  • Remove buggy shard validation code (#1951)
  • Fix some lint warnings raised in VS-Code (#1947)

Performance

  • Address some startup speed and performance issues (#1988)
  • Add a worker pool for importRoaring jobs (#2048)
  • Use UnionInPlace for computing time rows which involve multiple views (#2041)
  • Improve ingest performance with snapshot queue and unmarshaling improvements (#2024)
  • Improve row cache (#1974)

Removed

  • Remove extraneous stat tags to improve prometheus performance (#1996)

[1.3.1] - 2019-05-01

This version contains 1 contribution from 1 contributor. There are 6 files changed; 10 insertions; and 95 deletions.

Fixed

  • Remove shard validation to fix bug where some nodes weren't loading their fragments. #1951 (#1964)

[1.3.0] - 2019-04-16

This version contains 98 contributions from 10 contributors. There are 144 files changed; 12,635 insertions; and 4,341 deletions.

Added

  • Add license headers and CI check (#1940)
  • Add support to modify shard width at build time (#1921)
  • Add 'bench' Makefile target and run fewer concurrency level benchmarks (#1915)
  • Add server stats to /info endpoint (#1859)
  • Implement config options for block profile rate and mutex fraction (#1910)
  • Implement global open file counter using syswrap (to scale past system open file limits) (#1906)
  • Implement global mmap counter with fallback (to scale past system mmap limits) (#1903)
  • Add shard width to index info in schema (allows client to get shard width at run time) (#1881)
  • Add shift operator (#1761)
  • Support advertise address and listen on 0.0.0.0 (#1832)
  • Added convenience function to efficiently calculate size of a roaring bitmap in bytes (#1839)
  • Make sure more tests and benchmarks can have their temp dir set by flag (#1831)
  • Add sliceascending/slicedescending striped benchmarks (#1763)
  • Add setValue test and benchmarks (#1820)
  • Add a test for groupby filter with RangeLTLT (#1818)
  • Add tests for GroupBy with keys; removes unused Bit message from proto (#1811)

Fixed

  • Update to latest memberlist fork with race fixes (#1944)
  • Return original error instead of cause in handler (#1943)
  • Validate (and panic) on duplicate PQL arguments (#1938)
  • Add correct content type to query responses Fixes #1873 (#1936)
  • Address race condition by getting cluster nodes with lock (#1931)
  • Make sure to unmap containers before modifying (#1876)
  • Avoid probable race when creating fragments (#1863)
  • Improve help strings for metrics options (#1887)
  • Ensure ClearRow() arguments get translated (#1848)
  • Prevent omitting zero ids on columnattrs (#1846)
  • Set cache size to 0 if cache type is none (#1842)
  • Prevent deadlock in replication logic on reopening a store (#1834)
  • Pass loggers around properly in gossip (#1835)
  • Include read lock in cluster.Nodes() (#1836)
  • Raise an error on Rows() query against a time field with noStandardView: true (#1826)
  • Don't delete test fragment data (part of repo) (#1827)
  • Fix bug on upper end of bsi range queries (#1822)
  • Group by fixes (#1802)

Changed

  • Switch to GolangCI lint (#1924)
  • Return empty result set when query empty (#1937)
  • Add Go 1.12 to CircleCI (#1909)
  • Ignore fragment files from shards node doesn't own (#1900)
  • Go module support. Use Modules instead of dep for dependencies (#1616)
  • Merge Range() into Row() call. (#1804)
  • Add from/to range arguments to Rows() call (#1851)
  • Fixes Store call error messages, Rows doesn't need field argument (#1830)

Performance

  • BTree performance improvements (#1916)
  • Make Containers smaller, especially when they have small contents (#1901)
  • Address UnionInPlace performance regressions (#1897)
  • Small write path for import-roaring. Makes small imports faster (#1892)
  • Small write path for imports (#1871)
  • Remove copy for pilosa roaring files (#1865)
  • Disable anti-entropy if not using replication [performance] (#1814)
  • Group By—skip 0 counts as early as possible (#1803)
Raw
LOG.md

v 8.0.0 (unreleased)

  • Prevent anchors from being hidden by header (Stan Hu)
  • Remove satellites
  • Better performance for web editor (switched from satellites to rugged)
  • Faster merge
  • ...
  • Ability to fetch merge requests from refs/merge-requests/:id

v 7.14.1

  • Improve abuse reports management from admin area
  • Ability to enable SSL verification for Webhooks

v 7.14.0

  • Fix bug where non-project members of the target project could set labels on new merge requests.
  • Upgrade gitlab_git to 7.2.14 to ignore CRLFs in .gitmodules (Stan Hu)
  • ...
  • Fix broken code import and display error messages if something went wrong with creating project (Stan Hu)
Raw
proposal.md

Proposal Process

(largely stolen from https://github.com/golang/proposal)

Pilosa's development process is design-driven. Significant changes to the core libraries or tools must be first discussed, and sometimes formally documented, before they can be implemented.

This document describes the process for proposing, documenting, and implementing changes to Pilosa.

Pilosa's development process is primarily based on the Go language's process.

Goals

  • Make sure that proposals get a proper, fair, timely, recorded evaluation with a clear answer.
  • Make past proposals easy to find, to avoid duplicated effort.
  • If a design doc is needed, make sure contributors know how to write a good one.

Definitions

  • A proposal is a suggestion filed as a GitHub issue, identified by having the Proposal label.
  • A design doc is the expanded form of a proposal, written when the proposal needs more careful explanation and consideration.

Scope

The proposal process should be used for any notable change or addition to Pilosa or official tooling. Since proposals begin with the filing of an issue, even small changes can go through the process if appropriate. Deciding what is appropriate is a matter of judgement we will refine through experience. If in doubt, file a proposal.

Compatibility

Consider what effect this change will have on existing users - what can be done to mitigate impact? By the time Pilosa hits 1.0, we'll have to decide what sort of backwards compatibility promises we want to make with our APIs.

Process

  1. Create an issue (in the appropriate repository of the pilosa organization) describing the proposal.
  2. Have an initial discussion:
    • The goal is to (1) accept, (2) decline, or (3) ask for a design doc.
    • The discussion should be resolved in a timely manner.
    • If the author wants to write a design doc, then they can write one.
    • A lack of agreement means the author should write a design doc.
    • If there is disagreement about whether there is agreement, @travis is the arbiter.
  3. It's always fine to label a suggestion issue with the Proposal to opt in to this process.
  4. It's always fine not to label an issue. (it can be added later if necessary)
  5. If a proposal leads to a design doc:
    • The design doc should be checked in to the general repository as design/NNNN-shortname.md, where NNNN is the GitHub issue number and shortname is a short name (a few dash-separated words at most).
    • The design doc should follow the template.
    • It is expected that the design doc may go through multiple checked-in revisions.
    • New design doc authors may be paired with a design doc "shepherd" to help work on the doc.
    • For design documents should be wrapped around the 80 column mark. Each sentence should start on a new line so that comments can be made accurately and the diff kept shorter. Review comments should be restricted to grammar, spelling, or procedural errors related to the preparation of the proposal itself. All other comments should be addressed to the related GitHub issue.
  6. Once comments and revisions on the design doc wind down, there is a final discussion about the proposal.
    • The goal of the discussion is to reach agreement on (1) accept or (2) decline.
    • The discussion should be resolved in a timely manner.
    • If clear agreement cannot be reached, the arbiter reviews the discussion and makes a decision.
  7. The author (and/or other contributors) do the work.
Raw
pull-request-template.md

Status

👍READY/🚧IN DEVELOPMENT/⛔HOLD

Migrations

🟥YES | 🔵NO

Description

Related PRs

branch PR
other_pr_production link
other_pr_master link

Todos

  • 🔍Tests
  • 📝Documentation
  • 🆕Changelog

Deploy Notes

Steps to Test or Reproduce

Impacted Areas in Application

Raw
PULL_REQUEST_TEMPLATE.md

Overview

[Describe what this pull request addresses.]

Fixes #

Pull request checklist

  • I have read the contributing guide.
  • I have agreed to the Contributor License Agreement.
  • I have updated the documentation.
  • I have resolved any merge conflicts.
  • I have included tests that cover my changes.
  • All new and existing tests pass.
  • Make sure PR title conforms to convention in CHANGELOG.md.
  • Add appropriate changelog label to PR (if applicable).

Code review checklist

This is the checklist that the reviewer will follow while reviewing your pull request. You do not need to do anything with this checklist, but be aware of what the reviewer will be looking for.

  • Ensure that any changes to external docs have been included in this pull request.
  • If the changes require that minor/major versions need to be updated, tag the PR appropriately.
  • Ensure the new code is properly commented and follows Idiomatic Go.
  • Check that tests have been written and that they cover the new functionality.
  • Run tests and ensure they pass.
  • Build and run the code, performing any applicable integration testing.
  • Make sure PR title conforms to convention in CHANGELOG.md.
  • Make sure PR is tagged with appropriate changelog label.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment