'temporary' package

[Andreas Abel]

+1 to Non-Maintainer-Uploads in cases where maintainers are not 
responsive and fixes are on the "administrative" side, like making a 
package compile with a new ghc, base, etc.

Hackage-1 allowed NMUs unrestrictedly which is a double edged sword.

A possible workflow for a future hackage could be.

1. A non-maintainer makes an upload request on hackage.

    (Of course, he should communicate with the maintainer before by 
email etc.)

2. The maintainer can GRANT or DENY.

    On DENY, the upload request is rejected.  The maintainer indicates 
that he takes care of matters himself.

    On GRANT, the upload is made effective.  The maintainer approves the 
fixes by the NM.

3. If the maintainer does not respond to the request, after some 
timeout, say a month, the request is forwarded to the hackage admins. 
They can also GRANT or DENY.

4. Finally, if the hackage admins also timeout, then the upload is granted.

Such a process would not affect maintainership and would not take away 
any power from the maintainer.  It would allow non-maintainers to help 
with updating package to new ecosystems.

This is a compromise between hackage-1's "everyone can upload" and 
hackage-2's "only the maintainer can upload".


On 11.05.2014 01:41, Bardur Arantsson wrote:
> On 2014-05-10 23:21, James Curbo wrote:
>> 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
>
> As usual Debian has encountered and solved all these problems before.
> Sounds eminently sensible, so +1 to such a policy change.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/