[Haskell-cafe] Hackage trustee proposal: Curating the Hackage package collection

[Carter Schonwald]

Maintainers can already edit the meta data for their own packages.

As for small source changes, are you proposing that trustees have enough
acls to do those by default, or that hackage editing allow source level
changes?
On Mar 31, 2015 7:23 AM, "Sumit Sahrawat, Maths & Computing, IIT (BHU)" <
sumit.sahrawat.apm13 at iitbhu.ac.in> wrote:

> As Roman said, that definitely is a step in the right direction, but as
> hackage grows, it might not be possible for a small group of trustees to do
> all the work.
>
> I have some points that might be good to add:
>
>    1. The maintainers also get the same abilities as the trustees (edit
>    .cabal files, edit other package metadata etc.)
>    2. The trustees can then notify the maintainers (if the changes are
>    considerable) or make the changes themselves otherwise.
>    3. This also allows the maintainers to edit packages in case they
>    don't build, effectively removing the issue of what a "small source change"
>    is.
>
>
> On 31 March 2015 at 16:16, Roman Cheplyaka <roma at ro-che.info> wrote:
>
>> This is still very conservative, but definitely a step in the right
>> direction.
>>
>> On 31/03/15 13:33, Adam Bergmark wrote:
>> > Dear Haskell Community,
>> >
>> > For some time Hackage has contained a user group called "Trustees",
>> > http://hackage.haskell.org/packages/trustees/ .
>> >
>> >
>> > Description: The role of trustees is to help to curate the whole
>> > package collection. Trustees have a limited ability to edit package
>> > information, for the entire package database (as opposed to package
>> > maintainers who have full control over individual packages). Trustees
>> > can edit .cabal files, edit other package metadata and upload
>> > documentation but they cannot upload new package versions."
>> >
>> > In short, making sure that packages keep building and filling the gap
>> > between unreachable maintainers and package take-overs.
>> >
>> > Up until now we have been very careful with changes since we haven't
>> > had a defined process. Spurred by SPJ and others we have been working
>> > on a proposal for how we should operate.
>> >
>> > You can find the proposal here:
>> > https://gist.github.com/bergmark/76cafefb300546e9b90e
>> >
>> >
>> > We would now like your feedback!
>> >
>> > Some specific things from the proposal that we'd like your opinion on:
>> >
>> > * Section 1: No opt-out for restricting bounds
>> > * Section 2: Opt-out rather than opt-in procedure for loosening version
>> > constraints
>> > * Section 2: Do you care whether you are notified before or after a
>> > version constraint is loosened?
>> > * Section 3: The time frame for publishing simple source changes
>> > * Section 3: What exactly should constitute a "simple source change"
>> >
>> >
>> > We also have a github repository where YOU can file issues about
>> > broken packages, you can start doing this right now!
>> > https://github.com/haskell-infra/hackage-trustees/
>> >
>> >
>> > Please share this with as many people as possible.
>> > We are looking forward to hear your thoughts!
>> >
>> > Sincerely,
>> > Adam Bergmark
>> >
>> >
>> >
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> Regards
>
> Sumit Sahrawat
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150331/6dfbfb9e/attachment.html>