'temporary' package

[Edward Kmett]

You are perfectly within your rights to fork the package off to your own
copy and do whatever you want with it. You are welcome to fork all of
hackage if you need to.

People can then choose to prefer your more proactive maintenance strategy
or that of the original packages.

The concern I have is over the notion of *coopting maintainership* of the
original package on such a short timeline. I personally find *that* to be
the alarming part of this whole discussion.

I hereby formally *do not consent* to anything remotely resembling the
timeline proposed in this discussion for any of my packages. Fork or do not
use them if you feel you must.

If you don't trust a developer to ship on a timetable you can support, then
do not depend on their packages.

But the flipside of that is that if I don't trust a developer to not
spuriously split the community, I can't bring myself to depend on their
packages, either.

We lived through the great mtl/monads-fd/monads-tf split and it was
terrible with hackage divided into 3 camps that were mutually incompatible.

I personally prefer code that works together to gaining a few days
turnaround time or forking for minor differences in design goals.

We've produced a lot of heat from this discussion for a patch that was
trivially applied within a week of being submitted.

I think the fact that your patch was graciously applied so quickly by the
original author largely speaks to my point, but I'm exhausted by this
thread.

-Edward


On Sun, May 11, 2014 at 11:03 PM, Roman Cheplyaka <roma at ro-che.info> wrote:

> Many people seem upset about my words and/or actions.
>
> I think giving a bit of background should help clarify the matters here.
>
> Last time a similar situation came up[1], I simply forked a package (it was
> regex-tdfa) and notified others so that if they have the same problem,
> they may
> reuse my work instead of replicating it.
>
> [1]:
> http://www.haskell.org/pipermail/haskell-cafe/2014-January/112466.html
>
> Many people were concerned with that, arguing that this was unresponsible
> on my
> part and following this trend would lead to hackage fragmentation [2,3].
>
> [2]:
> http://www.haskell.org/pipermail/haskell-cafe/2014-January/112471.html
> [3]:
> http://www.haskell.org/pipermail/haskell-cafe/2014-January/112489.html
>
> So this time I made a compromise and sent out a couple of emails (which I
> didn't
> *have* to send) and gave a two days notice (which again I didn't *have* to
> give
> — I can fix the problem for myself instanteneously by simple forking).
>
> As I suspected, this was completely in vain. This didn't change anything,
> and
> eventually I still had to fork the package in order to get my packages
> back to installable state ASAP. The only thing I got in return is
> accusation of
> being hasty.
>
> So I'm gonna mark this as a failed experiment, and return to my policy of
> simply
> forking the packages whenever I think it's the optimal option for me and
> my users.
>
> (I'm not even sure whether I should notify this list of my forks. As I
> said, I'm
> doing this primarily so that others can reuse my work, but the kind of
> response
> I get each time is discouraging and distracts me from doing other work.)
>
> BTW, 'temporary' has been fixed today. Nevertheless, I will continue to
> maintain my fork, as I don't want this situation to repeat in the future.
> So if you already switched, or plan to switch to temporary-rc, you should
> feel
> safe to do so.
>
> Roman
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140512/18228670/attachment.html>