76 lines
3.5 KiB
YAML
76 lines
3.5 KiB
YAML
uuid:
|
|
- value: e179e840-bd5c-45b3-8bae-2b3706861bb3
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:18+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: 'Patches vs Merge Requests'
|
|
created:
|
|
- value: '2024-03-17T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:18+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2024/03/17/patches-vs-merge-requests
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>I'm aware of the ongoing changes to the issue queues on Drupal.org, I haven't contributed or committed as much recently, so I haven't had to use the new approaches, such as issue forks and GitLab merge requests.</p>
|
|
|
|
<p>Yesterday, though, I was able to do that whilst submitting <a href="/daily/2024/03/16/adding-tests-to-the-content-access-by-path-module">the tests I wrote to the Content Access by Path module</a>.</p>
|
|
|
|
<p>I've made many contributions to projects on Drupal.org, including Drupal core and Drupal.org itself, so I'm very familiar with how the issue queues and the patch workflow work.</p>
|
|
|
|
<p>When I first started contributing, we were using CVS, and before the "Great Git Migration".</p>
|
|
|
|
<p>I'm also familiar with the pull or merge request approach from working on open-source and team projects on GitHub, GitLab and Bitbucket.</p>
|
|
|
|
<p>I can see how a merge request-based workflow on Drupal.org will lower the barriers for new contributors, which seemed to be the case at DrupalCon Lille.</p>
|
|
|
|
<p>I look forward to adapting and using it more now that the patch workflow is deprecated and will soon no longer work as everything will switch to merge requests and leverage more of GitLab's features.</p>
|
|
|
|
<p>Another step forward for Drupal.org and the Drupal project.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>I'm aware of the ongoing changes to the issue queues on Drupal.org, I haven't contributed or committed as much recently, so I haven't had to use the new approaches, such as issue forks and GitLab merge requests.</p>
|
|
|
|
<p>Yesterday, though, I was able to do that whilst submitting <a href="/daily/2024/03/16/adding-tests-to-the-content-access-by-path-module">the tests I wrote to the Content Access by Path module</a>.</p>
|
|
|
|
<p>I've made many contributions to projects on Drupal.org, including Drupal core and Drupal.org itself, so I'm very familiar with how the issue queues and the patch workflow work.</p>
|
|
|
|
<p>When I first started contributing, we were using CVS, and before the "Great Git Migration".</p>
|
|
|
|
<p>I'm also familiar with the pull or merge request approach from working on open-source and team projects on GitHub, GitLab and Bitbucket.</p>
|
|
|
|
<p>I can see how a merge request-based workflow on Drupal.org will lower the barriers for new contributors, which seemed to be the case at DrupalCon Lille.</p>
|
|
|
|
<p>I look forward to adapting and using it more now that the patch workflow is deprecated and will soon no longer work as everything will switch to merge requests and leverage more of GitLab's features.</p>
|
|
|
|
<p>Another step forward for Drupal.org and the Drupal project.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|