Re: 'temporary' package

To add to this remark, Debian has an explicit process for situations just like this called Non-Maintainer Uploads (NMUs) which you can read about here: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu It seems like having a similar capability within Hackage, or more defined policy about when it kicks in, would be a good idea. The way it works in Debian, the original maintainer is not stripped of his role and a fork is not necessary. NMUs are often only done in extreme cases where the changes are small. (extreme breakage of a library, fixing security vulnerabilities, and so on) Of course, collaborative maintenance helps as well, but ultimately it's helpful to have some process to deploy quick fixes in a timely manner. James Michael Alan Dorman wrote:

I will observe that over the years, the Debian project has gradually evolved toward shared, or even group, maintainership for important packages---for the same reason: someone fafiates and the whole ecosystem starts piling up behind an important package whose maintainer is unresponsive.

Mike.

Niklas Hambüchen writes:

...

It's also worth mentioning that Hackage 2 has a nice "multiple maintainers" functionality, see for example this:

http://hackage.haskell.org/package/tasty/maintainers/

It's not a very visible feature though, the package page doesn't like it and it's not visible how many maintainers a package has (where having more than one could be a good quality metric that maybe should be advertised).

How about automatically bothering single maintainers with a "do you not want to add another maintainer on Hackage" email once they exceed some popularity threshold?

As an example, the "6289 downloads in last 30 days" would make a nice popularity indicator.

On 09/05/14 18:05, Niklas Hambüchen wrote:

...

On 09/05/14 16:14, Carter Schonwald wrote:

...

You do raise a good point, should taking over maintainership of a library adhere to PVP expectations? I don't think so - taking over maintainership should be a last resort in my opinion.

Having backup maintainers becoming common seems a better solution. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

---

Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries