Skip to content
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

Revert "emacs: set 29 as default version and remove 28" #272785

Merged
merged 1 commit into from
Dec 8, 2023

Conversation

mweinelt
Copy link
Member

@mweinelt mweinelt commented Dec 7, 2023

Reverts #270558

Kindly retarget this 25k rebuild PR to staging, like everyone else does it.

@mweinelt mweinelt merged commit 49cd2f2 into master Dec 8, 2023
5 of 6 checks passed
@mweinelt mweinelt deleted the revert-270558-pr/default-emacs-29 branch December 8, 2023 00:34
@AndersonTorres
Copy link
Member

What about power this off?

This is not a package with a truckload of dependency tree, like systemd or cmake.
It is just Emacs and its Elisp auto-generated plugins - a single trunk with many leaves.

Also, Emacs is not a hidden-but-very-important core package like systemd or SDL. It is an app that the users directly call and execute in their PCs.

It is simply insane that each and every release - or even a mere bugfix - of Emacs require sending it to staging because of the mass rebuild of auto-generated plugins.
Worse, the plugin auto-generation is still buggy after two years - we work around this by removing the files before generating them.

Also, there is nothing on the Staging branch that would be useful for Emacs that can't be done on the Master branch. Emacs does not need bleeding-edge mass-rebuild-triggering software to be built - the same compilers and the same autotools needed to build any other text editor, or application for that matter, can be found on Master.

That being said, I suggest to remove the auto-generated Elisp packages from Hydra. The users can install these packages in their local PC-XT machines like they did in the good old times of Linux 2.4...

@mweinelt
Copy link
Member Author

mweinelt commented Dec 8, 2023

This is mostly about the number of rebuilds this causes, not about it needing anything that is on staging.

If the rebuilds of its reverse dependencies are so cheap, why not make them preferLocalBuild?

@AndersonTorres
Copy link
Member

If the rebuilds of its reverse dependencies are so cheap, why not make them preferLocalBuild?

Can this be done on CI? If yes, then fine.

@vcunat
Copy link
Member

vcunat commented Dec 8, 2023

Maybe we could introduce some low-prio variant of the trunk jobset for such cases. It would get lower eval frequency, lower build shares (low priority), and channels wouldn't be waiting for it at all. We already have cross-trunk with these properties, though it's a specific area.

dansbandit pushed a commit to dansbandit/nixpkgs that referenced this pull request Dec 27, 2023
Too many rebuilds to go to master, even if they are cheap they cause a lot of delay on nixos-unstable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants