{"id":19054918,"url":"https://github.com/solus-project/tooling-central","last_synced_at":"2025-07-14T08:13:54.617Z","repository":{"id":145851702,"uuid":"89151782","full_name":"solus-project/tooling-central","owner":"solus-project","description":"Centralised repository for tooling discussions and TDD docs","archived":false,"fork":false,"pushed_at":"2017-05-11T07:06:50.000Z","size":32,"stargazers_count":6,"open_issues_count":0,"forks_count":2,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-02-22T01:20:58.237Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Makefile","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/solus-project.png","metadata":{"files":{"readme":"README.rst","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-04-23T15:25:05.000Z","updated_at":"2025-02-03T02:59:33.000Z","dependencies_parsed_at":null,"dependency_job_id":"24e12f27-488a-481b-8e32-49809c48943b","html_url":"https://github.com/solus-project/tooling-central","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/solus-project/tooling-central","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solus-project%2Ftooling-central","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solus-project%2Ftooling-central/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solus-project%2Ftooling-central/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solus-project%2Ftooling-central/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/solus-project","download_url":"https://codeload.github.com/solus-project/tooling-central/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/solus-project%2Ftooling-central/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":261624959,"owners_count":23186118,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-08T23:40:28.435Z","updated_at":"2025-06-24T07:08:47.978Z","avatar_url":"https://github.com/solus-project.png","language":"Makefile","funding_links":[],"categories":[],"sub_categories":[],"readme":"tooling-central\n===============\n\nThis repository will be used to mandate core requirements for all new Solus\ntooling projects, and aspects that existing tools should then adapt to in due\ncourse.\n\n\nTest Driven Development\n^^^^^^^^^^^^^^^^^^^^^^^\n\nAll new tools should ideally follow a Test Driven Development (TDD) approach, to\nensure that at every stage of the project each new function and behaviour is acting as\none would expect. This mightn't always be possible or suitable, however it should\nbe considered when starting a new project. If there are elements to your project\nthat **can** be tested, then **test them**.\n\nIdeally you should strive for a **high code coverage rate** (75%+). Additionally, the\nGitHub project should be integrated with a Continuous Integration service if it\nprovides a test suite, i.e. Travis + Coveralls.io. Understandably high coverage\nisn't always possible, but it should be a goal for testable components.\n\nStandards\n^^^^^^^^^\n\nCode hygiene is very important! Make sure you pick and stick to a coding style.\nResources are available in this repository to help you add testing to your\nprojects, notably ``Makefile.gobuild``\n\nMany of the integration steps make use of `misspell \u003chttps://github.com/client9/misspell\u003e`_ to ensure there are no\ntypos in the codebase.\n\nC\n-\n\nFor C projects, ensure you make use of a `.clang-format` file and enforce a\nfixed style on the codebase. Many Solus projects have example files that you\ncan use, and an example is included in this repository.\n\nGo\n--\n\nWhile not mandatory, it is recommended to use or base your build around the\nprovided ``Makefile.gobuild``. This will add some default targets, such as::\n\n    make check\n    make compliant\n\nAt minimum, you should look to replicate the basic functions of the ``make compliant``\ntarget::\n\n    cd somepkg\n    go fmt\n    golint\n    go vet\n\nAdd integration to your ``README`` with the Go Report Card and ensure you're\nattaining an A+ rating.\n\nPython\n------\n\nPythonic projects should use ``pep8`` and ``flake8`` to ensure the code is\nconformant with specifications and free of obvious errors. Add test suites\nif possible to confirm.\n\nDocumentation\n^^^^^^^^^^^^^\n\nAll binary tools shall provide at minimum:\n\n * A manual page for the main binary (``man(1)``)\n * A manual page for any configuration formats (``man(5)``)\n\nAny projects providing a public API/ABI should be fully documented internally.\nFor Golang this should be in the godoc format, and for C projects this should\neither be gtk-doc or doxygen.\n\nLicensing\n^^^^^^^^^\n\nThe preferred license depends on the language in use and other factors, such\nas snippets/libraries/linking involved.\n\nTypically, C libraries will be LGPL-2.1, potentially with a Linking Exception\nfor OpenSSL. C binaries will usually be GPL-2.0 (not GPL-3.0), as can be seen\nwith the Budgie Desktop.\n\nWhere other code is used, or there is little concern for project mixing, it\nmay be appropriate to use GPL-3.0, such as seen with ypkg, an entirely self\ncontained Python tool, which is mixed with GPL-3.0 snippet imports.\n\nFor Go projects, unless unavoidable, it is preferable for the project to\nuse the Apache-2.0 license. Consult any library licenses that may inadvertently\nrelicense the resulting binary when using cgo, i.e. linking to the GPL-3.0\nreadline.\n\nPlease ensure your repository includes a ``LICENSE`` file, and that all source\nfiles clearly indicate both copyright and license choice. Please use **short form**\nstandard license headers. It is not necessary to include the full terms in a header.\n\nFor sample files, tutorials, demos, etc, it is advisable to place them under the\nMIT license, to remove constraints from developers who may be reusing your code\nin their work.\n\n**DISCLAIMER**: I Am Not A Lawyer, And Likely Neither Are You. Always ensure\nyou are license compliant when linking or importing!\n\nLanguages\n^^^^^^^^^\n\nThe preferred tooling language for Solus is Go. However for those providing\na public API/ABI, it may be deemed suitable to use C. Likewise, some legacy\nprojects continue to use Python due to some artificial constraint, such as\nthe package manager still being Python.\n\nUsing Git\n^^^^^^^^^\n\nAlways try to remember that your git commits may serve as documentation to\nothers, and indeed, even yourself, later down the road. Two years later you\nmay find yourself bisecting a change and having not a clue why you made that\nchange, or what regressions it may cause by altering it.\n\nGive a very brief summary in the first line of your commit message, as a very\nvery high level overview of what this change is achieving. Then write another\nparagraph (doesn't need to be a story) describing the rationale and results\nof the change itself.\n\nAlso remember that the vast majority of git users will be viewing your changes\non the terminal, so please respect the 80x24 rules! Try not to wrap your lines,\nrather, manually line break them. Your first line should ideally be no longer\nthan 60 characters, and each line in the next paragraph shouldn't exceed 70.\nThis will ensure the message is readable on all terminals, without enforced\nline wrapping.\n\n\nHere is an example of a good commit message::\n\n    postinstall: Remove all GRUB_BACKGROUND handling\n    \n    We now no longer utilise a default background for GRUB in Solus, purely\n    because its very tacky and hard to get the image placement correct on a\n    multitude of resolutions. Thus we simplify the GRUB code and let CBM\n    handle all the heavy lifting.\n    \n    Signed-off-by: Ikey Doherty \u003cikey@solus-project.com\u003e\n\n\nAn atrocious commit message::\n\n    Another quick fix..\n    \n    Signed-off-by: Ikey Doherty \u003cikey@solus-project.com\u003e\n\nIt is terrible because it hasn't explained anything that has changed, nor the\nrationale.\n\nA badly formatted message::\n\n    This change should fix the styling on the GtkBox that was present in Gtk 3.12 but was later removed due to CSS class changes upstream as of the last sync.\n\nTry to get out of the habit of using ``git commit -m 'My changes'``, instead make\nuse of an interactive editor. If you're not comfortable with the default editor,\nthen switch it to one that is simpler, such as nano (like I do)::\n\n    git config --global core.editor nano\n\nIt is advisable to use your public GPG key to sign all commits and tags::\n\n    git config --global commit.gpgsign true\n    git config --global user.signingkey YOURKEYID\n\nSigning your changes (signing off and GPG signing) is highly recommended, as it\nindeed proves the change was really by you, and not anybody else. It allows you\nto own your changes completely, and is a good practice to get into.\n\nReleasing Projects\n^^^^^^^^^^^^^^^^^^\n\nRelying on automatically generated tarballs is no longer sufficient. Using autotools,\nyou should be using ``make distcheck`` to create a proper tarball for your tagged\nrelease, including all required assets/sources. For the Go projects you can use\nthe provided Makefile, or create your own script to generate tarballs using the\nfollowing::\n\n    git submodule init\n    git submodule update\n    git-archive-all.sh --format tar.gz --prefix ${PROJECT_NAME}-${VERSION}/ --verbose -t HEAD ${PROJECT_NAME)-${VERSION}.tar.gz\n\nYou can find ``git-archive-all.sh`` `here \u003chttps://github.com/meitar/git-archive-all.sh/blob/master/git-archive-all.sh\u003e`_.\n\nOnce your tarball is created, upload it to your GitHub releases page (on the relevant\ntag). Now ensure you sign your tarball and upload the accompanying ``.asc`` file to\nverify that this tarball is indeed the one that you created::\n\n    gpg --armor --detach-sign solbuild-1.3.1.tar.gz\n\nPlease note that when using ``autotools`` or ``meson``, you must bump your version\nnumber PRIOR to tagging, in ``configure.ac`` or ``meson.build`` respectively.\nWhen tagging, ensure to GPG sign it::\n\n    git tag -s v1.3.1\n    git push --tags\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsolus-project%2Ftooling-central","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsolus-project%2Ftooling-central","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsolus-project%2Ftooling-central/lists"}