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@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries