New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cryptonite-0.23 #2469

Closed
juhp opened this Issue Apr 26, 2017 · 16 comments

Comments

Projects
None yet
5 participants
@juhp
Contributor

juhp commented Apr 26, 2017

cryptonite-0.23 (Vincent Hanquez @vincenthz) is out of bounds for:

juhp added a commit that referenced this issue Apr 26, 2017

@vincenthz

This comment has been minimized.

Show comment
Hide comment
@vincenthz

vincenthz Apr 26, 2017

Contributor

some *** hackage trustee put some *** bounds on tls dependencies for no reason in a revision. the original package compiles very well, can stackage ignore revision ?

Contributor

vincenthz commented Apr 26, 2017

some *** hackage trustee put some *** bounds on tls dependencies for no reason in a revision. the original package compiles very well, can stackage ignore revision ?

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Apr 26, 2017

Contributor

I wish we could opt out of them, they were a terrible idea hoisted on the community against our will for bad technical reasons. Now Stackage is stuck with them, like all other bad decisions that are made upstream of us.

This specific action seems contrary to normal Hackage Trustee policy, but in line with the unofficial policy spelled out in this email: https://gist.github.com/snoyberg/e556b855b023cd04f6fd5e74bb94a52d. I wonder if any other Hackage Trustees will ever weigh in on if this is acceptable trustee behavior.

Contributor

snoyberg commented Apr 26, 2017

I wish we could opt out of them, they were a terrible idea hoisted on the community against our will for bad technical reasons. Now Stackage is stuck with them, like all other bad decisions that are made upstream of us.

This specific action seems contrary to normal Hackage Trustee policy, but in line with the unofficial policy spelled out in this email: https://gist.github.com/snoyberg/e556b855b023cd04f6fd5e74bb94a52d. I wonder if any other Hackage Trustees will ever weigh in on if this is acceptable trustee behavior.

@vincenthz

This comment has been minimized.

Show comment
Hide comment
@vincenthz

vincenthz Apr 26, 2017

Contributor

Is there a fundamental reason why we can't opt out or anything to do in this area ?

Contributor

vincenthz commented Apr 26, 2017

Is there a fundamental reason why we can't opt out or anything to do in this area ?

@alanz

This comment has been minimized.

Show comment
Hide comment
@alanz

alanz Apr 26, 2017

Contributor

In the same way that there is a build process for stackage to make sure everything works together, there is one for hackage too.

Both of these are used to point out issues that need to be resolved, to the benefit of the community.

There is nothing malicious about it. Occasionally mistakes get made, and they should be fixed, on whichever side is affected. This is all to the benefit of the greater haskell community.

Contributor

alanz commented Apr 26, 2017

In the same way that there is a build process for stackage to make sure everything works together, there is one for hackage too.

Both of these are used to point out issues that need to be resolved, to the benefit of the community.

There is nothing malicious about it. Occasionally mistakes get made, and they should be fixed, on whichever side is affected. This is all to the benefit of the greater haskell community.

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Apr 26, 2017

Contributor

Please explain how the added, clearly unnecessary upper bounds in this case help anyone.

Contributor

snoyberg commented Apr 26, 2017

Please explain how the added, clearly unnecessary upper bounds in this case help anyone.

@alanz

This comment has been minimized.

Show comment
Hide comment
@alanz

alanz Apr 26, 2017

Contributor

I suspect this case may be an error. But this should not invalidate the process as a whole. I am looking into it.

Contributor

alanz commented Apr 26, 2017

I suspect this case may be an error. But this should not invalidate the process as a whole. I am looking into it.

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Apr 26, 2017

Contributor

@vincenthz I think I can propose an opt-in field added to the build-constraints.yaml which states that Hackage revisions should be ignored for a package. cabal users and people making custom snapshots will still be affected by the decisions of Hackage Trustees (which apparently we have no input on at all), but at least normal Stackage curation will be insulated from such decisions and "errors."

Contributor

snoyberg commented Apr 26, 2017

@vincenthz I think I can propose an opt-in field added to the build-constraints.yaml which states that Hackage revisions should be ignored for a package. cabal users and people making custom snapshots will still be affected by the decisions of Hackage Trustees (which apparently we have no input on at all), but at least normal Stackage curation will be insulated from such decisions and "errors."

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Apr 26, 2017

Contributor

As a side note, it's really tiring constantly having to modify tooling to work around new "features" added upstream that cause nothing but harm.

Contributor

snoyberg commented Apr 26, 2017

As a side note, it's really tiring constantly having to modify tooling to work around new "features" added upstream that cause nothing but harm.

@juhp

This comment has been minimized.

Show comment
Hide comment
@juhp

juhp Apr 26, 2017

Contributor

It might nice if Hackage revisions were at least documented somewhere - like in a github repo.

Contributor

juhp commented Apr 26, 2017

It might nice if Hackage revisions were at least documented somewhere - like in a github repo.

@alanz

This comment has been minimized.

Show comment
Hide comment
@alanz

alanz Apr 26, 2017

Contributor

The revision for tls has been updated. http://hackage.haskell.org/package/tls-1.3.10/revisions/

Contributor

alanz commented Apr 26, 2017

The revision for tls has been updated. http://hackage.haskell.org/package/tls-1.3.10/revisions/

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Apr 26, 2017

Contributor

Thanks Alan.

Contributor

snoyberg commented Apr 26, 2017

Thanks Alan.

snoyberg added a commit to fpco/stackage-curator that referenced this issue Apr 26, 2017

juhp added a commit that referenced this issue Apr 26, 2017

Revert "cryptonite < 0.23 (#2469)"
with fixed revision

This reverts commit a4f6c58.

@juhp juhp closed this Apr 26, 2017

@juhp

This comment has been minimized.

Show comment
Hide comment
@juhp

juhp Apr 26, 2017

Contributor

Thanks!

Contributor

juhp commented Apr 26, 2017

Thanks!

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Apr 26, 2017

Contributor

I've implemented this new feature, but consider it experimental pending other curator feedback. I'll put up a post with information in the next day.

Contributor

snoyberg commented Apr 26, 2017

I've implemented this new feature, but consider it experimental pending other curator feedback. I'll put up a post with information in the next day.

@juhp

This comment has been minimized.

Show comment
Hide comment
@juhp

juhp Apr 26, 2017

Contributor

cryptonite-0.23 (Vincent Hanquez @vincenthz) is out of bounds for:

Contributor

juhp commented Apr 26, 2017

cryptonite-0.23 (Vincent Hanquez @vincenthz) is out of bounds for:

@juhp juhp reopened this Apr 26, 2017

juhp added a commit that referenced this issue Apr 26, 2017

@alanz

This comment has been minimized.

Show comment
Hide comment
Contributor

alanz commented Apr 26, 2017

juhp added a commit that referenced this issue Apr 26, 2017

Revert "re-instate cryptonite < 0.23 (#2469)"
fixed with avers revision

This reverts commit 8ab2f4d.
@DanBurton

This comment has been minimized.

Show comment
Hide comment
@DanBurton

DanBurton Apr 26, 2017

Contributor

I am +1 on stackage builds being able to selectively ignore revisions (or version bounds in general) when they are unhelpful. But we should avoid using this ability and just sort things out with trustees and package owners if at all possible.

Perhaps we should go so far as to say that Nightlies can ignore revisions, but LTS cannot? I do really want to avoid getting into a situation where people try to use a stackage snapshot, only to be blocked because their tooling says that the version constraints are wrong.

Contributor

DanBurton commented Apr 26, 2017

I am +1 on stackage builds being able to selectively ignore revisions (or version bounds in general) when they are unhelpful. But we should avoid using this ability and just sort things out with trustees and package owners if at all possible.

Perhaps we should go so far as to say that Nightlies can ignore revisions, but LTS cannot? I do really want to avoid getting into a situation where people try to use a stackage snapshot, only to be blocked because their tooling says that the version constraints are wrong.

@juhp juhp closed this May 2, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment