Hackage revision policy

[hasufell]

@Mikolaj said in Matrix that cabal team decided to avoid revisions for "obvious reasons". I don't know what those are and didn't get a reference to the relevant discussion when I asked (supposedly that happened on matrix long time ago).

Can I get a clarification here?

CCing some hackage trustees: @Bodigrim @andreasabel @phadej @andreabedini

Context: #9523

[Mikolaj]

Thank you @hasufell. That's as a good opportunity as any to actually forge our policy on revisions.

To clarify, let me copy what I said on Matrix:

I think, we try to be conservative with revisions for the obvious reasons
(two conflicting views on the same package)
...
yes, we try to avoid revisions, I think, because they cause the bounds on Hackage 
to be different than on github and in other places which can be confusing in various ways
> So?
> So you rather have failing build plans?
that depends on what build plans they are and what is exactly the cause of the failure
I'm not trying to be difficult
but just make sure it's really needed
...
yeah, I'm not sure how widely it's shared --- it was a discussion on this channel some time ago
*a long time ago

[Bodigrim]

I’d expect Cabal to rely on revisions even more than an average Haskell package, because of sparse release cycles and ripples they cause. In the context of #9523 a revision seems a no-brainer to me, I don’t see who is to win from postponing it and forcing a new Cabal release instead.

[gbaz]

I don't recall any policy about avoiding hackage revisions for cabal.There's no considerations I can think of that would affect cabal different than any other hackage package regarding this. We just should try to also ensure that the bounds are changed in-repo as well, but this also holds for packages on hackage in general.

[ulysses4ever]

I feel like revisions unblock more people than they trouble, so I'm in support of revisions in the Cabal project.

[andreabedini]

If a build plan works (for some definition of works) it should be allowed by the version bounds.
I don't see where the problem is, haven't we done revision many times before?

GitHub can be updated to reflect what is on Hackage (like everybody does).

[hasufell]

Can I expect cabal developers to take care of this or should this be redirected to hackage trustees now and in the future?

[andreabedini]

I see #9523 and backports have been merged. I don't know if there have been discussions in other channels. Are we all on the same page now? @Mikolaj would you like to comment here?

[Mikolaj]

Thank you for the discussion. It seems we have a concrete policy emerging. Let's also mention this on Thursday's cabal dev's meeting.

Can we try to make the policy more precise? What are the pre-conditions for a revision?

1. A PR with the same bound change?
2. A merged PR only?
3. Somebody saying the new bound works?
4. Somebody with a good track record convincingly arguing the new bound works?
5. Somebody with a good track record reporting a successful local test run with the new bounds?
6. A successful cabal CI run with the new bounds (but note that this extra work (which we did in the past), on a branch, because normal CI would probably not pick the newest version, for whatever reason (e.g., other packages not permitting it yet))?

edit:
7. Are revisions of multiple versions of cabal acceptable, as a rule?
8. Only minor versions or major versions as well? How many minor/major versions back?
9. If we mandate test runs, as above, are these required also for the old revisions (keep in mind that CIs on branches older than the newest release branch usually don't work, since they are not patched to work around various internal and external problems)?
10. If test runs are required for old versions, does it include minor versions (from tags) or only major versions (from branches)?

[Mikolaj]

I don’t see who is to win from postponing it and forcing a new Cabal release instead.

To clarify, both cabal 3.10.3 and cabal 3.12.1 releases are imminent, from what I understand.

This reminds me, we also need to clarify if revising many subsequent versions of cabal (as is proposed by @hasufell in this case) is something routine or exceptional. And if we expect CI test runs for all the versions or only major ones. Let me add a point above.

[ffaf1]

If a bug pops up becuase of a bound change, there is the possibility that no commit in the repository matches what users downloaded from Hackage, making bug-fixing a potential nightmare.

---

edit: as a simple example, take this git history

9054084c8 Merge #9515
4c1d382a4 Refactor 
2759cab02 Relax bytestring bounds
5a345672d Add flair
729c659d2 Use -XRecordWildCards
eb46bdca4 (haskell/3.10.8) Release 3.10.8 

Now, if we revise Cabal 3.10.8 to loosen bytestring bounds, when a user types cabal get Cabal, such user will get a collection of files which does not correspond to any our of commits/snapshots (the user would get eb46bdca4 plus a cherry-picked Relax bytestring bounds).

So if we introduced a bug, it might be a pain to debug, especially so if the snapshot at 2759cab02 Relax bytestring bounds runs fine but the “eb46bdca4 (haskell/3.10.8) Release 3.10.8 plus cherrypick” does not.

If cabal decides to approve revisions, it could be good to think about ways to mitigate such risks.

[Mikolaj]

Yes, at least a warning in our docs somewhere could be beneficial, perhaps recommending --allow-newer (any other tricks?) if a bug report can't be reproduced with github code. Or recommending to try to repro with the code downloaded from Hackage, I guess?

I'm sure this has been discussed to death for other projects and in flamewars on the internets and trustees are dead tired of this. Dear trustees, is there a FAQ somewhere that you distilled from such discussion? Tips and tricks, what can go wrong, how to best warn about the discrepancy, what's the answer to folks worried about signed/unsigned blobs and possible attacks, etc.? (I'm just making up problems --- I haven't participated in the flame wars and I'm generally pro-revisions, especially for packages that don't release often.)

[gbaz]

The typical policy for most packages is to bump upper bounds only on the most current version of a given package (or perhaps on the most current minor release among a all of a few major release series, if multiple major releases are being supported). In the unfortunate event that bounds need to be restricted, that needs to happen on all affected packages, not just the most current.

In conjunction with bounds bumps or restrictions, typically only the head of the repository (or the branch for each major release) has its cabal file edited in github.

I do not believe there are any common standards on what is considered "sufficient evidence" for a bounds change, since project structures are all so different.

there's a faq here, but i don't know if it discusses most of what you would be asking for. as long as you just change bounds to be more accurate through revisions, there's no special tips or tricks needed, nothing particular that can go wrong, no need to warn about discrepancies, and no issue arises with signing or possible attacks: https://github.com/haskell-infra/hackage-trustees/blob/master/revisions-information.md

again: we've never had a policy that i recall against revisions. hecate made some revision to 3.10.1.0 just five months ago (https://hackage.haskell.org/package/cabal-install-3.10.1.0/revisions/)

i think this is memory playing tricks.

[Bodigrim]

If a bug pops up becuase of a bound change, there is the possibility that no commit in the repository matches what users downloaded from Hackage, making bug-fixing a potential nightmare.

There seems to be an underlying assumption that package builds are set in stone and it's only revisions which could get in the way of reproducibility. But usually a Hackage package can be built with a multitude of compilers and dependency versions; revisions do not really bring much added complexity to the equation.

there's no special tips or tricks needed, nothing particular that can go wrong, no need to warn about discrepancies, and no issue arises with signing or possible attacks

That's my experience as well.