Hackage trustee proposal: Curating the Hackage package collection

older
Opt-in upper-bounds notification...

Adam Bergmark

31 Mar 2015 31 Mar '15

6:33 a.m.

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

Attachments:

attachment.html (text/html — 2.4 KB)

Show replies by date

Roman Cheplyaka

31 Mar 31 Mar

6:46 a.m.

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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Sumit Sahrawat, Maths & Computing, IIT (BHU)

7:23 a.m.

New subject: Hackage trustee proposal: Curating the Hackage package collection

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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards Sumit Sahrawat

Carter Schonwald

8:45 a.m.

New subject: Hackage trustee proposal: Curating the Hackage package collection

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@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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards

Sumit Sahrawat

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Sumit Sahrawat, Maths & Computing, IIT (BHU)

10:25 a.m.

New subject: Hackage trustee proposal: Curating the Hackage package collection

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. 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 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@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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards

Sumit Sahrawat

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards Sumit Sahrawat

Adam Bergmark

10:46 a.m.

New subject: Hackage trustee proposal: Curating the Hackage package collection

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) 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 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@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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards

Sumit Sahrawat

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards

Sumit Sahrawat

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Sumit Sahrawat, Maths & Computing, IIT (BHU)

10:52 a.m.

New subject: Hackage trustee proposal: Curating the Hackage package collection

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 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) 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 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@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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards

Sumit Sahrawat

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards

Sumit Sahrawat

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards Sumit Sahrawat

Edward Kmett

2:24 p.m.

New subject: Hackage trustee proposal: Curating the Hackage package collection

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) 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 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) 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 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)" 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 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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards

Sumit Sahrawat

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards

Sumit Sahrawat

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Regards

Sumit Sahrawat

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Oleg Grenrus

8:43 a.m.

Some ideas about: What exactly should constitute a "simple source change” - Adding an extension (e.g. FlexibleContexts) to make code compile - Adding an Applicative for Monad (or similar obvious “intristic” instance addition, e.g Semigroup for Monoids, if Semi-MP is in) - Editing import list (hiding clashing symbols, qualifying)

...

On 31 Mar 2015, at 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/ 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 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/ 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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

3707

Age (days ago)

3707

Last active (days ago)

List overview

Download

8 comments

6 participants

participants (6)

Adam Bergmark
Carter Schonwald
Edward Kmett
Oleg Grenrus
Roman Cheplyaka
Sumit Sahrawat, Maths & Computing, IIT (BHU)