summaryrefslogtreecommitdiff
path: root/CONTRIBUTING.rst
Commit message (Collapse)AuthorAgeFilesLines
* CONTRIBUTING.rst: Adding instructions to run the linter separatelytristan/toxic-lintingTristan Van Berkom2019-01-031-9/+12
|
* CONTRIBUTING.rst: Add instructions to recreate tox environmentchandan/toxifyChandan Singh2019-01-031-0/+6
| | | | | | | When we update our dependencies, developers will eventually need to recreate their `tox` environments to get correct results. This happens because `tox` isn't particularly good at recognizing changes in the requirements files.
* Move sphinx build functionality to toxChandan Singh2019-01-031-20/+9
| | | | | | | | | Currently the CI and the docs both have to duplicate the same inforation about how to gather dependencies etc, and have to use hacky ways to run them. Add a new `docs` environment to our tox setup so that building docs is as simple as running `tox -e docs`.
* CONTRIBUTING.rst: Add steps for installing non-python build dependenciesChandan Singh2019-01-031-5/+32
| | | | | | | | | | | Since we don't allow use of site packages by default in our `tox` configuration, people will need to install non-python build dependencies of some of our dependencies that do not provide pre-built wheels. We have two such packages at the moment: * psuitl: requires python C headers, compiler * pygobject: requires python C headers, pkg-config, compiler, cairo headers, and gobject libraries
* CONTRIBUTING.rst: Updated to reflect running tests using tox.Tristan Van Berkom2019-01-031-12/+40
|
* contributing: mandate end-to-end tests, allow othersAngelos Evripiotis2018-12-131-17/+44
| | | | | | | | | | | | | | | Update the section on adding tests, to fulfill these broad points: - Mandate end-to-end testing, with rationale. - Mention internal APIs as endpoints for testing. - Warn against pitfalls of unit-testing. It's more text than I would have liked, perhaps in later work we'll be able to say it with less. This change integrates feedback from the mailing list 'Guidance on Unit Tests' thread: https://mail.gnome.org/archives/buildstream-list/2018-November/msg00045.html
* contributing: add guidance on unit testsAngelos Evripiotis2018-11-151-0/+18
| | | | | Decrease uncertainty around whether unit tests are welcome in the project or not.
* contributing: emphasise the 'why' in commitsAngelos Evripiotis2018-11-081-0/+10
| | | | | | | | | | | Explain why it's useful to mention the decisions made for a change and provide links for background, e.g. issue numbers. My general experience of git histories is that folks don't do enough explaining, so it's great we have a contributing section for it. I've found it's easier for folks to stick to rules when they know the practical reasons for them, so provide some.
* contributing: non-WIP should always be landableAngelos Evripiotis2018-11-081-0/+6
| | | | | | | | | | | | | | I was recently surprised that we don't prefer addressing review comments in 'fixup!' commits. Coming from GitHub, I've found that fixup commits make it easier for reviewers to see what has changed since their last review. The idea is to use '--autosquash' before landing to clean up the history again. It's a pleasant surprise that it's easy to keep track of what changed in merge-requests between pushes, so we can always keep the history clean. Document this, so folks like me can see the light sooner.
* contributing: WIP again to be kind to reviewersAngelos Evripiotis2018-11-081-1/+7
| | | | | | | | As someone coming from GitHub to GitLab, I was pleasantly surprised by the 'filter by WIP status' option. To make sure we get the most out of it, add a guideline to keep the filter clean, to reduce reviewer burden.
* Fix spelling of it's and itsRichard Dale2018-10-161-4/+4
|
* CONTRIBUTING.rst: Added more guidelines about documenting the user guideTristan Van Berkom2018-10-141-10/+105
|
* CONTRIBUTING.rst: Fix typos in previous commit.Tristan Van Berkom2018-10-091-2/+2
| | | | Ooops, that was done far too quickly.
* CONTRIBUTING.rst: Added note about sphinx supporting docstrings on instance ↵Tristan Van Berkom2018-10-091-0/+5
| | | | | | | variables Python does not natively support this, but sphinx does parse them and includes these in the generated documentation.
* contributing.rst: no spaces before '?'Angelos Evripiotis2018-10-091-2/+2
|
* contributing.rst: de-paren subclass exampleAngelos Evripiotis2018-10-091-3/+3
| | | | It seems easier to read when separated into two sentences.
* contributing.rst: fix typo of 'get_count'Angelos Evripiotis2018-10-091-1/+1
|
* contributing.rst: fix whitespaceAngelos Evripiotis2018-10-091-3/+3
| | | | No tabs, no lines of only horizontal whitespace.
* contributing.rst: end lines with punctuationAngelos Evripiotis2018-10-091-23/+23
|
* CONTRIBUTING.rst: Added section in PEP-8 coding style about line lengths.Tristan Van Berkom2018-10-081-0/+15
| | | | | | We have a long line limit in order to handle the exceptions without making code unreadable as a result, this long line length limit is not an invitation to fill up the limit as much as possible.
* CONTRIBUTING.rst: Added a note that public API objects should be exposed ↵Tristan Van Berkom2018-10-081-0/+3
| | | | from __init__.py
* CONTRIBUTING.rst: Correcting `Context` example in the "imports" sectionTristan Van Berkom2018-10-081-2/+2
| | | | | | This example is very outdated and comes from pre 1.0 when the Context object was going to be public API. Just corrected the example made about imports to import the `Context` object from `._context` instead of `.context`.
* CONTRIBUTING.rst: Added section on file naming conventionTristan Van Berkom2018-10-081-0/+19
|
* CONTRIBUTING.rst: Added section about minimizing API surfacesTristan Van Berkom2018-10-081-8/+52
| | | | | And modified some titles so that the titles in CONTRIBUTING.rst actually follow the documentation guidelines for naming of section titles.
* contributing.rst: fix typoAngelos Evripiotis2018-10-071-1/+1
|
* CONTRIBUTING.rst: Some fixes in grammer and minor correctionsTristan Van Berkom2018-10-071-75/+73
|
* CONTRIBUTING.rst: Updating CONTRIBUTING guidelinesTristan Van Berkom2018-10-061-168/+994
| | | | | | | | | | | | | | | | | | | | This is almost a complete rewrite of the CONTRIBUTING guide. * The patch submission guidelines have become less ambiguous and more strict * Some general restructuring and reordering of the file took place * The codeing guidelines have changed completely. o There is much less room for ambiguity here now o More emphasis on consistency in the codebase o Added some more abstract points which should be considered when writing and reviewing patches * The policy on public/private symbols has been greatly clarified * Added new section about adding new core plugins and what needs to be done as a consequence of that
* Fix rst links for guideline linksAdam Jones2018-09-191-3/+2
|
* Rename HACKING.rst to CONTRIBUTING.rstAdam Jones2018-09-171-0/+627