'temporary' package

Edward Kmett ekmett at gmail.com
Sat May 10 17:15:37 UTC 2014


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 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:
>>
>>> -----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 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/
>>>
>>> iF4EAREIAAYFAlNuDe0ACgkQRtClrXBQc7X6hQD9Hwos368XOxIQVrqDINf2NuwH
>>> 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/20140511/18adab8f/attachment-0001.html>


More information about the Libraries mailing list