4 ms·

>Yet you expect other people, many of them volunteers, to take up the busywork of bounds maintenance, for free, so that your immense builds work. I have no ide

>Yet you expect other people, many of them volunteers, to take up the busywork of bounds maintenance, for free, so that your immense builds work. I have no idea how you came up with that absurd non-sequitur. >Yesod is not broken. It builds just fine using a sane build tool. Yesod does not become broken because you insist on using a tool that crafts arbitrary build plans. Nothing in that is accurate at all. There is nothing arbitrary about a cabal build plan.

massysett 10y ago
Since Yesod builds just fine, explain how it is "broken"?
- HaskellMuppet 10y ago
  The fallacy of that argument is assuming that tool X being able to build artifact Y means that X is "sane". The only thing this says is that tool X is able to build Y, nothing more and nothing less. For instance, I could easily implement a tool which is only capable to build `yesod`, and only `yesod`. Would that be a "sane" build-tool?
dllthomas 10y ago
> > Yet you expect other people, many of them volunteers, to take up the busywork of bounds maintenance, for free, so that your immense builds work. > I have no idea how you came up with that absurd non-sequitur. You can dispute the accuracy, but "the PVP as written puts too much burden on maintainers" was a part of the justification at the time for removing upper bounds. See, for instance, the following from someone with no connection to FP Complete that I'm aware of: https://mail.haskell.org/pipermail/haskell-cafe/2012-August/102894.html https://mail.haskell.org/pipermail/haskell-cafe/2012-August/... "As someone who recurrently is nudging a large number of maintainers every major ghc release to bump their bounds, I favor the no upper bounds approach!" It was not a non-sequitur, but an objection to your assertion that there was no problem with the PVP.
- hvr_ 10y ago
  > See, for instance, the following from someone with no connection to FP Complete that I'm aware of You may be interested to know that Carter (the guy you're quoting) knows better today, and has even become a Hackage Trustee whose mission is more or less to uphold those very PVP upper bounds ;-)
  - dllthomas 10y ago
    Amusing, but orthogonal to my point, which was that the move away from parts of the PVP was motivated by real concerns, and moreover that the comment above was specifically an obvious reference to concerns that had been voiced during that time. I am not arguing that the move away from the PVP was correct - I was uncertain at the time and I remain uncertain.
    - mightybyte 10y ago
      The concerns you're talking about here were primarily deficiencies in tooling, not an inherent problem with the PVP. Many of those deficiencies have been fixed (for example, --allow-newer) or there is work in progress that will fix them (cabal new-build, cabal.project files, etc).
      - dllthomas 10y ago
        That may very well be the case. Again, I'm not arguing about the PVP. I'm arguing that discussion of those concerns is not non sequitur.
- MustardTiger 10y ago
  > See, for instance, the following from someone with no connection to FP Complete that I'm aware of: https://mail.haskell.org/pipermail/haskell-cafe/2012-August/.. https://mail.haskell.org/pipermail/haskell-cafe/2012-August/.... Yes, people make mistakes. He no longer favors that approach, as he learned how bad it is. The difference is that FPC employees still continue to push it even when they know the problems.

massysett 10y ago

Since Yesod builds just fine, explain how it is "broken"?

HaskellMuppet 10y ago
The fallacy of that argument is assuming that tool X being able to build artifact Y means that X is "sane". The only thing this says is that tool X is able to build Y, nothing more and nothing less. For instance, I could easily implement a tool which is only capable to build `yesod`, and only `yesod`. Would that be a "sane" build-tool?

dllthomas 10y ago

> > Yet you expect other people, many of them volunteers, to take up the busywork of bounds maintenance, for free, so that your immense builds work. > I have no idea how you came up with that absurd non-sequitur. You can dispute the accuracy, but "the PVP as written puts too much burden on maintainers" was a part of the justification at the time for removing upper bounds. See, for instance, the following from someone with no connection to FP Complete that I'm aware of: https://mail.haskell.org/pipermail/haskell-cafe/2012-August/102894.html https://mail.haskell.org/pipermail/haskell-cafe/2012-August/... "As someone who recurrently is nudging a large number of maintainers every major ghc release to bump their bounds, I favor the no upper bounds approach!" It was not a non-sequitur, but an objection to your assertion that there was no problem with the PVP.

hvr_ 10y ago
> See, for instance, the following from someone with no connection to FP Complete that I'm aware of You may be interested to know that Carter (the guy you're quoting) knows better today, and has even become a Hackage Trustee whose mission is more or less to uphold those very PVP upper bounds ;-)
- dllthomas 10y ago
  Amusing, but orthogonal to my point, which was that the move away from parts of the PVP was motivated by real concerns, and moreover that the comment above was specifically an obvious reference to concerns that had been voiced during that time. I am not arguing that the move away from the PVP was correct - I was uncertain at the time and I remain uncertain.
  - mightybyte 10y ago
    The concerns you're talking about here were primarily deficiencies in tooling, not an inherent problem with the PVP. Many of those deficiencies have been fixed (for example, --allow-newer) or there is work in progress that will fix them (cabal new-build, cabal.project files, etc).
    - dllthomas 10y ago
      That may very well be the case. Again, I'm not arguing about the PVP. I'm arguing that discussion of those concerns is not non sequitur.
MustardTiger 10y ago
> See, for instance, the following from someone with no connection to FP Complete that I'm aware of: https://mail.haskell.org/pipermail/haskell-cafe/2012-August/.. https://mail.haskell.org/pipermail/haskell-cafe/2012-August/.... Yes, people make mistakes. He no longer favors that approach, as he learned how bad it is. The difference is that FPC employees still continue to push it even when they know the problems.