Re: [Haskell-cafe] Unmaintained packages and hackage upload rights

(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? 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? --Gershom On 1/30/14, 11:53 AM, Ben Gamari wrote:

Clark Gaebel writes:

...

How does the process of taking over maintenance add latency to your work?

1) Check out broken version of package. 2) Fix locally, bump version number locally. 3) cabal sandbox add-source ../fixed-package in any package that needs the fixed version. 4) Email hackage admins for upload rights. 5) Continue working on your actual project. 6) Receive upload privileges one day. 7) Upload fixed package.

As far as I can tell, the only real latency cost here is that paid to fix the broken version.

In my experience, step 4 involved several round trips between a number of different people. Admittedly, this is in part because it's easy to forget about the broken package after you have fixed it locally.

Cheers,

- Ben

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe