Re: qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method)

On 2014-02-25 20:38, Michael Snoyman wrote:

On Tue, Feb 25, 2014 at 9:23 PM, Gregory Collins mailto:greg@gregorycollins.net> wrote:

I really don't like this appeal to authority. I don't know who the "royal we" is that you are referring to here, and I don't accept the premise that the rest of us must simply adhere to a policy because "it was decided." "My side" as you refer to it is giving concrete negative consequences to the PVP. I'd expect "your side" to respond in kind, not simply assert that we're "breaking Hackage" and other such hyperbole.

Strongly agreed.

Of course, people who want to follow PVP are also going to need tooling to make sure their programs still build in the future because so many people have broken the policy in the past -- that's where proposed kludges like "cabal freeze" are going to come in.

This is where we apparently fundamentally disagree. cabal freeze IMO is not at all a kludge. It's the only sane approach to reliable builds. If I ran my test suite against foo version 1.0.1, performed manual testing on 1.0.1, did my load balancing against 1.0.1, I don't want some hotfix build to automatically get upgraded to version 1.0.2, based on the assumption that foo's author didn't break anything.

This is probably also the only sane approach at the moment for safe builds. Considering the whole hackage infrastructure is quite insecure at the moment (http download/upload, no package signing, etc), freezing your build packages after you have audited them is probably the only sensible way to ship secure products. In a production environment (at 2 different work places), i've seen two approachs for proper builds: * still using hackage directly, but pinning each package with a cryptographic hash on your build site. * a private hackage instance where packages are manually imported. build is using exclusively this. Using hackage directly(+ depending on the PvP) is at the moment too much like playing russian roulette. -- Vincent