Shared notifications for Bioconda recipe updates

[victorlin]

Brought up by @huddlej on Slack:

I recently created a Bioconda recipe for a tool we developed in the Blab and that I'm the only maintainer for. This made me wonder whether we should add the nextstrain-bot user as a maintainer to all of our Conda recipes, so everyone on the team has visibility into updates?

Tasks

• Create a new @nextstrain-team account (this should be its own issue)
• Add @nextstrain-team to bioconda recipes for @nextstrain: (GitHub search for repo:bioconda/bioconda-recipes "github.com/nextstrain"):
  • augur
  • nextclade
  • nextalign
  • nextclade_js (actually this one should be removed)
  • nextstrain
  • auspice
  • nextclade2
  • nextstrain-cli
• Add @nextstrain-team to bioconda recipes for @blab (GitHub search for repo:bioconda/bioconda-recipes "github.com/nextstrain"):
  • evofr
  • pathogen-embed

⛔️ Previously considered approaches

• Manually keep the lists of individual team members up to date with everyone on @nextstrain/core
  • This is too tedious with all the different recipes and need for individual PRs / manual approval.
• Use @nextstrain-bot
  • This won't work because @nextstrain-bot must be a member of @nextstrain/core to perform its bot duties, and there is no way to receive @mention email notifications for direct tags but not team tags.

[victorlin]

Should we include repos under @blab too? That would be these:

• evofr
• pathogen-embed

[huddlej]

@victorlin It's a good question that I don't know the answer to. The motivation for my original Slack post was to start a conversation about maintaining continuity of software maintenance responsibilities. The Nextstrain team is pretty good about this, but Blab is not always. Part of the reason the repos you mentioned live in blab and not Nextstrain is their origin in blab research projects, so we wouldn't initially expect anyone outside of blab to maintain them.

If we did not want conflate blab and Nextstrain, could we have an analogous @blab-bot? If so, who would get those notifications? Or does it make sense to just make sure that each project's Bioconda recipe has at least two listed maintainers? This could be the subject of a Nextstrain/Blab dev chat.

[victorlin]

I'm not sure if it's valid for Bioconda recipes, but an alternative may be to tag the team @nextstrain/core or @blab/core. These at least show up in GitHub notifications and possibly can be configured for email too.

UPDATE: There's a few recipes with what seems to be teams listed as maintainer. Example: bioconda#15274

Either the team doesn't exist or the tag doesn't work. I'm guessing it doesn't since @blab/core doesn't show up as highlighted here even though it exists.

[victorlin]

Discussed during today's dev chat. I'll add @nextstrain-bot to all Bioconda recipes under @nextstrain and @blab. Even though most of the Nextstrain team doesn't work on the @blab repos, at least we can be notified and redirect that notification to the right people within the lab.

[victorlin]

Another question: should we remove the individual accounts from the list? I'd say yes but would like to confirm with others before removing.

[ivan-aksamentov]

I never knew nextclade_js thing existed O_O

[ivan-aksamentov]

augur: bioconda@fe570e6
nextclade
nextalign
nextclade_js
nextstrain
auspice
nextclade2
nextclade-cli

The last one needs to be nextstrain-cli, I think

[victorlin]

I never knew nextclade_js thing existed O_O

Same... I see both that and nextclade were added by community members early on:

• Add recipe for nextclade Javascript command line tool bioconda/bioconda-recipes#28043
• Add recipe for nextclade C++ bioconda/bioconda-recipes#29160

Is nextclade_js still relevant? Maybe we should submit a PR to remove it.

[victorlin]

Unfortunately @nextstrain-bot can't get emails for @mentions without also getting emails for review requests to @nextstrain/core (and it needs to be a member of that team for its bot duties). Both are bundled under Participating, @mentions and custom:

I think the alternative is to set up a new user like @nextstrain-team solely for the purpose of @mentions. This means @nextstrain-bot needs a new email like <ops|dev>@nextstrain.org to free up hello@nextstrain.org for the new user. While setting up <ops|dev>@nextstrain.org is extra work, it might be useful for other things too such as some emails that currently go to admin@nextstrain.org. There should be a way to use the same email address for multiple accounts.

[ivan-aksamentov]

Is nextclade_js still relevant? Maybe we should submit a PR to remove it.

Not relevant for a long time. Probably even harmful.

[corneliusroemer]

Few points re bioconda, I might be the one with the largest activity on that project

• I'm not convinced the list of maintainers is massively important. The only meaningful impact it has is that autobump tags maintainers when it makes a PR. It doesn't notify when it doesn't find an update, as it did with nextstrain-cli due to pypi path changing. That's when being notified would be particularly useful.
• Potentially, the maintainer list is also useful if a bioconda maintainer has specific questions, as it provides a lost of people to ping

While there's no reason not to add a generic bot account, I do see downsides to removing individuals - I definitely don't want to be removed from any recipes. The nextstrain team is large, and so a single team maintainer is diffuse - much better to have individuals listed there who actually know a bit about bioconda recipes.

Yes, we should remove recipes of no longer maintained/useful tools. The artefacts remain on servers and the recipe remains in git history. But it makes it easier for bioconda maintainers to have one folder less in recipes dir (there are almost 10k)

Potentially more impactful than adding oneself as recipe maintainer would be if some of you became members of the bioconda org with approval rights. I don't remember how I got those bits but it wasn't hard. And it's been helpful to quickly be able to approve PRs for nextstrain team PRs.

The biggest issue with autobump is that it doesn't update dependencies. If someone wanted to help the broader bioconda community, a high impact thing might be to include pypi dependencies in the output of bioconda autobump PRs, to allow reviewers to see at a glance if any changes might be needed.

Being able to fix changed dependencies of autobump PRs is possibly the main benefit of widespread team notifications. But even then, that's only second best solution, as the best is to preemptively make a PR with updated dependencies (whenever we release a package and change it's dependencies, we should automatically think about updating bioconda deps to prevent them from going out of sync).

[tsibley]

Potentially more impactful than adding oneself as recipe maintainer would be if some of you became members of the bioconda org with approval rights. I don't remember how I got those bits but it wasn't hard. And it's been helpful to quickly be able to approve PRs for nextstrain team PRs.

Agreed it would be good for more on the team to have this! I tried two years ago, but couldn't get it to happen despite tagging the same person who granted your access.

[victorlin]

Thanks for the comments. This conversation has grown from the initial concern of who to add as maintainer for the newly created pathogen-embed recipe, but all these discussion points are worth having.

• 👍 for keeping individuals on the recipe maintainer lists. The shared account is more of a nice-to-have in case there is only one or a few individuals listed.

• Given the manual nature of the Bioconda PR merge process, I think we should stop relying on it as part of our release process to managed runtimes (Automate new builds/releases after Augur, Auspice, etc. releases conda-base#2 (comment)).

• The point about improving autobump requires more effort and is related to Automate dependency update checks for our packages #1 + discussions in Automate version bumping for Auspice #2.

[genehack]

This conversation has grown from the initial concern of who to add as maintainer for the newly created pathogen-embed recipe, but all these discussion points are worth having.

Added this comment to the dev-chat agenda, FWIW.