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

Edward Kmett ekmett at gmail.com
Tue Mar 31 18:24:52 UTC 2015


The only thing a trustee (or maintainer) can revise on an existing version
is they can tighten or relax constraints for the cabal file. This can be
used when a bound proved in practice to be too liberal or was
insufficiently liberal to support the latest version of its dependencies
without any semantic changes.

Anything more (such as adding an instance for a superclass), fixing an
import collision, etc. requires an new version.

-Edward

On Tue, Mar 31, 2015 at 10:52 AM, Sumit Sahrawat, Maths & Computing, IIT
(BHU) <sumit.sahrawat.apm13 at iitbhu.ac.in> wrote:

> Seems legit. If trustees can only release new versions, then that's the
> end of the discussion. I thought that trustees had the ability to revise
> the versions.
> Sorry for making a fuss.
>
> Best.
>
> On 31 March 2015 at 20:16, Adam Bergmark <adam at bergmark.nl> wrote:
>
>> Sumit, It's unclear to me whether you are referring to publishing new
>> revisions of versions or publishing new versions of packages.
>>
>> We have not discussed treating minor source changes as publishing new
>> revisions, my impression has been that we would upload a new version.
>> Maintainers can of course already do this.
>>
>> The introduction of metadata (.cabal file) revisions has already caused
>> lots of heated discussion, so I wouldn't dare to suggest hackage serving
>> fetching different tarballs on top of that :)
>>
>> On Tue, Mar 31, 2015 at 4:25 PM, Sumit Sahrawat, Maths & Computing, IIT
>> (BHU) <sumit.sahrawat.apm13 at iitbhu.ac.in> wrote:
>>
>>> Carter,
>>>
>>> Yes, I was talking about allowing maintainers to make source level edits.
>>> I don't see any harm in allowing broken packages to be updated as they
>>> won't work for anyone otherwise.
>>>
>>> I am not very inclined towards having the trustees edit packages
>>> directly. They themselves didn't do it very much till now, and they
>>> shouldn't have to.
>>> They can instead contact the maintainer and have him fix the issues. In
>>> case the maintainer is missing, they have no choice but to go ahead with
>>> the changes.
>>>
>>
>> Yes, maintainers should always be the go-to people for fixes, in a
>> perfect world trustees would not be needed.
>>
>> - Adam
>>
>>
>>
>>> It's a good balance, as having a small group of trustees will ultimately
>>> lead to slow response, whereas a large group is not preferable.
>>>
>>> On 31 March 2015 at 18:15, Carter Schonwald <carter.schonwald at gmail.com>
>>> wrote:
>>>
>>>> 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
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Regards
>>>
>>> Sumit Sahrawat
>>>
>>> _______________________________________________
>>> 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/d58c460c/attachment.html>


More information about the Haskell-Cafe mailing list