Problem/Motivation

Document decisions made about TUF in core issues

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork governance-3474816

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

  • tuf Comparechanges, plain diff MR !26
About issue forks

Comments

quietone created an issue. See original summary.

quietone opened merge request !26

quietone’s picture

quietone commented
Issue summary: View changes
Related issues: +#3370269: [policy] Add php-tuf/php-tuf to core governance — for experimental Automatic Updates & Project Browser modules, +#3370270: [PP-1] Add php-tuf/composer-integration to core dependencies, +#3331078: Add php-tuf/composer-stager to core dependencies — for experimental Automatic Updates & Project Browser modules

This should also include #3331078: Add php-tuf/composer-stager to core dependencies — for experimental Automatic Updates & Project Browser modules

cmlara’s picture

cmlara
he/him
commented

My understanding is the D.O. Ecosystem wants PHP-TUF to be adopted by other providers correct? Sites like packagist.org and really every composer repository out there?

If that is a fair statement I would suggest a radially different policy compared to what is currently proposed:

Separate the TUF projects from Drupal core.

Do not allow core maintainer status to play any role in the TUF project management, give the project an initial developer team and let them choose how the project is run, who is a maintainer, and have sole authority independent of the desires of the Drupal Core project or the Drupal.org infrastructure team.

Give the TUF project the freedom to make decisions that Drupal would disagree with in order to promote the protocols growth. Allow it to become its own ecosystem, do not try and force control over it from one single project that represents a fraction of the global Composer usage.

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
commented
Status: Active » Reviewed & tested by the community

The language provides space for governance adjustments if projects like PHP-TUF *do* get that wider adoption, so I personally feel this first iteration is ready to go.

poker10 made their first commit to this issue’s fork.

poker10’s picture

poker10 commented

The main heading is "Governance of php-tuf/composer-integration and php-tuf/php-tuf", but the text later mentions "all three" and "php-tuf/php-tuf, php-tuf/composer-stager, and `composer-integration'". Do we need to update the main title to include all three projects?

Also added some minor style fix to the MR.

quietone’s picture

quietone commented

This has been an item in the package manager meeting on Slack in October and December and now, in January. I think there have been ample opportunity for everyone to respond. So, lets commit this so we can use it in further discussions.

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
commented

If no further comment, let's commit 1 week from today.

  • hestenet committed 46323941 on main authored by quietone 
    feat: #3474816 Governance for projects on Github

By: quietone
By:...
hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
commented
Status: Reviewed & tested by the community » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.