It seems that the automerging is going pretty well so far.
If you do encounter any problems with automerge, you can open an issue here: https://github.com/JuliaRegistries/RegistryCI.jl/issues
1 Like
Looks like it definitely is working!
What is the suggested merging approach for existing package names ending with capitals? Renaming existing packages could be a bit disruptive but I would opt for that if that rule stays enforced.
The naming guidelines (normal capitalization and not too short) apply only to new packages.
The naming guidelines do not apply when merging new versions for existing packages.
1 Like
Thank you! I’ll rename a new package and resubmit.
Just FYI - you don’t have to rename your package! It is perfectly fine to have packages that don’t match the naming guidelines. It just means that the first time your package is registered, it needs to be manually merged by a human. After that, it will be automatically merged by automerge.
3 Likes
I think that it would be great if these guidelines were included in one of the relevant repositories.
I can think of making a PR to
and then just adding a link to that from the readme of
or should they go somewhere else?
3 Likes
Another possibility would be the General registries repo, since that’s what uses the automerge and package authors come into contact with it frequently (via Registrator’s PRs). That’s what I went with for this attempt at least: https://github.com/JuliaRegistries/General/pull/3567. I don’t have the full set of rules included though so that would be a great addition.
3 Likes
Just to say I added the list of requirements in the latest commit to that PR
Made a PR, including clarifications for questions which came up here:
4 Likes
Regarding this “important note” from the original post,
The following two PRs did not pass auto merge and then remained un-merged for many days. Is there a new procedure to request “non-auto merges”? If not, then it seems that in practice these guidelines are in fact requirements.
1 Like
You can always ask on the #pkg-registration channel on Slack.
2 Likes
would it make sense to not auto merge if the compat section of Project.toml does not include the latest version of a dependency? i think we should want that it does, and if it doesn’t then the package maintainers need to justify it.
preemptively i’m going to argue that the problem with relying on CompatHelper to do this is that it’s opt-in. were similar functionality included in the auto-merge script, then, at least for those packages registered in General, maintainers would get notified that they’re lagging behind the times even if they hadn’t installed CompatHelper (because they were too lazy, didn’t know about it, whatever).
2 Likes
While I agree that it is best to keep compat bounds up to date, I don’t think that the registry (and specifically automerging) is the right place to enforce this.
Denying automerging it is somewhat of a disproportionate sanction for something that is not actually harmful, and manual reviews would just impose extra work on the registry maintainers. In addition, this would not catch cases where a new release of a dependency is made after a version was tagged.
That said, if resources permit this, I think it would be great to make CompatHelper automatic for all packages in the registry (with an opt-out option).
I think disallowing this would be too stringent; what if you need to fix a bug, a key package you depended on just released version 2.0.0 and this requires a complete rewrite of your package?
However, your idea to provide some kind of notification at registration time is really good. 
4 Likes
That is news to me. I have not yet used Julia’s Slack. In the past any discussions before merge could occur in the PR. So maybe a note about how to request exceptions to the auto-merge should be added to the documentation of this new process.
1 Like
This should not be the answer.
People should not have to use Slack.
Indeed some people can’t use Slack for various reasons.
But more generally,
I feel like asking registry maintainers on Slack is a personal action,
where as this should be a beurocratic action.
If that makes sense?
2 Likes
Sure, it would be great to have another solution. Any suggestions?
We go through the queue periodically and do manual merges. For example, I went through yesterday and did as many manual merges as I could.
1 Like
I think manually revieing the queue is the way to go.
Is it hard to see which things have people actually talking on, vs just bots?
Maybe we should have a Registry feed slack channel that reposts any comments not made by a bot?
Like the stackoverflow one?
3 Likes