I'd say this is quite high priority as otherwise there's a big risk that the changes don't get merged upstream and we have to continually fix all released versions. In addition, having the author be aware can prevent confusion when debugging issues with their packages.

to reduce email spamming (I tend to batch-edit packages; if you add a stricter constraint, you often have to fixup previous releases as well), changes should be sent out summarised, at most once every 15 minutes or so...

also, @dcoutts mentioned, this notifications should be explicitly opted in by package authors

We changed our minds and want opt-out for notifications, right?

It might also be useful to say something about the revising user e.g., "JohanTibell (maintainer)", AdamBergmark (trustee)" so it's clear why the user has permission to create a new revision.

As a package maintainer, I want these notifications. If a trustee changes one of my packages on Hackage, I want to know. I also want these notifications to be opt-out rather than opt-in. Having these notifications could have prevented (or at least ameliorated) a recent dust-up regarding package revisions: https://www.reddit.com/r/haskell/comments/67u8he/stackages_norevisions_experimental_field/dgtoz9o/?context=4

A somewhat related issue was filed by @eborden here. I'd really like to see this implemented, as I'd hope this would result in more appreciation for the large amount of work Hackage Trustees are investing to help package maintainers keep the Hackage ecosystem in a healthy state, which is essential for providing a good user experience to both veterans (who need to be able to rely on Hackage & Cabal to "just work" to get work done and make productive use of Haskell) as well as newcomers (which would otherwise be discouraged before even having written the first line of Haskell) without having to rely on external 3rd-party systems.

I think for this long-standing feature-request to make progress we need to come up with an implementable specification. The email-based approach still seems to me to be the most reasonable to implement at this point (automatically filing issues or even PRs on GitHub/GitLab/DarcsHub/whatever etc would be require much more effort in terms of complexity as well as risking being in conflict with the respective terms of uses regarding spam/bot-use)

OTTOMH, Here's a non-exhaustive list of questions/choices in the design space we should try to get a handle on:

• Who shall get the notification?

  • All members of the current maintainer group?
  • Shall we notify the email addresses listed in the .cabal maintainer field?
  • Is it enough to have opt-in/opt-out granularity be per-account? Or do we need to give maintainers the ability to define which of their packages they care to get notifications about?
  • Shall we allow non-maintainers (i.e. "concerned citizens") to subscribe to notifications of packages they don't maintain?
  • Shall other trustees be notified too (maybe because they made prior revisions to that package already)?
  • Shall the one making the revision be notified as well?
  • Shall we support configuring separate email addresses for those notifications?

• What information shall the email notification look like/contain?

  • Do we need the likes of Add Change-comment field to cabal edits #315 to be implemented first?
  • .patch (against previous revision or against 0th revision?) or final .cabal?
  • include prior revision history for context?
  • Name of account making the change? Names of co-maintainer accounts?
  • Link to FAQ or other documentation?
  • Links to http://matrix.hackage.haskell.org reports right before and after the change?

• When to notify?

  • Only when trustees make a change? What if a maintainer made a change?
  • Instantly, or with "grace period" in order to allow notification to be batched into a single email?
    (Note that even though we try to use revision-strategies to minimize the amount of revisions needed, packages with many releases can easily require several dozens revisions being done in a relatively short amount of time.)
  • Shall it be possible to make silent changes? E.g. some wikis and other systems, allow you to make changes for which you can suppress notifications via checkbox on a case-by-case choice.

My opinions:

• All members of the current maintainer group should be notified.
• Extra email addresses listed in the Cabal file should not be notified.
• Opting out per package would be nice, but per account seems sufficient.
• Non-maintainers should not be notified.
• Other trustees should not be notified.
• The user revising the package should not be notified.
• Separate email addresses for notifications seems unnecessary.
• No other features need to be implemented first.
• A diff against the previous revision should be in the text of the notification, with the new full Cabal file included as an attachment.
• No prior revision history needs to be included.
• The name of the account making the revision should be included.
• Links to whatever can be included; that doesn't really matter.
• Notify only when trustees make a change.
• Send notifications instantly.
• It should be impossible to make silent changes.

branch in progress at https://github.com/gbaz/hackage-server/tree/user-notify

Finally finished off a basic PR on this. Needs a pref setting, and could be more featureful, but its a start.

We have this now:

So what needs to be done for this? I think it might be best to close this and make a new issue with concrete requirements. Because this is so old I can't figure out whether it's complete or not.