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.)