Stackage should automatically send PR to projects with upper-bounds issues

[rvion]

@snoyberg

it would save so much time to everyone, if some github bot could

• fork all projects having bounds issues (aeson 0.10 #845, optparse-applicative 0.12 #860, etc.)
• create a branch with a proper name referencing the issue
• change the upper bounds of the problematic dependency
• make a PR

by doing that,

• 🍺 most projects with travis setup would run travis checks right away with newer bounds making the whole process faster. In most cases, it would be one click away
• 🍻 tracking issues would be simplified: PR status (open / merged) will be displayed right after thefirst issue comment

---

Other ideas I would like feedback on:

related to the automatic PR content:

1. bump minor version of the package,
2. document the upper bound change in the changelog if present
3. add Readme.md and Changelog.md to cabal extra-files if present in git repo but not in cabal
4. point users to the (non existent for now) github hook tool service that auto push packages to hackage when version change on master branch
5. Suggest to add a travis.ci using stack with a link to a predefined template if no travis file found

related to the stackage file:

1. allow users to exclude their package from receiving automatic PR

[rvion]

also cc @borsboom @DanBurton @chrisdone to get some feedback.

[chrisdone]

I think everybody wants something like this but a PR would kick things off.

[phadej]

There is a huge problem: .cabal (and changelog) files don't support roundtrip. Using evil tools (e.g. regular expressions) is not reliable :(

I've been playing with no-upper-bounds builder, and indeed in my small testset of packages upper bounds were unnecessary too strict (e.g. tasty-0.11 and HUnit-1.3 didn't introduced anything radical).

• I did PRs for packages that were on github (most are nowadays)
• It wasn't too difficult, given you can make single file edits using web interface of github
  • I was afraid to do this first time
  • Cannot really require any stackage maintainer to do that in the long-term
  • But I learned that many things are quite difficult to automate. .cabal files are machine-readable, but not -editable :(

OTOH there was really breaking changes too, e.g. vector-0.10 to vector-0.11 broke dependant packages using fusion framework. The fix took some time to do. The problem here, is that you don't know how big the breaking change is. TIL about Kmett's versioning scheme, using that vector-0.11 should be vector-1. Then you'd know more. Still I'd prefer to make PRs which I could finish, and I know could have high probability to be accepted :)

Related idea:

• If we could make no-upper-bounds builder reliable enough, so we can trust it,
• package has travis setup,
  then in addition to (and IMO only if we did automated or manua) PR, Hackage trustees could make a revision relaxing the bounds.

Yet I'm 👍 for advocating of travis usage. Maybe I should write a tutorial blog post about it.

And as I a side comment, I'm a bit worried how much we start to rely on Github and Travis. Hopefully someone uses their private options too (i.e. indirectly funding the public part!)

[phadej]

And aeson-0.10 does really broke a lot of things (all packages I contribute to, which deal with some web APIs)

[DanBurton]

I suggest, if something like this is implemented, that we initially make it opt-in. Once we are satisfied that everyone who opted in is happy with the way it works, then we can turn it on by default and allow people to opt out.

I also suggest that the automated PR should include an overly polite comment stating: "this is a mindless robot that has given no thought to the issue other than merely attempting to bump the bounds, please feel free to disregard this PR if you don't find it helpful."

1. bump minor version of the package,

👍

2. document the upper bound change in the changelog if present

This crosses the boundary of what I think an automated tool should do. The PR could include a comment that recommends this course of action and includes a few lines of auto-generated content that the humans may choose to copy/paste into the changelog if they like it.

3. add Readme.md and Changelog.md to cabal extra-files if present in git repo but not in cabal

Again, maybe recommend in a comment and provide a copy/pasteable line, but I wouldn't make this part of the automated PR.

4. point users to the (non existent for now) github hook tool service that auto push packages to hackage when version change on master branch

My initial reaction is to be scared of such a tool. I could get used to it, but I'd usually rather err on the side of caution when it comes to publishing new versions of a package.

5. Suggest to add a travis.ci using stack with a link to a predefined template if no travis file found

Great suggestion that I think a lot of people will find useful.

allow users to exclude their package from receiving automatic PR

The opt-in/opt-out functionality should be a configuration option in build-constraints.yaml here in this repo.

[DanBurton]

Closing as de facto "won't do" per lack of recent engagement with this issue.