-
Notifications
You must be signed in to change notification settings - Fork 269
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
GHC Maintainer Preview #417
Conversation
On additional question would be: When do new versions of base and the other core libraries get published to hackage? |
Besides the community aspect, which sounds great, is this that different from a group of people:
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? |
In itself, nothing. It's literally the version that will be published under the X.Y tag a month later. |
I think this proposal identifies an important problem, but fails to really justify that it solves that problem. In particular:
Without a stronger story for how these things look under this proposal, it's hard to think about what gets better. |
Hi Chris, thanks for your feedback! I'll try to answer your remarks and will update the proposal accordingly.
Indeed, and it is a failure on my part: Nothing at the technical/physical level distinguishes it from a pre-release or release canditate
Yes but the past years have shown us that the ecosystem fails to follow.
No, this goes with the next minor release.
It is the last release candidate.
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.
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.
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.
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.
You missed the point, it's not about pestering people, but actively helping them migrate. |
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. |
Thanks for your response.
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.
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 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. |
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. |
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. |
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. |
A nightly-stlye stackage snapshot would be quite helpful. At this day, the nightly lags GHC by 2 months. |
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.
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 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. |
This reminds me of Rust's stable, beta, and nightly "release trains". We effectively have stable and nightly already, this sounds like beta |
I think there has been raised interesting concerns about the proposal, which i firmly think could help to make new ghc versions adoption smoother.
As i see it the key of the proposal is the coordination of efforts to speed up the migration. 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. |
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. |
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 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
@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. |
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. |
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.
The breaking up base / decoupling base from GHC downstream goal of that also works well for this, because it means:
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. |
I can find a shepherd and get the proposal process going. Or are you looking for something less heavy to assess the chances first? |
@nomeata I would very much like to get the process going 🙇 |
In
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. |
@int-index I know, but I was told to put this proposal here in order to gather feedback. :) |
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. |
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. |
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. |
@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? |
GHCHQ is not GHC Steering Committee. IIRC @bgamari didn't even like the term GHCHQ, because it's not that well defined. |
TBH, I don't think we need maintainers preview. It would be great to have more release candidates though. E.g. GHC-9.2:
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:
changes of plans haven't been communicated. I'd be a lot happier library maintainer if the promised 5-6 intermediate So if GHC release team cannot keep up with their current promises, |
Ah well, that's a pity it's been used so much throughout the years. :) |
@phadej I am not certain to see what would prevent the last RC to be a "Maintainer preview"?
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. |
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. |
@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. |
@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 |
You've drawn the line at critical bugs, so it's not really impossible. :)
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"? |
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. |
Okay great, sounds good to me |
In fact https://www.haskell.org/ghc/blog/20170801-2017-release-schedule.html
Major features are frozen before the first alpha! |
Ben writes
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. |
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. |
@simonpj my opinion is that the competencies of the hackage trustees wrt NMUs (non-maintainer updates) should be extended to be able to:
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:
Finally, hackage should be augmented to show which versions were NMUs. 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. |
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. |
Do you mean trustees are understaffed? How is the situation wrt applications? Has there been calls for participation? |
The biggest issue of things not building IMO is due to 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! |
Here is the rendered proposal