Fwd: ghc-7.6 branch
johan.tibell at gmail.com
Fri Jun 29 00:05:38 CEST 2012
On Thu, Jun 28, 2012 at 6:26 AM, Ian Lynagh <igloo at earth.li> wrote:
> You didn't give a clear answer to my question. Am I right in thinking
> that your answer would be "Yes, the GHC release should be delayed
I did answer it, just not with a "yes" or "no" as it's a false
dichotomy. I gave you the 4 options that I think are reasonable.
Perhaps someone could think of others, but those are the standard ones
typically used by open source communities.
> (or at least, for long enough for the maintainer to be declared MIA)
Something reasonable. Perhaps a few weeks to a month. Since this
hasn't actually ever been a problem from what I can tell it doesn't
matter much at this point.
I had a quick look at the list of packages in question
(http://hackage.haskell.org/trac/ghc/wiki/Repositories) and to my
knowledge all these maintainers are around (and typically well-known
contributors in the community.)
>> I think the problem is one of misunderstanding how the
>> process of managing dependencies ought to work (and how it works
>> elsewhere.) "We must release a new version of so-and-so lib because we
>> made such-and-such change" is wrong. Upstream changes (i.e. to GHC
>> deps) ought to happen before downstream releases of dependent code
>> (i.e. GHC.)
> This is actually the main reason that the situation between GHC and the
> libraries it uses is different to most other packages, both within
> Haskell and without:
> It is true that ghc depends on (for example) containers; but containers
> also depends on base, and base/ghc are so intertwined that they are
> essentially the same package (at least, I don't think you're suggesting
> that we should make separate base and ghc releases).
> That is what I mean by them being part of the same system.
> For example, I recently removed the 'catch' export from Prelude, and
> this required corresponding changes in Cabal, Win32 and haskeline. It's
> not possible to make the change in the base library without making the
> corresponding changes, or the GHC build would break, and there's no
> reason the maintainers of the other packages would make the change if I
> didn't ask them to.
> A more mundane example is library dependencies. If we make a change in
> filepath that requires bumping its major version, then we need libraries
> such as Cabal to relax their dependency on filepath or, again, the GHC
> build would break.
Go ahead and make those changes to your local clones. That's
reasonable. That in no way forces you to make releases of those
packages. You have the time from you make the changes to the next GHC
release to get the changes pushed upstream and released.
> Yes. Some of the upstreams respond so fast that it makes my head spin,
> while others often either don't respond or continually promise to get to
> things soon. (again, these are good, well-meaning people, who do a lot
> for the community).
Have you tried pointing out that this is a problem for GHC and perhaps
suggest that they let you make a release on their behalf?
>> I believe this is the first time I've seen an email of this kind
>> from GHC HQ.
> Generally these mails are all directly to maintainers. They're generally
> longer than this, but in essence it normally goes something like
> mail 1: "Could you take a look at this patch please?"
> mail 2: "Did you have a minute to look at that patch?"
> mail 3: "I think the patch is good. Would it help if I pushed it for you?"
> mail 4: "This is blocking other things, so I'd like to push it.
> Please let me know within a week if you object"
> (there may be multiple mail 2s, and mail 3 sometimes gets an
> affirmative response).
> Once this has happened a few times, we tend to suggest switching to a
> system where we just push by default, without the need for the mails and
> the delay (in fact, more-or-less what Gershom suggested).
If the maintainer is fine with such a solution this is of course fine.
But what if they're not? Note that this has nothing to do with
releasing from HEAD, which GHC has typically done in the past. Such
patches typically only require a patch release.
P.S. The Haskell Platform is most likely moving to the complete
opposite approach of what GHC uses; a call for version bumps will go
out some time before the release and if maintainers don't ask to have
their package version bumped, it will stay at the same version used
for the last release.
More information about the Glasgow-haskell-users