Upper bounds in PVP WAS: Gearing up (again) for the next release: 2014.2.0.0

Starting a separate subject for this response so I don't drive Mark
absolutely crazy.
On Wed, Apr 9, 2014 at 3:19 PM, Vincent Hanquez
On 2014-04-08 16:29, Gregory Collins wrote:
Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the Hackage package versioning policy and until this is fixed I think that issue precludes it from being included in the platform.
First of, you might want to read up on the difference between the definition of policy and rules/law. "obey" doesn't have its place here.
Second, the tls/crypto ecosystem is following most of the PvP apart from "3 Dependencies in Cabal".
Third, The PvP doesn't actually *enforce* any requirements on dependencies. I can only see CAN, SHOULD, MAY in the section 3. On the other hand, you can find MUST in section "2 Versions numbers", and as far I'm concerned the tls/crypto ecosystem is following each requirements in this section.
Reading that section myself, I have to say I agree with Vincent's interpretation. It would seem therefore that the packages under question are in fact in compliance with the requirements of the PVP, and therefore there's no blocker to including tls in the platform in the future, regardless of how you interpret the HP's statement "we follow the Haskell Package Versioning Policy". So if someone wants to object to inclusion of tls, it would have to be on technical grounds, rather than simply quoting a document. Michael

On 2014-04-10 at 13:00:50 +0200, Michael Snoyman wrote: [...]
Third, The PvP doesn't actually *enforce* any requirements on dependencies. I can only see CAN, SHOULD, MAY in the section 3. On the other hand, you can find MUST in section "2 Versions numbers", and as far I'm concerned the tls/crypto ecosystem is following each requirements in this section.
Reading that section myself, I have to say I agree with Vincent's interpretation. It would seem therefore that the packages under question are in fact in compliance with the requirements of the PVP, and therefore there's no blocker to including tls in the platform in the future, regardless of how you interpret the HP's statement "we follow the Haskell Package Versioning Policy".
Just a thought: Maybe the requirement levels stated in the PVP in terms of may/should/must could benefit from a bit more formalization in terms of something like RFC2119. [RFC2119]: http://tools.ietf.org/html/rfc2119

On 2014-04-10 13:52, Herbert Valerio Riedel wrote:
Just a thought: Maybe the requirement levels stated in the PVP in terms of may/should/must could benefit from a bit more formalization in terms of something like RFC2119.
[RFC2119]: http://tools.ietf.org/html/rfc2119
+1. (I think that the RFCs terms may actually have been the intended meaning, but it could definitely stand to be spelled out explicitly in either case.)

I also like this change, and a lot of people use RFC2119 formalization
even without direct reference I find. So I'm +1 on adopting it.
On Thu, Apr 10, 2014 at 7:25 AM, Bardur Arantsson
On 2014-04-10 13:52, Herbert Valerio Riedel wrote:
Just a thought: Maybe the requirement levels stated in the PVP in terms of may/should/must could benefit from a bit more formalization in terms of something like RFC2119.
[RFC2119]: http://tools.ietf.org/html/rfc2119
+1. (I think that the RFCs terms may actually have been the intended meaning, but it could definitely stand to be spelled out explicitly in either case.)
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

It seems like this issue has clearly been the source of
disagreement/misunderstanding, so +1 from me too. The harder question
is precisely what changes should be made.
On Thu, Apr 10, 2014 at 8:38 AM, Austin Seipp
I also like this change, and a lot of people use RFC2119 formalization even without direct reference I find. So I'm +1 on adopting it.
On Thu, Apr 10, 2014 at 7:25 AM, Bardur Arantsson
wrote: On 2014-04-10 13:52, Herbert Valerio Riedel wrote:
Just a thought: Maybe the requirement levels stated in the PVP in terms of may/should/must could benefit from a bit more formalization in terms of something like RFC2119.
[RFC2119]: http://tools.ietf.org/html/rfc2119
+1. (I think that the RFCs terms may actually have been the intended meaning, but it could definitely stand to be spelled out explicitly in either case.)
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Regards,
Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 2014-04-10 13:52, MightyByte wrote:
It seems like this issue has clearly been the source of disagreement/misunderstanding, so +1 from me too. The harder question is precisely what changes should be made. Oh please.
While it was not explicitely stated as being RFC2119, RFC2119 is still *common* *sense*, and probably intented for universal communication with non native english speaker. English speakers (which many PvP original authors are) would have very likely the correct (and RFC2119 compliant) understanding of those words. Also must I say that RFC2119 is a document from 1997, predating the PvP by many many years. As Bardur said, "I think that the RFCs terms may actually have been the intended meaning" Suggesting that this was the source of disagreement/misunderstanding, is in my opinion disingenuous at best. Otherwise I'm all for (+1) spelling out that the PvP is following RFC2119; there's no harm for being crystal clear about this. -- Vincent

On 2014-04-10 15:41, Vincent Hanquez wrote:
On 2014-04-10 13:52, MightyByte wrote:
It seems like this issue has clearly been the source of disagreement/misunderstanding, so +1 from me too. The harder question is precisely what changes should be made. Oh please.
Don't be to quick to judge -- I think applying the http://en.wikipedia.org/wiki/Principle_of_charity might be in order (and not just in this particular sub-thread). There may be quite a bit of wiggle-room for interpretation here, but... (see below)
Otherwise I'm all for (+1) spelling out that the PvP is following RFC2119; there's no harm for being crystal clear about this.
Maybe you should just officially propose a simple amendment to the PVP stating this and we'll see how many (or: if any) of the originators of the PVP (dis)agree? Of course, we'll also see how many other interested parties (dis)agree. Personally, I'd weigh the opinions of the originators significantly more heavily of course, but this *is* a pseudo-democratic process, so let's see what happens :) Regards,

On Thu, Apr 10, 2014 at 9:41 AM, Vincent Hanquez
On 2014-04-10 13:52, MightyByte wrote:
It seems like this issue has clearly been the source of disagreement/misunderstanding, so +1 from me too. The harder question is precisely what changes should be made.
English speakers (which many PvP original authors are) would have very likely the correct (and RFC2119 compliant) understanding of those words.
Not at all. Natural spoken English simply isn't that precise. From http://thesaurus.com/browse/should: "As with shall and will, most educated native speakers of American English do not follow the textbook rule in making a choice between should and would. See also shall." The PVP is not written in the style of RFC2119, so I think it's quite reasonable to interpret it as you would interpret normal English speech. "When publishing a Cabal package, you should ensure that your dependencies in the build-depends field are accurate. This means specifying not only lower bounds, but also upper bounds on every dependency." I as a native English speaker read that to mean that upper bounds MUST be specified on every dependency if you want to comply with the spirit of that document.
Suggesting that this was the source of disagreement/misunderstanding, is in my opinion disingenuous at best.
No. Now we see that this is exactly the source of at least one misunderstanding.
Otherwise I'm all for (+1) spelling out that the PvP is following RFC2119; there's no harm for being crystal clear about this.
Here we're in agreement.

On 2014-04-10 15:04, MightyByte wrote:
The PVP is not written in the style of RFC2119, so I think it's quite reasonable to interpret it as you would interpret normal English speech.
"When publishing a Cabal package, you should ensure that your dependencies in the build-depends field are accurate. This means specifying not only lower bounds, but also upper bounds on every dependency."
I as a native English speaker read that to mean that upper bounds MUST be specified on every dependency if you want to comply with the spirit of that document.
There would be maybe some doubts, provided that was the only use, but you can find MUST correctly specified in the first section multiple times. For me, it's a clear sign that the authors meant to differentiate between the levels. -- Vincent

There are no uses of the string "MUST", so I did not use the RFC2119
interpretation. When I read "not only lower bounds, but also upper
bounds on every dependency" I interpret that to be a pretty strong
imperative. So let's definitely get this clarified.
On Thu, Apr 10, 2014 at 10:17 AM, Vincent Hanquez
On 2014-04-10 15:04, MightyByte wrote:
The PVP is not written in the style of RFC2119, so I think it's quite reasonable to interpret it as you would interpret normal English speech.
"When publishing a Cabal package, you should ensure that your dependencies in the build-depends field are accurate. This means specifying not only lower bounds, but also upper bounds on every dependency."
I as a native English speaker read that to mean that upper bounds MUST be specified on every dependency if you want to comply with the spirit of that document.
There would be maybe some doubts, provided that was the only use, but you can find MUST correctly specified in the first section multiple times. For me, it's a clear sign that the authors meant to differentiate between the levels.
-- Vincent

1) The PVP is not written in RFC style: It is conversational and addresses the reader direction. 2) It's terms aren't those of RFC 2119. 3) The phrase "you should ensure" in section 3 was clearly meant that it was expected of the maintainer. Including upper bounds. Now, if someone would like to have a go at re-writing the PVP in the style of an RFC, so that if PVP conformance is more rigorously defined, (which will surely explicitly reference RFC 2119), please write up a version (and a new thread) and we'll discuss it. - Mark

Hello *, To get the balling rolling, I've converted the mediawiki version of the PVP to markdown for easy editing via GitHub. Please note this is just a suggestion, there a certainly other possible workflows for collaborative editing; However using GitHub provides the following features: - A web-based Markdown editor - Decentralized: everyone can fork the repo (and you can see the fork-graph), everyone can steal (aka 'git pull') each others commit into his own repo. - Branching inside a repo (e.g. for multiple variants) - Annotating/commenting patches TLDR: feel free to fork (or ignore) https://github.com/hvr/PVP HTH hvr On 2014-04-10 at 16:36:59 +0200, Mark Lentczner wrote:
1) The PVP is not written in RFC style: It is conversational and addresses the reader direction. 2) It's terms aren't those of RFC 2119. 3) The phrase "you should ensure" in section 3 was clearly meant that it was expected of the maintainer. Including upper bounds.
Now, if someone would like to have a go at re-writing the PVP in the style of an RFC, so that if PVP conformance is more rigorously defined, (which will surely explicitly reference RFC 2119), please write up a version (and a new thread) and we'll discuss it.
- Mark _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- "Elegance is not optional" -- Richard O'Keefe

Am 10.04.2014 20:27, schrieb Herbert Valerio Riedel:
Hello *,
To get the balling rolling, I've converted the mediawiki version of the PVP to markdown for easy editing via GitHub. Please note this is just a suggestion, there a certainly other possible workflows for collaborative editing; However using GitHub provides the following features:
- A web-based Markdown editor
- Decentralized: everyone can fork the repo (and you can see the fork-graph), everyone can steal (aka 'git pull') each others commit into his own repo.
- Branching inside a repo (e.g. for multiple variants)
- Annotating/commenting patches
TLDR: feel free to fork (or ignore) https://github.com/hvr/PVP
Btw. it simplifies merging if the content is formatted one-sentence or one clause per line.

I haven't carefully studied the reason, but the crypto-related packages
cause us more build problems than any other family of packages.
I'm sure we're not the only ones; that's probably why Greg and
others were assuming that they don't comply.
The rampant lack of dependency upper bounds in these
package make them extremely difficult and frustrating to
install.
If you try to install a package depending on tls that is older
than a month or two, it's just a nightmare. One after the next,
crypto packages trick cabal into committing early to a
version that is too new, and then the build fails with some
complex chain of broken dependencies. You fix that one in
cabal.config, and repeat.
Even if the wording about supplying upper bounds in PVP
is "SHOULD", in my opinion that means MUST for inclusion
in HP. Packages in HP are supposed to be stable.
However, I would really like to see tls in HP. Why not just
add the upper bounds?
Thanks,
Yitz
On Thu, Apr 10, 2014 at 2:00 PM, Michael Snoyman
Starting a separate subject for this response so I don't drive Mark absolutely crazy.
On Wed, Apr 9, 2014 at 3:19 PM, Vincent Hanquez
wrote: On 2014-04-08 16:29, Gregory Collins wrote:
Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the Hackage package versioning policy and until this is fixed I think that issue precludes it from being included in the platform.
First of, you might want to read up on the difference between the definition of policy and rules/law. "obey" doesn't have its place here.
Second, the tls/crypto ecosystem is following most of the PvP apart from "3 Dependencies in Cabal".
Third, The PvP doesn't actually *enforce* any requirements on dependencies. I can only see CAN, SHOULD, MAY in the section 3. On the other hand, you can find MUST in section "2 Versions numbers", and as far I'm concerned the tls/crypto ecosystem is following each requirements in this section.
Reading that section myself, I have to say I agree with Vincent's interpretation. It would seem therefore that the packages under question are in fact in compliance with the requirements of the PVP, and therefore there's no blocker to including tls in the platform in the future, regardless of how you interpret the HP's statement "we follow the Haskell Package Versioning Policy".
So if someone wants to object to inclusion of tls, it would have to be on technical grounds, rather than simply quoting a document.
Michael
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (10)
-
Austin Seipp
-
Bardur Arantsson
-
Henning Thielemann
-
Herbert Valerio Riedel
-
John Wiegley
-
Mark Lentczner
-
Michael Snoyman
-
MightyByte
-
Vincent Hanquez
-
Yitzchak Gale