git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: The Sharp Ninja <ninja@thesharp.ninja>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Feature suggestion: Features Sets and Feature Dependencies Sets
Date: Wed, 23 Sep 2020 12:34:24 +0000	[thread overview]
Message-ID: <DM6PR12MB32446D3BE708BF5158CA0444D5380@DM6PR12MB3244.namprd12.prod.outlook.com> (raw)

# Proposal for Feature Sets and Feature Dependency Sets

I believe a very useful feature for Git would be the addition of Feature Sets and Feature Dependency Sets.  

## Feature and Feature Set

A Feature is a defined domain of functionality, such as a specific service of an API.  Features can be managed as a subset of the repository, allowing for segmenting a repository into working groups that have their own set of permissions for the pool of users with access to the repository.  As an example, User A may not have permissions to merge within the repository, but within Feature A he is allowed to do so.  This would streamline integrating new users into large repositories and teams.

A collection of related artifacts that together form the basis of a Feature is a Feature Set.  All artifacts within the feature set are managed equally by a merging of permissions for the Feature and the Repository with most permissive permission being chosen.  

## Changes to Workflow

Once a user has cloned a repository, he may chose to scope his work to the Feature Set.  All Fetch/Pull/Push operations are limited to the Feature Set.

Checking out a Feature Set automatically creates a new branch for tracking the changes by the user.

## Feature Dependency Sets

Artifacts that are not part of a Feature, but directly affect the Feature can be added to a Feature Dependencies Set.  When scoping actions to the Feature, artifacts related to the Feature by way of inclusion in a Feature Dependency Set are also included in the activities.  If a commit includes changes to items in the Feature Dependency Set then creating a pull request will generate two PRs, the first a normal PR with normal permissions that includes only the changes in the Features Dependency Set, to be adjudicated via the normal workflow, and the second PR scoped to both the changes in the Feature Set and Feature Dependency Set in the Feature's user-level branch.

## Finalizing a Feature Set 

Ultimately the Feature Set work will become a PR to master/main and be adjudicated via the normal workflow.


             reply	other threads:[~2020-09-23 12:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 12:34 The Sharp Ninja [this message]
2020-09-25  1:58 ` Feature suggestion: Features Sets and Feature Dependencies Sets brian m. carlson
2020-09-28  9:45   ` The Sharp Ninja

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM6PR12MB32446D3BE708BF5158CA0444D5380@DM6PR12MB3244.namprd12.prod.outlook.com \
    --to=ninja@thesharp.ninja \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).