Re: Stackage LTS 14

[Timothy Sample <samplet@ngyro.com>]

Hello,

Marius Bakke <mbakke@fastmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>>> Ricardo, what do you think?  Are we okay to take over
>>> wip-haskell-updates?  Does a mega commit make sense or do you think
>>> that’s a bad idea?
>>
>> Yes, you can take over wip-haskell-updates.

Great!  I’ve pushed a new branch with updated Haskell packages.  It’s a
little messy yet, but I want the build farm to help me find build
problems before cleaning up too much.  I updated all the packages using
“guix refresh”, and then built and fixed enough to build “ghc-aeson”.
There were a lot of problems, some of which I fixed with “squash!”
commits that I can squash later.  (I’m hoping that using “squash!”
commits to fix the “guix refresh” commits will make collaboration
easier, but maybe it will just give me a headache later when I have to
squash everything – we’ll see!)

>> A single big commit is not a good idea, but you don’t really need it as
>> you’d merge the branch in one go, so Cuirass would not end up evaluating
>> any of the intermediate commits anyway.  It’s still good to have smaller
>> commits to better undo individual changes and more easily understand
>> related changes.
>
> AIUI individual updates cannot really be un-done, because that would
> break the entire dependency chain.
>
> I think it's OK to "squash" instances like this, both to clarify that
> the changes are in fact related, and to make bisecting less painful.

That’s correct, Marius.  Jumping in anywhere along this chain of commits
would yield broken Haskell packages.  That’s what I was hoping to avoid
with a big, atomic commit.  I get that big commits like that are really
hard to audit, though.  Right now, I’m doing it with small commits, but
it is easy enough to go from one style to the other before we merge.

I suppose the core-updates workflow is essentially small commits.  A big
change like bumping GCC happens, and then packages that break as result
of that change get fixed in later commits.  Maybe we should keep that
style for consistency.

I’ll leave it to you maintainers to make the final call.  ;)


-- Tim