search

haskell-infra / hackage-trustees

Issue tracker for Hackage maintainance and trustee operations
https://hackage.haskell.org/packages/trustees/
42 stars 7 forks source link

aeson-2.0.0.0 issues. #318

Closed phadej closed 2 years ago

phadej commented 2 years ago

FYI, when you make revisions, for packages not compatible with aeson-2.0.0.0, the proper upper bound is <1.6 (that is what should been there to begin with), not <2. It's possible that the aeson-1.6.0.0 will exist (though unluckily).

andreasabel commented 2 years ago

Well... I think there are two modes in which upper bounds are assigned:

  1. Pessimistic: The upper bounds determine a version set for which there is evidence of successful build. Restriction of upper bounds is not needed in the pessimistic flavor, but relaxation can occur when there is evidence of success.
  2. Optimistic: The upper bounds determine a version set for which there is no evidence of build failure. Restriction of upper bounds is necessary once a build failure is documented. (Relaxation is never needed.)

I would argue that if a package does not have an upper bound on aeson at all, it belongs into the optimistic ballpark. Thus, the proper restriction is aeson < 2 when there is evidence of build failure with aeson-2. As there is no aeson-1.6 yet, there cannot be evidence of build failure.
Should there be a aeson-1.6 in the future that produces build failures, further restrictions should be applied. Switching a package from aeson < infinity to aeson < 1.6 would imo mean to switch a package from optimistic to pessimistic; this might not be in the intention of the package author.

phadej commented 2 years ago

In my experience Hackage Trustees have no time to be optimistic. If maintainers are quick and do (optimistic) revisions themselves, that's great. But I aim that we don't need to revisit the same package-version twice or more times (for the same dependency!)

In fact, https://hackage.haskell.org/upload read about

Package uploaders may choose to exclude individual package uploads from curation, by setting the x-curation: field of the package's cabal file to uncurated. Packages which are uncurated have no expectations on them regarding versioning policy. Trustees or maintainers may adopt uncurated packages into the curated layer through metadata revisions. Metadata revisions must not set the value of the x-curation field to any variant of uncurated.

That implies that once we do revision, we curate it to the end of time. If interpreted strictly,` we should add upper bounds to all dependencies when we make a revision, to adhere to the PVP.

phadej commented 2 years ago

For example, @sjakobi made revisions for twenty yaml package versions with aeson <2. If for whatever reason, aeson-1.6 is released which still breaks yaml, that's another 20 revisions. However, if the first revision were with aeson <1.6 bound, then it would be probably enough to make one or two (one per major series) relaxing revisions (in case the aeson-1.6 change is not breaking yaml). Less work in total.

As there are plenty of responsive Hackage Trustees, you Andreas included, the delay caused waiting for relaxing revision is a lot less then pain caused by broken builds locally and CIs etc. all over the place.

andreasabel commented 2 years ago

@phadej wrote:

But I aim that we don't need to revisit the same package-version twice or more times (for the same dependency!)

I can live with that as long as we only start restricting once the first failed build happens. (And this should be the case...) To express it in my previous terminology: We can switch a package from optimistic to pessimistic once optimism has failed.

phadej commented 2 years ago

I didn't say that we need to restrict packages which are building fine or there are no install plans because dependencies are preventing them.

This issue was motivated by @sjakobi making aeson <2 revisions (e.g. https://hackage.haskell.org/package/yaml-0.11.6.0/revisions/). That should been aeson <1.6. (But not worth making them again anymore, so just FYI). yaml was failing to build.