freckle-app 1.0.1.0

[alexeyzab]

ekg-core (Eric Conlon ejconlon@gmail.com @ejconlon, Library and exe bounds failures) (not present) depended on by:

• freckle-app-1.0.1.0 (>=0.1.1.7). Freckle Engineering freckle-engineering@renaissance.com @pbrisbin @mjgpy3 @StevenXL. @freckle. Used by: library

[pbrisbin]

👋 Can you clarify what needs to happen here? It seems like ekg-core is present on master.

[alexeyzab]

Seems like it's been disabled:

        - ekg-core < 0 # tried ekg-core-0.1.1.7, but its *library* does not support: base-4.15.0.0
        - ekg-core < 0 # tried ekg-core-0.1.1.7, but its *library* does not support: ghc-prim-0.7.0

Sorry for the ping, I guess not much can be done here right now

[ejconlon]

@pbrisbin Though I no longer use ekg, I am a maintainer. If you submit a PR I can help merge, and I can also get the bounds updated in Hackage.

[pbrisbin]

Hi @ejconlon sorry, it took me a minute to look into this again but those bounds seem fixed on master ekg-core as of L0neGamer/ekg-core#43, so we just need a release?

[pbrisbin]

Though I no longer use ekg, I am a maintainer

@ejconlon ping on this please -- this is blocking a few of our packages getting (back) into Stackage now. And there is L0neGamer/ekg-core#47 ;)

[bergmark]

freckle-app was disabled when we updated to aeson 2, so I'll close this.

[pbrisbin]

@bergmark is there an Issue open anywhere tracking the aeson-2.0 breakage as it relates to our packages (including freckle-app). I suspect we'll have a lot to do on this front, and I haven't gotten any notifications about it besides this comment.

[bergmark]

Since we upgraded we no longer maintain the tracking issue. But if you search for freckle-app in https://github.com/commercialhaskell/stackage/blob/master/build-constraints.yaml you will find some mentions on what's missing (some info may be out of date, we regenerate these things ocassionally). You can also build your project with the latest nightly snapshot to get an up-to-date view.

[pbrisbin]

Apologies for asking some follow-ups, and do point me at any general docs if they exist, but

Since we upgraded we no longer maintain the tracking issue

What does "we upgraded" and "the tracking issue" mean here?

I'm guessing it means "moved to aeson-2.0" and "an Issue indicating packages broken by aeson-2.0". If that's the case, then my original question still stands -- I never saw such an Issue to begin with, was there one (that is no longer maintained)?

My experience in this eco-system has been:

• Get your package in
• If something changes and you get a bound added or booted out, an Issue like this is opened
• Fix your stuff, maintainers remove that bound or put you back, and this Issue gets closed

I realize this is pretty naive given the sorts of scenarios that may happen. For example, we have packages with old versions in lts-18 with an upper bound, but the new version works with nightly and the bound should be removed in lts-19. I have zero idea how that gets managed given the single build-constraints file on main...

You can also build your project with the latest nightly snapshot to get an up-to-date view.

Of course, but I have been using Issues such as this one as a TODO list of when I need to -- so I'd just like to understand better when I can and can't expect them to be opened and closed.

[bergmark]

Apologies for asking some follow-ups,

No worries. It can be hard to know what is going on in the stackage workflow. We have been working on tooling to make things more transparent to maintainers, but we have not started to use it fully yet.

I'm guessing it means "moved to aeson-2.0" and "an Issue indicating packages broken by aeson-2.0". If that's the case, then my original question still stands -- I never saw such an Issue to begin with, was there one (that is no longer maintained)?

Correct, #6217. Looks like you were not mentioned in the original issue. I suspect freckle-app was either not in nightly at that point, or we were on a version that did not have an upper bound on aeson (e.g. https://hackage.haskell.org/package/freckle-app-1.0.2.7) which means you wouldn't get an automated ping. @juhp put in a lot of effort to open issues on affected packages, but our tooling to detect which packages we should be checking was not in place at that point. This should be easier to do going forward, but we will still probably use it selectively on issues with large impact since it's not fully automated.

In general, when you are transitively affected (here datadog had issues) then we haven't had anything in place to automate notifying everyone that's affected. We can do better now, but it requires that we put in some extra effort.

I have zero idea how that gets managed given the single build-constraints file

LTS is harder to track. If you want to add or update packages there then you should file an issue against https://github.com/commercialhaskell/lts-haskell. I have a proposal at #6359 to have a separate build-constraints file for LTS as I think this will make it easier for us stackage curators and maintainers to work with it. It would bring the LTS flow much closer to what we do for nightly.

Another thing that I didn't get around to yet is to do some sort of monthly update on packages that have been dropped. The tooling for this was recently added so it should be straight forward.

[pbrisbin]

Thank you very much for the extra explanation!

It sounds like my expectations are mostly correct, and it was the complexity of the scenario (aeson -> datadog -> freckle-app) that caused the lack of a notification.

I will mostly focus on keeping our packages in nightly (via the main build-constraints); I'm still not sure what my responsibilities are for a scenario like:

• freckle-app 1.0.x is in lts-18.x
• freckle-app got "< 1.1" added in build-constraints
• freckle-app got disabled in build-constraints
• We (think we) fixed freckle-app in 1.1.x

What do I have to do, if anything, to ensure that lts-18.(x + 1) continues to have 1.0.x, and lts-19 gets 1.1.x?

After going through all of this, I get the impression the fixed freckle-app-1.1.x, assuming it compiles against nightly, can just be re-added in build-constraints, and that this will ensure lts-19 gets it. Is that right?

And will lts-18.(x + 1) just keep it without any actions on my part?