Re-enable lts based testing #266
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Mar 31, 2021
This reverts commit 8a8d5f7. There will be a separate GH Actions workflow for rebuilding the manpage, and generatemanpage will be dropped from xmonad.cabal (see xmonad#283) therefore the revert no longer makes sense and the stack workflow can indeed be reverted back to a working state so we can continue from there. For more information, see the following revenge revert storm: Related: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Mar 31, 2021
pandoc's API changes often enough that distros like Debian were patching our GenerateManpage.hs to work with their version of pandoc, and it doesn't build against any Stackage LTS except the recently released LTS-17. Also, building pandoc from source takes quite some time and resources. But for what benefit? We're not using any special pandoc functionality whatsoever. It's just that it was all in Haskell and the entire build was orchestrated by cabal, but is all that complexity and resource consumption worth it? I think not. (Frankly, this whole thing was just a massive waste of time as the help text in Config.hs isn't generated at all, so we still need to do this manually. And then, the default key-bindings in core are unlikely to change ever again.) Let's simplify this: * drop all dependencies except base and just run it through runhaskell * add a Makefile and GH Actions workflow that invokes this after push * only ship the results in release tarball, not the scripts which are considered our dev infrastructure Related: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Mar 31, 2021
pandoc's API changes often enough that distros like Debian were patching our GenerateManpage.hs to work with their version of pandoc, and it doesn't build against any Stackage LTS except the recently released LTS-17. Also, building pandoc from source takes quite some time and resources. Therefore, separate it into its own cabal project and invoke it in CI to make sure we're releasing an up-to-date manpage, and don't encourage downstreams to rebuild it -- it's now just our dev tooling. (Uncached run of the generatemanpage workflow takes more than half an hour, which seems incredibly wasteful for what it does. The default key-bindings in core are unlikely to change ever again, the help text in Config.hs isn't generated at all, so we still need to do that thing manually, I'm really not convinced this is worth the trouble...) Closes: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Mar 31, 2021
pandoc's API changes often enough that distros like Debian were patching our GenerateManpage.hs to work with their version of pandoc, and it doesn't build against any Stackage LTS except the recently released LTS-17. Also, building pandoc from source takes quite some time and resources. Therefore, separate it into its own cabal project and invoke it in CI to make sure we're releasing an up-to-date manpage, and don't encourage downstreams to rebuild it -- it's now just our dev tooling. (Uncached run of the generatemanpage workflow takes more than half an hour, which seems incredibly wasteful for what it does. The default key-bindings in core are unlikely to change ever again, the help text in Config.hs isn't generated at all, so we still need to do that thing manually, I'm really not convinced this is worth the trouble...) Closes: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Mar 31, 2021
pandoc's API changes often enough that distros like Debian were patching our GenerateManpage.hs to work with their version of pandoc, and it doesn't build against any Stackage LTS except the recently released LTS-17. Also, building pandoc from source takes quite some time and resources. Therefore, separate it into its own cabal project and invoke it in CI to make sure we're releasing an up-to-date manpage, and don't encourage downstreams to rebuild it -- it's now just our dev tooling. (Uncached run of the generatemanpage workflow takes more than half an hour, which seems incredibly wasteful for what it does. The default key-bindings in core are unlikely to change ever again, the help text in Config.hs isn't generated at all, so we still need to do that thing manually, I'm really not convinced this is worth the trouble...) Closes: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Mar 31, 2021
pandoc's API changes often enough that distros like Debian were patching our GenerateManpage.hs to work with their version of pandoc, and it doesn't build against any Stackage LTS except the recently released LTS-17. Also, building pandoc from source takes quite some time and resources. Therefore, separate it into its own cabal project and invoke it in CI to make sure we're releasing an up-to-date manpage, and don't encourage downstreams to rebuild it -- it's now just our dev tooling. (Uncached run of the generatemanpage workflow takes more than half an hour, which seems incredibly wasteful for what it does, and that's the reason why I add GenerateManpage.cabal.project.freeze. The default key-bindings in core are unlikely to change ever again, the help text in Config.hs isn't generated at all, so we still need to do that thing manually, I'm really not convinced this is worth the trouble...) Closes: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Mar 31, 2021
pandoc's API changes often enough that distros like Debian were patching our GenerateManpage.hs to work with their version of pandoc, and it doesn't build against any Stackage LTS except the recently released LTS-17. Also, building pandoc from source takes quite some time and resources. But for what benefit? We're not using any special pandoc functionality whatsoever. It's just that it was all in Haskell and the entire build was orchestrated by cabal, but is all that complexity and resource consumption worth it? I think not. (Frankly, this whole thing was just a massive waste of time as the help text in Config.hs isn't generated at all, so we still need to do this manually. And then, the default key-bindings in core are unlikely to change ever again.) Let's simplify this: * drop all dependencies except base and just run it through runhaskell * add a Makefile and GH Actions workflow that invokes this after push * only ship the results in release tarball, not the scripts which are considered our dev infrastructure Closes: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
This was referenced Mar 31, 2021
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Apr 1, 2021
pandoc's API changes often enough that distros like Debian were patching our GenerateManpage.hs to work with their version of pandoc, and it doesn't build against any Stackage LTS except the recently released LTS-17. Also, building pandoc from source takes quite some time and resources. But for what benefit? We're not using any special pandoc functionality whatsoever. It's just that it was all in Haskell and the entire build was orchestrated by cabal, but is all that complexity and resource consumption worth it? I think not. (Frankly, this whole thing was just a massive waste of time as the help text in Config.hs isn't generated at all, so we still need to do this manually. And then, the default key-bindings in core are unlikely to change ever again.) Let's simplify this: * drop all dependencies except base and just run it through runhaskell * add a Makefile and GH Actions workflow that invokes this after push * only ship the results in release tarball, not the scripts which are considered our dev infrastructure Closes: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Apr 1, 2021
pandoc's API changes often enough that distros like Debian were patching our GenerateManpage.hs to work with their version of pandoc, and it doesn't build against any Stackage LTS except the recently released LTS-17. Also, building pandoc from source takes quite some time and resources. Therefore, separate it into its own cabal project and invoke it in CI to make sure we're releasing an up-to-date manpage, and don't encourage downstreams to rebuild it -- it's now just our dev tooling. (Uncached run of the generatemanpage workflow takes more than half an hour, which seems incredibly wasteful for what it does, and that's the reason why I add GenerateManpage.cabal.project.freeze. The default key-bindings in core are unlikely to change ever again, the help text in Config.hs isn't generated at all, so we still need to do that thing manually, I'm really not convinced this is worth the trouble...) Closes: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Apr 27, 2021
pandoc's API changes often enough that distros like Debian were patching our GenerateManpage.hs to work with their version of pandoc, and it doesn't build against any Stackage LTS except the recently released LTS-17. Also, building pandoc from source takes quite some time and resources. But for what benefit? We're not using any special pandoc functionality whatsoever. It's just that it was all in Haskell and the entire build was orchestrated by cabal, but is all that complexity and resource consumption worth it? I think not. (Frankly, this whole thing was just a massive waste of time as the help text in Config.hs isn't generated at all, so we still need to do this manually. And then, the default key-bindings in core are unlikely to change ever again.) Let's simplify this: * drop all dependencies except base and just run it through runhaskell * add a Makefile and GH Actions workflow that invokes this after push * only ship the results in release tarball, not the scripts which are considered our dev infrastructure Closes: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
liskin
added a commit
to liskin/xmonad
that referenced
this pull request
Apr 27, 2021
pandoc's API changes often enough that distros like Debian were patching our GenerateManpage.hs to work with their version of pandoc, and it doesn't build against any Stackage LTS except the recently released LTS-17. Also, building pandoc from source takes quite some time and resources. But for what benefit? We're not using any special pandoc functionality whatsoever. It's just that it was all in Haskell and the entire build was orchestrated by cabal, but is all that complexity and resource consumption worth it? I think not. (Frankly, this whole thing was just a massive waste of time as the help text in Config.hs isn't generated at all, so we still need to do this manually. And then, the default key-bindings in core are unlikely to change ever again.) Let's simplify this: * drop all dependencies except base and just run it through runhaskell * add a Makefile and GH Actions workflow that invokes this after push * only ship the results in release tarball, not the scripts which are considered our dev infrastructure Closes: xmonad#283 Related: xmonad#260 Related: xmonad#261 Related: xmonad#265 Related: xmonad#266 Related: xmonad#267 Related: xmonad#268
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.