Fwd: ghc-7.6 branch

[Johan Tibell]

On Wed, Jun 27, 2012 at 3:20 AM, Paolo Capriotti <p.capriotti at gmail.com> wrote:
> On Wed, Jun 27, 2012 at 12:30 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
>>> * Some libraries will need to have version bumps, which means that other
>>>  libraries will need to loosen their dependencies, which means another
>>>  release will be needed anyway
>>
>> GHC is no different that any other library here though. Library A is
>> released and thus library B needs to be updated and released. The
>> argument here is that the author of library A needs to make a release
>> of the author of library B's package.
>
> The difference is that here the dependency is mutual, in a way. GHC needs
> library B to build, and library B needs to adapt to changes to GHC.

Making a local change is not the same as making a release though. I
make local changes to other people's code all the time, to unblock
myself until the patches have made their way upstream. I'm not against
that, I'm against releasing other people's code except they explicitly
ask you to.


> That's not what I wrote, however. We are just creating branches at this stage.
> If we do make changes and need a version bump, we will coordinate again with
> the maintainer to ensure everything goes upstream normally.

I know that's not what you wrote (hence the "has not happened yet"
part.) But consider the scenario for a second. If GHC adds a new
package as a dependency now all of a sudden the maintainer of that
package is in a situation where he/she explicitly needs to state a
preference to have someone else not make release versions of his/her
package!

> It still makes sense for us to maintain a 'ghc-x.x' branch in each of the
> mirrored resositories. It doesn't have to mirror an upstream branch
> necessarily, but that's the easiest way to ensure all commits end up upstream.

Except this is not what happens always. Commits have not always made
it upstream in the past and sometimes packages released by GHC aren't
uploaded to Hackage.

> The current workflow is:
>
>  - library needs a change
>  - make the change locally, validate, test
>  - send the patch upstream

This doesn't always happen.

>  - wait for the patch to be integrated
>  - pull changes into the corresponding GHC mirror

Just amend

> - Before release, ask maintainer to make new release the package.

and we'll be in the same situation of all other packages on Hackage.

> Using tags as you propose should also be possible, but it would require a
> release on the part of the library maintainer every time a change is made, and
> then we need to update our mirror and point it to the new tag.

I don't really object to you having unreleased changes for shorter
periods of time. Just you releasing them.

> The advantage would be that no revision of GHC ever depends an unreleased
> revision of a library, but is this really worth the extra trouble? Those
> intermediate releases are not particularly meaningful, and they may even end up
> being unusable with every released version of GHC.

I don't think this is necessary. The problem is releasing other
people's code, not having temporary deviating branches.

P.S. All these problems will disappear once we have proper ACLs on
Hackage, as at that point no one but the maintainer and people he/she
gives permission to can upload his/her package to Hackage.

-- Johan