https://nf-co.re logo
Join Slack
Powered by
Goooood morning! What do our fantastic maintainer...
# team-maintainers
j
Goooood morning! What do our fantastic maintainers think about this RFC from @Edmund ? https://github.com/nf-core/proposals/issues/49 TL;DR Switch from dev branches and occasional merges into main (git flow), to regular PRs directly into main The advantages @Edmund is espousing is while it increases review burden slightly (every PR to main still maybe requires 2 reviews), it will hopefully force people to do much smaller PRs (beause no-one likes massive PRs, and it scares people off from vollunteering reviewing) and generally will increase reviewing frequency across the community - so you'll have a much greater chance of rapidly finding a reviewer.
m
I like this idea
n
I think this is worth testing out with one pipeline first as I'm not sure what the exact effect will be in our community
j
The issues is I don't think we will see the effect on a single pipeline
One pipeline could do it but then no-one is willing to review so often
n
Also a valid point 🤔 I'm just a bit worried this will be quite chaotic if we release it for all pipelines at once
j
Why so?
Tell me your thoughts
n
This is a pretty big change to the development flow of nf-core and as we are with a loooot of pipeline developers makes me think that some people might miss this change at all and be really confused about it
But that's mainly a communication issue
j
Yeah, I don't htink there is really any infrastructure change other than branch protection, right?
n
A gradual adoption might be better in this case IMO
👍 1
👍🏻 1
So start with a couple pipelines so we have some nice examples and slowly push the system on other pipelines in due time
That way we also have some nice test cases with people that are in the loop 😛
m
For me, we should aim to be better, not only in the code we write, but in the way we write the code too
👍 2
f
I would just love automated CHANGELOG creation - i have this in another project where we just take care of goo PR titles and then they go into the CHANGELOG automatically.
party this 2
👍 2
👍🏻 1
j
OK fine maybe this is one for #C070369GP7T because we are awesome then
m
@Famke Bäuerle we have a github action for tools to do automated changelog updates. You should be able to copy most of the logic for your pipeline(s)
m
Could we have this i nthe TEMPLATE?
this 1
m
Probably but I am not sure if I am ready to test another github action development cycle 😄
this is fine fire 1
🐕 1
p
Automated changelogs typically rely on having good PR hygiene - not something that we've felt confident about community-wide in the past before, which is why it hasn't already made it into the template
👍 1
eg. using PR titles and similar
Maybe we could use an LLM to look at code changes and write automated PR titles or something, to have better quality changelogs without changing people's behaviour, but it starts to get complicated then..
ai thumbsdown 3
(or a CI check that makes sure that PR titles follow conventions and are somehow descriptive enough)
Anyway, off topic sorry!
On the OP to reiterate my thoughts, I'm not sure that changing the branching behaviour will necessarily fix all ills, and I'm worried it'll cause more problems than it solves.
💯 1
But I do agree that we should try to explore other ways to make PRs more atomic and reviewable
this 1
j
@Maxime Garcia maybe we need to resurrect the gamification/currency idea...
🙏 1
m
Stacked prs might also help, but graphite doesn't really support our kind of community nicely
j
What is graphite?
m
p
I have Cursor set up to review on MultiQC, I've been quite impressed with it's reviews so far. eg. it caught this earlier today.
But standard Python project might get better reviews than nf-core..?
I can look into getting Seqera to foot the bill for Claude to review nf-core reviews if we think that would be worth it 🤔 (maybe start with just a couple of repos to sanity check the cost first).
If we can write up really good review instructions for claude to work off, I could see that being quite useful.
m
The automation I’d welcome is something that creates a GitHub release for every push to 
main
, taking the changelog as the body of the release post.
p
shared a GIF
We talked about doing that before but were worried that it's quite a lot of magic and would be easy to make errors with
I wonder if we could do something with a github action that runs on 
workflow_dispatch
though 🤔
Runs AWS megatests, pulls in the changelog and commits it to 
dev
etc, once all tests are passing and everything looks good, it automatically merges to 
main
and creates the release
That way it's more explicit, UI-based for the release and has more safeguards as can chain required CI
this 1
👍 1
j
I would like a 'realeae' button
And then wire it up to a big red USB button
f
smashing red button
💯 2
j
And then could face release parties at the end of Hackathons where each team can come up to a podium and hit the button for their respective pipeline 🤣
m
Sign me up
and it raises the nf-core flag
n
oh oh and fireworks?!
e
I love where this is going!
@Nicolas Vannieuwkerke, I 100% agree. This is not going to be an overnight change. I think #C070369GP7T would be a fine place to start if you want @James Fellows Yates and ping in #C069B2Z5P1R when things break or don't work the way you'd expect. I think it'd be nice to just call it main, and then we could denote that way, but we already did the whole main branch migration.
The automation I’d welcome is something that creates a GitHub release for every push to 
main
, taking the changelog as the body of the release post.
I think releasing every push to main is a bit much and might just be a lot of noise. But what I am thinking is that every push to main(for pipelines past 1.0.0), we can run one mega test—just a default launch that makes sure it runs on AWS and keep it under five bucks for the pipeline run. I think each of those could be really valuable. Then we can do all the different pathways you want to test, etc, on Megatests for releases.
j
I think releasing every push to main is a bit much and might just be a lot of noise.
Not if we stick with the current gitflow system
👍 1
I think this would be a reasonable parital work around to make releasing itself more palatable?
p
No love for my github-actions idea? sadpanda
Problem with pushing to main is that all automation has to go after that happens. So if tests fail etc etc. then it's too late, it's already merged.
💯 1
🤷🏻‍♂️ 1
j
Um @Phil Ewels it was the most popularn one so far 😉
yay wait 1
Open in Slack
PreviousNext
Powered by