๐Ÿ‡บ๐Ÿ‡ธUnited States @drumm

NY, US
Account created on 17 July 2003, over 20 years ago
#

Merge Requests

More

Recent comments

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Images on organization pages are not really something we planned for. If we want them, we could add an image upload field or use CKEditor Media on D10

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Just tested it with git push origin :0.1.2 and broke my complete git access. No git push or git clone to any repo was possible anymore. Logging in and accepting the ToS fixed the broken git access. The error message could have been a bit more elaborative.

This one-time ToS agreement is not related to pushing the tag, it was required of everyone: https://www.drupal.org/drupalorg/blog/updating-how-contributors-accept-t... โ†’

The error message is not something that we can configure in GitLab.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

The project name, โ€œStatisticsโ€ also needs to be unique for autocomplete fields, like the Project field in the issue update form on this page. You could call it something like โ€œStatistics from core.โ€ I did go ahead and delete the conflicting project, since it was a sandbox with no code, that was a bit spammy. So the โ€œStatisticsโ€ name is also free now.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US
๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Both categories and ecosystem are updated by the downstream modules by editing their project page. The only difference is ecosystem is an autocomplete for the project, like rules, vs selecting a category from a list.

Before re-arranging categories, the former rules category did have 426 modules, many not related to or integrating with Rules module. The ecosystem selection has the potential to be more accurate, since maintainers arenโ€™t looking at a list of categories, often not knowing what โ€œrulesโ€ might mean as a category.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

A big difference from GitHub & Packagist.org is that Drupal.org releases are permanent. Unlike the other services, we do not allow deleting or replacing releases, so you know you will be able to deploy the same code indefinitely.

We do get occasional support requests for deleting accidental releases, which we do not allow. If everything were more automated, I expect there would be more accidental releases.

That said, we certainly should make some things nicer. For example, if you push a tag which could be a release, we could have links to directly create that release, rather than relying on maintainers to find the place to add a release.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

If https://www.drupal.org/project/statistics โ†’ is not set up in the next day or two, I should re-reserve it, so it isn't taken by another project.

If a different name could be used, then ๐Ÿ“Œ Ensure that Statistics does not get special core treatment Active would not be needed and we avoid any unexpected Composer behavior.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Adding deployment notes

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This is all done in drupalorg code, adding another check in TugboatPreview::fromGitLabPayload()

We could have it react to Drupal.org issue tag, or GitLab merge request label. I think we should use a MR label. When issues are on GitLab, the MR/issue relation is a bit looser, a MR could be associated with multiple issues, we don't want to think about figuring out that logic. Checking an MR label will be more straightforward. And it would be good to start getting some use of MR labels.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

For command-line access, people will see:

$ git ls-remote git@gitlabstg1-aws.drupalsystems.org:project/drupalorg.git
remote:
remote: ========================================================================
remote:
remote: You (@drumm) must accept the Terms of Service in order to perform this action. To accept these terms, please access GitLab from a web browser at https://git.code-staging.devdrupal.org.
remote:
remote: ========================================================================
remote:
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

So we will want to do a decent amount of communication about this upcoming change since it will be a little disruptive.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Updating TODOs about how GitLab accounts behave

Looks like for everyone else, a ToS non-agreed account is a regular GitLab user account, they can be made maintainers, etc

For new users, command line Git access is irrelevant, they won't be able to add an SSH key or set up access tokens until they have agreed. Need to see how it does for existing accounts when ToS is enforced.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This will need a merge request instead of patch now.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This is now running.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Modules with 7 or more categories have been reset to have no categories.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This is now deployed

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This is now deployed. The only remaining task is to clear categories from modules which selected too many.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

The page is now at https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... โ†’

I shortened the header text since ๐Ÿ“Œ Create guidelines for adding new categories Needs review should cover everything about maintaining categories once done.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Was where this page should land discussed? I think under https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... โ†’ may be the best place.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I think the guidelines could use an introduction paragraph before getting into the workflow/policy. What are these categories? How are they used? Why are they important?

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

apaderno noted on ๐Ÿ“Œ Create a "Categories" Help page on Drupal.org Active , the Drupal.org content issue queue has a Module categories component: https://www.drupal.org/project/issues/content?text=&status=All&prioritie... โ†’

That would be fine to use. The category updates usually donโ€™t land as code changes, so they donโ€™t need to be in the Drupal.org customizations project. If there is a migration or UI change, that does need to be in the Drupal.org customizations project.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

While we are on Drupal 7, we should keep changes minimal. Setting the fieldโ€™s cardinality to 3 works well.

When weโ€™ve upgraded, we can look at other field widgets. Maybe as simple as using the checkboxes widget, altering in the category descriptions, and putting it in a scrollable container.

I canโ€™t think of how a primary category would practically show up in search indexing. We could have a boost for a primary category matching the category search filter; but I think the project usage, full text search matches, and other project quality boosts would be larger, making a primary category match less likely to change result ordering. And this keeps the widget, and explanation for the module maintainer, more straightforward.

Since this is a field configuration update, we should set the description at the same time, linking to the page being created at ๐Ÿ“Œ Create a "Categories" Help page on Drupal.org Active . Something like:

Review category descriptions โ†’ , select up to 3.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Sorry for the oversight, the post has been updated.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Since weโ€™re already communicating with project maintainers a lot with separate issues for their description, logo, and potentially categories now, Iโ€™m hesitant to make more work for project maintainers.

Like we did for the category migrations, the revisions of the project page will have the URL to this issue for an explanation.

Since its always good to have specifics, here are the module with 7 or more categories:

7 Open Y Google Translate โ†’
7 DXPR Builder | Drupal Page Builder | Bootstrap Layout Builder โ†’
7 Watchdog Event Extras โ†’
7 Query-Based Views (Q-Views) โ†’
7 Entity Schedule Sync โ†’
7 Facebook-style Links โ†’
7 Service links โ†’
7 org โ†’
7 mailflatrate for drupal 8 โ†’
7 Dsi center โ†’
7 File uploader by Uppy โ†’
7 Support Ukraine โ†’
7 Splitting.js โ†’
7 SMSC โ†’
7 Role Based Views Entity Reference โ†’
7 E-MAILiT Sharing Buttons โ†’
7 Web Service Client Manager โ†’
7 TotalFlow โ†’
7 Commerce clone product variation โ†’
7 JW Platform Media Source โ†’
7 CMP Sirdata โ†’
7 COOKiES Services โ†’
7 Contextual Administration โ†’
7 Website Toolbar โ†’
7 Convert URL Filter โ†’
7 Type User Nids โ†’
7 Featured Content โ†’
7 Communities โ†’
7 DubBot โ†’
7 Icomoon โ†’
7 Kill Adblock โ†’
7 COOKiES Media Entity Facebook โ†’
7 Update Me โ†’
7 Excluded โ†’
7 Encrypted Text โ†’
7 POWr Form Builder โ†’
7 Nodelocks โ†’
7 Super Nav โ†’
7 File uploader โ†’
7 Resize Text โ†’
7 Google Picker โ†’
7 Variants โ†’
8 Intelligent Content Tools โ†’
8 Marketing Automation โ†’
8 Hiberus tools โ†’
8 AddToAny Share Buttons โ†’
8 CiviCRM Entity โ†’
8 Ajax Table โ†’
8 shortlink โ†’
8 Import Export โ†’
8 Embed Import โ†’
9 Apture โ†’
10 Headup Complementary Content Widget โ†’
10 Persian Date for Drupal 8 โ†’
11 Social Sharing, Follow Bar & Share Buttons by GetSocial.io โ†’
11 OSF for Drupal โ†’
11 Wibiya โ†’
12 changedetection.io โ†’
13 Share Buttons, Related Posts, Content Analytics - Shareaholic โ†’
18 Drupal Extra โ†’
19 Test Drupal 2021 โ†’
19 Textimate โ†’

If any already have description update requests, Iโ€™d recommend adding recommended categories to that issue.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

With ๐ŸŒฑ Migrating "Categories" on Drupal.org Project pages Active done, the distribution is:

MariaDB [drupal]> SELECT s.c, count(1) FROM (SELECT count(fd_tv3.entity_id) c FROM node n INNER JOIN field_data_field_project_type fdf_pt ON fdf_pt.entity_id = n.nid AND fdf_pt.field_project_type_value = 'full' LEFT JOIN field_data_taxonomy_vocabulary_3 fd_tv3 ON fd_tv3.entity_id = n.nid WHERE n.status = 1 AND n.type = 'project_module' GROUP BY n.nid ORDER BY NULL) s GROUP BY s.c;
+----+----------+
| c  | count(1) |
+----+----------+
|  0 |     4977 |
|  1 |    14199 |
|  2 |     8442 |
|  3 |     4120 |
|  4 |     1552 |
|  5 |      465 |
|  6 |      160 |
|  7 |       42 |
|  8 |        9 |
|  9 |        1 |
| 10 |        2 |
| 11 |        3 |
| 12 |        1 |
| 13 |        1 |
| 18 |        1 |
| 19 |        2 |
+----+----------+

93% of modules, excluding sandboxes, have 3 or fewer categories.

I think we should have some allowance for projects with 4, maybe 5 or 6, categories to remain as-is. Once this issue is fixed, they will have to pare down their own categories when they next update their project. We wouldn't be able to make good bulk decisions to remove the extra categories. And I think the data loss from resetting them to having no categories would not be helpful overall.

The ones with 7 or 8 or more categories can be reset to none, since those are clearly outliers with less-meaningful selections.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

As noted when creating the release, releases are permanent. If 1.3.0-alpha2 were deleted, that would break deployments for anyone who has found it. Worse, if later some different code replaced 1.3.0-alpha2, that would defeat the purpose of releases.

I recommend noting what happened in the release notes and continuing on releasing 1.3.0-alpha3, 1.3.0-beta1, etc.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I think the header/footer text is done. Making sure the process is updated everywhere can happen with ๐Ÿ“Œ Create guidelines for adding new categories Needs review

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This is now all done. Search indexing is still catching up, I'll continue to monitor it and motivate it if needed tomorrow.

Thanks everyone!

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I didnโ€™t see a category with good data that might be a candidate for migrating to ecosystems. Like the Rules/Automation example, categories use is just not restricted enough to match up to a single module.

The merges are now running, log of a dry run is attached. Using code:

$terms_to_merge = [
  74 => 13434,
  76 => 13434,
  8818 => 53,
  68 => 58,
  63 => 57,
  13158 => 59,
  101 => 59,
  26738 => 59,
  75 => 59,
  55 => 104,
  196950 => 64,
  70 => 64,
  66 => 52,
  119 => 52,
  7266 => 69,
  61 => 20224,
  65 => 20224,
  124 => 20224,
  71 => 20224,
  122 => 60,
  62 => 67,
];
$terms = taxonomy_term_load_multiple(array_merge(array_keys($terms_to_merge), $terms_to_merge));
foreach ($terms_to_merge as $key => $value) {
  print $terms[$key]->name . ' โ†’ ' . $terms[$value]->name . PHP_EOL;
}
$tids_to_merge = array_keys($terms_to_merge);
$result = (new EntityFieldQuery())->entityCondition('entity_type',  'node')
->propertyCondition('type', 'project_module')
->fieldCondition('taxonomy_vocabulary_3', 'tid', $tids_to_merge)
->execute();
foreach (array_chunk(array_keys($result['node']), 50) as $nids) {
  foreach (node_load_multiple($nids) as $node) {
    print $node->nid . ' ' . $node->title . ': merging';
    $merged = [];
    $existing_terms = array_column($node->taxonomy_vocabulary_3[LANGUAGE_NONE], 'tid');
    foreach ($node->taxonomy_vocabulary_3[LANGUAGE_NONE] as $delta => $item) {
      if (in_array($item['tid'], $tids_to_merge)) {
        print ' ' . $item['tid'] . ':' . $terms[$item['tid']]->name . 'โ†’' . $terms[$terms_to_merge[$item['tid']]]->name . '-';
        if (in_array($terms_to_merge[$item['tid']], $existing_terms)) {
          print 'exists';
          unset($node->taxonomy_vocabulary_3[LANGUAGE_NONE][$delta]);
        }
        else {
          print 'update';
          $node->taxonomy_vocabulary_3[LANGUAGE_NONE][$delta]['tid'] = $terms_to_merge[$item['tid']];
          $existing_terms = array_column($node->taxonomy_vocabulary_3[LANGUAGE_NONE], 'tid');
        }
        $merged[] = $terms[$item['tid']]->name . 'โ†’' . $terms[$terms_to_merge[$item['tid']]]->name;
      }
    }
    print PHP_EOL;
    $node->revision = TRUE;
    $node->log = t('Updating module categories, @merged, see https://www.drupal.org/project/drupalorg/issues/3383004', [
      '@merged' => implode(', ', $merged)
    ]);
    node_save($node);
  }
}
๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Hopefully there should be an existing block of styles to add white space between items, as we do in other sidebar lists like this, that can have another selector added.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Automation now has 426 (!!) modules. Most of which are not part of the Rules ecosystem.

To be clear, no merges have happened yet, so those 426 modules are the ones that were in the Rules category. We probably should not migrate them to the ecosystem field, since most of them are not related to Rules.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Added to Primary language & Other languages

The first Language field is for UI translation, when we enable more of that on Drupal.org. Currently, Yakut is not translated at https://localize.drupal.org/translate/drupal_core. The place to start organizing translators is https://www.drupal.org/project/issues/localizedrupalorg?text=&status=Ope... โ†’

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Thanks for reporting, fixed the typo

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

RTBC retesting on DrupalCI was expensive. If I recall correctly, 20% of all compute for DrupalCI at times, highly dependent on the RTBC queue.

If we were to rebase every MR on every commit, and run pipelines, that would be incredibly wasteful, expensive, and a lot of junk to read through in the MR activity.

If a MR can be automatically rebased without conflicts, it probably does not need a rebase. The pipelines already test the merged result with upstream commits at the time. Viewing the MR page will tell you if there are merge conflicts and a manual rebase is needed.

In my view, the missing piece is committers knowing that tests still pass as they merge.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

When using GitLabโ€™s merge UI, there is the capability for maintainers to โ€œmerge if pipelines passโ€ https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html

I believe the main drawbacks of GitLabโ€™s merge UI for core are:

  • Git commit authorship is set to the merge request author. There are a number of GitLab issues about this, starting from https://gitlab.com/gitlab-org/gitlab/-/issues/26902
  • GitLabโ€™s commit message templating wonโ€™t have an option for a list of usernames
๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This API is now allowed.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I tried out the subtree splitter a bit on staging with the diff from the MR. As far as I can tell, it works okay.

The subtree splitter is not a blocker.

I expect more of the parent plan needs to be done before proceeding, this seems like one of the final steps, so leaving this postponed.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Education is now being removed, the log is attached.

The "ecosystem" functionality is already on Drupal.org. On https://www.drupal.org/project/rules โ†’ , click "Projects that extend this" in the right sidebar. Each project can be updated to say it extends Rules. ("Ecosystem" is a bit of an abstract term, we should try to keep it out of UIs and elsewhere.)

We might want to pause and identify categories that should be migrated to ecosystems as well. We could update every project in the Automation, formerly Rules, category to say they extend rules.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

With ๐Ÿ“Œ Migrate drupal.org issues to gitlab issues Needs review upcoming, we won't be making too many changes to the existing issues on Drupal.org. Once issues are migrated, we can make sure everything uses a WYSIWYG editor and remove BUEditor's UI completely.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

The description for Education is missing

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Moving file management into merges, since there is already another media category.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Content - Rename to "Content Editor Tools"

But the description is

Content Editing Experience - Enhance the editorial interface and improve the processes and workflows around creating, editing or removing content.

Please update the issue summary to correct one of those

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Attached is a dry run of the removals, which will serve as a backup. Script used is:

$terms_to_remove = [
  56 => 'Community',
  88 => 'Content Construction Kit (CCK)',
  4654 => 'Drush',
  19440 => 'Examples',
  11478 => 'Features Package',
  7404 => 'Mobile',
  16190 => 'Novelty',
  90 => 'Organic Groups (OG)',
  51425 => 'Other',
  19984 => 'Project management',
  116 => 'RDF',
  73 => 'Theme Enhancements',
  89 => 'Views',
];
$tids_to_remove = array_keys($terms_to_remove);
$result = (new EntityFieldQuery())->entityCondition('entity_type',  'node')
->propertyCondition('type', 'project_module')
->fieldCondition('taxonomy_vocabulary_3', 'tid', $tids_to_remove)
->execute();
foreach (array_chunk(array_keys($result['node']), 50) as $nids) {
  foreach (node_load_multiple($nids) as $node) {
    print $node->nid . ' ' . $node->title . ': removing';
    $removed = [];
    foreach ($node->taxonomy_vocabulary_3[LANGUAGE_NONE] as $delta => $item) {
      if (in_array($item['tid'], $tids_to_remove)) {
        print ' ' . $item['tid'] . ':' . $terms_to_remove[$item['tid']];
        $removed[] = $terms_to_remove[$item['tid']];
        unset($node->taxonomy_vocabulary_3[LANGUAGE_NONE][$delta]);
      }
    }
    print PHP_EOL;
    $node->revision = TRUE;
    $node->log = t('Removing module categories, @removed, which are being discontinued, see https://www.drupal.org/project/drupalorg/issues/3383004', [
      '@removed' => implode(', ', $removed)
    ]);
    node_save($node);
  }
}
๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I've confirmed this passes in private testing.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

A blog post has a specific date

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This is deployed again. I reviewed all the examples from this issue, and everything looks good, as far as I can tell. The new way of getting advisories from composer names is much more straightforward and foolproof.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Since there is no code, this can be deleted. I am also setting up that list of project names to be reserved.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

No need for a feature flag, dispatcher is already not publicly accessible and wonโ€™t be again. In the unlikely event it does come back, we have the Git history.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I'd expect GitPod to ask for write access when you click the authorize link, where you are taking personal responsibility for GitPod's secret handling and use.

The documentation at https://www.gitpod.io/docs/configure/authentication/gitlab#connecting-yo... says the service account access should be

Check the scopes api and read_user

Which is what was granted when authorizing the application.

As far as I know, this was set up according to the GitPod documentation. There may have been a change in GitLab or GitPod since the documentation was written. I think this would be a question for GitPod support.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I can not think of a good reason to have a core-related placeholder project. Of course, there are zero specific examples in the issue summary, so that's speculation.

We need a list of placeholder projects to get started.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This is now scheduled for late April 2024 when we can drush vset pift_testing_enabled 0 and follow up with completely removing the unreachable code.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I spotted a much more reliable DB table to map Composer namespaces to Drupal.org projects. And I added the special case for Drupal Core. This still needs a bit more testing before putting it back into https://packages.drupal.org/8/packages.json, which I'll plan to do toward the start of my day sometime this week.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I expect most of these placeholder projects should be deleted. We have a way to reserve project names that does not require a placeholder project.

We would need a list of placeholder projects to get started. (No one with access to delete projects should delete them yet, let's get a list together first.)

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

We are not adding new features to issues on Drupal.org as ๐Ÿ“Œ Migrate drupal.org issues to gitlab issues Needs review is upcoming. Individual project maintainers can update their issue summary templates to ask for Slack links.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Yes, https://packages.drupal.org/8/security-advisories?โ€ฆ can not be TUF protected, since it is dynamic. The Composer plugin will either have to remove the fetch from there, falling back to the current behavior using each individual project's metadata; or make sure the security-advisories data is fetched safely and matches the individual project metadata.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This is now deployed. It was actually good that this was reserved, since moving components out of core without coordinating with packages.drupal.org updates is not fun. All core components without existing projects are now reserved in settings.php, https://bitbucket.org/drupalorg-infrastructure/drupal.org/src/9798fe7981...

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Thanks for the issue summary updates. I also added ๐Ÿ“Œ Replace โ€œView results on dispatcherโ€ link with deprecation message Fixed since those links now go nowhere.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Sorry for the delay here, I was on vacation.

Is the text of the comment, like the example posted on โœจ PostgreSQL driver doesn't support SSL option Needs work all good?

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

The proposed resolution is missing coordinating with the Drupal Association for packages.drupal.org adjustments, which needs to be done any time a module or theme moves into or out of core with the same name. Picking a different name for the contrib version would make this go a lot more smoothly for Composer.

If a new name can't be used, a new issue like #3308347: Ensure that ckeditor does not get special core treatment โ†’ needs to be created, and updated when the module is ready to be installed on its own. There are still risks, see ๐Ÿ› Incorrect version of CKEditor being parsed from info.yml files Active and its related issues.

Reserving the name via project_issue module wasn't intended, but I'm glad it was, since these steps were being skipped. I'll look at getting every other core component's name reserved.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I confirmed that cache clearing is working. There is also caching at the CDN for the project avatar. That should also be actively cleared on push as well. It takes a few seconds for the CDN cache to clear, so this likely was a race condition. We can look closer if it becomes a recurring problem.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Are all changes documented and ready here?

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Correct, it is good to get this out of the way in-place, so it is less complexity for the larger migration.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Sure, either policy works. We can get the packaging pipeline, including subtree splits, running on staging and try out this change, so we have less of a chance of debugging in production.

I posted to #3285191-18: [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health โ†’ a prominent place weโ€™ll need to update, https://www.drupal.org/download โ†’

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

3.x-dev is the https://www.drupal.org/project/prototype/releases/8.x-3.x-dev โ†’ release. Version numbers for Composer drop the 8.x- API compatibility prefix. That release is packaged from the 8.x-3.x branch. 15ebbd47787c19907649fa6c55497931411abfb5 is the most recent commit on that branch.

I recommend the maintainers merge 3.x into 8.x-3.x and delete the 3.x branch to avoid further confusion.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I believe tarball packaging depends on this https://git.drupalcode.org/project/drupalorg/-/blob/2647a1a82a012af30376...

And weโ€™d have to check if this is hard-coded anywhere in subtree splitting, https://bitbucket.org/drupalorg-infrastructure/subtree-splitter/src/master/

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

It looks like there was another problem when I smoke tested this after deployment.

I installed an old, unsupported version of Drupal with composer create-project drupal/recommended-project:^9 test-drupal

With api-url removed, now composer audit returns the advisory for https://www.drupal.org/sa-core-2024-001 โ†’ . It was missed after deployment yesterday.

https://packages.drupal.org/8/security-advisories?packages[]=drupal/core isn't returning the advisories it should.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I backed out the api-url from security-advisories again. So it only has metadata: true now.

Since composer require drupal/paragraphs-paragraphs_library installs drupal/paragraphs as a dependency, https://packages.drupal.org/8/security-advisories?packages[]=drupal/para... should be returning nothing. Composer audit will catch the advisory when drupal/paragraphs is checked.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Nothing prevents people from picking older versions when making new issues, like ๐Ÿ“Œ HTML characters are not displayed correctly in the entity autocomplete Active

move remaining non 11.x issues

Since I donโ€™t expect 7.x issues to be touched, I had been ignoring this and using the more-specific instructions.

->fieldCondition('field_issue_version', 'value', ['9.0.x-dev', '9.1.x-dev', '9.2.x-dev', '9.3.x-dev', '9.4.x-dev', '9.5.x-dev', '10.0.x-dev', '10.1.x-dev', '10.2.x-dev'])

Gets to 5,029 issues to be updated. The remaining discrepancy is likely that Fixed issues have not been updated in bulk updates like this, and there are a handful of unpublished issues which donโ€™t turn up in searches, but will be updated.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This is now deployed.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I plan to deploy the https://packages.drupal.org/8/packages.json change in the next hour.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

This API should be better-behaved now.

naderman / Seldaek - can you think of any other testing to do before putting this back in https://packages.drupal.org/8/packages.json, along with removing query-all?

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Thanks for bringing up multiple select, I see scoped labels are mutually exclusive: https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels

So we should also decide if we want to migrate each field to a scoped label like component::GitLab, or non-scoped with a prefix component GitLab, or simply GitLab. I can't think of a reason not to migrate components for every project to non-scoped labels. This is a good issue for planning that.

I also took a look at the labels UI for in GitLab. Projects without labels have a "Create a default set of labels" button which results in https://git.drupalcode.org/project/drupalorg/-/labels (Any labels you create now will not be special-cased for issue migration, so I donโ€™t recommend creating labels for your projects now, unless they help your MR workflow.)

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I think this is all fixed now. https://www.drupal.org/project/elasticsearch_helper_aws/releases/8.x-6.x... โ†’ and https://www.drupal.org/project/elasticsearch_helper_instant/releases/8.x... โ†’ did not have composer instructions, so I rebuilt their composer metadata to fix it up. The other two looked all good.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

For priority, I end up pretty much ignoring it in contrib. My priority as a maintainer might mismatch the reporterโ€™s priority. It isnโ€™t worth nitpicking over what the correct priority is. Core has more-formal definitions of priorities, so it is useful there. As a contrib maintainer, I would like the ability to remove the priority metadata from some projects.

Version will have to be per-project regardless. GitLab does not have the same sort of version field in issues, it will be just another scoped label. The label values will have no relation to the tags, branches, or releases, except for naming conventions. Migrated issues will have the existing issue version values migrated. Weโ€™ll have to decide if Drupal.org creates a new label for the project when a new release is made, or if thatโ€™s left to maintainers to do, if they want.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

https://www.drupal.org/project/ckeditor_selectall โ†’ has no releases, so is not installable with Composer.

ckeditorselectall is a project containing ckeditor_selectall module. Composer is designed to only do project dependencies (ckeditorselectall), but Drupal core works with module dependencies (ckeditor_selectall). So packages.drupal.org uses Composer metapackages to make dependencies available via the module name, which eased the transition to Composer when namespacing the Drupal dependencies with project & module name was less common.

If ckeditor_selectall creates a release in the future, it will have a different Composer namespace, so ckeditor_selectall's current behavior in Composer is not changed. We wouldn't want to allow that since it would change what code sites get. Composer namespaces do not always match up to the project name.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Paths under jobs are now allowed authenticated write access.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

It looks like ๐Ÿ“Œ Create guidelines for adding new categories Needs review is not ready yet, and that should be made official first.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I updated the issue summary with stubs of the ideal format. For implementing this, it will be 3 phases, delete old categories, update categories being kept, merge categories that will be merged. It would be good to have the lists in that format, including the category descriptions.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Where are the actual descriptions of the categories? I looked for them first at ๐ŸŒฑ Migrating "Categories" on Drupal.org Project pages Active , since it would be convenient to update the descriptions as the categories are updated.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

Are there descriptions for the categories that are being kept?

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I first started looking at DrupalCI abandonment on October 24, 2023 when 3,455 projects had 7,155 DrupalCI schedules. 534 were removed when testing with Drupal 9 was disabled, leaving 104 moving away from DrupalCI on their own in 3 months. I expect many of the remaining projects are minimally maintained and we can't expect their maintainers to put in extra work.

1,713 projects have used GitLab CI.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I went ahead and took care of this.

๐Ÿ‡บ๐Ÿ‡ธUnited States drumm NY, US

I think we should keep this simple, and only schedule:

  • No new testing schedules
  • Disable DrupalCI testing

The most official communication about disabling DrupalCI testing is:

While we don't have a specific date for that yet, it will be retired within a year (possibly by July 2024).

Letโ€™s go ahead and say July 1st for Disable DrupalCI testing.

For now new testing schedules, DrupalCon Portland is May 6-9. We might as well pick a date around then.

We should send emails to people with DrupalCI testing set up. Maybe 2 weeks before each date, so weโ€™re sending at most 2 emails.

There are currently 2,817 projects with 5,285 testing schedules set up. This has been steadily dropping already.

Production build https://api.contrib.social 0.61.6-2-g546bc20