I’ve opened a PR for the nf-core/pacvar pipeline on the dev branch:
After requesting help in the Slack #pacvar and #review-request channels, I haven’t been able to get feedback for over two weeks. I suspect the main issue may be the size of the PR. Many of the changes accumulated over time as I added new features in my fork and tried to address multiple issues at once, and I didn’t initially realize how many commits and file changes had built up.
Most of the changes are related to module upgrades and compliance with the nf-core template v3.5.1. The core workflow-related changes are primarily confined to workflow/pacvar.nf, along with the addition of new local subworkflows to support structural variant and copy-number variant calling.
I’d appreciate advice on how best to proceed. Should I continue to follow up with the lead developer, or would it be preferable to split this into multiple smaller PRs? Breaking it up would require a significant time investment (on the order of several weeks), but I’m willing to do so if that’s the recommended path forward. Any guidance would be very welcome. Thank you.
Describing what’s in the PR really helps, and pointing the reviewers towards the files with the main changes. In the future, aim for smaller releases, for example every time a template update is out, together with any (even small) PRs you might have until then, make a release PR.
Let me have a look tomorrow morning!
Thank you very much again. This has been a valuable learning process for me, and I truly appreciate your comments and guidance. I’ve updated the PR comments to include additional details.
The PR is too large to review effectively. 200 files & 76 commits.
An indication of this is that github is unable to render the PR properly (“Single file mode Due to the size of this pull request, only one file can be shown at a time.”
Another issue is that is crosses many domains, you’re unlikely to find someone who can provide constructive advice on both devcontainers, github actions, pre-commit hooks and bio informatics pipelines.
Personally what i would do is:
Keep your branch as a reference
Identify a small area of functionality (say your devcontainer changes just because I see them at the top) and put them into their own small branch, newly created off of the master branch, and open a PR for just that
These can be reviewed quickly and easily
Once that PR is merged, rebase your personal reference branch on the updated master and observe that your branch now differs from master slightly less.
Its a labourous process but you’ll gradually be able to break down this monolithic PR into many small ones
Peter_Kneale, thank you for the valuable comments and for carefully drafting the guidance that helps keep PRs clean and easier for both developers and reviewers. I really appreciate it and learned a lot from this process.