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

[Vincent Hanquez]

On 2014-02-25 19:23, Gregory Collins wrote:
>
> On Mon, Feb 24, 2014 at 10:44 PM, Michael Snoyman <michael at snoyman.com 
> <mailto:michael at snoyman.com>> wrote:
>
>     But that's only one half of the "package interoperability" issue.
>     I face this first hand on a daily basis with my Stackage
>     maintenance. I spend far more time reporting issues of restrictive
>     upper bounds than I do with broken builds from upstream changes.
>     So I look at this as purely a game of statistics: are you more
>     likely to have code break because version 1.2 of text changes the
>     type of the map function and you didn't have an upper bound, or
>     because two dependencies of yours have *conflicting* versions
>     bounds on a package like aeson[2]? In my experience, the latter
>     occurs far more often than the former.
>
>
> That's because you maintain a lot of packages, and you're considering 
> buildability on short time frames (i.e. you mostly care about "does 
> all the latest stuff build right now?"). The consequences of violating 
> the PVP are that as a piece of code ages, the probability that it 
> still builds goes to *zero*, even if you go and dig out the old GHC 
> version that you were using at the time. I find this really 
> unacceptable, and believe that people who are choosing not to be 
> compliant with the policy are BREAKING HACKAGE and making life harder 
> for everyone by trading convenience now for guaranteed pain later. In 
> fact, in my opinion the server ought to be machine-checking PVP 
> compliance and refusing to accept packages that don't obey the policy.
If you're going to dig an old ghc version, what's stopping you from 
downloading old packages manually from hackage ? I'm sure it can even be 
automated (more or less).

However, I don't think we should optimise for this use case; I'ld rather 
use maintained packages that are regularly updated. And even if I wanted 
to use an old package, provided it's not tied to something fairly 
internals like GHC's api or such, in a language like haskell, porting to 
recent version of libraries should be easier than in most other language.

Furthermore, some old libraries should not be used anymore. Consider old 
libraries that have security issues for example. Whilst it's not the 
intent, It's probably a good thing that those old libraries don't build 
anymore, and people are forced to move to the latest maintained version.

The PvP at it stand seems to be a refuge for fossilised packages.

> Like Ed said, this is pretty cut and dried: we have a policy, you're 
> choosing not to follow it, you're not in compliance, you're breaking 
> stuff. We can have a discussion about changing the policy (and this 
> has definitely been discussed to death before), but I don't think your 
> side has the required consensus/votes needed to change the policy. As 
> such, I really wish that you would reconsider your stance here.

"we have a policy".

*ouch*, I'm sorry, but I find those biggoted views damaging in a nice 
inclusive haskell community (as I like to view it).

While we may have different opinions, I think we're all trying our best 
to contribute to the haskell ecosystem the way we see fit.

-- 
Vincent