[Haskell-cafe] Unmaintained packages and hackage upload rights

[Erik Hesselink]

As one of the hackage admins, I should probably weigh in here too.

First, let's not forget that one of the big new features of the new
hackage was the addition of proper permission checks for uploading new
versions of packages. Previously, anyone could upload any package,
which is a huge security risk for one, and also violates the
expectations of package owners as well. So I think this feature is a
good one.

Second, there are a lot of abandoned packages. It is good for the
community if people take over maintenance of these, so the process for
doing this should be as smooth as possible.

Note that these two things are at odds. So we have to find a balance.
Johan already mentioned the process we use, although we recently
discussed changing it a bit so that the hackage admins would email the
maintainer instead of the user wanting to take over. This is because
of a recent mishap where a package was taken over because the
maintainer missed the initial email (and haskell-cafe message).

I agree that this process is suboptimal, at least for some scenarios.
It's a lot of work for both the user and the hackage admins. Also,
it's unclear to me how long the wait periods have to be. The
distinction between actually taking over maintainership and just doing
some small fixes seems to be a good one, though it's not exactly clear
where to draw the line. Fixing compilation issues on newer GHCs and
relaxing dependencies seems ok to me, though.

There is support for trustees on the new hackage, as other's
mentioned. These can maintain any package. Perhaps this would be a
good time to recruit a few of them?

Regards,

Erik

On Thu, Jan 30, 2014 at 7:39 PM, Duncan Coutts <duncan at well-typed.com> wrote:
> On Thu, 2014-01-30 at 13:11 -0500, Gershom Bazerman wrote:
>> (ccing hackage admin alias directly, just to make sure the right people
>> are seeing all the emails)
>>
>> I think there are two _different_ issues we've been conflating under
>> "taking over a package".
>>
>> 1) A package is genuinely unmaintained and it should be taken over by
>> someone else, and someone steps up. This is fine to take some time, in
>> my book. Our current process, as described by Johan Tibell, is
>> reasonable. It _should_ be easily accessible from the hackage homepage,
>> _and_ it should be on the haskell wiki. Perhaps the homepage could link
>> to a hackage FAQ on the wiki? Volunteers on any of this?
>
> Right, Johan described our policy, and indeed that should be documented
> in obvious places.
>
>> 2) A package needs patching to work with the latest deps, and the
>> maintainer is unreachable, then we just want to upload a fixed version
>> soon. But who knows, maybe we don't want to take it over for good. Maybe
>> the maintainer is just on a monthlong vacation on a small island chain.
>> Maybe they're sick, or busy at work. This is the sticking point.
>>
>> So maybe we could have a different policy on the latter. There are
>> people like Roman, Ben, others, who I feel like I sort of "know" from
>> their presence in the community, whether or not I've met them
>> personally. I'd feel comfortable letting trusted community members not
>> "take over" packages entirely without process, but use a more relaxed
>> process simply to upload simple patches for compatibility, etc.
>>
>> Is there some way that we could create a "two process" approach -- one
>> for taking over a package, and a more relaxed one for trusted
>> individuals to fix things up easily?
>
> So this one is easy so long as the maintainer (or one of the
> maintainers) is reachable, because then a maintainer can spend 30
> seconds to add the person volunteering to make the fix to the maintainer
> group for the package.
>
> If the maintainer(s) is/are unreachable then that's a hard call. They
> have not pre-approved (which they can do by adding some trusted person
> to the maintainer group) and they are not in a position to approve or
> not in the short term as they are unreachable. In general we like to
> give authors/maintainers strong control over their packages.
>
> I should note that a maintainer could pre-approve some helper to whom
> they can delegate the decision. For example, suppose volunteered to be a
> person of good taste who would review cases where the package needs
> fixing in simple ways but the maintainer is away. That person does not
> have to be the one who develops the fix or even necessarily the person
> who uploads it. What the maintainer would need to do is to add that
> volunteer of good taste to the maintainer group, and then that volunteer
> now has all the same rights as the "real" maintainer and so can upload
> the fixed package themselves or even add the person who did the fix to
> the maintainer group too (different maintainers and fixers might agree
> different policies here).
>
> But otherwise, in general I think we do not want to force maintainers to
> accept "fixes" from other developers without any kind of pre-approval.
> So the worst case of there being no pre-approved helper and the
> maintainer uncontactable in the short term would simply remain.
>
> On the other hand we can certainly encourage and ease setting up
> pre-approval with volunteers, especially for important packages. Or just
> encourage people to add secondary/backup maintainers to their packages.
>
> A little bit of planning will avoid the angst.
>
> --
> Duncan Coutts, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>