No. In my opinion, there's no good reason why a package should remain broken for more than a day, given that there are people who has found, reported, and fixed the issue. All the actual work is done, now someone just has to push a button. * Oliver Charles [2014-05-07 13:29:40+0100]

Isn't a 4 day turn around on a pull request a little hasty?

- ocharles

On Wed, May 7, 2014 at 8:50 AM, Roman Cheplyaka wrote:

...

Hi Max,

are you still maintaining the 'temporary' package? There's a breakage waiting to be fixed (with a patch): https://github.com/batterseapower/temporary/pull/12

If I don't hear from you in two days, I'll request maintainership and/or fork the package.

Roman

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

The worse people treat their packages, the sooner! * Carter Schonwald [2014-05-09 09:46:01-0400]

When should we expect a -rc for everything?

On Friday, May 9, 2014, Roman Cheplyaka wrote:

...

http://hackage.haskell.org/package/temporary-rc

I am now looking for backup maintainers for this fork to ensure that a similar situation won't occur again. Contact me off list if you'd like to become one.

* Roman Cheplyaka javascript:;> [2014-05-07 10:50:00+0300]

...

Hi Max,

are you still maintaining the 'temporary' package? There's a breakage waiting to be fixed (with a patch): https://github.com/batterseapower/temporary/pull/12

If I don't hear from you in two days, I'll request maintainership and/or fork the package.

Roman

Indeed. Especially since there are people with active hakage trustee powers, a request on the libraries list to fix an immediate breakage when the maintainer is unreachale for some period of time can now be auctioned upon. But this only happens when that request is actually made, along with a concrete fix proposed and evidence that the maintainer is hard to reach. Would somone like to start that request ? Note that this is orthogonal to the issue of who will maintain the lib going forward of course. On Friday, May 9, 2014, Erik Hesselink wrote:

Aren't you overreacting a bit? It's only been two days since your initial email...

Erik

On Fri, May 9, 2014 at 3:53 PM, Roman Cheplyaka javascript:;> wrote:

...

The worse people treat their packages, the sooner!

* Carter Schonwald javascript:;> [2014-05-09 09:46:01-0400]

...

When should we expect a -rc for everything?

On Friday, May 9, 2014, Roman Cheplyaka javascript:;> wrote:

...

http://hackage.haskell.org/package/temporary-rc

I am now looking for backup maintainers for this fork to ensure that a similar situation won't occur again. Contact me off list if you'd like to become one.

* Roman Cheplyaka javascript:; javascript:;> [2014-05-07 10:50:00+0300]

...

Hi Max,

are you still maintaining the 'temporary' package? There's a breakage waiting to be fixed (with a patch): https://github.com/batterseapower/temporary/pull/12

If I don't hear from you in two days, I'll request maintainership and/or fork the package.

Roman

_______________________________________________ Libraries mailing list Libraries@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/libraries

On Fri, May 9, 2014 at 4:30 PM, Roman Cheplyaka wrote:

* Erik Hesselink [2014-05-09 16:19:43+0200]

...

Aren't you overreacting a bit? It's only been two days since your initial email...

In which way am I overreacting?

My initial email said:

...

If I don't hear from you in two days, I'll request maintainership and/or fork the package.

And that's exactly what I did.

Or, if you're referring to the conversation with Carter, I don't think it was meant seriously.

Yes, I took that to mean that you thought Max was treating his package badly. If that's not the case, ignore what I said. Erik

I can follow Roman's point and don't find it overreacting. When you're building software on which your success depends (e.g. for your job or when it fuels your research), its very obstructing when the ecosystem around you breaks, and you want it fixed as soon as possible. Of course having your own fork for everything solves that, but it'd be great to avoid that effort and it breaks a key good thing in the Haskell ecosystem: For many things there's only one package that does it right, and it would be nice to keep that up. On 09/05/14 15:19, Erik Hesselink wrote:

Aren't you overreacting a bit? It's only been two days since your initial email...

Erik

You do raise a good point, should taking over maintainership of a library adhere to PVP expectations? On Friday, May 9, 2014, Erik Hesselink wrote:

I can see this. However, there are solutions available. Local forks you already mentioned (and setting up your own hackage is very easy), but there are also freeze files in cabal now. Additionally (sorry, I have to mention it) upper bounds make builds much more stable. This whole thing wouldn't have happened if 'temporary' had an upper bound on its dependency on 'exceptions'.

Of course your builds should stay working (which is why I advocate upper bounds) but there should also be a sense of package ownership, I think. The current trustee setup is meant for small fixes when an owner is gone/missing.

Erik

On Fri, May 9, 2014 at 4:40 PM, Niklas Hambüchen javascript:;> wrote:

...

I can follow Roman's point and don't find it overreacting.

When you're building software on which your success depends (e.g. for your job or when it fuels your research), its very obstructing when the ecosystem around you breaks, and you want it fixed as soon as possible.

Of course having your own fork for everything solves that, but it'd be great to avoid that effort and it breaks a key good thing in the Haskell ecosystem: For many things there's only one package that does it right, and it would be nice to keep that up.

On 09/05/14 15:19, Erik Hesselink wrote:

...

Aren't you overreacting a bit? It's only been two days since your initial email...

Erik

---

Libraries mailing list Libraries@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/libraries

It's also worth mentioning that Hackage 2 has a nice "multiple maintainers" functionality, see for example this: http://hackage.haskell.org/package/tasty/maintainers/ It's not a very visible feature though, the package page doesn't like it and it's not visible how many maintainers a package has (where having more than one could be a good quality metric that maybe should be advertised). How about automatically bothering single maintainers with a "do you not want to add another maintainer on Hackage" email once they exceed some popularity threshold? As an example, the "6289 downloads in last 30 days" would make a nice popularity indicator. On 09/05/14 18:05, Niklas Hambüchen wrote:

On 09/05/14 16:14, Carter Schonwald wrote:

...

You do raise a good point, should taking over maintainership of a library adhere to PVP expectations?

I don't think so - taking over maintainership should be a last resort in my opinion.

Having backup maintainers becoming common seems a better solution. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I tend to agree with Erik. It is frustrating to be blocked in development on an external dependency, but in this situation I think making a public fork is more likely to hurt the broader haskell community. If this practice becomes widespread, our dependency graphs will become hopelessly fractured. On the bright side, no more cabal hell ;) John L On Fri, May 9, 2014 at 8:02 AM, Erik Hesselink wrote:

I can see this. However, there are solutions available. Local forks you already mentioned (and setting up your own hackage is very easy), but there are also freeze files in cabal now. Additionally (sorry, I have to mention it) upper bounds make builds much more stable. This whole thing wouldn't have happened if 'temporary' had an upper bound on its dependency on 'exceptions'.

Of course your builds should stay working (which is why I advocate upper bounds) but there should also be a sense of package ownership, I think. The current trustee setup is meant for small fixes when an owner is gone/missing.

Erik

On Fri, May 9, 2014 at 4:40 PM, Niklas Hambüchen wrote:

...

I can follow Roman's point and don't find it overreacting.

When you're building software on which your success depends (e.g. for your job or when it fuels your research), its very obstructing when the ecosystem around you breaks, and you want it fixed as soon as possible.

Of course having your own fork for everything solves that, but it'd be great to avoid that effort and it breaks a key good thing in the Haskell ecosystem: For many things there's only one package that does it right, and it would be nice to keep that up.

On 09/05/14 15:19, Erik Hesselink wrote:

...

Aren't you overreacting a bit? It's only been two days since your initial email...

Erik

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

spoke with edward, we're gonna wait and give Max (who's pretty darn busy) the breathing room to do the fixes needed. On Sat, May 10, 2014 at 11:13 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

Alex, honestly the thread isn't about maintainership, but rather pushing a fix to temporary.

Likewise, Maxes other public libs, like test-framework, haven't been maintained in nearly a year.

What's going to happen is sometime today/ tomorrow I'm going to push a minor version bump to temporary to stop the breakages.

Then if max doesn't reply in the next month, figuring out new maintainership.

Nothing precludes reverting the maintainership to max should he then surface. But if someone's been Mia for months already, not so likely :-)

On Saturday, May 10, 2014, Alexander Berntsen wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

I just wanted to say that this whole thread is close to scaring me off *ever* putting a library on Hackage. I have worked in free software for quite some time, and let me assure you that it's not common practice elsewhere to hijack software if the maintainer does not respond for four days.

Forking is OK, that's a freedom afforded to us by free software. But if Hackage ever adopts a policy in which it's OK for someone to hijack libraries if the maintainer is unable to respond in four days, I'm definitely keeping my software away from Hackage.

I agree completely with Jake. This is all a big nonsense to me.

As a sidenote: Just recently a maintainer of a program I'm a developer of did not respond in a couple of days. Turns out his mother had died. Imagine if he came back and had to go through a bunch of red tape to get back maintainership, because someone couldn't wait four days. How absolutely demotivating and frustrating. Then he checks his email to find a thread on the software's mailing list, with "there's no good reason why a package should remain broken for more than a day". - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlNuDe0ACgkQRtClrXBQc7X6hQD9Hwos368XOxIQVrqDINf2NuwH uWirnL5GYObPP5o1KdgA/jsGwIVXFg+ILOR8z2/EbsnWopKUq5Dr+y4IpmrOOUp5 =ZBhp -----END PGP SIGNATURE----- _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I like this email, and perhaps the ideas therein should be used as a guideline for how hackage/admin powers are used! its certainly very easy for a downstream maintainer to temporarily resolve their compat issues with a private in tree copy of their dependency (assume that the types of the upstream are never exposed in the down stream api of course!) On Sat, May 10, 2014 at 1:15 PM, Edward Kmett wrote:

I just want to say that I personally find this thread an the the similar "sky is falling" discussion about Lennart being on vacation for 2 weeks to be alarming and far far too hasty.

Please consider the implications of such a 'shoot first' policy on participation within the community.

Max has written a lot of packages that people depend on, but maintenance is not always done on the time table of the most eager user. I would hesitate to risk driving him out of the community / removing his agency from this matter simply because he doesn't respond fast enough for you.

I sent him some patches for ansi-wl-pprint, and while I nervously wondered this exact same thing about whether he was still active, he accepted them within a couple of weeks and shipped out a new version.

Bryan O'Sullivan took a month or two to merge patches from me for text in the past. Should I have forked text or taken it away from him?

Ross Paterson has accumulated two years of patches and libraries@requests and updates to transformers. I harassed him a couple of times over that interval and even offered to take over maintainership, but it is his package, his timeline and his call. Given the scope of the package and the number of factors involved it was well within his rights to deliberate as long as he did, and it was his call to minimize breakage by batching a bunch of seemingly minor changes into one big release. I'd even argue in retrospect that it was the right call. He's also probably rightly annoyed at me for being so damn pushy. ;)

Lennart ultimately responded positively to the request to just bump and ship, but he'd also have been within his rights not to have.

I'm currently slowly working through the ramifications of the new transformers/mtl release for all of my packages. They are deceptively complicated.

If I naively slam the version bounds up then I will break many big packages that depend on my packages that are at or near the backtracking limit of cabal. It already has caused some problems and I'm in search of the right fix.

I live, eat, and breath Haskell, but if someone were to pull this stunt on me while I'm in the process of deliberating, just because I happen to be off in Australia at a conference and have reduced attention to note and rebut such a thread (which I am!) I would get quite angry and it would be a reasonable response.

I've had 2 week stretches when I'm working in an environment where I can't adequately test a patch that "should just work" and I've had some I took one that purported to work on trust that broke everything.

Not everyone produces micro-updates for every package they maintain daily, nor should they be forced to by some overeager package maintenance policy that actively discourages participation.

When you interact with another package maintainer please consider that your patch may not be the only thing going on in their life.

-Edward Kmett

On Sun, May 11, 2014 at 2:37 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

spoke with edward, we're gonna wait and give Max (who's pretty darn busy) the breathing room to do the fixes needed.

On Sat, May 10, 2014 at 11:13 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

Alex, honestly the thread isn't about maintainership, but rather pushing a fix to temporary.

Likewise, Maxes other public libs, like test-framework, haven't been maintained in nearly a year.

What's going to happen is sometime today/ tomorrow I'm going to push a minor version bump to temporary to stop the breakages.

Then if max doesn't reply in the next month, figuring out new maintainership.

Nothing precludes reverting the maintainership to max should he then surface. But if someone's been Mia for months already, not so likely :-)

On Saturday, May 10, 2014, Alexander Berntsen wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

I just wanted to say that this whole thread is close to scaring me off *ever* putting a library on Hackage. I have worked in free software for quite some time, and let me assure you that it's not common practice elsewhere to hijack software if the maintainer does not respond for four days.

Forking is OK, that's a freedom afforded to us by free software. But if Hackage ever adopts a policy in which it's OK for someone to hijack libraries if the maintainer is unable to respond in four days, I'm definitely keeping my software away from Hackage.

I agree completely with Jake. This is all a big nonsense to me.

As a sidenote: Just recently a maintainer of a program I'm a developer of did not respond in a couple of days. Turns out his mother had died. Imagine if he came back and had to go through a bunch of red tape to get back maintainership, because someone couldn't wait four days. How absolutely demotivating and frustrating. Then he checks his email to find a thread on the software's mailing list, with "there's no good reason why a package should remain broken for more than a day". - -- Alexander alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlNuDe0ACgkQRtClrXBQc7X6hQD9Hwos368XOxIQVrqDINf2NuwH uWirnL5GYObPP5o1KdgA/jsGwIVXFg+ILOR8z2/EbsnWopKUq5Dr+y4IpmrOOUp5 =ZBhp -----END PGP SIGNATURE----- _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

+1 to this. I have 1-2 pieces of pretty subtle code where I'm better off having private copies of standard transformers machinery than using the versions on hackage because I need pretty stringent guarantees about when inlining will happen. On Sat, May 10, 2014 at 2:11 PM, Gershom Bazerman wrote:

On 5/10/14, 1:15 PM, Edward Kmett wrote:

...

I just want to say that I personally find this thread an the the similar "sky is falling" discussion about Lennart being on vacation for 2 weeks to be alarming and far far too hasty.

A huge +1 to all of this.

The worst/best thing about maintaining packages that people care about is that people expect because you've done work they rely on, you have committed to be on-call tech support.

I understand that Max did a bunch of very important work, then became occupied with other things in the world. And in the long term, that needs to be sorted out. But in the short term, a four-day-notice policy is silly. And furthermore, even though there's nothing _wrong_ with forking promiscuously, it tends to create a mess, to no good end.

Finally, I want to note that it is worthwhile to go and read the code of the temporary package. It fits in less than a page, and consists of a few functions that, while somewhat subtle, are each "conceptually" one-liners and only in fact take four or so normal sized lines of code.

Clearly, the easier path, if that library breaks on you, is to copy and paste the relevant functionality.

For all the concerns about package stability, we should also perhaps recognize that introducing new dependencies in your own code will also always carry a cost, and sometimes the easiest thing is just to not introduce that dependency.

--Gershom

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Sat, May 10, 2014 at 8:11 PM, Gershom Bazerman wrote:

I understand that Max did a bunch of very important work, then became occupied with other things in the world. And in the long term, that needs to be sorted out. But in the short term, a four-day-notice policy is silly. And furthermore, even though there's nothing _wrong_ with forking promiscuously, it tends to create a mess, to no good end.

Just a small note since this was mentioned a couple of times: as hackage admins we don't have a 'four-day-notice policy'. The package takeover procedure [0] just says 'a while', and we've taken this to mean at least 2-3 weeks to account for vacations, other absences, general busyness etc. Erik [0] http://www.haskell.org/haskellwiki/Taking_over_a_package

It might be good to also mention a user's options for using their own fork of a package while waiting for an update on hackage. Part of peoples' frustration seems to be coming from a feeling that they're blocked on waiting for the package to be updated. Tom El May 10, 2014, a las 15:35, Carter Schonwald escribió:

Let's update that policy with your and Edwards remarks?

On Saturday, May 10, 2014, Erik Hesselink wrote:

...

On Sat, May 10, 2014 at 8:11 PM, Gershom Bazerman wrote:

...

I understand that Max did a bunch of very important work, then became occupied with other things in the world. And in the long term, that needs to be sorted out. But in the short term, a four-day-notice policy is silly. And furthermore, even though there's nothing _wrong_ with forking promiscuously, it tends to create a mess, to no good end.

Just a small note since this was mentioned a couple of times: as hackage admins we don't have a 'four-day-notice policy'. The package takeover procedure [0] just says 'a while', and we've taken this to mean at least 2-3 weeks to account for vacations, other absences, general busyness etc.

Erik

[0] http://www.haskell.org/haskellwiki/Taking_over_a_package _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Actually, just a follow-up idea, what if cabal reported a link to this (or other) page whenever it fails? It would be (one or two lines) more verbose, but it could be helpful from an usability point of view... Just a suggestion, Cheers 2014-05-10 22:10 GMT+01:00 João Cristóvão :

...

It might be good to also mention a user's options for using their own fork of a package ...

I was going to say: perhaps an Wiki entry stating what to do in case the build fails, but of course, it turns out there is one already:

http://www.haskell.org/haskellwiki/Cabal/Survival

I would only add two steps: 1a) If the package has a github repository, check out if someone else already forked it (on github, not hackage) and check it out as a temporary solution or 1b) Do "cabal get -s package", and fix the package yourself, and... 2) with the use of cabal sandboxes, namely the "cabal sandbox add-source", the problem is easily solved.

I apply this most of the times I detect a package problem in parallel with notifying the author, and it has suited me well. Perhaps its just a case of forwarding the users to this page?

Cheers

2014-05-10 21:49 GMT+01:00 :

It might be good to also mention a user's options for using their own fork

...

of a package while waiting for an update on hackage. Part of peoples' frustration seems to be coming from a feeling that they're blocked on waiting for the package to be updated.

Tom

El May 10, 2014, a las 15:35, Carter Schonwald < carter.schonwald@gmail.com> escribió:

Let's update that policy with your and Edwards remarks?

On Saturday, May 10, 2014, Erik Hesselink wrote:

...

...

I understand that Max did a bunch of very important work, then became occupied with other things in the world. And in the long term, that needs to be sorted out. But in the short term, a four-day-notice policy is silly. And furthermore, even though there's nothing _wrong_ with forking

On Sat, May 10, 2014 at 8:11 PM, Gershom Bazerman wrote: promiscuously,

...

it tends to create a mess, to no good end.

Just a small note since this was mentioned a couple of times: as hackage admins we don't have a 'four-day-notice policy'. The package takeover procedure [0] just says 'a while', and we've taken this to mean at least 2-3 weeks to account for vacations, other absences, general busyness etc.

Erik

[0] http://www.haskell.org/haskellwiki/Taking_over_a_package _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Sat, May 10, 2014 at 6:59 PM, Anthony Cowley wrote:

One: depend upon a repository rather than a package on hackage. You can list a tag on your github fork of an upstream package as a dependency until a new version is pushed to hackage. I don't think this works now, and it opens a can of worms about supported version control systems, archival availability of those repositories, and overall duplicates some amount of the decision making that already goes into hackage.

http://hackage.haskell.org/package/cabal-meta addresses "depend on a repository" decently.

On 2014-05-10 19:15, Edward Kmett wrote:

I just want to say that I personally find this thread an the the similar "sky is falling" discussion about Lennart being on vacation for 2 weeks to be alarming and far far too hasty.

Please consider the implications of such a 'shoot first' policy on participation within the community.

[--snip--] I've snipped most of it, but +1000 to everything you said! Some people like really long vacations *away from computers*, some people like to batch things up, etc. Trusted users bumping some version bounds is one thing, but taking over maintainership just because someone is AFK for 4 days? That's insane! (If such a policy were in effect, I'm pretty sure GHC itself could have already been taken over by someone other than SPJ just because he was on vacation or otherwise indisposed.) Likewise for the requirement for "backup maintainers" to avoid such problems. Although my Hackage packages are all (happilfy for me) towards the leaves of the dependency tree, I don't actually know anyone that I trust sufficiently and who is competent enough in Haskell to be a backup for maintainer for any of my packages. I imagine that the people who have packages with lots of reverse dependencies are even more hard pressed to find suitable "backups". So, yeah. +1000 to what ekmett said. Regards,

On 05/12/2014 03:46 AM, John Meacham wrote:

I pull out code I wrote myself just 3 years ago and find it can't build on a sligthly newer version of the same compiler, yet C code, written to a 20 year old version of the language on a different OS with a different compiler still adapts and works out of the box. We have somehow made a more messed up dependency situation than C has.

I routinely can't build C code because I don't have the right version of a library installed, and have to tweak things hoping for the best. This happens just about every time I need to package something for an "older" distribution. 20 years old C code would probably not suffer from this because it would most likely only depends on libc.

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 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

* Carter Schonwald [2014-05-11 10:33:05-0400]

Max has kindly uploaded a fix to hackage today. And on an incredibly zippy time scale for being so busy.

But hackage will still have temporary-rc forever. Roman, any plans on marking that deprecated please?

No (as you can read in the quoted message).

On Sunday, May 11, 2014, Edward Kmett wrote:

...

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 javascript:_e(%7B%7D,'cvml','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.orgjavascript:_e(%7B%7D,'cvml','Libraries@haskell.org'); http://www.haskell.org/mailman/listinfo/libraries

* Peter Simons [2014-05-11 21:39:30+0200]

...

I will continue to maintain my fork, as I don't want this situation to repeat in the future.

That doesn't make much sense to me, though. You've got what you wanted: the patch you needed has been applied!

Not quite. What I want is that this situation (package remaining uninstallable for a non-trivial amount of time) never happens again. I don't want to go through this process next time something breaks in 'temporary'. Roman

Hi Roman, I think it is great that you made a fixed package available in a timely manner for the communtiy. On Sun, May 11, 2014 at 1:10 PM, Roman Cheplyaka wrote:

* Peter Simons [2014-05-11 21:39:30+0200]

...

...

I will continue to maintain my fork, as I don't want this situation to repeat in the future.

That doesn't make much sense to me, though. You've got what you wanted: the patch you needed has been applied!

Not quite. What I want is that this situation (package remaining uninstallable for a non-trivial amount of time) never happens again. I don't want to go through this process next time something breaks in 'temporary'.

Are you using cabal freeze? There only seems like 2 situations where this event should be a problem. 1) As an application author you really want to upgrade exceptions to 0.6 in your code base and can't wait 2 weeks for things to stabilize. 2) As a library author you really want to release an update that allows for exceptions to 0.6 I am curious what the case is and if introducing cabal freeze could help out. Greg Weber

On Sun, May 11, 2014 at 11:10 PM, Roman Cheplyaka wrote:

In this case I'm speaking as an open source library author, whose library depends on temporary.

So no, cabal freeze can't help here.

Roman

Have you considered autoconf? I know it is a painful syntax due to the macro processing, but it is wicked powerful. Rather than futz around with version numbers or having to magically predict the future, I just have macros like HC_CHECK_MODULE(Data.Foo,[baz::Int],[packagea,packageb,packagec]) and it will check each package for the module with the id of the right type and include the first it finds. If a package maintainer changes behavior that in their mind wasn't version breaking that affects me and decides not to bump a version number it doesn't matter one bit, I just add a line in my conf file to check for the bug and adapt. For more complicated things, I can check things like whether instances are defined, size of types and whatnot, all one liners. The best part is no need for version number archeology or having to wait on anyone else or risk breaking someone else. Any changes monotonically increase the portability without breaking it for others. If a package i need is "broken", and i want to release now, I just include a patch to the third party package in my dist, autoconf checks if it is needed and applies it before building the dependency, I have the situation resolved in fifteen minutes rather than having to wait on anyone blocking my release. and it is backwards and forwards compatible, since it checks whether the patch is needed it won't apply it to older versions and when the issue is fixed upstream then it is just no longer applied. I do have a longer term project dealing with autoconfs shortcomings in a general way (mainly its sh/unix dependence and m4 quirkyness), autoconf's pretty awful in some ways, but not nearly as bad as the attempts to replace it. John -- John Meacham - http://notanumber.net/

The main public one that does interesting things would be jhc, here is its autoconf http://repetae.net/repos/jhc/configure.ac . Some interesting things it does is look for both readline and editline and decide which one or neither to use, it will compile no matter what is installed however. it checks whether haskell98 and base are compatible, and if not, adds a compatibility layer, and checks for an instance of Monoid Doc, generating one if needed but not including it otherwise to avoid duplicate instances. Until recently this gave me compatibility back to ghc 6.8 for a pretty complex package. (I bumped the minimum to 7.2 conciously because I decided view patterns and field punning were just way to useful to not use, it allowed me to drop some other autoconf rules). But i never needed to dig into exactly which version numbers of stuff made the changes i care about, and my tests will work for any compiler, not just ghc. I was never blocked for long by a change in an external package. in fact, there very well could not be a global version number combo that lets me compile without the targeted checks, a lot of the code is shared between other projects and needs broader ranges of ghc/jhc compatibility. Now some more interesting stuff is going on here http://repetae.net/repos/jhc/lib/ext/ it has patches to fix up versions of libraries, my build script will pull the version from hackage with wget then apply the patch and build. Ignore the fact that some have .cabal extensions, historical quirk I am excising, It was way more confusing to have cabal files with jhc when none of the public cabal files actually work with it. now jhc uses fully declarative yaml files, Ironically, people ask when jhc will support cabal when it does, it has for a while, it just doesn't help at all due to cabals design, looking at even the simplest cabal project (https://hackage.haskell.org/package/bytestring) has its dependencies in terms of ghc-prim and specific versions of base, (including, perplexingly, a maximum version, precognitive abilities are apparently a requirement for using hackage; that should have been a sign something was off in the design.). But the important thing is, under cabals rules it would and does just give up with jhc despite it compiling just fine under it, as it has a different base and no ghc-prim. And I can't even try to reverse engineer the file because base > 4.2 gives no indication of _why_ that version is needed, every hackage package is like this, refering to specific versions that only make sense in the context of ghc and have no actual information about what is needed from the environment. I suppose i could bug each and every hackage author to stick 'if jhc' sections and get pissy on the lists when they don't keep them up to date, and, like guessing future version maximums most would just have to guess about what jhc needs. In any case, a system that grows as the square of the number of compilers and packages clearly won't work in the long run. hackage is depressingly antagonistic to other compilers and grossly ghc specific as an ecosystem, not just ghc specific, but ghc-haskell over the last couple versions specific due to having to get on the cabal dependency maintenence treadmill when your guessed maximum versions are reached, then, under cabals design, have to go back and add new sections when people want to use different compilers. An idea i have been playing with to replace autoconf with something feature compatible is adding a portable '/bin/sh' and windows powershell (is there a better universal windows scripting format?) backend to jhc, one of the main issues with autoconf is there is no insulation between the backend (portable sh) and the front end, m4 macros that generate portable sh. Adding a new target like windows is hard. By insulating the configuration language with an actual compiler it would plug that major hole. Plus, it is the perfect poster child for where strong typing is needed, you are writing code for systems that you specifically don't have access too to test on as a goal. Because these scripts are supposed to work for systems that will be invented in the future or your neighbors machine running ObscureBSD, so catching bugs at compile time is a huge boon for branches you will likely never be able to test yourself. John On Mon, May 12, 2014 at 8:13 AM, Carter Schonwald wrote:

Interesting. What's an example lib of yours that does this?

On Monday, May 12, 2014, John Meacham wrote:

...

On Sun, May 11, 2014 at 11:10 PM, Roman Cheplyaka wrote:

...

In this case I'm speaking as an open source library author, whose library depends on temporary.

So no, cabal freeze can't help here.

Roman

Have you considered autoconf? I know it is a painful syntax due to the macro processing, but it is wicked powerful.

Rather than futz around with version numbers or having to magically predict the future, I just have macros like HC_CHECK_MODULE(Data.Foo,[baz::Int],[packagea,packageb,packagec]) and it will check each package for the module with the id of the right type and include the first it finds.

If a package maintainer changes behavior that in their mind wasn't version breaking that affects me and decides not to bump a version number it doesn't matter one bit, I just add a line in my conf file to check for the bug and adapt. For more complicated things, I can check things like whether instances are defined, size of types and whatnot, all one liners. The best part is no need for version number archeology or having to wait on anyone else or risk breaking someone else. Any changes monotonically increase the portability without breaking it for others.

If a package i need is "broken", and i want to release now, I just include a patch to the third party package in my dist, autoconf checks if it is needed and applies it before building the dependency, I have the situation resolved in fifteen minutes rather than having to wait on anyone blocking my release. and it is backwards and forwards compatible, since it checks whether the patch is needed it won't apply it to older versions and when the issue is fixed upstream then it is just no longer applied.

I do have a longer term project dealing with autoconfs shortcomings in a general way (mainly its sh/unix dependence and m4 quirkyness), autoconf's pretty awful in some ways, but not nearly as bad as the attempts to replace it.

John

-- John Meacham - http://notanumber.net/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- John Meacham - http://notanumber.net/