NY, US
Account created on 17 July 2003, almost 22 years ago
#

Merge Requests

More

Recent comments

🇺🇸United States drumm NY, US

And we can open this process to everyone for more testing, we don’t need to complete the migration for the new process to be the default.

🇺🇸United States drumm NY, US

https://git.drupalcode.org/security/22-contribution_records-security/-/i... shows this working. When a security team member changes the project name in the title, this is triggered.

I need to update https://www.drupal.org/drupal-security-team/security-team-procedures/sec... before closing.

🇺🇸United States drumm NY, US

Fixed. This was probably unintentionally changed during some menu updates.

🇺🇸United States drumm NY, US

I believe the main work left is to migrate the issues. As far as I'm aware, the new setup is feature-complete enough.

🇺🇸United States drumm NY, US

It's been awhile with everything known resolved enough, so calling this fixed. We can always open followups when needed.

🇺🇸United States drumm NY, US

(Forgot to update credit)

🇺🇸United States drumm NY, US

It's been awhile with everything known resolved, so calling this fixed. We can always open followups when needed.

🇺🇸United States drumm NY, US

This UI is not customized on Drupal.org, it is straight from Drupal core. Issue edit pages are only an example.

🇺🇸United States drumm NY, US

This should be okay for reducing glyphs for now, we can always re-add specific scripts if people who can read them provide feedback later.

🇺🇸United States drumm NY, US

Add tracking for when recipes from Drupal.org are applied Active might have this implemented in ComposerHelper::getPackageName(), not hooked up to update module yet.

🇺🇸United States drumm NY, US

This is the first request for this update we’ve had.

We do have integrity checks ensuring the commit emails are always synced correctly. We’d lose knowing about user syncing issues if we were to update your email.

🇺🇸United States drumm NY, US

Easiest would probably be copying text from https://localize.drupal.org/translate/languages. I’ve definitely seen names in all of those scripts, although I don’t know what the -ext options are offhand.

🇺🇸United States drumm NY, US

This should be ready to deploy, which I’m not doing before the US holiday weekend.

🇺🇸United States drumm NY, US

We do need a font with all the glyphs, since people’s names are in many scripts, localize.drupal.org has many languages, and everywhere the global community is communicating.

🇺🇸United States drumm NY, US

Removing the Summary heading that isn’t needed

🇺🇸United States drumm NY, US

Looks like this was “needs work” for standards & formatting, and those have been improved. I’m going to be bold and call this done. If there is something to do, feel free to kick back to another status with specific changes needed.

🇺🇸United States drumm NY, US

I’m a bit wary of running yarn install 4x. That will be extra compute, which is generally more expensive than storage. And it is additional network requests, that have potential to get noticed by upstream providers. We don’t really have a good setup to know the real cost tradeoff.

If we were able to do things like skip eslint & stylelint when JS & CSS aren’t changed in a MR, this would be a great approach. That should be a net reduction in compute.

Making a separate node_modules job/artifact might be an option, although it’d be more wall time to get through each pipeline, don’t know if that’s a good idea.

For now I’ve raised the artifact size limit to 250M to give us a bit more breathing room.

🇺🇸United States drumm NY, US

This is easy to deploy whenever ready.

🇺🇸United States drumm NY, US

Add tracking for when recipes from Drupal.org are applied Active should be doable and provide better data.

Implementing this workaround would be just as much work as the server-side of the correct tracking, and is not a quick win. This might even take more time, I do not think we have the module dependencies stored in a database table.

🇺🇸United States drumm NY, US

(Updating to resolve Drupal.org issue indexing issue, please disregard)

🇺🇸United States drumm NY, US

(Updating to resolve Drupal.org issue indexing issue, please disregard)

🇺🇸United States drumm NY, US

(Updating to resolve Drupal.org issue indexing issue, please disregard)

🇺🇸United States drumm NY, US

The warning on edit is now deployed.

It didn’t cross my mind before that we could theoretically fix the display somewhere in custom field formatting, without the underlying date module bug being fixed. Assuming enough time zone information is stored consistently.

🇺🇸United States drumm NY, US

I’ve deployed that fix and repackaged all 11.2.* releases. I believe that the downloads should be good now. And the additional error handling should show this type of problem earlier next time.

Please follow 📌 Remove drupal/legacy-project as a starting point for Drupal 10 Needs work and related issues for future changes to supported file layouts (recommended-project vs legacy-project) and packaging. The downloadable packages are generated with Composer, so you can use them as a starting point and get modules and other dependencies with Composer, but it is best to use Composer from the start, so you are familiar with it.

🇺🇸United States drumm NY, US

Looks like this was simply running on a too-old version of PHP. I am updating that, and adding exception handling if composer create-project fails.

🇺🇸United States drumm NY, US

This is likely a drupalorg or infrastructure issue for packaging. I’ll leave the issue here for findability, and move once closer to a fix.

I think we do want to keep the tarball packaging in some form, it is somewhat of an end-to-end test of the subtree splits and project templates working correctly, and is one of the faster packaging steps.

As far as I can tell, the subtree splits and templates look good for now.

Tarball packaging would switch to recommended-project to support 📌 Remove drupal/legacy-project as a starting point for Drupal 10 Needs work , and removing / deprecating them will hopefully be more coordinated than them not being packaged correctly.

🇺🇸United States drumm NY, US

When issues move to GitLab, https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... will be replaced by GitLab’s label listing like https://gitlab.com/gitlab-org/gitlab/-/labels. So we don’t want to spend time rearranging something that will go away.

Deleting tags is highly destructive and removes the history of when a tag was added or removed from any issue. It should happen only for spam and things like briefly-used misspellings. Unfortunately, I have seen tags that must have been over-aggressively been deleted by site moderators, but it hasn’t been bad enough for me to spend time investigating. If something is approaching a code of conduct issue, or just plain unwelcoming, that could be a good reason to delete it.

Tags can be renamed, which might be another option. Something like “(historical)” or some other convention could be used when the description is useful for additional context. For example, “VDC” will always need explanation.

I also recommend removing descriptions, like from the PHP version tags.

🇺🇸United States drumm NY, US

GitLab pages will not be indexed in the Drupal.org site search, so there will be some loss of findability, but we probably will want to de-emphasize the site search anyway, as some important projects are on GitLab pages already.

The unique thing API module could do, and does for .txt files, is auto-link references to classes/functions/etc like any docblock comment. For example https://api.drupal.org/api/drupal/core%21INSTALL.txt/11.x has links to other files. That is not used much, so I’m sure serious use would find improvements to be made (URLs aren’t auto linked, but would be less-relevant for markdown) in addition to adding markdown parsing.

That said, I think it is all good to go ahead with GitLab pages. There should be some plan to completely replace and delete documentation like https://www.drupal.org/docs/8/api/cache-api/cache-api , so we try to avoid the usual problem of good documentation initiatives accumulating into just more versions of more documentation to be disorganized.

🇺🇸United States drumm NY, US

I suspect the current design was intentional so that the page was not overwhelming.

You can actually filter the Drafts tab by published status: https://www.drupal.org/list-changes/drupal/drafts?keywords_description=&... and get to what you are looking for.

🇺🇸United States drumm NY, US

We are monitoring for known causes of integrity issues, such as queues not being processed promptly. Verifying the entire repository would probably take multiple days and have little practical benefit for spotting issues which I suspect are only present for a few minutes at a time.

🇺🇸United States drumm NY, US

Can we go ahead and delete the www.drupal.org pages right away, as redirects are added?

🇺🇸United States drumm NY, US

What is the URL you are seeing this on?

🇺🇸United States drumm NY, US

I don’t see git@git.drupalcode.org mentioned on that page either.

Regardless, this is not something we can change, git.drupalcode.org is fronted by a CDN, which forwards HTTP connections, not SSH. So swapping the protocol used without getting the full documented Git remote URI will not work.

🇺🇸United States drumm NY, US

This is deployed now, and organization ranking has been recalculated.

🇺🇸United States drumm NY, US

Both https://packagist-signed.drupalcode.org and https://packages.drupal.org/8 should be in composer.json with "tuf": true

https://packages.drupal.org/8 only includes contrib modules and themes from Drupal.org. The rest of Drupal, including core, is distributed via Packagist.org, which does not have code signing. packagist-signed.drupalcode.org mirrors packagist.org, so core and the TUF library are signed.

🇺🇸United States drumm NY, US

https://packagist-signed.drupalcode.org/metadata/3.root.json is by design, that will only exist when the root metadata is refreshed for a 3rd time.

I keep hitting https://packages.drupal.org/8 could not be fully loaded (Maximum allowed download size reached. Content-length header indicates 7240 bytes. Allowed 1024 bytes), package information was loaded from the local cache and may be out of date

Until https://github.com/php-tuf/composer-integration/issues/128 is resolved, I have basically no capability to help with issues like this. I need to know which HTTP request is causing the problem.

🇺🇸United States drumm NY, US

Where did you see instructions to use git@git.drupalcode.org?

That is not listed as a remote URI on pages like https://git.drupalcode.org/project/drupal or on https://www.drupal.org/project/drupal/git-instructions and is not a domain that accepts SSH connections.

🇺🇸United States drumm NY, US

Screenshot of the addition to the Owner tools page for each organization.

🇺🇸United States drumm NY, US

Issue originally raised by xjm in Slack.

🇺🇸United States drumm NY, US

We did recently refresh the root metadata ahead of the expiration later this month for both:

I would expect the client to fetch and use this automatically. If we refreshed and rotated keys in the root metadata as a result of a compromise, I would think the client should automatically start using the new metadata, which has a chain of trust back to 1.root.json. This should be checked against the TUF spec.

This will need some debugging to figure out where the root cause is.

🇺🇸United States drumm NY, US

Confirmed that made it through to https://github.com/drupal/recommended-project & https://github.com/drupal/legacy-project

That also means we could add a README.md to each, so anyone who lands on the GitHub repo has some explanation.

🇺🇸United States drumm NY, US

This is probably the right version.

🇺🇸United States drumm NY, US

Issue are migrating to GitLab, Move issues from www.drupal.org to git.drupalcode.org Postponed , so we aren’t adding features to the existing issues. GitLab does support videos, https://docs.gitlab.com/user/markdown/#videos. You can already upload a video to a merge request to see how it works.

🇺🇸United States drumm NY, US

I think at this point we would like to move https://www.drupal.org/project/localgov from "Distributions" to "General projects" to support straightforward composer require.

That’s now done and https://packagist.org/packages/drupal/localgov is now available.

2. Is it important to make the .info file and composer.json to have the same dependencies? (It seems that drupal.org packaging adds things it finds in the .info file).

Yes, it is very important that dependencies are in composer.json. That is the only source of dependency management for general projects. Those are published straight to Packagist.org, which has no idea what an info file might be. It is a good idea to keep them in sync for modules & themes too.

I think that might have everything in this issue answered

🇺🇸United States drumm NY, US

Attach Drupal CMS custom-packaged .tar.gz files Active is now done and confirmed localize.drupal.org is able to parse cms releases.

🇺🇸United States drumm NY, US

This is complete and localize.drupal.org has parsed the missing releases, which I manually repackaged into a tgz files.

🇺🇸United States drumm NY, US

This is now deployed: https://www.drupal.org/project/drupal

The short descriptions can be updated by core release managers.

🇺🇸United States drumm NY, US

This should now be allowed.

🇺🇸United States drumm NY, US

We have a notice like that for D7 documentation already. For example: https://www.drupal.org/docs/7/understanding-drupal

https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... is more of a lost & found of potentially-unmaintained documentation that could still use triage. For example, https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... has a supported version compatible with Drupal 11, and that documentation has a good chance of being relatively current.

The only thing needed to close out this issue is triaging the orphaned book pages at https://www.drupal.org/node/3522465

🇺🇸United States drumm NY, US

Agreed we should keep the short descriptions for all, and make them more concise & accurate. If some descriptions really shouldn’t be there, should be able to edit the release to remove them. Some explanation for showing older versions makes sense to me.

🇺🇸United States drumm NY, US

Search indexing has now caught up again.

🇺🇸United States drumm NY, US

Mixing the subtree split & other derivative repositories into GitHub is not a good idea for access management long-term. Everything working the same way will be much better to manage.

(If we had general projects ready for when core required subtree splits, we would not have used GitHub.)

🇺🇸United States drumm NY, US

As part of #3048700: Discontinue groups.drupal.org we removed multi-site searching from Drupal.org. This caused all content on www.drupal.org to be marked for reindexing. We’ve accelerated that reindexing and it should complete within the next 2 days.

🇺🇸United States drumm NY, US

We can continue putting redirects in by hand. Where should the two pages you linked go to?

We do keep records of deleted nodes, but now is not a good time to engineer new functionality as we’re migrating the site. That is something we could build once documentation is fully migrated, if the search for the previous page title is tested and shown to be useful.

🇺🇸United States drumm NY, US

Updating link for  https://www.drupal.org/project/drupalorg/issues/3528485 📌 Move GitLab security issue triage project to hide issue counts Active

🇺🇸United States drumm NY, US

Yes, the labels filter is hiding in the left sidebar, at the bottom.

🇺🇸United States drumm NY, US

I did a quick pass through the orphaned book pages ( https://www.drupal.org/node/3522465 ) and deleted a couple of pages for themes that didn’t have D7 or later versions.

The can be deleted but I don't have edit accees, the bitcahce project is unsupported.

And those have been deleted too, thanks!

What about the pages for modules that do not have a stable D7 release?

I think we have to keep those for now, there will be plenty of people with D7 sites that they need to figure out, and documentation has potential to help.

🇺🇸United States drumm NY, US

Even if this feature was present in GitLab, it is always best to keep patches locally

MR.patch URLs should never be used by composer patches. The upcoming 2.x version https://github.com/cweagans/composer-patches has some protections built-in, including https://github.com/cweagans/composer-patches/issues/347. The best way to help is to look into blockers for the 2.0.0 release of composer-patches, and help move those forward. Until then, you might consider setting up CI to flag improper composer-patches use in your projects.

Even if this were a GitLab feature, local copies of patches still eliminate the possibility of the remote URL becoming unavailable, changing, or causing other chaos. And you have a definite record of what your codebase was patched with. For example, we may need to clean up stale forks for closed issues in the future, that could affect the MRs from those forks. Indefinite MR patch hosting is not a service we can promise to provide.

🇺🇸United States drumm NY, US

The missing statuses are filled out now:

  • Reviewed & tested by the community → Security status::reviewed & tested
  • Ready for SA to be Published → Security status::ready to be published
  • Postponed → Security status::postponed
  • Closed (duplicate) → Closed::duplicate
  • Closed (won't fix) → Closed::invalid, potentially might be other statuses

And what I mentioned in #5 is done by https://git.drupalcode.org/project/drupalorg/-/commit/109256299611a258d8... & https://git.drupalcode.org/security/triage/-/commit/cc6e081e6ab08d16f49b...

So I think everything we’ve thought of has been followed up on.

🇺🇸United States drumm NY, US

This was deployed and organization rank has recalculated.

Production build 0.71.5 2024