'temporary' package

[James Curbo]

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<mail at nh2.me> 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 at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>> _______________________________________________
>> 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