-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include patch in the email notification about revisions #1226
Comments
I think this won’t hurt but won’t be tremendously helpful either. 99.9% (active) packages use GitHub (maybe less so of packages that are not active but that need to have bounds updates; still, a majority), and getting a patch in email is not exactly how you think about a helpful GitHub workflow. You’d get a much greater bang for the buck if you could automate 1) GitHub PR, 2) adding a tag for the new revision when the PR is merged. The latter can be done via a GH bot, I think: Julia ecosystem uses a “tag bot” quite actively lately. |
“Use |
@ffaf1 this is not all is it? Let's see, you need
Did I miss anything? I really want to be able to get a notification email on my phone, click a link in the email without leaving the phone, and be done with it. If the CI is not done by the time I get to the email I just snooze it to later (one swipe away), and it's still one click away. |
I think it is feature creep to have Hackage interact with unreleased sources (e.g preparing patches). It would be better to have some separate tool handle the patch generation and GitHub integration. GitHub is a proprietary platform, and should not get special status on Hackage. I don't know of any language ecosystem where the package hosting service also is used for generating upstream patches. There is dependabot, and there is no reason why a solution like that wouldn't work for Haskell. If there is any infrastructure in Hackage that is difficult to use in a separate project, we should clean that up. Similar to how to we have a separation between cabal-install and Cabal. |
The point is that hackage is in a unique position: it has access to revisions (which are curated), and already sends an email to maintainers that are subscribed
I agree, that's why I suggested a patch |
Generating a patch in a web interface between revisions would be a good start. (EDIT: the current "semantic" patch could also be improved; but raw textual patch would be also useful as e.g. trustees sometimes add comments why some revision is made) That said, I usually just download the most recent revision and overwrite |
As discussed on #hackage, receiving a patch/pr/mr when a revision is made would help make the update flow back upstream.
Hackage can already send an email notification when a revision happens, so I think it makes sense to include a patch in the email. Plus, this method is forge-agnostic as opposed to integration with github/gitlab/codeberg/...
If the email address the patch is sent to is configurable separately from the main email address, we'd also get free integration with mailing lists (sourcehut etc)
The text was updated successfully, but these errors were encountered: