[Haskell-cafe] Unmaintained packages and hackage upload rights

[Duncan Coutts]

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/