NMU for the amazonka-* package family

[endgame]

I am filing this issue to start the Non-Maintainer Upload process for the amazonka* family of packages.

amazonka (and gogol) are extremely useful libraries, and are key to writing cloud-native Haskell. Unfortunately, the most recent hackage release for amazonka is over two years old, and is missing features like:

• The Hong Kong region, aka ap-east-1
• Support for current versions of http-client, unliftio-core, bytestring, base, and time
• New EC2 instance types

As a result, the folk recommendation seems to be "use a private fork", "point at a PR branch", or "use latest master".

In November 2020, Brendan Hay (the maintainer) mentioned that he was planning to cut a new hackage release for amazonka, (and follow up with a gogol release after that). There's been no update since then, and the community is lining up to offer help.

[endgame]

I sent the following email today, to start the two-week deadline described in the NMU policy.

Hello Brendan,

I'm writing to you as a Hackage Trustee, about the possibility of a new Hackage release for the amazonka package family.

In the GitHub issue at https://github.com/brendanhay/amazonka/issues/574 , you mentioned that you were planning on preparing a new release. It's been a few months since then - how is it going? Is there anything I or the community can do to help get this out? There were quite a few people offering to help out on that issue.

I've also raised https://github.com/haskell-infra/hackage-trustees/issues/300 to discuss the possibility of an NMU release, but I'd much prefer to help you do the release as the packages' maintainer.

If you've got things in hand, could you please update the github issue? There's quite a few people looking forward to a release.

Best,

-- Jack

[brendanhay]

I'd be interested to know what set of source changes you plan on uploading to Hackage as a "new release"? What do you consider a stable and/or sufficiently recent set of commits?

The master branch contains a much larger number of changes than the fixes you've listed above and many of them have cascading effects, particularly regarding dependency upgrades. Even in the case of the instance type or region updates - they're a potentially breaking change (pattern synonyms).

There is a main-develop branch which attempts to coalesce these all into a >= 2.0 release, but it's dependent on personal development time.

If you're happy to start the NMU process then I assume you have a plan on making a much smaller incremental 1.x release by cherry picking changes - then please, feel free to create a PR and I'm more than happy to upload it.

[phadej]

I'm not trustee, but these changes AFAIK fall outside of what has been considered for NMU, which is make package compile with newer version of compiler, i.e. not adding new features in particular.

There are cases where maintainers are unavailable indefinitely or for long periods. This is not usually an urgent problem, but sometimes when a package has lots of others that depend on it, those other packages can be blocked from working with newer dependencies. For example a package that is not updated for a long period may block all packages that depend on it from working with a newer compiler or base library release.

[endgame]

@phadej Good point, thanks.

@brendanhay Since current master has a bunch of new stuff that's potentially breaking, getting it CI'd to the point where you'd feel comfortable uploading a new "small" release to hackage would be great. What if we called it 1.7.0 for the sake of argument, assumed that it'll be a breaking change, used it as an opportunity to get GHC 8.6/8.8/8.10 support in (potentially removing 7.10/8.0/8.2), as well as support for newer versions of non-bundled libraries and recent stackage snapshots? From there, publish the package candidates to hackage with a notice period, perhaps, because it'll be a larger change?

We're using amazonka at work, and as such I've got the OK to spend some work hours helping out here. The current project cycle at work wraps up at the end of this week, so the next couple of weeks are going to be good for me to help out. If the main constraint is your personal development time, what can I do to make that time as effective as possible? Tell me what you need and I'll try to work out how to give it to you. It sounds like CI would be a good first step - perhaps we close this issue and move that discussion to the amazonka GH issue tracker?

[gbaz]

Just want to underline again for clarity, no trustee policies should involve adding new features, only keeping things building. It's important to have delineated scope for these things, otherwise confusion can abound. That said -- glad it looks like this thread is finding a way forward for the amazonka packages :-)

[endgame]

https://github.com/brendanhay/amazonka/pull/617 Brendan is actively preparing a new release.