Issue Forks and Merge Requests are scheduled for general availability on all projects on Nov 10, 2020.

We're very excited to report that we're now very close to opening up a beta test of merge requests integrated with Drupal.org issues.

Stepping back for a moment, let's remember the ideal contribution flow that we defined when evaluating our Developer tool options: 

Drupal Flow

  • The issue itself should remain a single-threaded conversation for discussing the particular problem to be solved.
  • Every issue will be associated with one canonical issue fork(with multiple branches, as needed) which can be collaborated on by any contributor, and merged by a project maintainer.
  • Contributors will be able to modify the code in these issue forks by:
    • Checking out the code and committing/pushing changes to the workspace.
    • Inline editing files using GitLab's web interface.
    • Legacy: uploading a patch.
  • All types of contribution—whether merge requests or the legacy patch workflow—will continue to trigger DrupalCI testing.
  • Issue forks can be rebased (manually or automatically) when needed to resolve conflicts with upstream commits.
  • Contributors and project maintainers will be able to comment on individual lines of code.

The foundation for this work is the ability to create these issue forks from an issue on Drupal.org. This involves building an interface from Drupal.org that creates an issue fork in GitLab associated with the Drupal.org issue, and then any Drupal.org user can push to that fork and branches within it. Maintainers may then merge this work from a branch on the issue fork the project.

That foundational work to create the necessary git hooks and access control management is now complete.

The next steps are:

When will merge requests be available to the community at large?

Creation of issue forks is now available to a limited subset of projects this week. Over the course of the next several weeks, we hope to implement the additional UI features that will display relevant information about the issue forks back in the Drupal.org issue, and ultimately allow merge requests themselves.

We hope to have the beta of merge request functionality available to some projects no later than DrupalCon Global, in Mid-July. From there, we'll work through feedback from our beta testers, and work with Drupal core maintainers, to enable issue forks for all projects in the coming months

How can you get involved?

As a module maintainer, please leave a comment on this issue with the list of your project shortnames that you'd like to opt-in.

Please note that not all projects will necessarily be selected for the beta trial.

Issue fork drupalorg-3152637

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:

    Support from Acquia helps fund testing for Drupal Acquia logo

    Comments

    hestenet created an issue. See original summary.

    hestenet’s picture

    Issue summary: View changes
    singularo’s picture

    Happy to beta/trial on:
    stratoserp
    shepherd

    jonathanshaw’s picture

    Very happy to beta on xero_sync. Surprised not more replies here, I'm really looking forward to using this as a contributor.

    mglaman’s picture

    It'd be great to try with Drupal Commerce.

    dww’s picture

    Not that there's much dev traffic, but I'd be happy to give this a spin at least at:
    https://www.drupal.org/project/views_taxonomy_term_name_into_id

    I'm asking co-maintainers about a few others actually in use (address, datetime_extras, etc) and will reply here once there's confirmation.

    You could do these, too, but seriously no one uses them but me (from what I can see):
    https://www.drupal.org/project/entity_reference_number_widget
    https://www.drupal.org/project/toolbar_responsive_search

    ;)

    Excited to see this coming together!

    Thanks!
    -Derek

    benjifisher’s picture

    I maintain a few small projects:

    • typogrify
    • ptoc
    • multicolumn
    markie’s picture

    Beta trial on smart_trim please.

    DamienMcKenna’s picture

    A *huge* thank you to everyone who has worked on this effort, it's greatly appreciated!

    I'd be happy to test this on the Metatag project.

    bobbygryzynger’s picture

    Thanks all! I would be happy to test this on shopify.

    NickDickinsonWilde’s picture

    I'd love to opt in for EVERYTHING, but reasonably:
    - views_slideshow
    - field_states_ui
    - entity_redirect

    zoiosilva’s picture

    Very interesting, seems to be the right way to go. I wonder if it would be possible to point to "fork versions" of the module using composer.

    Greg Boggs’s picture

    easy_breadcrumb
    config_suite
    styleguide
    author_pane
    alinks

    drumm’s picture

    Very interesting, seems to be the right way to go. I wonder if it would be possible to point to "fork versions" of the module using composer.

    This won’t be possible. Packages.drupal.org only has metadata for releases made by maintainers. And there’s a chance you’ll want to combine changes from multiple issues, so no single fork will have everything you need for deployment.

    I recommend still using https://packagist.org/packages/cweagans/composer-patches. If the changes you want from an issue are in a single commit, you can get the plain diff from GitLab like https://git.drupalcode.org/issue/drupalorg-3071681/-/commit/5e4cc03e8b3c.... GitLab does not support arbitrary diffs yet: https://gitlab.com/gitlab-org/gitlab/-/issues/15593. So for changes with more commits, you’ll need to make and store the diff locally. That isn’t a bad idea overall, less reliance on 3rd parties for builds is always nice.

    Maintaining your own local fork of the repository for deployment, combining changes from multiple issue forks, is also possible.

    drumm’s picture

    stratoserp, shepherd, xero_sync, commerce, views_taxonomy_term_name_into_id, entity_reference_number_widget, toolbar_responsive_search, typogrify, ptoc, multicolumn, smart_trim, metatag, shopify, views_slideshow, field_states_ui, entity_redirect, easy_breadcrumb, config_suite, styleguide, author_pane, alinks are all now opted in. Please follow up here if I managed to miss any, or if there are more to add.

    I’ve done an initial pass at the documentation at https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer..., which is linked from the bottom of each Issue fork block. In particular, you may need to nudge contributors to still post patches to the issue queue for DrupalCI testing until #3072048: Test merge requests made in GitLab with DrupalCI is done.

    Any followups on the functionality will be best at #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces, or one of its child issues. Ideas for merge requests can go to #2205815: Merge requests in Drupal.org issue queues?.

    drumm’s picture

    Issue summary: View changes

    (Minor update to issue summary)

    alexmoreno’s picture

    Happy to beta test it in webp as well

    Thanks, exciting times 😊

    drumm’s picture

    webp has them now too.

    dww’s picture

    Thanks, @drumm, this is very exciting!

    I got confirmation for both of these, too:

    Cheers,
    -Derek

    drumm’s picture

    address & datetime_extras are done!

    ChristianAdamski’s picture

    I'd like to take part in the beta as well with

    Geolocation module

    Thanks!

    drumm’s picture

    Added geolocation too

    mahmoud-zayed’s picture

    Happy to beta test it on bootstrap_layout_builder

    mglaman’s picture

    Requesting commerce_api as well, as we're actively developing there

    drumm’s picture

    Issue forks have been added to bootstrap_layout_builder & commerce_api

    nicoloye’s picture

    Hello, happy to beta test it on forms_steps.

    Thanks !

    andypost’s picture

    Masquerade module already trying to use issue branch, so requesting testing here

    drumm’s picture

    forms_steps & masquerade can now use issue forks.

    Issue forks have their basic functionality working now, and we’re officially moving into working to enable merge requests: #2205815: Merge requests in Drupal.org issue queues?

    andypost’s picture

    @drumm Thank you!

    Now it looks like old branches are not compatible with new forks or the old "workspaces" block could be removed
    Example in right sidebar https://www.drupal.org/project/masquerade/issues/2923845

    voleger’s picture

    I also can try to test new fork flow on toolbar_language_switcher module

    ressa’s picture

    Great news! I heard about it via @mglaman's blog post Trying out issue forks on Drupal.org!, and it looks like the initiative wasn't announced on Planet Drupal. Perhaps intentionally, since it is in Beta? Otherwise, announcing it on Drupal Planet would probably increase the number of participants, if that is desired.

    Also, perhaps consider updating "Pull/merge request" in the graphics to "Merge request", since that is what Gitlab use, and also what is used in the text on this page?

    hestenet’s picture

    Hm! The post definitely went out on the Drupal.org blog- https://www.drupal.org/drupalorg/blog/developer-tools-initiative-part-6-...

    Are we sure that didn't make it to Planet?

    djdevin’s picture

    ressa’s picture

    Sorry, you're right @hestenet, it's on page 2 of Drupal Planet ("Developer Tools Initiative - Part 6: Update on Merge Requests" 17 Jun 2020 at 21:03), with a link to this issue. I was looking for the title of this page, which is of course an issue, and not a blog post :-)

    drumm’s picture

    toolbar_language_switcher & quiz now have issue forks!

    Now it looks like old branches are not compatible with new forks or the old "workspaces" block could be removed

    That block has branches made in the project repository, which might differ from the issue fork. People working in the issue fork might want to use those branches in the issue fork, and they are still useful to know about. As a maintainer of a project, using feature branches without merge requests might remain as a useful part of some workflows.

    voleger’s picture

    that would be nice to have an option to generate the full git command with remote URL and proper remote name.

    Fewer interactions with sidebar would be better for newcomers and will save few seconds in general.
    Now I have to copy remote-name and remote URL separately (one interaction to expand the Clone block and 2 copy interaction).

    I also noticed that now a maintainer would work more with different remotes on the single project, so I propose adding a recommendation to rename "origin" remote name to "< project_name >" remote name. This will reduce possible unintended pushes to the wrong repo during the work on multiple projects.

    drumm’s picture

    I opened #3155137: Add full Git commands for working with issue forks to follow up on adding instructions. I’ve made an initial pass at documenting best practices at https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer.... They could use additional work and real-world use before adding them to the UI.

    drumm’s picture

    colorbox_field_formatter, config_auto_export, dimension & wysiwyg_template now have issue forks enabled.

    hussainweb’s picture

    johnzzon’s picture

    We'd be extremely happy to test this on https://www.drupal.org/project/layout_builder_modal

    opdavies’s picture

    drumm’s picture

    do_username, wordpress_db_migrate, layout_builder_modal, override_node_options, copyright_block, tailwindcss, null_user, system_user all now have issue forks enabled, thanks!

    opdavies’s picture

    Thanks Neil.

    andrewmacpherson’s picture

    I'd like to try this on migrate_devel module, please. There's an issue there which I'm considering a few different approaches for, so the multiple branch aspect of issue forks will be interesting to try.

    hussainweb’s picture

    Thank you @drumm!

    With a very basic trial, I see two things.

    1. Give commands we can copy/paste to pull the changes as a branch in the repo. I see you have already created an issue for this at #3155137: Add full Git commands for working with issue forks.
    2. Clarify the reason and usage for "New branch".

    Right now, this appears immediately once we click "Fork [project]". It kinda implies that we should click that to create a new branch. My first thought is why even have this option. In most cases, we have a patch build upon a previous patch, so a single branch should be enough. That said, there are some reasons for having multiple branches:

    1. Rebasing, but even merging the main branch into the issue fork branch would give similar results.
    2. Trying out an entirely different approach.

    Now, the second point is not frequent but still a valid reason to have this functionality. I would suggest we could improve the UX around this to clarify how maintainers could use the feature. How about something like this?

    1. When someone clicks "Fork [project]", a fork for the issue is created along with a separate branch. The branch name could be the same as the issue number. It could (optionally) be prefixed or suffixed with the issue branch so that the maintainer knows the target branch from the branch name.
    2. The "New branch" option should still be there but in most cases, we never have to use it.
    3. Give per-branch commands that the contributors can copy/paste to pull in changes for each of the branches.

    Another thing I'm wondering: Do these issue forks get cleaned up once the issue is closed or at some other point?

    ressa’s picture

    PS. I still think the graphic could benefit by getting updated from "Pull/merge request" to "Merge request", since that is what Gitlab use.

    Bhanu951’s picture

    I would like to try it on my sandbox project.
    Please enable access to it.

    https://www.drupal.org/sandbox/bhanu951/3103712

    drumm’s picture

    migrate_devel & sandbox/bhanu951/3103712 are now opted in.

    1. When someone clicks "Fork [project]", a fork for the issue is created along with a separate branch. The branch name could be the same as the issue number. It could (optionally) be prefixed or suffixed with the issue branch so that the maintainer knows the target branch from the branch name.
    2. The "New branch" option should still be there but in most cases, we never have to use it.

    Opened #3155690: Add new branch on issue fork creation for this.

    Another thing I'm wondering: Do these issue forks get cleaned up once the issue is closed or at some other point?

    There will be a lot of information in intermediate commits, comments on those, comments on the merge request, etc, that could be useful for digging into followup issues. And while non-ideal, patches do get deployed to production sites, we don’t want to break everyone’s builds right away.

    The issue fork itself is relatively cheap, GitLab doesn’t make a full copy of the project repository’s history. Other data will pile up, and potentially become large or cumbersome, we’ll have to wait and see how it behaves under real use. Removing issue forks for closed (fixed) issues after some number of weeks or months is likely in the long run.

    smccabe’s picture

    commerce_fraud plz

    voleger’s picture

    Also noticed that would be helpful to have two links on the commit comment message:

    - first is the link to the diff on Gitlab UI between commit and source repo branch; No glue for now how to generate the link to the diff without merge requests enabled.

    - another link available if it's not the first commit. This link will follow the user to the diff page between the commit and previous commit within the forked repo. https://git.drupalcode.org/issue/{fork_id}/-/compare/{previous_commit_hash}...{commit_hash}

    So in the result the commit comment message would be provided automatically with two diffs

    - first diff will show the compatibility with upstream branch, and it woul be actual patch if no conflicts would be provided. So that patch can be downloaded from the Gitlab UI and uploaded to the issue be page for the testing purposes.

    - second - classic interdiff between the patches commits

    dpi’s picture

    Requesting for preview_link since there is active development.

    drumm’s picture

    commerce_fraud & preview_link are now opted in.

    voleger - I noted your comment at #3071681: Decide what information about issue forks to show on issue page on Drupal.org, implement.

    For now, I’m concentrating on enabling merge requests and fixing any bugs, then I’ll come back and do another pass at the UI.

    kristiaanvandeneynde’s picture

    Hell yeah, sign me up! Group and Subgroup please.

    drumm’s picture

    group & subgroup now have issue forks enabled.

    jsacksick’s picture

    Hey, could you opt in commerce_paypal and commerce_shipping please?

    plopesc’s picture

    Could be possible to have it enabled in https://www.drupal.org/project/migrate_default_content?

    Thank you

    drumm’s picture

    commerce_paypal, commerce_shipping & migrate_default_content now have issue forks enabled.

    drumm’s picture

    #3071755: Show merge request activity on www.drupal.org issues & #3071752: Enable ability to open merge requests for branches in issue forks are going well. We should be able to do initial enabling of merge requests for the beta projects as soon as tomorrow. I’m planning to update those issues with details, and open followup issues to track a few backlogged items, before enabling them.

    drumm’s picture

    Merge requests are now enabled for the beta projects. Notably, DrupalCI testing is still in our backlog: #3072048: Test merge requests made in GitLab with DrupalCI

    Other feedback around merge requests, and the rest of our backlog is at #2205815: Merge requests in Drupal.org issue queues? & #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces

    mandclu’s picture

    Would love to try this for my projects, especially smart_date

    hussainweb’s picture

    Can I also ask to enable this on my new project: preloader? I am working on that at the moment and could test the functionality there.

    tedbow’s picture

    Exciting!

    I would like to opt-in on https://www.drupal.org/project/role_notices

    Thanks!

    nkoporec’s picture

    Would love to try it out on: https://www.drupal.org/project/sitemeta

    Thanks!

    energee’s picture

    sanduhrs’s picture

    dipakmdhrm’s picture

    This is amazing!
    I'd love to Opt-in for:

    1. asymmetric_menu_trees: https://www.drupal.org/project/asymmetric_menu_trees
    2. flexible_add_more_widgets: https://www.drupal.org/project/flexible_add_more_widgets
    3. media_thumbnail_url_formatter: https://www.drupal.org/project/media_thumbnail_url_formatter

    Thank you!

    drumm’s picture

    smart_date, preloader, role_notices, sitemeta, adminimal_admin_toolbar, rdfui, openid_connect, asymmetric_menu_trees, flexible_add_more_widgets & media_thumbnail_url_formatter all now have issue forks enabled. Thanks for testing out this new functionality.

    voleger’s picture

    Noticed that there is no possibility to change the issue status from the related merge request page.
    Is it possible to synchronize the merge request label's definitions with the related issue field values?
    Let's say, I had reviewed proposed changes and wanna change the issue status to RTBC, so I can just set the appropriate label in the merge request page, and in the result related issue has updated issue status.

    scuba_fly’s picture

    I would like to opt-in the following projects:

    cocoon_media
    elui
    social_media

    fabianderijk’s picture

    yannickoo’s picture

    I would like to opt-in for following modules:

    Thanks! :)

    drumm’s picture

    Issue forks are now enabled for bbb, filefield_paths, upgrade_check, email_nd, menu_item_extras, taxonomy_access_fix, gin, gin_toolbar, gin_login, graphql_twig, graphql_responsive_image, paragraphs_modal_edit, fortytwo, flood_unblock, rest_menu_items, o365, linked_field, menu_link_attributes, view_mode_selector, social_media, elui, cocoon_media

    Noticed that there is no possibility to change the issue status from the related merge request page.
    Is it possible to synchronize the merge request label's definitions with the related issue field values?
    Let's say, I had reviewed proposed changes and wanna change the issue status to RTBC, so I can just set the appropriate label in the merge request page, and in the result related issue has updated issue status.

    Yes, we’ll need to figure this out. Another consideration is which merge request is the agreed upon solution for the issue. With patches, the best patch is occasionally not the most-recently-uploaded, and people end up re-uploading it again just to make that the latest patch. We don’t want to repeat that.

    DamienMcKenna’s picture

    Something I noticed: while comments on merge requests are posted back to the issue, they are not delivered via email to the issue's followers. That said, it does send a message when a new pull request is created, so it's a step forwards. I'll open a new issue about this.

    wizonesolutions’s picture

    I would like to opt in for:

    fillpdf
    commerce_recurring_metered
    commerce_recurring_pcui

    WidgetsBurritos’s picture

    I would like to opt in these two modules:

    drumm’s picture

    web_page_archive, performance_budget, commerce_recurring_pcui, commerce_recurring_metered & fillpdf now have merge requests enabled.

    Kgaut’s picture

    I'd like to optin also for this module :

    apidae_tourisme

    drumm’s picture

    apidae_tourisme now has issue forks enabled.

    matthieuscarset’s picture

    I'd like to opt in for these modules please:

    codekarate’s picture

    I'd like to optin for the gatsby module please.

    drumm’s picture

    menu_manipulator, menu_manipulator_sitemap, twitter_api_block, block_user_info, and gatsby now have issue forks enabled.

    grahl’s picture

    Please enable it for crm_core, ldap, ldap_sso and rokka. Thanks!

    drumm’s picture

    Issue forks are now enabled for crm_core, ldap, ldap_sso & rokka

    tunic’s picture

    We would like to opt in for the GA Push module, please.

    Thanks!

    drumm’s picture

    Issue forks are now enabled for ga_push!

    bserem’s picture

    drumm’s picture

    Issue forks are now enabled for project_issue_file_test, pace, admin_feedback, rua & commerce_winbank_redirect

    bserem’s picture

    Great, thanks!

    brianperry’s picture

    I'd be interested in opting in for ui_patterns_pattern_lab. Thanks!

    drumm’s picture

    ui_patterns_pattern_lab now has issue forks enabled.

    mglaman’s picture

    Would 💙 to add this to commerce_avatax

    drumm’s picture

    commerce_avatax now has issue forks enabled.

    alison’s picture

    Hi! Would love to opt-in "nodeaccess", please!

    Thank you so much!

    nod_’s picture

    Could you add the pwa module please?

    Balu Ertl’s picture

    I’d love to help this workflow integration efforts by reporting feedback with my following contrib modules:
    config_partial_export
    config_single_export
    l10n_tm
    l10n_terminology_long
    l10n_terminology_short

    drumm’s picture

    config_partial_export, config_single_export, l10n_tm, l10n_terminology_long, l10n_terminology_short, pwa & nodeaccess now have issue forks enabled.

    Grimreaper’s picture

    Hello,

    Could you please add the following modules?

    - Context Profile Role
    - File Extractor
    - Image Styles Mapping
    - CMIS API
    - Entity Share
    - Entity Share Cron
    - Entity Visibility Preview

    Regards,

    • drumm committed 6ff7fd7 on 7.x-3.x
      Issue #3152637: Allow opting-in individual issues for issue forks
      
    drumm’s picture

    context_profile_role, file_extractor, mage_styles_mapping, cmis, entity_share, entity_share_cron, and entity_visibility_preview now have issue forks enabled.

    For core, we are going to beta test with a small number of individual issues to make sure everything is working. The first issue is #3151676: Remove unnecessary calls to drupal_get_path(), replace with __DIR__

    renatog’s picture

    Please can you add it on Modal Page?

    https://www.drupal.org/project/modal_page

    Thanks a lot

    bserem’s picture

    We've been testing FORKS and MRs in my team (the first impressions are really good) and I'd like to point out something that might not be clear to everybody:

    Gitlab does generate a Patch file for one commit, which is easily accessible with a URL (that can be added to Composer for example):
    patch files on gitlab

    The same is true for a merge request, just a bit harder to find a first:
    patch file on gitlab from merge request

    Luckily enough it seems that the patch filename doesn't change when the MR gets more commits, but the contents do. So people will always get the updated version in their composer patches using the same URL to the patchfile (which could also lead to other issues!).

    @drumm Should we document this in the top of this issue or shall I add it to the docs page here: https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer...

    Grimreaper’s picture

    @drumm, Thank you :)

    drumm’s picture

    modal_page now has issue forks enabled.

    bserem - Please go ahead and edit https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer..., thanks! This issue summary is effectively temporary and won’t be updated once issue forks are enabled for all projects.

    bserem’s picture

    Done, here is the link with instructions on getting patch files from Gitlab to be used with Composer (or other tool):
    https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer...

    a-fro’s picture

    We'd be happy to test with recent modules we've been working on:

    https://www.drupal.org/project/collection
    https://www.drupal.org/project/erf

    drumm’s picture

    collection & erf now have issue forks enabled.

    AaronBauman’s picture

    Just came to this thread after seeing merge requests had been enabled on gitlab - exciting!
    Please opt-in to issue forks for https://www.drupal.org/project/salesforce

    thanks drumm!

    drumm’s picture

    salesforce now has issue forks enabled.

    mattshoaf’s picture

    I'd like to sign up for the beta: webform_myemma
    Thanks!

    markie’s picture

    +1 on adding how to get a patch URL for composer out of a merge request / commit to the documentation / issue description. That was a great find.

    krlucas’s picture

    Please enable Google Analytics Event Tracker for issue forks:
    https://www.drupal.org/project/google_analytics_et

    jwilson3’s picture

    Probably the wrong thread to discuss this, but tbh not sure of a better place to comment this, that would get eyeballs:

    Luckily enough it seems that the patch filename doesn't change when the MR gets more commits, but the contents do. So people will always get the updated version in their composer patches using the same URL to the patchfile (which could also lead to other issues!).

    Isn't this inherently a bit reckless? Most people use cweagans/composer-patches these days to link to a patch from Drupal.org If the patchfile gets updated magically, then each time a build tool builds a deployable artifact, you could be deploying unvetted code. (Eg, Imagine someone accidentally committing a syntax error to a patch -- an unfortunately timed release could cause an unpredictable 500 error causing at the worst a production site downtime, and at the least a developer scratching their head scrambling to track down and back out something potentially completely unrelated to the intentional code changes in the release that broke unexpectedly).

    AaronBauman’s picture

    Isn't this inherently a bit reckless? Most people use cweagans/composer-patches these days to link to a patch from Drupal.org If the patchfile gets updated magically, then each time a build tool builds a deployable artifact, you could be deploying unvetted code

    Yes, most users probably don't want to run with MR-patches from gitlab.
    commit-patches are fine, since they will not change.

    If you need patches from more than one commit, either upload the patch to the issue or add it directly to your project, per
    Drumm's suggestion in #14:

    I recommend still using https://packagist.org/packages/cweagans/composer-patches. If the changes you want from an issue are in a single commit, you can get the plain diff from GitLab like https://git.drupalcode.org/issue/drupalorg-3071681/-/commit/5e4cc03e8b3c.... GitLab does not support arbitrary diffs yet: https://gitlab.com/gitlab-org/gitlab/-/issues/15593. So for changes with more commits, you’ll need to make and store the diff locally. That isn’t a bad idea overall, less reliance on 3rd parties for builds is always nice.

    Maintaining your own local fork of the repository for deployment, combining changes from multiple issue forks, is also possible.

    drumm’s picture

    google_analytics_et now has issue forks enabled.

    voleger’s picture

    I would like to opt-in the following projects:

    - pmfs
    - queue_ui

    Thank you!

    drumm’s picture

    Issue forks are now enabled for pmfs & queue_ui.

    fgm’s picture

    Is it possible to have issue forks enabled for "dfp" ? I'm a not the maintainer of the module, but there's a pending D9 port issue which has been RTBC for months and having a fork would enable sites to reference the fork until the maintainers commit the D9 version to the mainline.

    Retracted: @Gábor Hojtsy suggested a better approach, using branch aliases.

    drumm’s picture

    Issue forks are now enabled for those core issues. #3167029: Opt-in core issues into the Drupal.org Issue Forks and Merge Requests Beta is the main issue for opting in core issues.

    Gábor Hojtsy’s picture

    @fgm: Matthew Grasmick (my boss) who originally documented his use of composer version aliases (at https://matthewgrasmick.com/posts/screencast-updating-drupal-9-15-minutes) told me yesterday he does not suggest those anymore, given that tricking composer to thinking Drupal 9 is Drupal 8 could cause other issues. He also said issue forks would indeed be the best intermediate solution for now until a project lands their Drupal 9 patch. That is not widely possible at the moment due to the feature being in the testing phase.

    fgm’s picture

    @Gábor Hojtsy thanks for the heads up. For now, this solved our issue, but I'll keep an eye on this issue to switch to issue forks when they become available for those lagging modules the maintainers don't update.

    Mixologic’s picture

    Issue forks do not show up at packages.drupal.org, so even if you had one enabled it would not help with the d8->d9 situation.

    DamienMcKenna’s picture

    .. but you could use git to download the fork..

    Gábor Hojtsy’s picture

    @Mixologic yeah it would be more like what @DamienMcKenna suggests, the "Require Any Git Repository with Composer" section from https://www.daggerhart.com/composer-how-to-use-git-repositories/ let's say, where you specify the metadata for composer and pull in the git repo. The git repo for the fork would mean there is a canonical repo for the Drupal 9 port in progress and no need to fork it on github, etc. Maybe at that point https://github.com/cweagans/composer-patches would work to patch the repo as well locally and thus no need for the fork git repo necessarily? That would be a good discussion for #3168047: Commit Project Update Bot patches to under-maintained projects for Drupal 9 compatibility.

    hestenet’s picture

    Issue summary: View changes

    Updated issue summary to note that we intend to push issue forks and merge requests to general availability across all projects on November 10th.

    You may still request an opt-in to the beta period in the meantime.

    hestenet’s picture

    Issue summary: View changes
    hestenet’s picture

    Issue summary: View changes
    svenryen’s picture

    Hi! We're going to undertake a major rewrite of EU Cookie Compliance and start working on a version 2.0. Would be really cool if we can be part of the beta.

    drumm’s picture

    EU Cookie Compliance now has issue forks enabled.

    frob’s picture

    I would like to try this with:

    speedboxes
    google_analytics_et
    google_analytics_lite

    drumm’s picture

    speedboxes & google_analytics_lite now have issue forks enabled. google_analytics_et already had issue forks.

    batigolix’s picture

    Would be happy to help testing with this project:
    - https://www.drupal.org/project/flood_control

    fabianderijk’s picture

    Would love to join with the flood_control module!

    drumm’s picture

    flood_control now has issue forks enabled.

    jhodgdon’s picture

    I'd like to opt in with the following projects:
    https://www.drupal.org/project/honey [it's a theme project, hope that is OK]
    https://www.drupal.org/project/config_update

    Thanks!

    Also I just updated this docs page:
    https://www.drupal.org/docs/develop/git/git-for-drupal-project-maintaine...
    and recently have also made this one:
    https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa...

    The new one is for maintainers; the older one is for all contributors.

    drumm’s picture

    Issue forks are now enabled for honey & config_update

    jrglasgow’s picture

    drumm’s picture

    Issue forks are now enabled for saml_sp.

    mxr576’s picture

    I'd like to opt-in with https://www.drupal.org/project/mjml

    drumm’s picture

    mjml now has issue forks enabled.

    eelkeblok’s picture

    drumm’s picture

    fragments & drush_lock now have issue forks enabled.

    vdsh’s picture

    drumm’s picture

    leaflet_geojson, geocluster & libraries_delay_load now have issue forks enabled.

    drumm’s picture

    Status: Active » Fixed
    Related issues: +#3078139: Enable issue forks for all projects

    Issue forks are now enabled for all issues. Thanks for testing them out on your projects!

    TR’s picture

    Um, how do I opt OUT of this?

    This was rolled out with no notice to contributed project maintainers, without a change record, and with incomplete and outdated documentation (e.g. https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer...).

    I am not interested in changing the workflow for my projects at this time.

    hestenet’s picture

    Hi @TR

    There is no way to opt out of the feature, however, I will note that the existing patch workflow and all of the testing configuration for patches still work exactly as they always did, at least for now.

    If someone makes a merge request on an issue but you'd rather treat it as a patch, you can also still get a plain text diff and work with it that way.

    Opening a merge request and using those is only an additional feature on top of these issues.

    As far as communication goes:

    Yes - you are correct that we did not do an all-maintainer email. I will rectify that today and get one sent out with links to the documentation. We set the date in collaboration with core maintainers, and we did do notification in a few places:

    • The issue summary at the top of this issue and the other related issue have a large banner indicating today is launch day.
    • There is a change record here: https://www.drupal.org/node/3181553
    • We've tweeted several times.
    • We've mentioned it in Drupal Slack several times.
    • We talked about this beta in the what's new on d.o blog posts in August and Sept (although the date wasn't set at the time).

    I'll get a notification email for maintainers drafted to be sent directly, with links to the CR and documenation.

    hestenet’s picture

    I meant to include documentation links in that last comment. Here they are (from the change record):

    And yes! They absolutely do need additional updating - and it would certainly be appreciated if anyone who participated in this beta would help to do so.

    TR’s picture

    Change record was still a *draft* when I posted #149; it was only published after my post, and it was only created yesterday.

    By "incomplete and outdated documentation", I gave a specific example where the documentation is still tagged as "incomplete" and the content of that documentation described this feature as not finished - "in active development and being tested with some projects". You have changed some of that content since my post in #149.

    Yes, I have been aware of this work in progress for some time, and I deliberately did NOT opt-in when this issue was opened back in June. The communications I've seen all portray this as "opt-in" to allow developers the ability to use this workflow. It's talked about as an *option*. Noticeably absent is discussion about how the larger community will be impacted by this change - sure, a lot of developers will appreciate this feature, but a lot more would appreciate it more if it were optional, because we all have our preferred sets of tools. And the rest of the community (the majority) will look at this as yet another huge impediment towards contribution.

    What has not been adequately communicated is that this feature would become mandatory for everyone at some point. While I have no objection to this feature being used where it is wanted, having it forced on us is another matter. There is a larger issue about whether this continued race towards an even more developer-centric Drupal is beneficial to the community. The vast majority of users can't even contribute anymore, and making this forking feature mandatory makes that situation worse.

    dww’s picture

    There's nothing forced here on anyone. Projects can (and some probably will) continue to be entirely patch based. If you want to put a note on your project page(s) and/or in the help text for issues in your queue(s) saying "I'm not going to look at merge requests, please only upload patches.", that's 100% your call. You can even add that to the default issue template for your project if you want. ;) Folks might create issue forks for some of your issues, anyway. You don't have to look at them. If folks would rather collaborate via a git repo and you just see the stream of activity in your issues like they were uploading patches, cool. If you never want to create an issue fork or work that way, you don't have to. Until you run into a project maintainer that will *only* accept a MR, in which case, at least they're still on d.o at all and didn't move to GitHub or Gitlab or whatever. That'd definitely be forcing a different workflow on you. This change is meant to help prevent that.

    And yes, the docs for this (and nearly every part of Drupal) always need more help. :)

    And yes, the notifications don't always go out early enough for everyone's liking... thanks for raising the alarm and helping to instigate the notifications we did get.

    Cheers,
    -Derek

    hestenet’s picture

    @TR - I don't know how to correct the misconception that this was going to be a per-project optional feature after it left beta. This has to be one of the most overcommunicated features in the history of Drupal.org, apart from the maintainer wide emails (you were correct on that front, one at the beginning of beta setting expectations would have been appropriate).

    I'm certainly willing to discuss this further with you, and get feedback with any other users who agree - though I think we should perhaps do so in the meta, since this thread was specifically related to the beta process for this feature.

    The larger meta is here: #2488266: [META] Improve Git workflow on Drupal.org by implementing issue workspaces

    Status: Fixed » Closed (fixed)

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