Done, https://packagist.org/packages/drupal/events is now at Packagist and will be available in a few minutes, once processed.
benjifisher → credited drumm → .
This is planned to be deployed later today.
This hadn’t been deployed to localize.drupal.org yet, but is now.
We’ll need to know which releases need a re-parse to fully have this done.
This can be added, but I would prefer that we did not do this, just in case we do decide to host more namespaces on packages.drupal.org.
Since this is done server-side, I don’t think there’s a reason for anything in core.
I'll go ahead and get this moving. Comments are not allowed for new change records. The next step is disabling them for existing change records and 📌 Consider deleting comments on change records Active
(Saving to correct Drupal.org’s issue index, please disregard.)
I believe everything is done here
Attached is that backup. I am removing the fields now
This is deployed.
Thanks!
Backfilling completed and this has been running smoothly for over a week.
For Drupal.org, we could always sort by “relevancy” which is
- Project usage, potentially with boosts added later for moving projects up/down based on signals that reliably show module quality
- When searching for text, the primary ranking is the text search (balanced among title/description/etc) and then usage and any other factors
Like we do on https://www.drupal.org/project/project_module → . I’m not sure we actually need any other sorting options. The point for this issue would be making sure we’re not hard-coding anything like “most installed”
This should not be hard-coded to 2 digits as well. For a contrib module with 2.x and 2.0.x, sorting should be consistent.
When 12.x comes around there won't be an 11.x around any more, so we don't need to think about that.
Release branches are permanent, so 11.x is not going away.
N.x releases should be sorted the same way in any case, so we shouldn’t hard-code 11
https://git.drupalcode.org/project/project/-/blob/132a1ca69dd97276a4d03f... is where this sorting happens.
We could swap in a new sort function there, since better MRs will ease the transition to issues in GitLab. What I could use help with is thinking through a replacement/layer-on-top-of version_compare() that sorts as expected.
These use the teaser node view https://git.drupalcode.org/project/drupalorg/-/blob/9dd89c9beb77d5f8afb4...
We should think about using more of the design elements from the project browser client:
- Categories
- Covered by security advisory policy icon
- Number of installs (unsure about this, how useful is the raw number without context?)
So next steps are:
- Have a look around at other project node teaser usages throughout Drupal.org, and decide if we want to update them everywhere. I can’t think of another use offhand.
- Update the node teaser view for projects, or render another way.
No action needed, just noting this - this should not have been an exception because a new module took one of these names and more time is needed to clean up now.
This should also extend to sort orders. For example, the default sort order being only project usage could be augmented to consider other factors, like minimal maintenance being ranked lower. And other sources won’t have usage information.
This might be a follow-up issue - for the Drupal.org source, this metadata should come from Drupal.org itself, not be hard-coded in the client code.
For example, we might merge maintenance status & development status, or their options in the future. We should be able to do that, including changing what’s rolled up into more-simplified "show maintained / show everything” filters.
Checking frequently isn’t an issue for traffic server-side, the CDN absorbs that.
In highly critical security releases, even checking at the end of the security release window is not ideal. A bad enough vulnerability would be exploited before the window is over. And the window is ideal, but not a rule. If there’s a 0-day, any day is good for fixing the issue. If there’s some issue in the release process, late is better than waiting another week. Even under ideal conditions, we might reschedule, these sorts of things should not be hard-coded into Drupal core.
The one thing I would ask for is encouraging skewing when sites ask for updates, so we don’t have a spike of traffic at the top of an hour, its spread out throughout an hour.
longwave → credited drumm → .
The warning is now deployed and the announcement is at https://www.drupal.org/drupalorg/blog/ending-packagesdrupalorg-support-f... →
I've put some notes for the changes needed in child issues.
Deployed, and removed a bunch of displays which are no longer used. Let me know if I removed anything we were using.
Looks okay to transfer, done!
Please do send the Slack screenshot to confirm
This is deployed and new releases are being caught up. I fully expect this needs forward-porting.
Re indexes - I didn't catch the comments here before simplifying the update function in the MR. For this one, I’m not too concerned about database portability. It works for localize.drupal.org, and if anyone happens to be running this stack in D7 on Postgres and needs the extra key handling, followups are welcome.
I think this is ready to deploy now.
This will be displayed alongside Packagist.org’s warning:
Warning from https://repo.packagist.org: Support for Composer 1 is deprecated and some packages will not be available. You should upgrade to Composer 2. See https://blog.packagist.com/deprecating-composer-1-support/
https://packagist.org/packages.json uses "warning-versions":"<1.99" I’m not sure if they have a reason for that, but I’d rather follow their lead, even if it might not be technically correct.
We should definitely link to our announcement about packages.drupal.org’s support, once its drafted & posted.
This will happen in 2 phases:
- Stop updating Composer 1 metadata - Composer 1 will still be functional with packages.drupal.org, but will not have any new releases or other updates. I’d like to do this in about a month, the week of August 5 or 12
- Remove Composer 1 metadata - Composer 1 will no longer be able to use packages.drupal.org. I’d like to do this a month or two later, the week of October 1 would put it after DrupalCon Barcelona
Both can be announced directly to users like https://packagist.org/packages.json has
"warning":"Support for Composer 1 is deprecated and some packages will not be available. You should upgrade to Composer 2. See https://blog.packagist.com/deprecating-composer-1-support/","warning-versions":"<1.99"
And we should have various other announcements, including a couple blog posts.
This is now allowed.
Yes, we can allow this.
That said regardless of whether or not we can or should provide an optimized recipe author experience, I would argue that we will have lost the mission for Starshot itself if site builders have to search and scour to find a collection of recipes that will match the functionality they could get from installing a single, popular plugin on a competing platform.
We could also say adding many recipes to one repo is jumping to a developer-focussed solution ahead of figuring out the user experience. Being able to find recipes designed to work together is something to consider in #3447063: [Meta] Plan for recipe findability on Drupal.org and Project Browser → .
Where the repositories are should be irrelevant to end-users. A monorepo would be a developer convenience for tightly-coupled recipes. Subtree splitting each recipe from the monorepo to each individual project makes the recipes functionally the exact same as each recipe in one repository.
In scenario 2, the suggestions API sounds to me like the ecosystem association currently built into drupal.org. I'm not sure if this is planned to carry over to Gitlab at some point, but if it is, maybe that could be the underpinning for having additional recommendations?
Projects remain on Drupal.org indefinitely, they are not moving to GitLab. This means we always have a place for metadata, categorization, user-focussed descriptions, etc for project browsing. This parallels other systems for browsing extensions - app stores, Wordpress plugins, browser extensions, and other equivalents to project browsing all have additional metadata and centralization, and don’t rely on just Git repositories.
We use Drupal’s regular theme('user_picture'), which adds the linking. As a general rule, we don’t fight Drupal when we don’t need to. And we are only doing limited updates to the Drupal 7 site as we migrate to modern Drupal. If Drupal 10 has changed this, we’ll see that when we get there.
Added 2 more child issues:
- 📌 Add host key verification for sending targets to rugged for signing Active this is a security hardening. We are not sending anything private to be signed by rugged, but we should still verify where we are sending it
- 🌱 Deprecate composer 1 Active will reduce the error rate for the client, especially if our rugged stack has an outage
I think it is safe to say we won’t fix this at this point.
Adding #3325040: [Packaging Pipeline] Securely sign packages hosted on Drupal.org using the TUF framework and Rugged → as a parent issue. Composer 1 support causes https://packages.drupal.org/8/packages.json to be updated frequently. TUF will flag any time that packages.json is updated, but the hash of the file has not been updated. Once Composer 1 is no longer supported, https://packages.drupal.org/8/packages.json will effectively become a static file, greatly reducing the impact of any rugged/signing disruptions.
And we need to get this done before updating this codebase to modern Drupal.
We can call this done https://packages.drupal.org/8/metadata/
The CDN handling was simplified and is at https://gitlab.com/drupal-infrastructure/package-signing/check-cache/-/b...
The Drupal code to get targets signed is at https://git.drupalcode.org/project/drupalorg/-/blob/424d969f020a49aa3fe3...
This is now ready: https://packages.drupal.org/8/metadata/
Before calling it done, we need:
- #3352216: Securely sign Drupal core packages, even though they are hosted on GitHub/packagist directly →
- securesystemslib includes non-compliant `keyid_hash_algorithms` property when generating key IDs https://gitlab.com/rugged/rugged/-/issues/192
- Reset processing targets batch on boothttps://gitlab.com/rugged/rugged/-/issues/191
- Nice to have, not required - Clean up more completely when targets containing empty directories are processed https://gitlab.com/rugged/rugged/-/issues/149
- Verify root key rotation process
We have the start of this in production at https://packagist-signed.drupalcode.org/packages.json & https://packagist-signed.drupalcode.org/metadata/
The remaining work is to get all of the drupal/ namespace on Packagist.org mirrored. This is ready with https://gitlab.com/drupal-infrastructure/package-signing/packagist-signe..., and needs debugging for why it hasn’t succeeded in production.
I believe we have this resolved.
Part of a recipe is composer.json for dependencies and other metadata.
Composer keeps it simple and supports only one composer.json per-project, at the root level of the repository.
Drupal’s support for sub-modules & sub-themes, each with their own dependencies, was one of the main reasons we created packages.drupal.org as a shim for supporting Drupalisms in Composer. We do not plan on doing anything special for recipes. Their metadata is distributed directly via Packagist.org as regular PHP projects, no special Drupal handling.
I believe we can call this done now. Thanks everyone!
DrupalCI is now disabled and no new tests will run. Existing test results will be available for 6 months. No DrupalCI test results will be migrated to GitLab, so a project with issues migrated to GitLab will have DrupalCI test results deleted at that time.
Looks good, deployed. Thanks!
Yes, I should have said delete the comments.
Not that this will help practically, I will post a backup of the data, including revisions, to this issue. So we’re not totally throwing it out, although it won’t be practically accessible.
This is indeed superseded by 📌 Migrate drupal.org issues to gitlab issues Needs review . The decision to migrate has been made, it is a matter of having capacity to get that closer to the top of the to-do list.
Done. I’ll consider authenticating with Drupal.org to be a good second factor to validate this, and the confirmed emails for both accounts match.
https://www.drupal.org/project/drupal/issues/3056698 → is the canonical URL. I recommend using https://www.drupal.org/i/3056698 → when making a link when you only have a Drupal.org node ID.
The text at the top of the create issue form is set by core maintainers by editing the core project page.
https://www.drupal.org/community/contributor-guide/reference-information... → can be edited by anyone. Go ahead and make any clear improvements, and gain consensus on any changes that aren’t straightforward.
In the future, issues are moving to GitLab 📌 Migrate drupal.org issues to gitlab issues Needs review . Version and other metadata will be labels on the issue, and we will be using GitLab’s UI for this, which is not customizable. For example, if the core maintainers remove the Version::5.x label, that may remove it from all historical issues, it would need testing before doing too much. I’m not aware of any ability to disable using a label on new issues, other than a triage bot to automate corrections.
Since this is coming in the next few months, we are limiting changes to the issue UI on Drupal.org, to focus on the migration. This means we likely will not be setting the version dropdown to a suggested/recommended default.
Looks good to me too. We will be running this on Drupal.org’s codebase.
Done!
The field is now deleted.
Agreed, I think we can go ahead and delete this field.
I see no reason why “Introduced in version” can’t be multi-valued. We’ll need to update the Views showing both fields regardless, which should be straightforward.
We should hold off on adding new fields until after Drupal.org is migrated off of Drupal 7.
I’ve gone ahead and hidden the display of these fields and made editing read-only.
To simplify Drupal.org migration and maintenance, we do want to go ahead and drop these fields. I’ll make a final backup attached to this issue when that happens. I think we can go ahead and drop the checkbox fields. The text field content could be appended to another field, if we want to keep it.
And the text field content is attached.
The checked checkbox fields:
MariaDB [drupal]> SELECT count(1), group_concat(entity_id) FROM field_data_field_online_recorded WHERE field_online_recorded_value = 1\G
*************************** 1. row ***************************
count(1): 85
group_concat(entity_id): 1294406,1302736,1312352,1319812,1379694,1388376,1450328,1450334,1450336,1450338,1450340,1458586,1719084,1734814,1790518,1880620,2016305,2022859,2058941,2079895,2147705,2160225,2162063,2201089,2214085,2296697,2379475,2409381,2451661,2459367,2460819,2476661,2535224,2535246,2616600,2895946,2899118,2928113,2976856,2996568,3019696,3026278,3079238,3087638,3087640,3087642,3095199,3102690,3115844,3133575,3135392,3144035,3152945,3159276,3170786,3171552,3177647,3188254,3191231,3200327,3218910,3222512,3223425,3225678,3225679,3225681,3246370,3246630,3247837,3249720,3251343,3255073,3268407,3270759,3280109,3281085,3281089,3283577,3339546,3339549,3349399,3357138,3368903,3380685,3418160
1 row in set (0.000 sec)
MariaDB [drupal]> SELECT count(1), group_concat(entity_id) FROM field_data_field_theme_recorded WHERE field_theme_recorded_value = 1\G
*************************** 1. row ***************************
count(1): 20
group_concat(entity_id): 1294406,1379694,1388376,1450328,1450334,1450336,1450338,1450340,1880620,2009120,2022859,2158619,2160225,2379475,2476661,3026278,3133575,3355112,3368903,3418160
1 row in set (0.001 sec)
MariaDB [drupal]> SELECT count(1), group_concat(entity_id) FROM field_data_field_module_recorded WHERE field_module_recorded_value = 1\G
*************************** 1. row ***************************
count(1): 52
group_concat(entity_id): 1294406,1302736,1312352,1319812,1340622,1379694,1388376,1397774,1450328,1450334,1450336,1450338,1450340,1458586,1626346,1880620,1914710,1935708,2022859,2044515,2060189,2079895,2158619,2162063,2409795,2451661,2459367,2459373,2460819,2476661,2495707,2713593,2733435,2737401,2747231,2830442,2899118,2996568,3019696,3026278,3083715,3130551,3133575,3177647,3188254,3247837,3339546,3339549,3367425,3367447,3368903,3418160
1 row in set (0.001 sec)
MariaDB [drupal]> SELECT count(1), group_concat(entity_id) FROM field_data_field_examples_recorded WHERE field_examples_recorded_value = 1\G
*************************** 1. row ***************************
count(1): 32
group_concat(entity_id): 1294406,1302736,1379694,1388376,1450328,1450334,1450336,1450338,1450340,1880620,1914710,2079895,2181351,2409795,2476661,2899118,2933737,2996568,3019696,3026278,3133575,3177647,3188254,3247837,3263301,3339546,3339549,3367425,3367447,3368903,3380685,3418160
1 row in set (0.001 sec)
MariaDB [drupal]> SELECT count(1), group_concat(entity_id) FROM field_data_field_coder_recorded WHERE field_coder_recorded_value = 1\G
*************************** 1. row ***************************
count(1): 95
group_concat(entity_id): 1294406,1340622,1343526,1379694,1388376,1450328,1450334,1450336,1450338,1450340,1880620,2058941,2060189,2079895,2138505,2286021,2296697,2335327,2419329,2423651,2476661,2935965,3026278,3046368,3102690,3115844,3118852,3133575,3135392,3144035,3152945,3159276,3170786,3171552,3171772,3177647,3188254,3191231,3200327,3210688,3212492,3213562,3219882,3222512,3225678,3225679,3225681,3229085,3229087,3236736,3236738,3239365,3239367,3247837,3249720,3251343,3255073,3258132,3258895,3260105,3268407,3268588,3270759,3271410,3273990,3274254,3276951,3280109,3282086,3293575,3299682,3300156,3305425,3313421,3339546,3339549,3357138,3360165,3364824,3364827,3364829,3364839,3364894,3364899,3367425,3367447,3368903,3380685,3387255,3387256,3387258,3387259,3396051,3412864,3418160
1 row in set (0.001 sec)
MariaDB [drupal]> SELECT count(1), group_concat(entity_id) FROM field_data_field_coder_update_recorded WHERE field_coder_update_recorded_value = 1\G
*************************** 1. row ***************************
count(1): 83
group_concat(entity_id): 1294406,1340622,1379694,1388376,1450328,1450334,1450336,1450338,1450340,1539312,1880620,2019303,2079895,2476661,2842083,3026278,3118852,3133575,3135392,3144035,3152945,3159276,3170786,3171552,3171772,3177647,3188254,3191231,3200327,3210688,3212492,3213562,3219882,3222512,3225678,3225679,3225681,3229085,3229087,3236736,3236738,3239365,3239367,3247837,3249720,3251343,3255073,3258132,3258895,3260105,3268407,3268588,3270759,3271410,3273990,3274254,3276951,3280109,3282086,3293575,3299682,3300156,3305425,3313421,3339546,3339549,3357138,3364824,3364827,3364829,3364839,3364894,3364899,3367425,3367447,3368903,3380685,3387255,3387256,3387258,3387259,3412864,3418160
1 row in set (0.001 sec)And “Other” defaults to checked, the unchecked ones are:
MariaDB [drupal]> SELECT count(1), group_concat(entity_id) FROM field_data_field_other_recorded WHERE field_other_recorded_value = 0\G
*************************** 1. row ***************************
count(1): 99
group_concat(entity_id): 1225062,1235918,1294416,1294434,1294560,1295398,1296384,1298642,1311610,1327978,1328756,1353496,1353920,1379694,1397774,1397856,1412416,1412420,1451282,1539312,1571618,1605356,1626352,1637540,1704454,1719084,1721582,1736314,1764252,1796000,1825832,1825844,1826444,1834108,1845692,1914710,1920826,1952798,1953036,1967614,2009120,2016305,2019303,2019739,2032175,2032185,2043385,2047135,2050669,2130393,2142533,2143783,2149853,2155761,2164069,2166575,2168399,2181569,2181921,2215725,2227667,2259727,2286021,2286025,2409795,2451661,2459367,2460819,2480945,2534062,2535224,2535246,2646240,2772525,2839085,2857562,2866124,2906736,2908490,2916197,2934304,3060933,3104677,3115844,3120980,3130551,3211347,3212880,3215268,3238149,3248036,3263524,3263973,3269169,3283577,3348648,3349399,3403416,3419104
1 row in set (0.000 sec)We do not delete releases from Drupal.org. Once a release has been made available, it is permanently there for anyone who might be using the release. This includes dev releases and their branches.
When you get to these releases, I recommend making the 3.1.*, 3.2.* release series from the 3.x branch. Then only branch 3.1.x when it needs to diverge from 3.2.*.
Merged!
Done!
This field is now gone, backup of its data is attached.
Thanks all, this has been deployed.
drumm → made their first commit to this issue’s fork.
This is now allowed for POST requests.
For organization ranking, we can weight this based on project usage, like we do for issues.
Before getting into crediting organizations, we want to make sure people are credited. That means making a release should be highlighted on your user profile page, like https://www.drupal.org/u/catch → . A couple ideas to start:
- A separate listing of “Releases made”, like “Projects maintained,” would be the most straightforward. For medium to large screens, could position to the right of “Projects maintained.” Would need to either count for each project, or see if we need a “more” link if listing them all.
- Merging in with “Projects maintained,” adding a count, would save some screen real-estate. Would need to think about what, if anything, to do when someone who made releases is no longer a maintainer of a project.
Once people are credited, this should guide how credit appears on organization pages like https://www.drupal.org/tag1-consulting → .
For storing the organization metadata, it would be most straightforward to have a field like “Supporting organizations” on projects. That could be a straightforward entity reference field; I don’t think “How they helped” would be necessary for releases. Using the issue-style organization/customer setup would be overly-complicated, but if we do need that, we can follow what we did for security advisories.
Once we have the data for organizations, we should pick where/how to show it on release pages.
I went ahead and deleted the @drupal8changes block from https://www.drupal.org/list-changes/drupal → , since it is just a block, and wasn’t in code anywhere.
Next steps for the field on project pages:
- Remove the display, other references to it, and field configuration
- Make a backup
- Remove the field
Done
I do think we should keep some old versions. If you end up with an old site, or old memory, it is useful to see old documentation, to help track down what has changed.
(Saving to resolve issue indexing issue, please disregard.)
The 3343584-fix-the-issues branch doesn’t actually exist at https://git.drupalcode.org/issue/advanced_title_block-3343584/-/branches.... This was likely the branch that was supposed to be created on forking, but GitLab must not have received and completed that API request.
Since work is happening in other branches, I’ve deleted Drupal.org’s record of it.