haskell-infra / hackage-trustees

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

shake-0.17.7 doesn't work with older GHCs #217

Closed vmchale closed 5 years ago

vmchale commented 5 years ago

see hackage matrix here

phadej commented 5 years ago

META:

@haskell-infra/hackage-trustees should we have a policy that issues like this: regarding just released versions of packages, should first be reported to the maintainer. In this case Neil is very responsive maintainer, and probably would fix issue himself.

hvr commented 5 years ago

Fwiw; It appears @ndmitchell did resolve this already via https://hackage.haskell.org/package/shake-0.17.7/revisions/ - thus closing this


as for

should we have a policy that issues like this: regarding just released versions of packages, should first be reported to the maintainer. In this case Neil is very responsive maintainer, and probably would fix issue himself.

I think it's sensible to have the maintainer be informed as well. The way the Hackage/Cabal ecosystem is designed we need to act in a timely matter, and the more people you notify, the lower the expectation value of the response time fixing the build-plan regression in the system; and minimizing the amount of inaccurate/wrong metadata (including minimzing the phases in the time-dimension) in the Hackage collection is basically the reason of existence of the Hackage Trustees... ;-)

So what I'm saying is, that ideally issues ought to be brought to the maintainers as well as the trustees at the same time; this can be done by either

  1. filing a ticket in the maintainer's issue tracker and notifying trustees via a mention of the @haskell-infra/hackage-trustees handle, or
  2. by filing a ticket here in the issue tracker and notifying the package's maintainer via github mentions of the respective username handles.

(or in the case of emails communication by including e.g. trustees@hackage.haskell.org in the set of recipients)