agreeing a policy for maintainers and hackageDB

[Isaac Dupree]

+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 <ndmitchell at gmail.com> 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 <duncan.coutts at worc.ox.ac.uk> 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 at haskell.org
>>  >  http://www.haskell.org/mailman/listinfo/libraries
>>  >
>>  _______________________________________________
>>  Libraries mailing list
>>  Libraries at haskell.org
>>  http://www.haskell.org/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>