haskell
Include patch in the email notification about revisions
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)
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.
getting a patch in email is not exactly how you think about a helpful GitHub workflow
“Use git am <patch> to apply this patch” may not be as handy as a PR but it is pretty painfree
@ffaf1 this is not all is it? Let's see, you need
- create a file with the patch,
- a local checkout of the repo,
- create a branch (you want a PR that will run CI before merging to
main), - write a boring commit message yourself,
- push and create a PR.
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
GitHub is a proprietary platform, and should not get special status on Hackage
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 .cabal file if someone else have made a revision and I need to reapply it locally.
