This is my attempt at improving the instructions (using some of the info from this discussion)
1 Like
In terms of UI I woudn’t say it’s better IMO, but it helps avoid having to delete Git tags which is essentially like rewriting history on your master branch, so that’s one nice thing.
I agree. I’m not really a big fan of the process myself, but it does work at least. And the nice thing is that it’s just a PR to be made, therefore you can wrap it in a variety of frontends.
Don’t worry, you’ll get that soon 
1 Like
FYI: I have added a trigger comment to manually tell TagBot to create your release, for when you didn’t install the app until after your registry PR was merged, or something else went wrong. See this readme section for more details.
1 Like
Believe it or not, we didn’t change the release process on a whim or just to annoy you. A lot of time and energy was spent thinking about and designing the new process and it was designed specifically to fix shortcomings in the old process. The key problem with triggering registration via git tags and GitHub releases is that they are supposed to be immutable—once they are made, they should never be deleted or changed. With the old process, at the time you tagged something, you couldn’t possibly yet know if it was going to be an acceptable release or not. Maybe you made some mistake and the release was going to get rejected by CIBot. If the registration process rejected your proposed release triggered by creating a git tag or GitHub release, then you only have two bad options:
-
Delete and replace the tag / release that you already created in order to retrigger the release review process.
-
Just abandon the tag / release that you already created and skip on to a new one, leaving holes in the registered sequence of releases.
Almost no one did the former since it is appropriately annoying to replace tags or releases—because you aren’t supposed to do it. So in practice, people just would tag five different versions in a row until they got it right and as a result, Julia packages would regularly “release” five versions at at time, four of which are broken, uninstallable and never used by anyone. This problem was only going to get worse because we want to start doing more automated checks on packages, including making sure that they:
- Have correct, sane package structure and layout.
- Pass their own tests.
- Don’t break the tests of reverse dependencies, with which they are supposed to be compatible.
- Have correct compatibility bounds on their dependencies.
Since we’re planning on making the verification process stricter, it’s going to be more likely that the first attempt to register a new version won’t work, so the old process was simply not going to cut it. The new process separates proposing a new version from approving it, allowing all kinds of verification and testing in the middle, and only when a package is vetted and approved, does the new version get tagged after the fact.
Any issues with triggering doc builds can be solved with automation just as simply as tagging and creating releases has been.
15 Likes
Oh, and as to why there are two bots—there’s also a good reason for that! We already tried it the other way: originally Registrator made and tagged releases for you. But when we asked people to alpha test this, some people complained that it required write access to your repos—which it needs so that it can tag releases for you. Now GitHub does not allow choosing which permissions you grant a bot, it’s all or nothing. So we had to remove that feature entirely and make Registrator only require read access. But of course then the first complaint is “How come I have to create releases myself? Attobot did that for me, why can’t Registrator?” You can see where this is going… So the only option is to have a separate bot that has write access and does automatic tagging. People that don’t want to grant bots write access can make their own tags, everyone else can add TagBot to their repos and get tags automatically.
10 Likes
People working on designing the new registry workflow have spent a significant part of the last few months thinking about the whole process, eg in #849, and other discussions preceding that, without “losing focus”.
As always, things can be improved (and they are being improved on a daily basis). But after months of hard work which resulted in a functional and conceptually coherent solution, I don’t think it is nice to imagine that you can, or need to, “provoke” anyone to do better. They already did an excellent job.
2 Likes
@fredrikekre, @StefanKarpinski, @Tamas_Papp, I guess I was just unreasonable and harsh on my words on this one. I’m very sorry about that. I respect all the effort you put in this work.
I think this is the 2nd time I put a negative feedback on anything in this community. The first time was on the pkg.julialang.org situation. Both these cases have something in common: if they’re wrong, they will hurt the community. So my intent here was to antecipate problems that outsiders of this forum will face. But, as I said, maybe I’m just wrong and trying to help the wrong way.
I once was a music producer and sometimes I could spend 48 hours in a row listening to the same 5 minute audio. In the end, the client gets by and catches something wrong in the result. It was really a pain, specially when I liked the song. But the thing is that it is very easy to lose perspective when you spend a lot of time on a single task. It hurts everytime, but the result was always better. I hope you understand.
3 Likes
FWIW, I am not one of the contributors on this. I am just concerned that if working on tooling leads to a lot of complaints no matter what you do (because every change breaks someone’s workflow), then contributors will eventually burn out.
Instead, we should reward such work with a positive attitude (at minimum) and take occasional glitches gracefully. Especially since they get fixed really, really quickly.
I appreciate the sentiment—thank you for the kind reply. Bug reports, suggestions, constructive criticisms, etc. are always very much welcomed. To give feedback on your feedback, “I liked it better the old way” and “please think about the overall process” are just not very helpful comments. It’s obvious that one should think about the whole process. To suggest that’s not what we’ve been doing is, well, kind of insulting. If we had something like attobot that people liked and we’ve changed it, perhaps there was a reason. And indeed, the reason to deviate from the previous way is precisely because of thinking about improving the overall process.
1 Like
I just got an email saying
" Julia TagBot, installed on your account is requesting updated permissions."
with a link to an unfamiliar url on github like this:
[https://github.com/settings/installations/955…]
and it asks for a password. I can’t tell if this is legit or phishing.
This came up on slack - apparently it’s legit and due to https://github.com/JuliaRegistries/TagBot/pull/22
3 Likes
Yes this was me. I generally wouldn’t consider https://github.com/*** to be phishy 
1 Like
Also, adding read access to issues isn’t too alarming either—that’s already public info.
3 Likes
Hi @christopher-dG, I’m pretty late to the convo here, but does the TagBot still support manually triggering a tag? I had an issue with Docs not being deployed, so I had to delete the original tag and recreate it one commit ahead to trigger a new travis CI pipeline with a diferent yml config. I’ve since deleted that new tag, and I’m trying to go back and recreate the original tag so it’s in sync with the package registry. I’d like tagbot to do it since it creates nice release notes for me.
I tried TagBot tag and @TagBot tag in the commit comments, but I haven’t been able to retrigger it.
Thanks,
Vincent
EDIT
I was trying to comment TagBot tag on the commit instead of the PR… 
. I put the comment on the PR in the registry and it worked like a charm.
1 Like