agreeing a policy for maintainers and hackageDB

newer
Strictness of enumFrom* on numeric...

Ross Paterson

23 Jun 2008 23 Jun '08

5:05 a.m.

As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are: * users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer. When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt: If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves. A Maintainer value of "none" indicates that the package is not supported. If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported.

Show replies by date

Duncan Coutts

23 Jun 23 Jun

6:14 a.m.

On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote:

...

As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are:

* users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer.

When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt:

If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves.

A Maintainer value of "none" indicates that the package is not supported.

If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported.

Looks good to me, except that I think I agree with Gwern that an empty maintainer field is better than a distinguished value like "none". We can always make the web page note that the package has no maintainer. If on the other hand everyone thinks "none" is a good idea then we should make hackage upload enforce that the maintainer field is not empty. Duncan

Ross Paterson

6:34 a.m.

On Mon, Jun 23, 2008 at 11:14:51AM +0100, Duncan Coutts wrote:

...

On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote:

...
A Maintainer value of "none" indicates that the package is not supported.

Looks good to me, except that I think I agree with Gwern that an empty maintainer field is better than a distinguished value like "none".

I don't mind whether the distinguished value is "", "none" or something else, just that there is one. I suppose the empty string is easier to get right.

Ross Paterson

26 Jun 26 Jun

10:10 a.m.

On Mon, Jun 23, 2008 at 11:14:51AM +0100, Duncan Coutts wrote:

...

Looks good to me, except that I think I agree with Gwern that an empty maintainer field is better than a distinguished value like "none".

Is that still your view?

...

We can always make the web page note that the package has no maintainer.

If on the other hand everyone thinks "none" is a good idea then we should make hackage upload enforce that the maintainer field is not empty.

The library already warns about it; all that would be needed is to adjust the severity level.

Iavor Diatchki

2:03 p.m.

Hi, I'd prefer that we omit the maintainer field for packages whose maintainer is unknown. I think that this leads to a cleaner design than choosing an arbitrary distinguished value. -Iavor On Thu, Jun 26, 2008 at 7:10 AM, Ross Paterson wrote:

...

On Mon, Jun 23, 2008 at 11:14:51AM +0100, Duncan Coutts wrote:

...
Looks good to me, except that I think I agree with Gwern that an empty maintainer field is better than a distinguished value like "none".

Is that still your view?

...
We can always make the web page note that the package has no maintainer.

If on the other hand everyone thinks "none" is a good idea then we should make hackage upload enforce that the maintainer field is not empty.

The library already warns about it; all that would be needed is to adjust the severity level. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Duncan Coutts

23 Jun 23 Jun

5:51 p.m.

If a few more people could read this nice short policy and say "yes that looks fine, I agree" then that would be very helpful. If this is to be something that we put on hackage and expect people to follow then it needs to be *seen* to be supported by people in the community. If we need to act on the policy we don't want to be open to the accusation that the policy was just imposed by Cabal bureaucrats hell-bent on spoiling people's fun but that it actually reflects the general view of the Haskell hacker community. Just because it isn't controversial doesn't mean we don't need your support! :-) Of course if you do have any questions or suggestions then now is a good time to mention them. Duncan On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote:

...

As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are:

* users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer.

When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt:

If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves.

A Maintainer value of "none" indicates that the package is not supported.

If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported.

Neil Mitchell

6:06 p.m.

Hi (+1) Support, with two things: 1) I agree with Duncan. I think blank is a much better field name than "none". What if Mr None wants to maintain a package :-) Another reason is that its less likely to go wrong, and valid in any language. 2) " If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported." I would change the final sentance to: "Then put your own name in the Maintainer field, to indicate your ongoing support for the package." People will figure out that if they want to fork and abandon then they can blank the maintainer field, but by default a fork should come with support. We don't want to enourage one-shot packages with no support! But that's a minor thing, and if people want to leave it as it is then that's fine. Thanks Neil On 6/23/08, Duncan Coutts wrote:

...

If a few more people could read this nice short policy and say "yes that looks fine, I agree" then that would be very helpful.

If this is to be something that we put on hackage and expect people to follow then it needs to be *seen* to be supported by people in the community. If we need to act on the policy we don't want to be open to the accusation that the policy was just imposed by Cabal bureaucrats hell-bent on spoiling people's fun but that it actually reflects the general view of the Haskell hacker community.

Just because it isn't controversial doesn't mean we don't need your support! :-)

Of course if you do have any questions or suggestions then now is a good time to mention them.

Duncan

On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote:

...
As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are:

* users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer.

When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt:

If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves.

A Maintainer value of "none" indicates that the package is not supported.

If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Niklas Broberg

6:12 p.m.

+1 from me too, and I agree with the points raised by Neil. Cheers, /Niklas On 6/24/08, Neil Mitchell wrote:

...

Hi

(+1) Support, with two things:

1) I agree with Duncan. I think blank is a much better field name than "none". What if Mr None wants to maintain a package :-) Another reason is that its less likely to go wrong, and valid in any language.

2) " If a package is being maintained, any release not approved and

supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported."

I would change the final sentance to: "Then put your own name in the Maintainer field, to indicate your ongoing support for the package." People will figure out that if they want to fork and abandon then they can blank the maintainer field, but by default a fork should come with support. We don't want to enourage one-shot packages with no support!

But that's a minor thing, and if people want to leave it as it is then that's fine.

Thanks

Neil

On 6/23/08, Duncan Coutts wrote:

...
If a few more people could read this nice short policy and say "yes that looks fine, I agree" then that would be very helpful.

If this is to be something that we put on hackage and expect people to follow then it needs to be *seen* to be supported by people in the community. If we need to act on the policy we don't want to be open to the accusation that the policy was just imposed by Cabal bureaucrats hell-bent on spoiling people's fun but that it actually reflects the general view of the Haskell hacker community.

Just because it isn't controversial doesn't mean we don't need your support! :-)

Of course if you do have any questions or suggestions then now is a good time to mention them.

Duncan

On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote:

...
As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are:

* users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer.

When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt:

If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves.

A Maintainer value of "none" indicates that the package is not supported.

If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Isaac Dupree

6:29 p.m.

+1 also Niklas Broberg wrote:

...

+1 from me too, and I agree with the points raised by Neil.

Cheers,

/Niklas

On 6/24/08, Neil Mitchell wrote:

...
Hi

(+1) Support, with two things:

1) I agree with Duncan. I think blank is a much better field name than "none". What if Mr None wants to maintain a package :-) Another reason is that its less likely to go wrong, and valid in any language.

2) " If a package is being maintained, any release not approved and

supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported."

I would change the final sentance to: "Then put your own name in the Maintainer field, to indicate your ongoing support for the package." People will figure out that if they want to fork and abandon then they can blank the maintainer field, but by default a fork should come with support. We don't want to enourage one-shot packages with no support!

But that's a minor thing, and if people want to leave it as it is then that's fine.

Thanks

Neil

On 6/23/08, Duncan Coutts wrote:

...
If a few more people could read this nice short policy and say "yes that looks fine, I agree" then that would be very helpful.

If this is to be something that we put on hackage and expect people to follow then it needs to be *seen* to be supported by people in the community. If we need to act on the policy we don't want to be open to the accusation that the policy was just imposed by Cabal bureaucrats hell-bent on spoiling people's fun but that it actually reflects the general view of the Haskell hacker community.

Just because it isn't controversial doesn't mean we don't need your support! :-)

Of course if you do have any questions or suggestions then now is a good time to mention them.

Duncan

On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote:

...
As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are:

* users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer.

When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt:

If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves.

A Maintainer value of "none" indicates that the package is not supported.

If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Ross Paterson

8:28 p.m.

On Mon, Jun 23, 2008 at 11:06:35PM +0100, Neil Mitchell wrote:

...

1) I agree with Duncan. I think blank is a much better field name than "none". What if Mr None wants to maintain a package :-) Another reason is that its less likely to go wrong, and valid in any language.

OK, the package page now flags packages with empty or omitted Maintainer fields (e.g. tagsoup-0.1). The checkPackage function in Cabal still gives a warning on an empty Maintainer field, which is reported by the upload script. I don't know whether that should be changed. (I think unsupported packages rate a bit of disapproval.)

...

2) " If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported."

I would change the final sentance to: "Then put your own name in the Maintainer field, to indicate your ongoing support for the package." People will figure out that if they want to fork and abandon then they can blank the maintainer field, but by default a fork should come with support. We don't want to enourage one-shot packages with no support!

I'd prefer not to leave anything implicit. If we're going to permit unsupported forks, we ought to say what they should look like. (They are, after all, happening now.)

Ross Paterson

8:37 p.m.

On Tue, Jun 24, 2008 at 01:28:44AM +0100, Ross Paterson wrote:

...

OK, the package page now flags packages with empty or omitted Maintainer fields (e.g. tagsoup-0.1).

That's easily undone if people decide on a reserved string for unsupported packages.

Neil Mitchell

8:44 p.m.

...

...
I would change the final sentance to: "Then put your own name in the Maintainer field, to indicate your ongoing support for the package." People will figure out that if they want to fork and abandon then they can blank the maintainer field, but by default a fork should come with support. We don't want to enourage one-shot packages with no support!

I'd prefer not to leave anything implicit. If we're going to permit unsupported forks, we ought to say what they should look like. (They are, after all, happening now.)

Do we want to permit unsupported forks? I am not convinced they are a good idea. As for the maintainer field, thinking about it further, it seems to make sense that no maintainer field is equal to a maintainer field of "" - hence using a blank string for unsupported seems like a bad idea. Therefore an explicit "unsupported" value probably makes more sense. Thanks Neil

Isaac Dupree

24 Jun 24 Jun

9:42 a.m.

Neil Mitchell wrote:

...

Hi

...
...
I would change the final sentance to: "Then put your own name in the Maintainer field, to indicate your ongoing support for the package." People will figure out that if they want to fork and abandon then they can blank the maintainer field, but by default a fork should come with support. We don't want to enourage one-shot packages with no support!

I'd prefer not to leave anything implicit. If we're going to permit unsupported forks, we ought to say what they should look like. (They are, after all, happening now.)

Do we want to permit unsupported forks? I am not convinced they are a good idea.

what do we do if a package becomes unsupported? delete it? Or are you just concerned about it if they're *forks* that no one ever intended to support (rather than a maintainer of a package leaving after a while)? anyway, here's the conflict between hackage as a repository of anything Haskell that someone might use/start maintaining, or hackage as a collection of stuff that's generally supposed to work "out-of-the-box" to some extent(cabal-install). Does cabal-install make it easy to install something that's not in hackage.haskell.org (but is somewhere else on the web, where you know the URL)? -Isaac

Neil Mitchell

9:52 a.m.

...

what do we do if a package becomes unsupported? delete it? Or are you just concerned about it if they're *forks* that no one ever intended to support (rather than a maintainer of a package leaving after a while)?

The second. Packages will become unsupported, packages will be forked, but being forked and unsupported simultaneously is probably bad. Thanks Neil

Bulat Ziganshin

10:29 a.m.

New subject: Re[2]: agreeing a policy for maintainers and hackageDB

Hello Isaac, Tuesday, June 24, 2008, 5:42:48 PM, you wrote:

...

...
Do we want to permit unsupported forks? I am not convinced they are a good idea.

imho, we are going too deep into this topic. there are even proposals to force developers to answer emails :) We have AUTHORS field which should list everyone contributed to the package just for copyrighting purposes. and we have MAINTAINER field for the person(s) which are ready to accept patches, feature requests and ask dumb user questions. that's all if one uploading package know person which maintains package in above-mentioned meaning, he declare that person in .cabal file. if noone is expected to support the package, it may be mentioned too non-maintainers shouldn't upload new versions of maintained packages without written ;) maintainer permission. well, as far as maintainer answers their letters it should be ok to fork existing maintained library Foo as SuperFoo and leave it unmaintained - sometimes we write just for fun (things useful for other haskellers) i think that Hackage should be database of ALL packages, and other ways should be used to distinguish between better and worse ones (such as download count, maintainer field, version, last update time...) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Duncan Coutts

8:07 p.m.

New subject: Re[2]: agreeing a policy for maintainers and hackageDB

On Tue, 2008-06-24 at 18:29 +0400, Bulat Ziganshin wrote:

...

i think that Hackage should be database of ALL packages, and other ways should be used to distinguish between better and worse ones (such as download count, maintainer field, version, last update time...)

Yes. The archive is supposed to be persistent. We don't want to be deleting packages just because they have suffered bit rot. Of course we also need to be able to present to users the subset of current working maintained packages that we actually suggest that they use (using all the metadata you mention). Duncan

Gwern Branwen

1 Jul 1 Jul

1:57 p.m.

On 2008.06.24 18:29:03 +0400, Bulat Ziganshin scribbled 1.3K characters:

...

Hello Isaac,

Tuesday, June 24, 2008, 5:42:48 PM, you wrote:

...
...
Do we want to permit unsupported forks? I am not convinced they are a good idea.

imho, we are going too deep into this topic. there are even proposals to force developers to answer emails :)

We have AUTHORS field which should list everyone contributed to the package just for copyrighting purposes. and we have MAINTAINER field for the person(s) which are ready to accept patches, feature requests and ask dumb user questions. that's all

if one uploading package know person which maintains package in above-mentioned meaning, he declare that person in .cabal file. if noone is expected to support the package, it may be mentioned too

non-maintainers shouldn't upload new versions of maintained packages without written ;) maintainer permission. well, as far as maintainer answers their letters

And how would we handle the case where the package is fully maintained, but the maintainer hates Cabal & Hackage and would never give permission? Does the maintainer have eternal veto power over uploads?

...

it should be ok to fork existing maintained library Foo as SuperFoo and leave it unmaintained - sometimes we write just for fun (things useful for other haskellers)

i think that Hackage should be database of ALL packages, and other ways should be used to distinguish between better and worse ones (such as download count, maintainer field, version, last update time...)

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

As I've indicated elsewhere, I'm a strong supporter of this view. It is better from a long-term view: personal websites are hard to find, they are evanescent, and the opposite view induces great friction and transaction costs. Filtering out packages is easy; but there is no library to undelete information, no way to recover packages purposefully deleted or discouraged from ever being on Hackage. -- gwern MI6 SISDE 36800 Waihopai ple SP4 illuminati FSF cracking rico

Philippa Cowderoy

2:07 p.m.

On Tue, 1 Jul 2008, Gwern Branwen wrote:

...

...
non-maintainers shouldn't upload new versions of maintained packages without written ;) maintainer permission. well, as far as maintainer answers their letters

And how would we handle the case where the package is fully maintained, but the maintainer hates Cabal & Hackage and would never give permission? Does the maintainer have eternal veto power over uploads?

To the extent it's legal to do so? Upload a package clearly marked as unofficial, with the maintainer field blank. -- flippa@flippac.org Sometimes you gotta fight fire with fire. Most of the time you just get burnt worse though.

Isaac Dupree

2:41 p.m.

Philippa Cowderoy wrote:

...

On Tue, 1 Jul 2008, Gwern Branwen wrote:

...
...
non-maintainers shouldn't upload new versions of maintained packages without written ;) maintainer permission. well, as far as maintainer answers their letters And how would we handle the case where the package is fully maintained, but the maintainer hates Cabal & Hackage and would never give permission? Does the maintainer have eternal veto power over uploads?

To the extent it's legal to do so? Upload a package clearly marked as unofficial, with the maintainer field blank.

If someone wants to put a version on hackage and act as maintainer for it (presumably mostly pulling updates from the "upstream"), should we let them? Although, this situation sounds too hypothetical for me to have any idea how to answer my own question.

Gwern Branwen

3:18 p.m.

On 2008.07.01 14:41:11 -0400, Isaac Dupree scribbled 0.8K characters:

...

Philippa Cowderoy wrote:

...
On Tue, 1 Jul 2008, Gwern Branwen wrote:

...
...
non-maintainers shouldn't upload new versions of maintained packages without written ;) maintainer permission. well, as far as maintainer answers their letters And how would we handle the case where the package is fully maintained, but the maintainer hates Cabal & Hackage and would never give permission? Does the maintainer have eternal veto power over uploads?

To the extent it's legal to do so? Upload a package clearly marked as unofficial, with the maintainer field blank.

If someone wants to put a version on hackage and act as maintainer for it (presumably mostly pulling updates from the "upstream"), should we let them? Although, this situation sounds too hypothetical for me to have any idea how to answer my own question.

It's not hypothetical at all. Meachem's Drift stuff is on Hackage, but he certainly hasn't accepted any cabalization patches for it. And I asked in part because I have an experimental cabalization of Darcs which I maintain, and I was thinking of uploading it to Hackage since Darcs 2.0.2 got released - which would be exactly this situation (Roundy has made it clear he opposes cabalization of Darcs, even removing stuff that would make it easier). -- gwern rs9512c Echelon disruption sweep Montenegro TEXTA NSES FBI Phon-e AC

Henning Thielemann

3:26 p.m.

On Tue, 1 Jul 2008, Gwern Branwen wrote:

...

And I asked in part because I have an experimental cabalization of Darcs which I maintain, and I was thinking of uploading it to Hackage since Darcs 2.0.2 got released - which would be exactly this situation (Roundy has made it clear he opposes cabalization of Darcs, even removing stuff that would make it easier).

Too sad, I thought David was looking for contributors. Wouldn't Cabal simplify contributions?

David Roundy

3:33 p.m.

On Tue, Jul 01, 2008 at 09:26:12PM +0200, Henning Thielemann wrote:

...

On Tue, 1 Jul 2008, Gwern Branwen wrote:

...
And I asked in part because I have an experimental cabalization of Darcs which I maintain, and I was thinking of uploading it to Hackage since Darcs 2.0.2 got released - which would be exactly this situation (Roundy has made it clear he opposes cabalization of Darcs, even removing stuff that would make it easier).

Too sad, I thought David was looking for contributors. Wouldn't Cabal simplify contributions?

No, because it would complicate the build system, so that contributors who wanted to work on darcs would have to deal with autoconf, gnu make *and* cabal. And it would double the number of possible build scenarios, unless we required cabal, in which case it would break compatability with older systems. It's just not worth the maintenance nightmare. David

Ross Paterson

3:20 p.m.

On Tue, Jul 01, 2008 at 07:07:16PM +0100, Philippa Cowderoy wrote:

...

On Tue, 1 Jul 2008, Gwern Branwen wrote:

...
...
non-maintainers shouldn't upload new versions of maintained packages without written ;) maintainer permission. well, as far as maintainer answers their letters

And how would we handle the case where the package is fully maintained, but the maintainer hates Cabal & Hackage and would never give permission? Does the maintainer have eternal veto power over uploads?

To the extent it's legal to do so? Upload a package clearly marked as unofficial, with the maintainer field blank.

Under the proposed policy, you'd need to rename the package and change the maintainer field.

Simon Peyton-Jones

23 Jun 23 Jun

8:16 p.m.

It looks good to me. (I do rather agree that an explicit "unsupported" would be better than blank in the maintainer field.) I'm still hoping that someone will make Hackage able to support user reviews and ratings, so that well-engineered packages get the good feedback they deserve, and stand out from the crowd. Simon | -----Original Message----- | From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On | Behalf Of Duncan Coutts | Sent: 23 June 2008 22:52 | To: Haskell Libraries | Subject: Re: agreeing a policy for maintainers and hackageDB | | If a few more people could read this nice short policy and say "yes that | looks fine, I agree" then that would be very helpful. | | If this is to be something that we put on hackage and expect people to | follow then it needs to be *seen* to be supported by people in the | community. If we need to act on the policy we don't want to be open to | the accusation that the policy was just imposed by Cabal bureaucrats | hell-bent on spoiling people's fun but that it actually reflects the | general view of the Haskell hacker community. | | Just because it isn't controversial doesn't mean we don't need your | support! :-) | | Of course if you do have any questions or suggestions then now is a good | time to mention them. | | Duncan | | On Mon, 2008-06-23 at 10:05 +0100, Ross Paterson wrote: | > As a few people have noted, we need to agree a policy in this area. | > As I see it, the drivers are: | > | > * users need to know whether what they're downloading is supported, | > and if so by whom. | > * maintainers are entitled to control what goes out in their name. | > * allocating version numbers for a particular package name should be | > the prerogative of the maintainer. | > | > When something is agreed, I propose to put it on the hackageDB upload | > page and expect people to follow it. Here's my first attempt: | > | > If the Maintainer field names a person or group, the release as | > a whole (including packaging) is the named maintainer's approved | > release, which they are supporting (at least for some time after | > the release). Ideally a maintainer would make that clear by | > uploading the release themselves. | > | > A Maintainer value of "none" indicates that the package is | > not supported. | > | > If a package is being maintained, any release not approved and | > supported by the maintainer should use a different package name. | > Then use the Maintainer field as above either to commit to | > supporting the fork yourself or to mark it as unsupported. | | | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries

Henning Thielemann

24 Jun 24 Jun

5:24 a.m.

On Tue, 24 Jun 2008, Simon Peyton-Jones wrote:

...

I'm still hoping that someone will make Hackage able to support user reviews and ratings, so that well-engineered packages get the good feedback they deserve, and stand out from the crowd.

As Chris Kuklewicz explains in the other thread "package spam", an unmaintained package is often not generated by someone who uploads a new version where only the Cabal field Maintainer is removed or changed to the empty string. Actually a package most oftenly becomes unmaintained by being not updated for a long time. Thus I think the time of the last release, the highest compiler version it is tested with and so on may be sorting criteria for finding out the most up-to-date packages. If nevertheless an unmaintained flag should be managed, this should be part of HackageDB (like user reviews), not part of Cabal. But then I wonder who shall decide whether a package is maintained or not. Sometimes users are afraid that a package is unmaintained because there was no new release for half a year, although patches are constantly committed to a darcs repository.

Ross Paterson

5:47 a.m.

On Tue, Jun 24, 2008 at 11:24:08AM +0200, Henning Thielemann wrote:

...

As Chris Kuklewicz explains in the other thread "package spam", an unmaintained package is often not generated by someone who uploads a new version where only the Cabal field Maintainer is removed or changed to the empty string. Actually a package most oftenly becomes unmaintained by being not updated for a long time. Thus I think the time of the last release, the highest compiler version it is tested with and so on may be sorting criteria for finding out the most up-to-date packages. If nevertheless an unmaintained flag should be managed, this should be part of HackageDB (like user reviews), not part of Cabal. But then I wonder who shall decide whether a package is maintained or not. Sometimes users are afraid that a package is unmaintained because there was no new release for half a year, although patches are constantly committed to a darcs repository.

All that other information will be useful in building the complete picture. Breaking changes to the core libraries are also helpful in weeding out unmaintained packages :-). The maintainer field is an additional piece of information, describing the situation at the time of the release. There are two kinds of uploads that are happening now, but are difficult to distinguish from normal releases: * museum pieces: a package that hasn't been touched for years is updated to use Cabal and the latest libraries and uploaded. * can't wait for the maintainer: someone takes the current state of the darcs repository, possibly makes a few fixes, and uploads that. If these are to be allowed, users (and future filtering schemes) really need to be able to identify them.

Ross Paterson

30 Jun 30 Jun

4:48 a.m.

On Tue, Jun 24, 2008 at 01:16:21AM +0100, Simon Peyton-Jones wrote:

...

(I do rather agree that an explicit "unsupported" would be better than blank in the maintainer field.)

What's your reason for that preference? (We're talking about the text of the .cabal file, rather than what's displayed on the package page.)

Antti-Juhani Kaijanaho

24 Jun 24 Jun

3:30 a.m.

On Mon, Jun 23, 2008 at 10:51:43PM +0100, Duncan Coutts wrote:

...

If a few more people could read this nice short policy and say "yes that looks fine, I agree" then that would be very helpful.

Yes, that looks fine, I agree :) I would prefer that a missing Maintainer field were a bug in the metadata instead of being semantically significant. Otherwise there would be no way of distinguishing between "I forgot to add my Maintainer line" and "I am not supporting this". -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/

Antti-Juhani Kaijanaho

3:33 a.m.

Also, if putting one's name and address as maintainer is going to imply that the package is supported, we ought to define what minimal level of support is expected. Responds to mails? Accepts/rejects patches in a timely fashion (how fast?)? Answers user handholding requests in a helpful manner? Makes regular releases (how often?)? -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/

Isaac Dupree

9:51 a.m.

Antti-Juhani Kaijanaho wrote:

...

Also, if putting one's name and address as maintainer is going to imply that the package is supported, we ought to define what minimal level of support is expected. Responds to mails? Accepts/rejects patches in a timely fashion (how fast?)? Answers user handholding requests in a helpful manner? Makes regular releases (how often?)?

well, assuming maintainer=libraries@h.o is "supported", we clearly shouldn't expect anything more than we expect ourselves to do. Which is in practice something like: - responds to mails (at least usually) - can easily ignore patches, due both to the library submissions proposal policy (submitters are told to run off to GHC Trac and learn that too), and then once that's done, by accident (so then they have to poke someone, but because of the policy, that now generally gets a definite response). If process is followed, timeframe is a few weeks. - regular releases? I have no idea, except I think it's probably at least once a year because of major GHC versions (at least for boot-packages). -Isaac

Gwern Branwen

1 Jul 1 Jul

2:03 p.m.

On 2008.06.24 10:30:39 +0300, Antti-Juhani Kaijanaho scribbled 1.4K characters:

...

On Mon, Jun 23, 2008 at 10:51:43PM +0100, Duncan Coutts wrote:

...
If a few more people could read this nice short policy and say "yes that looks fine, I agree" then that would be very helpful.

Yes, that looks fine, I agree :)

I would prefer that a missing Maintainer field were a bug in the metadata instead of being semantically significant. Otherwise there would be no way of distinguishing between "I forgot to add my Maintainer line" and "I am not supporting this".

-- Antti-Juhani Kaijanaho, Jyväskylä, Finland

The alternative is worse: why is it better to have three values ('Specifically unmaintained', 'Maintained by foo', 'not specified either way/omitted field')? At least with the omitted field being significant, users can proceed knowing that if there is a maintainer of a package with omitted maintainer field, they haven't been too diligent about packaging the program. And we already have a situation where omissions are significant. Consider the license: field. If a license isn't specified, it must, legally, be AllRightsReserved. That's the law. -- gwern MI6 SISDE 36800 Waihopai ple SP4 illuminati FSF cracking rico

Antti-Juhani Kaijanaho

3:08 p.m.

(As I've asked before, please don't send me copies of list emails, unless you have reason to believe I am not subscribed.) On Tue, Jul 01, 2008 at 02:03:51PM -0400, Gwern Branwen wrote:

...

The alternative is worse: why is it better to have three values ('Specifically unmaintained', 'Maintained by foo', 'not specified either way/omitted field')?

Arguing by question, hmm? I think I answered that one in my original mail, and you don't give any reason for me to reconsider.

...

At least with the omitted field being significant, users can proceed knowing that if there is a maintainer of a package with omitted maintainer field, they haven't been too diligent about packaging the program.

Failing to check for a trivial error is indiligence? Perhaps. I prefer that such trivial errors be checkable by program - and that requires that a missing value is distinct from a null value.

...

And we already have a situation where omissions are significant. Consider the license: field. If a license isn't specified, it must, legally, be AllRightsReserved. That's the law.

You are making an analogy that supports my position, not yours. A missing Cabal license field says "there is no information about license here", not "all rights reserved": thus, the field distinguishes between a missing value and a null value (indeed, if this analogy supported your position, there would be no AllRightsReserved value!). It is true that if the package comes with no license, then you don't have any rights beyond what the law provides you (it does some, but it depends on the jurisdiction). However, there are more ways than just the Cabal license field to specify your license. Personally, I would regard the Cabal license field as informational only and check the package for the actual license statement before doing anything that requires a license. Likewise, I would never release a Cabal package which contains no license statement beyond the Cabal license field. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/

Brandon S. Allbery KF8NH

3:21 p.m.

On 2008 Jul 1, at 15:08, Antti-Juhani Kaijanaho wrote:

...

...
And we already have a situation where omissions are significant. Consider the license: field. If a license isn't specified, it must, legally, be AllRightsReserved. That's the law.

A missing Cabal license field says "there is no information about license here", not "all rights reserved": thus, the field distinguishes

Sadly, the law disagrees. If no license is specified, the license *is* "All Rights Reserved". It doesn't matter what conventions we'd like to apply. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Henning Thielemann

3:24 p.m.

On Tue, 1 Jul 2008, Brandon S. Allbery KF8NH wrote:

...

On 2008 Jul 1, at 15:08, Antti-Juhani Kaijanaho wrote:

...
...
And we already have a situation where omissions are significant. Consider the license: field. If a license isn't specified, it must, legally, be AllRightsReserved. That's the law.

A missing Cabal license field says "there is no information about license here", not "all rights reserved": thus, the field distinguishes

Sadly, the law disagrees. If no license is specified, the license *is* "All Rights Reserved". It doesn't matter what conventions we'd like to apply.

I think the point was, that there is no law which forces licenses to be specified in the Cabal file, and thus can be anywhere and need not be registered in the Cabal project file.

Antti-Juhani Kaijanaho

4:36 p.m.

On Tue, Jul 01, 2008 at 09:24:49PM +0200, Henning Thielemann wrote:

...

I think the point was, that there is no law which forces licenses to be specified in the Cabal file, and thus can be anywhere and need not be registered in the Cabal project file.

That was exactly my point. Thank you. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/

Gwern Branwen

12 Jul 12 Jul

4:48 p.m.

On 2008.07.01 22:08:52 +0300, Antti-Juhani Kaijanaho scribbled 2.9K characters:

...

(As I've asked before, please don't send me copies of list emails, unless you have reason to believe I am not subscribed.)

On Tue, Jul 01, 2008 at 02:03:51PM -0400, Gwern Branwen wrote:

...
The alternative is worse: why is it better to have three values ('Specifically unmaintained', 'Maintained by foo', 'not specified either way/omitted field')?

Arguing by question, hmm? I think I answered that one in my original mail, and you don't give any reason for me to reconsider.

...
At least with the omitted field being significant, users can proceed knowing that if there is a maintainer of a package with omitted maintainer field, they haven't been too diligent about packaging the program.

Failing to check for a trivial error is indiligence? Perhaps. I prefer that such trivial errors be checkable by program - and that requires that a missing value is distinct from a null value.

Yes, it is. Given that by the time a package is uploaded to Hackage, a dev will have seen the warnings at least twice (once on the upload, and once for each and every test-compile-from-tarball), a dev would have to be quite unobservant to not even notice it

...

...
And we already have a situation where omissions are significant. Consider the license: field. If a license isn't specified, it must, legally, be AllRightsReserved. That's the law.

You are making an analogy that supports my position, not yours.

A missing Cabal license field says "there is no information about license here", not "all rights reserved": thus, the field distinguishes between a missing value and a null value (indeed, if this analogy supported your position, there would be no AllRightsReserved value!).

You were the one who was saying that things should be machine checkable. Three values is ambiguous. With an omitted field, either omission or AllRightsReserved is enough to know that the copyright situation is either unclear (and hence you must assume AllRightsReserved) or outright hostile (in which case you cannot use it). Otherwise, omission is just... omission. If you propose that there should be an explicit Unmaintained value, then any tool or website needs to handle the omitted case; the only reasonable approach is to assume that omitted maintainer field means Unmaintained - at which point all Unmaintained has done is introduce yet more verbosity. (I actually disagree with AllRightsReserved, but I know enough to pick my battles - there is no way I will be able to convince the Cabal devs to remove the value, when it is in active use and has been for some time; arguing against inaugurating a new value is much more doable.)

...

It is true that if the package comes with no license, then you don't have any rights beyond what the law provides you (it does some, but it depends on the jurisdiction). However, there are more ways than just the Cabal license field to specify your license.

Sure, but do not all Linux package managers (and others) insist on having important metadata in a standard format? To go back to the license example, they do not let the package say ¨oh, the license info is some file 5 directories down and generated by the configure script¨, but it is the file LICENSE, in debian/.

...

Personally, I would regard the Cabal license field as informational only and check the package for the actual license statement before doing anything that requires a license. Likewise, I would never release a Cabal package which contains no license statement beyond the Cabal license field.

-- Antti-Juhani Kaijanaho, Jyväskylä, Finland

-- gwern Rule TA Morwenstow rita co ERR CTU walburn Fukuyama IRA

Antti-Juhani Kaijanaho

6:24 p.m.

On Sat, Jul 12, 2008 at 04:48:39PM -0400, Gwern Branwen wrote:

...

On 2008.07.01 22:08:52 +0300, Antti-Juhani Kaijanaho scribbled 2.9K characters:

...
Failing to check for a trivial error is indiligence? Perhaps. I prefer that such trivial errors be checkable by program - and that requires that a missing value is distinct from a null value.

Yes, it is. Given that by the time a package is uploaded to Hackage, a dev will have seen the warnings at least twice

If both intentional and unintentional missing field get the same warning, then the warning is useless, as a developer will have learned to ignore it.

...

...
A missing Cabal license field says "there is no information about license here", not "all rights reserved": thus, the field distinguishes between a missing value and a null value (indeed, if this analogy supported your position, there would be no AllRightsReserved value!).

You were the one who was saying that things should be machine checkable.

Yes I was! And I still am. I don't understand how is it possible that we two use the same arguments to argue exactly opposite positions. That's just weird (and in my opinion, your analysis is flawed - and I'm sure you'll say the same of mine).

...

Three values is ambiguous.

Exactly the other way around - three values is UNambiguous, since three real values are not being conflated in two nominal values. Sheesh.

...

If you propose that there should be an explicit Unmaintained value, then any tool or website needs to handle the omitted case

Why the if? I thought it was the POINT of this thread that such a value is being proposed. And yes, obviously all tools will have to handle any value defined for a field. That does not depend on whether there is a separate null value or not.

...

the only reasonable approach is to assume that omitted maintainer field means Unmaintainedi

No, it doesn't. It also can mean "the developer forgot". If there is an explicit null value ("unmaintained"), then leaving the field out can be made an error condition - a reason for rejecting an upload.

...

Sure, but do not all Linux package managers (and others) insist on having important metadata in a standard format?

Of course they do. And, since you mentioned Debian, I might mention that omitting Maintainer field in a Debian package is grounds for package rejection. There is a special value denoting "orphaned" (ie. lacking a dedicated maintainer). -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/

Ian Lynagh

24 Jun 24 Jun

7:51 a.m.

On Mon, Jun 23, 2008 at 10:51:43PM +0100, Duncan Coutts wrote:

...

Of course if you do have any questions or suggestions then now is a good time to mention them.

I think we should also say what "maintainer: libraries@haskell.org" means: how we decide which packages should use that as maintainer, who can do uploads of them, etc. Thanks Ian

Ross Paterson

8:08 a.m.

On Tue, Jun 24, 2008 at 12:51:59PM +0100, Ian Lynagh wrote:

...

On Mon, Jun 23, 2008 at 10:51:43PM +0100, Duncan Coutts wrote:

...
Of course if you do have any questions or suggestions then now is a good time to mention them.

I think we should also say what "maintainer: libraries@haskell.org" means: how we decide which packages should use that as maintainer, who can do uploads of them, etc.

I think it means that interface changes have to go through the library submissions process. Currently releases of them are created as part of GHC releases, but I guess you want to change that for some of them at some point in the future.

Don Stewart

23 Jun 23 Jun

7 p.m.

ross:

...

As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are:

* users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer.

When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt:

If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves.

A Maintainer value of "none" indicates that the package is not supported.

If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported.

Go for it.

Bryan O'Sullivan

11:18 p.m.

On Mon, Jun 23, 2008 at 2:05 AM, Ross Paterson wrote:

...

When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it.

Thanks for putting this together. I like it, and I think that any colour will do for the bike shed maintainer field.

Gwern Branwen

1 Jul 1 Jul

2:07 p.m.

On 2008.06.23 20:18:41 -0700, Bryan O'Sullivan scribbled 0.3K characters:

...

On Mon, Jun 23, 2008 at 2:05 AM, Ross Paterson wrote:

...
When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it.

Thanks for putting this together. I like it, and I think that any colour will do for the bike shed maintainer field.

I realize this looks like a trivial discussion, but small things can make big differences - this is one of the primary convictions I've carried away from my Wikipedia experience. The difference in edits between a wiki that forces you to make an account to edit and one that allows anonymous edits can be considerable, even though an account takes like 10 seconds to make (if you've done it before). Similarly, if we force people to explicitly say whether or not something is maintained instead of having a reasonable default when omitted - we are ratcheting up how much of a commitment a Hackage upload represents. People only have so much commitment in them. Supply and demand... -- gwern MI6 SISDE 36800 Waihopai ple SP4 illuminati FSF cracking rico

Josef Svenningsson

27 Jun 27 Jun

8:57 a.m.

+1 Looks good to me. Josef On Mon, Jun 23, 2008 at 11:05 AM, Ross Paterson wrote:

...

As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are:

* users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer.

When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt:

If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves.

A Maintainer value of "none" indicates that the package is not supported.

If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Ross Paterson

23 Jul 23 Jul

5:57 p.m.

On Mon, Jun 23, 2008 at 10:05:59AM +0100, Ross Paterson wrote:

...

As a few people have noted, we need to agree a policy in this area. As I see it, the drivers are:

* users need to know whether what they're downloading is supported, and if so by whom. * maintainers are entitled to control what goes out in their name. * allocating version numbers for a particular package name should be the prerogative of the maintainer.

When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt:

If the Maintainer field names a person or group, the release as a whole (including packaging) is the named maintainer's approved release, which they are supporting (at least for some time after the release). Ideally a maintainer would make that clear by uploading the release themselves.

A Maintainer value of "none" indicates that the package is not supported.

If a package is being maintained, any release not approved and supported by the maintainer should use a different package name. Then use the Maintainer field as above either to commit to supporting the fork yourself or to mark it as unsupported.

OK, I think there's broad agreement, except for the minor point of what value to use for unmaintained packages, and most people find it hard to care enough to settle that issue. So I'll just go with the above and clean up later if we ever come to a decision on that point.

Duncan Coutts

25 Jul 25 Jul

8:46 a.m.

On Wed, 2008-07-23 at 22:57 +0100, Ross Paterson wrote:

...

...
When something is agreed, I propose to put it on the hackageDB upload page and expect people to follow it. Here's my first attempt:

...

OK, I think there's broad agreement, except for the minor point of what value to use for unmaintained packages, and most people find it hard to care enough to settle that issue. So I'll just go with the above and clean up later if we ever come to a decision on that point.

Great. So I see you've published the policy on the hackage website: http://hackage.haskell.org/packages/upload.html So if we're going with "maintainer: none" then I guess we should disallow blank or unspecified maintainer on upload. Duncan

6143

Age (days ago)

6175

Last active (days ago)

List overview

Download

44 comments

18 participants

participants (18)

Antti-Juhani Kaijanaho
Brandon S. Allbery KF8NH
Bryan O'Sullivan
Bulat Ziganshin
David Roundy
Don Stewart
Duncan Coutts
Gwern Branwen
Henning Thielemann
Ian Lynagh
Iavor Diatchki
Isaac Dupree
Josef Svenningsson
Neil Mitchell
Niklas Broberg
Philippa Cowderoy
Ross Paterson
Simon Peyton-Jones