{"id":25000625,"url":"https://github.com/gluster/glusterfs-specs","last_synced_at":"2026-01-07T22:44:08.596Z","repository":{"id":35240568,"uuid":"39500068","full_name":"gluster/glusterfs-specs","owner":"gluster","description":"Mirror of the specifications and design documents for components and features in Gluster. Patches need to be sent through Gerrit.","archived":false,"fork":false,"pushed_at":"2019-01-10T06:57:27.000Z","size":3135,"stargazers_count":45,"open_issues_count":1,"forks_count":42,"subscribers_count":27,"default_branch":"master","last_synced_at":"2025-02-04T19:42:21.071Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"http://review.gluster.org/#/q/project:glusterfs-specs","language":null,"has_issues":false,"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/gluster.png","metadata":{"files":{"readme":"README.md","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}},"created_at":"2015-07-22T10:26:45.000Z","updated_at":"2022-04-05T07:42:51.000Z","dependencies_parsed_at":"2022-09-16T20:00:32.973Z","dependency_job_id":null,"html_url":"https://github.com/gluster/glusterfs-specs","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gluster%2Fglusterfs-specs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gluster%2Fglusterfs-specs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gluster%2Fglusterfs-specs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gluster%2Fglusterfs-specs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/gluster","download_url":"https://codeload.github.com/gluster/glusterfs-specs/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246230501,"owners_count":20744346,"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":"2025-02-04T19:36:20.486Z","updated_at":"2026-01-07T22:44:08.568Z","avatar_url":"https://github.com/gluster.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"Gluster Specs Repository\n------------------------\n\nThis is a git repository for release planning and design review of enhancements\nto Gluster.  This provides an ability to ensure that everyone has signed off on\nthe approach to solving a problem early on.  There are two general kinds of\ndocuments here.\n\n * Feature pages, covering anything that the user or administrator will see\n   plus planning information (e.g. security or resource impacts).  These follow\n   a fairly rigid template to ensure that all necessary topics are addressed.\n\n * Design specs, which provide **developer specific** information about the\n   (actual or proposed) implementation of a feature.  These are more free form,\n   because every feature/project breaks down into different pieces requiring\n   different emphasis.  Because each design is likely to be represented by\n   multiple documents, either in different formats or to address different\n   sub-components, design specs should be placed in subdirectories rather than\n   directly in the ``design`` directory (even if at first there's only one\n   design document).\n\nThe idea here is that anyone in the community can evaluate, comment on, and\npotentially vote on feature pages.  Once a feature has been accepted as part of\na release, its feature page is moved into one of the ``accepted`` subdirectories\nand its ``design`` subdirectory is created.\n\nRepository Structure\n--------------------\n\nThe structure of the repository is as follows::  \n```\n+-- under_review/  \n|\n+-- accepted/\n|   +-- release-3.6/  \n|   +-- release-3.7/  \n|\n+-- done/  \n|   +-- release-3.6/  \n|   +-- release-3.7/  \n|\n+-- design/\n|   +-- feature_1/\n|   +-- feature_2/\n```\n\nImplemented specs will be moved to ``done`` once the associated code has\nlanded.\n\nThe Flow of an Idea from your Head to Implementation\n----------------------------------------------------\nFirst propose a feature by adding a page to the ``under_review`` directory so\nthat it can be reviewed. Reviewers adding a positive +1/+2 review in gerrit are\npromising that they will review the code when it is proposed. Feature pages\nshould be approved and merged as soon as possible, and feature pages in the\n``under_review`` directory can be updated as often as needed. Iterate on it.\n\n1. Have an idea.\n2. Propose a feature.\n3. Reviewers review the feature page. As soon as 2 core reviewers like\n   something, merge it. Iterate on the feature page as often as needed, and\n   keep it updated.\n4. Once a feature has been accepted as part of a release - meaning that\n   resources are available to work on it - move its page to the appropriate\n   ``accepted`` subdirectory and create a ``design`` subdirectory for it.  We\n   follow an agile(ish) development process, but that's no excuse for failing\n   to consult others and to do that you need to write something down.\n5. Once the design is at least somewhat settled, write code.\n6. As issues surface in both the design and the code, update both the feature\n   page and the design spec(s) as appropriate.\n7. Once the code lands (with all necessary tests and docs), the feature page\n   can be moved to the ``done`` directory. If a feature needs a spec, it needs\n   docs, and the docs must land before or with the feature (not after).\n\nSpec Lifecycle Rules\n--------------------\n1. Land quickly. Both feature pages and design specs are living documents, and\n   should live live in the repository - not in gerrit.\n2. A feature page is supposed to **facilitate** creation of a detailed\n   description, not to be one already when it's first proposed. That way the\n   merits of the idea can be discussed and landed and not stuck in gerrit limbo\n   land.\n3. Design specs are not goals in themselves but tools to facilitate technical\n   discussions within the developer community.\n\nHow to submit a new feature for review\n--------------------------------------\n1. Clone this repo\n2. Copy the ``template.md`` file in ``under_review`` directory to\n   ``your_feature.md`` \n3. Make changes to ``your_feature.md``\n4. Submit changes using ``git-review`` tool.\n\nHow to ask questions and get clarifications about a spec\n--------------------------------------------------------\nTo make a comment, suggestion or to ask a question use the gerrit interface\nlike you do for code patches on glusterfs project.\n\nLearn As We Go\n--------------\nThis version of README is largely inspired from openstack-swift project. We can\nchange the process and update this README as we learn and adapt.\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgluster%2Fglusterfs-specs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgluster%2Fglusterfs-specs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgluster%2Fglusterfs-specs/lists"}