'temporary' package

Carter Schonwald carter.schonwald at gmail.com
Sat May 10 17:52:21 UTC 2014

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

On Sat, May 10, 2014 at 1:15 PM, Edward Kmett <ekmett at gmail.com> 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 at 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 at 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 at 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 <alexander at plaimi.net>
>>> wrote:
>>>> 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 at 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/
>>>> uWirnL5GYObPP5o1KdgA/jsGwIVXFg+ILOR8z2/EbsnWopKUq5Dr+y4IpmrOOUp5
>>>> =ZBhp
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>> _______________________________________________
>> 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/20140510/fbf75d78/attachment.html>

More information about the Libraries mailing list