[Haskell-cafe] Handling absent maintainers

[Jason Dagit]

On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton <mwotton at gmail.com> wrote:

> Hello all,
>
> I've recently had problems with haskell-src-meta. While it's a great
> package, it doesn't currently compile on GHC 6.12, and Matt Morrow
> doesn't seem to be around to push the version that does to Hackage.
> Our "one-world" approach with cabal seems to discourage forking as a
> casual act, so when a package that others rely on goes AWOL, it's very
> awkward to fix it.
>
> I can think of a few ways to get around my current problems:
>
> 1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton,
> or something similar - this could be said to pollute the namespace,
> but would solve my immediate problem. I'd have to similarly specialise
> the chain of packages up to the one I actually want to use as well,
> though.
>
> 2. run my own hackage server and tell my users to use that instead.
>
> 3. ... profit?
>
> Ideally, I'd like to be able to say something like "cabal install
> my-hacked-package --as original-package" - are there fundamental
> reasons that wouldn't be possible, or a bad idea?
>

I haven't (yet) run into a completely AWOL maintainer.  Usually I can
contact the maintainer and offer to upload a new version for them.  I'm
currently in this role with Takusen.  I'm not the Takusen maintainer, but I
expect to be uploading the next version soon as it looks like I've been
given permission.

I've had this happen with a couple other packages and it was always a
similar situation.  Negotiate with the listed maintainer to do an upload on
their behalf.  I've found that offering to do the work for them usually
helps tremendously.  And it makes a lot of practical sense.

Now, what you're proposing is interesting.  I believe github/patch-tag have
this model?  Everyone has their own branch of everything they contribute to,
listed right on the website?  This is inline with another idea I've heard
where we'd have a 'stable' hackage and 'unstable/dev' versions.  But, how
does this work for resolving and communicating dependencies?

On a philosophical note about cabal, cabal wants to be able to reason
statically about the API (types, functions, modules) a package provides.  So
flags should primarily be used to configure platform specific bits necessary
for compilation or implementation details, but not to change the API of a
compiled library.  From this point of view it seems to me that what your
describing needs to be baked into either the package name or the version --
that is whatever cabal is going to look at during constraint satisfaction.

I like your idea and I'd like to hear more about how we could accomplish it
within the philosophical framework that cabal already has.

Thanks,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100715/ec4beb2c/attachment.html