GHC Maintainer Preview

[Kleidukos]

Here is the rendered proposal

[maralorn]

On additional question would be: When do new versions of base and the other core libraries get published to hackage?
I suggest doing this at the moment of the Maintainer Preview Release so that for example developers can get notified by their packdeps.haskellers.com RSS feed.

[AndreasPK]

Besides the community aspect, which sounds great, is this that different from a group of people:

• Treating the compiler release as "Maintainer Preview"
• Making their own announcement of most popular libraries supporting the new release

Stacks LTS versions have a very similar result for example.

It's certainly a good goal to have! But it's a but unclear what makes a "Maintainer Preview" any different from the official release of a new GHC version currently? If all that is required from GHCs side is calling the expected last RC a "Maintainer Preview" that is likely fine. But it sounds like you want stronger guarantees than that to me?

[Kleidukos]

what makes a "Maintainer Preview" any different from the official release of a new GHC version currently?

In itself, nothing. It's literally the version that will be published under the X.Y tag a month later.
Now, when the version is published, we also bring on the table our best efforts to have started a migration of the ecosystem to support it. Also, I want to repeat that this is all done on a best-effort basis, we are not getting paid in any way for this stuff, so the best way to ensure that shit gets done is to be actively involved (or pay for someone's salary).

[cdsmith]

I think this proposal identifies an important problem, but fails to really justify that it solves that problem. In particular:

1. It's unclear what distinguishes a Maintainer Preview release from a pre-release. Maintainers of key libraries already strive to update their libraries before GHC's release, and successfully use pre-releases to do so. On the other hand, if bugs are found during the Maintainer Preview window, would GHC fix them for the final release? Or would they have to wait for the next GHC point version? If bugs would be fixed, isn't this essentially just another pre-release?
2. It's similarly unclear what distinguishes a Maintainer Preview release from a GHC release. Is anything stopping users who are eager for new compiler features like linear types or record dot syntax from installing the maintainer preview and developing applications with it? Are we just intentionally making it harder for people to do so? Someone mentioned that Stackage is already a sort of whole-community release cycle that post-dates the GHC release, and it has very similar goals to this proposal without needing to delay the GHC release and make things more complex for early adopters.
3. How are library developers supposed to know when it's time to update their libraries? The current answer is that they wait until the libraries they depend on are updated, which happens continuously over time, on an unpredictable schedule. I don't see how this proposal improves the situation. Declaring a Maintainer Preview release still does guarantee that my library's dependencies will build with the new GHC. So I'm still back to waiting for whatever difficult-to-predict time it becomes feasible to update my own library, except that now I also have non-actionable alerts pestering me about updating a library when I cannot do anything about it.

Without a stronger story for how these things look under this proposal, it's hard to think about what gets better.

[Kleidukos]

Hi Chris, thanks for your feedback! I'll try to answer your remarks and will update the proposal accordingly.

It's unclear what distinguishes a Maintainer Preview release from a pre-release.

Indeed, and it is a failure on my part: Nothing at the technical/physical level distinguishes it from a pre-release or release canditate

Maintainers of key libraries already strive to update their libraries before GHC's release, and successfully use pre-releases to do so

Yes but the past years have shown us that the ecosystem fails to follow.

On the other hand, if bugs are found during the Maintainer Preview window, would GHC fix them for the final release?

No, this goes with the next minor release.

It's similarly unclear what distinguishes a Maintainer Preview release from a GHC release.

It is the last release candidate.

Is anything stopping users who are eager for new compiler features like linear types or record dot syntax from installing the maintainer preview and developing applications with it?

I do not believe in technically restricting users from using those "Maintainer Preview" releases, but the communication around them should strongly highlight what kind of release they are using.

and it has very similar goals to this proposal without needing to delay the GHC release and make things more complex for early adopters.

The delay is to provide a better out-of-the-box experience for users who stick with major releases, like industrial users and people who do not wish to beta-test GHC.

How are library developers supposed to know when it's time to update their libraries?

We communicate on our official communication channels, and there is the possibility of maaaaaybe emailing them with the email they provide with their Hackage account. I'd like this point to be discussed because this is a contentious subject and I do not wish to advocate for such a plan without building consensus (for, or against) first.

I don't see how this proposal improves the situation.

The proposal is to make the schedule more predictable by actively helping libraries with a lot of dependant update, and thus accelerate the updating schedule for the rest of the ecosystem.

except that now I also have non-actionable alerts pestering me about updating a library when I cannot do anything about it.

You missed the point, it's not about pestering people, but actively helping them migrate.

[Bodigrim]

I think this proposal mixes social and technical components of the migration process.

With regards to a technical bit, there is an existing culture (e. g., on Stackage and in many companies) of treating GHC X.Y.1 as a preview, and GHC X.Y.2 as a production-ready release. For the sake of simplicity, I'd prefer to encourage this notion instead of introducing one more type/kind/sort of releases.

[cdsmith]

Thanks for your response.

Maintainers of key libraries already strive to update their libraries before GHC's release, and successfully use pre-releases to do so

Yes but the past years have shown us that the ecosystem fails to follow.

Okay, we agree on this. Then I'm looking for what in this proposal addresses the causes of this failure.

I was under the impression, from my first read, that a change in the versioning and the delayed production release was at the core of this proposal. I don't see how this addresses the problem. Maintainers can already do the same thing with release candidates that they could do with a maintainer preview release. I cannot think of a case where it's been impossible to resolve backward compatibility issues in a release candidate, prior to a blessed final release. Late release candidates usually see only bug fixes, and library updates can happen in parallel.

What has been a problem is that there isn't sufficient community pressure and feedback to drive updates until GHC is released. But delaying adoption of GHC actually makes that take longer! The early adopter community is a key player in getting Haskell's library ecosystem in shape when a new GHC release drops.

Is the core of the proposal, then, the recruitment or hiring of a team of helpers to migrate libraries? If so, it seems this could stand alone without changes to the version numbering or release timing, unless there's some synergy I'm missing between these two parts of the proposal? But such a proposal should also address the question of how these new helpers are different from Hackage Trustees, and whether we need both at the same time.

How are library developers supposed to know when it's time to update their libraries?

We communicate on our official communication channels, and there is the possibility of maaaaaybe emailing them with the email they provide with their Hackage account. I'd like this point to be discussed because this is a contentious subject and I do not wish to advocate for such a plan without building consensus (for, or against) first.

I think this misses the point of what I was saying. If GHC 9.4 Maintainer Preview is out, it's probably still too early for most libraries to be updated. If a library depends on vector, for example, and vector still doesn't build with GHC 9.4, then the maintainer of that library cannot do anything. So bulk communications don't do the job. What maintainers need is an alert that says: all of your dependencies DO build with GHC 9.4, but your library DOESN'T. That's when the time is ripe for them to do something about it. Right now, there's no good way to get that notification, and as a result maintainers sometimes fall back to waiting for users to complain.

I think (just a hypothesis) that something like this could help the situation. I think that Hackage Trustees already have tools for stuff like this. I don't think that a single broadcast "It's time to update for 9.4" to everyone all at once does any good, because for most people, such an announcement is useless until their dependencies are buildable.

[Bodigrim]

In a social dimension it would be nice to elaborate why existing initiatives, embodied in Hackage trustees and Stackage curators, are deemed insufficient (?). Stackage curators already operate very close to the described approach.

[Shimuuar]

I'd say we already have maintainer's preview. It's called release candidate. Why then libraries aren't updated during RC phase? How do you even install RC? Maintainers are lazy, so they will only start testing their libraries with RC if it's easy. Quoting proposal: "make it available in ghcup, the Ubuntu PPA (so that it can be easily used by CI systems like GitHub Actions or Travis)".

Second reason is already stated by @cdsmith. It's difficult to know when all your dependencies are updated and you can start updating your library (or you don't need to do anything and all is well). Doing that accurately enough that it's useful

Overall I think that only way to make libraries update faster is to reduce friction of updates as much as possible.

[neongreen]

Should we allow them to unsuscribe from such emails?

I am not sure but I believe that a significant number of people just mark emails as spam when they don't immediately know how to unsubscribe from unwanted emails.

Mail providers, in their turn, are quite trigger-happy about such things — and start marking all emails from this sender as spam. So including an unsubscribe button is for the sender's own good.

At least this is the standard advice I heard re/ unsubscribe buttons. Things might work differently nowadays.

[dpwiz]

make it available in ghcup, the Ubuntu PPA

A nightly-stlye stackage snapshot would be quite helpful. At this day, the nightly lags GHC by 2 months.

[hasufell]

"make it available in ghcup, the Ubuntu PPA (so that it can be easily used by CI systems like GitHub Actions or Travis)"

Yes, ghcup has been adding pre-releases since the first GHC-9 pre-release and it has worked well so far, except for a bug with ghc-pkg. What could be improved here for the ghcup/ppa/chocolatey maintainers is to give 1-2 days heads-up of imminent releases (basically, when @bgamari uploads the bindists, put the release announcement on hold and notify said maintainers). That will allow much better releases in lockstep as has been pointed out numerous times on the reddit release threads.

A nightly-stlye stackage snapshot would be quite helpful. At this day, the nightly lags GHC by 2 months.

I don't understand how stackage comes into play here. I thought the only reasonable way to test this is to use hackage, utilize cabals --allow-newer=base etc. and then go from there, analyzing the build failures. This could probably be made into a CI run, flagging failed packages.

Which brings me to the next point:

---

I think the only way this would reasonably work was if hackage had its own bugtracker to coordinate such things. Then you can have a bug report "update ecosystem to GHC-9.2.1 core libraries", have it trigger a CI run and then create tickets for every related build failure as dependencies of that meta-ticket, assigning them to the respective maintainers of every library.

This is how large distros do such migrations. You can't do it with emails, repos scattered across github, gitlab, darcsden or private servers. When there's no single point of communication and bug reporting place for ecosystem issues, then you can't coordinate such things.

[Ericson2314]

This reminds me of Rust's stable, beta, and nightly "release trains". We effectively have stable and nightly already, this sounds like beta

[jneira]

I think there has been raised interesting concerns about the proposal, which i firmly think could help to make new ghc versions adoption smoother.

Is the core of the proposal, then, the recruitment or hiring of a team of helpers to migrate libraries? If so, it seems this could stand alone without changes to the version numbering or release timing, unless there's some synergy I'm missing between these two parts of the proposal? But such a proposal should also address the question of how these new helpers are different from Hackage Trustees, and whether we need both at the same time.

As i see it the key of the proposal is the coordination of efforts to speed up the migration.
The prerelease is nothing but a cheap way to signal the migration period has started. So it sets a target date that we all (the community) should try to achieve.
Coordination is important cause the responsability and the timing of adoption depends on random early adopters that has to work alone, chasing maintainers and making patches from their particular interests (i have been on of those!) and no following a optimal global strategy. As usually they are not affiliated with any official haskell org, their work are usually ignored by maintainers, which in turn are burnt out for the rapid succession of ghc breaking changes.

Afaik hackage trustees work is not to make patches and supervise libs adoption of new ghc releases. They have been very very busy with no code related package metadata changes and we all should be very thankful for it.

[myShoggoth]

One way to think about this problem space is as a dependency graph, where we're updating the very foundation of it and working our way up. Would a visualization of that sort help? So on the left side (for instance) we have GHC itself and the core libraries, and for a new release we've verified those and they're green. Then we notify the subset of library maintainers who only have those for dependencies. Once those are updated and verified (if needed), we move again to the next set.

The upside here is that when a maintainer is notified, it is because their dependencies are ready.

Each library could have green (building and verified), yellow (building, not verified), or red (not building or not passing tests). This can continue to be updated after the GHC release so people know the status of libraries for that particular release, and it gives the GHC core peeps additional, easy to parse data to determine when the ecosystem is ready for the new version to be officially released such that the user base will be happy.

Which is clearly @Kleidukos 's aim: When a GHC release is official, it is actually usable by most people.

[bgamari]

I think that this proposal seeks to address a very real problem: Currently it does take quite a while for a new GHC release to be usable by most of the community. One major reason for this is the fact that Haskell projects tend to have rather large (and, in particular, deep) dependency graphs. The depth of these graphs means that it can take several months for compatibility to "trickle down" to end users since a package will generally not updated until its dependencies are usable.

I am having a hard time seeing is how the proposal addresses this depth issue; we can provide a maintainer preview release, but ultimately I suspect that even a month isn't going to be sufficient for an appreciable fraction of Hackage to gain compatibility unless something else changes.

In particular, dependency depth issue is especially problematic when some ubiquitously-used libraries lack responsive maintainers. In this case it can take months for large swaths of the community to even begin porting. For instance, GHC 9.0 is currently unusable for most web server applications due to the lack of a compatible Cryptonite release. This sort of situation has repeated itself again and again over the course of my involvement in the Haskell community.

Historically we have thought of this primarily as a social problem, where the solution is to find a new maintainer. However, the regularity with which this recurs makes me wonder whether this is the correct framing. Afterall there also exists technical solutions which attack this same problem (e.g. package repository overlays, like the head.hackage overlay used in testing GHC). The problem is these solutions run somewhat contrary to the wide deference the community has historically given to package maintainers.

One way to think about this problem space is as a dependency graph, where we're updating the very foundation of it and working our way up. Would a visualization of that sort help? So on the left side (for instance) we have GHC itself and the core libraries, and for a new release we've verified those and they're green. Then we notify the subset of library maintainers who only have those for dependencies. Once those are updated and verified (if needed), we move again to the next set.

@myShoggoth, note that the Hackage Matrix Builder already provides the technical infrastructure for this. It would just need someone to take it over and implement the notifications and possibly a graph visualisation.

[tomjaguarpaw]

In particular, dependency depth issue is especially problematic when some ubiquitously-used libraries lack responsive maintainers.

I'm increasingly concerned by this issue. Earlier today I posted a message to haskell-cafe asking for help designing a "living will", initially to ensure smooth transition for my own packages should I become unresponsive, but with the hope that subsequently it will lead to a more commonly adopted policy throughout the ecosystem. I would welcome input on that thread.

[Ericson2314]

I very much like @bgamari's framing. I wrote https://gitlab.haskell.org/ghc/ghc/-/wikis/Rehabilitating-Orphans-with-Order-theory because I also agree these long dependency dependency critical paths are quite costly.

1. code reuse is great
2. critical path length is the worse cost
3. ergo libraries / critical path is an important metric.
4. From there it's a small step to seeing
5. orphans being bad linearizes dependencies making that metric worse
6. ergo let's make orphans good!

The breaking up base / decoupling base from GHC downstream goal of that also works well for this, because it means:

• Old base can support new GHC, adding a "checkpoint" to get some value from only fixing the library not language breakage issues
• Generally amortizing the work by allowing a "fix new base, fix new ghc" tick-tock will reduce latency

So yeah, I am not opposed to this proposal because it might be good for other reasons (and the Rust beta train antecedent I mentioned is well regarded by compiler devs over there that I trust), but I do not think this proposal is the right remedy for the problem it currently intends to solve.

[nomeata]

I can find a shepherd and get the proposal process going. Or are you looking for something less heavy to assess the chances first?

[Kleidukos]

@nomeata I would very much like to get the process going 🙇

[int-index]

In ghc-proposals’s readme, we say:

A GHC Proposal is a document describing a proposed change to the compiler, the GHC/Haskell language, or the libraries in the GHC.* module namespace.

However, this document suggests a change to the release process and community management, not to the language, the compiler, or the libraries.

I do not feel qualified to make a recommendation, and I don’t think it falls within the duties of the GHC Steering Committee. Labeling as out of scope. Members of the committee who have opinions can of course join the discussion in this GitHub thread.

To be clear, I do not mean to discourage this initiative, I just don’t think it qualifies to go through the usual proposal process.

[Kleidukos]

@int-index I know, but I was told to put this proposal here in order to gather feedback. :)

[int-index]

Yes, I see no problem using this repository as a platform for the discussion, and indeed, it seems to have gathered quite a few detailed responses.

But I would not submit this proposal to the committee, if not for any formality then for the fact that it currently does not include @bgamari who is the current release manager and as such is probably most qualified to judge the merit of the proposed change.

[goldfirere]

There have been several proposals adjacent to our process, but beyond it. This is one -- I agree with the assessment that it is technically out of scope. Another recent one was the proposal about defaulting plugins -- we consider plugin design to evolve too quickly to be appropriate here. In recent work I was doing with @sheaf, we struggled to find a venue to discuss our plugin ideas and collect feedback.

So, what do we do? Who decides? I don't have a good answer to suggest, but I think what we currently have is not quite working -- at least, I felt frustrated by the lack of a place to discuss plugin-structure changes. #441 is yet another example of a proposal that deserves discussion... but we don't know where.

I hesitate to suggest it, but maybe we need yet another committee. This would be focused on non-language aspects of GHC. I would hope that it could get by with a lighter-weight proposal process than the one we have here... maybe something like the new CLC proposal process (https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md) would be appropriate -- I very much appreciate the less formal tone there.

The alternative to making a committee would seem to be either to let decisions accrue by happenstance (urgh) or to appoint a benevolent dictator. Right now, we're effectively in "happenstance" mode. (Example: I approved several changes to the plugin architecture recently after trying and failing to generate conversation about them. But there is no grand plan here!) I'm not against appointing a dictator, but I tend to think that inviting several people to collaborate is going to lead to better results than leaving this to any one individual.

What do others think here? I personally do think we have to take some action, as there have been just too many instances of worthwhile discussions like this one here that have stalled due to lack of process.

[hasufell]

What do others think here?

I think our problems are not about proposal processes. I think there are already too many. It's about engaging in discussions, a sane moderation of those and a final decision, even if it is informal.

[Kleidukos]

@goldfirere isn't GHCHQ supposed to supervise the operational aspects of GHC development? Can't the discussions live in this repo as well, but for a different set of people responsible for them?

[phadej]

GHCHQ is not GHC Steering Committee. IIRC @bgamari didn't even like the term GHCHQ, because it's not that well defined.

[phadej]

TBH, I don't think we need maintainers preview. It would be great to have more release candidates though. E.g. GHC-9.2:

• 2021-04-22 - alpha2 https://www.haskell.org/ghc/blog/20210422-ghc-9.2.1-alpha2-relased.html
• 2021-08-23 - rc1 https://discourse.haskell.org/t/ghc-9-2-1-rc1-is-now-available/2915
• 2021-10-29 - release https://discourse.haskell.org/t/ghc-9-2-1-released/3527

I have tried rc1 and found issues, the release itself looks good.

https://gitlab.haskell.org/ghc/ghc/-/milestones/365 btw has completely different schedule:

3 March 2021: Release branch forked
10 March 2021: Alpha 1 released
31 March 2021: Alpha 2 released
14 April 2021: Alpha 3 released
28 April 2021: Alpha 4 released
5 May 2021: Beta 1 released
12 May 2021: Release candidate 1 released
26 May 2021: Final release

changes of plans haven't been communicated.

I'd be a lot happier library maintainer if the promised 5-6 intermediate
releases were actually done.

So if GHC release team cannot keep up with their current promises,
I don't think its helpful for an external committee to require more work.
OTOH, I'd expect that GHC Steering Committee would figure out
what can be improved so the current process goes well.

[Kleidukos]

Ah well, that's a pity it's been used so much throughout the years. :)
And yes I know it is not the Steering Committee, this one is only in charge of checking if GHC follows the language/standard.

[Kleidukos]

@phadej I am not certain to see what would prevent the last RC to be a "Maintainer preview"?

So if GHC release team cannot keep up with their current promises,
I don't think its helpful for an external committee to require more work.

There is a grave misunderstanding I think, I am first and foremost looking for the consent (if not cooperation) of the GHC release managers, and I don't think another committee that is not them will be the proper solution.

[phadej]

I am not certain to see what would prevent the last RC to be a "Maintainer preview"?

Because you never know which release candidate will be the last one.

I don't like the current situation where quite a lot changes are between last RC and the proper release. But I don't think (trying to) label the last release candidate as "_final" will help. There will be _final_final_final maintainer previews then too.

[Kleidukos]

@phadej This is a matter of internal discipline, at some point lines need to be drawn and newly-found bugs need to be planned for fixing at the next patch release. There is no universal algorithm for this, that's the job of the release managers.

[phadej]

@Kleidukos I don't agree. Making a "Maintainer Release", and then waiting a week or two, and even some critical bugs are found, not fixing them but rather going for a release because Maintainer Preview Release have to be fully identical to the final version.

I'd rather see GHC team making release candidates periodically (as promised), and then saying "the last release candidate is good, lets make it the release". I.e not trying to guess which release candidate will be the latest one

[Kleidukos]

and even some critical bugs are found, not fixing them but rather going for a release because Maintainer Preview Release have to be fully identical to the final version.

You've drawn the line at critical bugs, so it's not really impossible. :)

I'd rather see GHC team making release candidates periodically (as promised), and then saying "the last release candidate is good, lets make it the release".

Sorry, how is that fundamentally different from "The last release candidate is good, let's freeze feature development and bug fixing on it, wait for maintainers to catch up, and ship the release"?

[phadej]

"The last release candidate is good, let's freeze feature development

The feature development should be freezed by the first release candidate. There should be a chance that the first release candidate is also the last one.

[Kleidukos]

Okay great, sounds good to me

[phadej]

In fact https://www.haskell.org/ghc/blog/20170801-2017-release-schedule.html

The release process today
Cutting a GHC release is a fairly lengthy process involving many parties and a significant amount of planning. The typical
process for a major release looks something like this,

• (a few months after the previous major release) A set of release priorities are defined determining which major features we want in the coming release
• wait until all major features are merged to the master branch
• when all features are merged, cut a stable branch

Major features are frozen before the first alpha!

[simonpj]

Ben writes

In particular, dependency depth issue is especially problematic when some ubiquitously-used libraries lack responsive maintainers. In this case it can take months for large swaths of the community to even begin porting....This sort of situation has repeated itself again and again over the course of my involvement in the Haskell community.

How can we address this? In a more constructive way than by blaming unresponsive maintainers, who should rather be praised for producing a library on which so many people rely, and may have many legitimate reasons for being unresponsive.

I doubt that the main problem is the availability of effort to fix library X. It's the lack of availability of the sole author of X, who alone has the power to fix X. We should strive to avoid single points of failure like this -- it puts too much pressure on individuals, and it does not scale well when you have many single-points-of-failure.

Does our "overlay" mechanism help to address this? Could we have a GHC-9.4 overlay of Hackage, in which packages were fixed by anybody? Then when the maintainer was ready, he or she could do the "right" fix (which might of might not be identical to the one done in the overlay), release the package, and adjust the overlay to use the new "official" release.

The goal would be to offer support to maintainers, by taking them off the critical path, without taking away their god-like powers over the package they wrote.

If we had a setup like this, maybe we then could have a Zero Hackage Failure scheme. (Presumably not all of Hackage, but perhaps all the dependencies of 'lens' or some specified set of roots.) It could be a fantastic way to engage the community.

I don't know enough about Hackage and the package ecosystem to have a well-informed view here, but I'd love us, together, to come up with a creative solution here, that made a new GHC release available "with batteries" much more quickly, and with less stress on individuals.

[simonpj]

There have been several proposals adjacent to our process, but beyond it. This is one -- I agree with the assessment that it is technically out of scope. Another recent one was the proposal about defaulting plugins -- we consider plugin design to evolve too quickly to be appropriate here. In recent work I was doing with @sheaf, we struggled to find a venue to discuss our plugin ideas and collect feedback.

Well the GHC Steering Committee is called the "GHC Steering Committee", not the "GHC Language Design Committee". In principle the same group (perhaps augmented a bit) could discuss broader proposals. But perhaps with a different repo, so the language-design bit and the broader process/ecosystem bit don't get confused.

My anxiety is only that being a member of the steering committee is already pretty onerous, and this might make it more so -- and would need a broader range of expertise. One could address that by having more members, or by splitting into two, I guess.

[hasufell]

@simonpj my opinion is that the competencies of the hackage trustees wrt NMUs (non-maintainer updates) should be extended to be able to:

1. apply security patches or memory bugfixes (this might be more controversial)
2. apply any patch that is required to update a library to the latest state of the ecosystem (including GHC patches, but also others)

These patches should be posted to a dedicated mailing list (or issue tracker), which interested parties can follow and provide reviews. Liability lies with the patch author. The process of applying these would follow the already conservative process of the trustees. Feature patches are not allowed.

---

In the context of GHC releases, this could work as follows:

1. during development of a new release, patches are kept in the head.hackage repository
2. once it's clear no more visible API changes will make it into the release, a call for participation with a link to all the patches can be published to the libraries mailing list
3. a month after the release, packages that haven't been updated yet will enter the NMU workflow
4. either the NMU workflow successfully manages to contact the maintainer or the patches are applied without explicit consent

---

Finally, hackage should be augmented to show which versions were NMUs. cabal could then have an option to ignore such packages, but it's possible this can be achieved simply with remote constraint/freeze files (once that feature lands).

Hackage, in my opinion, is not your private package hosting service. It's a shared resource. People (and companies) rely on it.

---

That said, I'm slightly in disfavor of a continuous overlay approach (having worked on two linux distros that heavily make use of them). They come with their own issues, especially for users, who have to figure out how overlays interact with each other and if they even get a working package set out of it.

However, it surely is a non-intrusive option.

[phadej]

i don't like the idea of extending the scope of NMUs. That would be an extra responsibility for trustees, which essentially makes them a co-maintainers of whole Hackage. It's a volunatory job, this is IMHO too much asked.

Trustees has a lot of responsibilities already, but completely no power to change anything. This disbalance is not good long term.

[hasufell]

i don't like the idea of extending the scope of NMUs

Do you mean trustees are understaffed? How is the situation wrt applications? Has there been calls for participation?

[Ericson2314]

The biggest issue of things not building IMO is due to base shipping with GHC. It means everyone needs to bump upper bounds too often, and that slows down the "upgrade wave" that cascades through Hackage, in that if people are stuck on the package you depend on they might not even be trying to build yours yet.

I think we should first make plans to solve that, and with the elephant in the room addressed, we can then better see other changes are needed, if any at all!