non-maintainer uploads to hackageDB
I think we need, perhaps not a policy, but some agreed etiquette regarding uploads to hackageDB. (Please hold off on the technical suggestions until we've decided what behaviour we want.) Personally, I'd rather have all maintainers doing their own uploads. As I user, I'd like to know that someone takes responsibility for the whole of a package I download, including the packaging, and will be available for bug fixes and enhancements (such as making it work with the next GHC release). As this is free software, there's nothing to stop someone forking a package and maintaining their own version. Then as a user I'll need to choose between the two, but I'll still be looking for a maintainer of the whole package. It might be fair to ask that someone creating a fork change the name of the package in some way, to avoid confusion (and eating up the original maintainer's version numbers). This is a different situation from Linux or BSD distributions, where primary releases are repackaged to conform with native conventions. HackageDB is an upstream site, where people can make their own releases, using a common package format (Cabal). (Similarly I don't think we need the pristine+patches setup used by those distributions: maintainers should just take care of the pristine.)
On Mon, Feb 25, 2008 at 1:35 AM, Ross Paterson
I think we need, perhaps not a policy, but some agreed etiquette regarding uploads to hackageDB. (Please hold off on the technical suggestions until we've decided what behaviour we want.)
Personally, I'd rather have all maintainers doing their own uploads. As I user, I'd like to know that someone takes responsibility for the whole of a package I download, including the packaging, and will be available for bug fixes and enhancements (such as making it work with the next GHC release).
As this is free software, there's nothing to stop someone forking a package and maintaining their own version. Then as a user I'll need to choose between the two, but I'll still be looking for a maintainer of the whole package. It might be fair to ask that someone creating a fork change the name of the package in some way, to avoid confusion (and eating up the original maintainer's version numbers).
This is a different situation from Linux or BSD distributions, where primary releases are repackaged to conform with native conventions. HackageDB is an upstream site, where people can make their own releases, using a common package format (Cabal). (Similarly I don't think we need the pristine+patches setup used by those distributions: maintainers should just take care of the pristine.)
I'm sorry I missed this when it was first posted. My suggested policy is that a non-maintainer who wants to upload a package should ask the maintainer first, and allow for a reasonable response time before uploading a package. If a package is uploaded against the maintainer's wishes, the maintainer should be allowed to request to have it removed. If the uploader is eager to have the package released, he is welcome to help fix the issues that the maintainer wants resolved before releasing. If the uploader still insists on uploading, he should fork the package. Hopefully this should be very rare. /Björn
On Wed, Mar 12, 2008 at 02:02:38PM +0100, Bjorn Bringert wrote:
My suggested policy is that a non-maintainer who wants to upload a package should ask the maintainer first, and allow for a reasonable response time before uploading a package.
Having reflected a bit more, I see even less value in having a package uploaded by someone who isn't maintaining it. If I download something and have a problem with it, or have a suggested improvement, whom shall I contact? The answer to that is supposed to be the email address in the Maintainer field. If they take no responsibility for the package I'm trying to use, I'm going to regret downloading it. (Some abandoned software continues to be useful, but I'd prefer to see it marked as unmaintained, so that I know what I'm letting myself in for.)
If the uploader is eager to have the package released, he is welcome to help fix the issues that the maintainer wants resolved before releasing.
Sure, or send the maintainer packaging patches. That seems a more useful model to me.
If the uploader still insists on uploading, he should fork the package. Hopefully this should be very rare.
I have no problem with forks, as long as they're maintained (which is indeed rare). They should probably have a different name though, if the original is still active.
participants (2)
-
Bjorn Bringert -
Ross Paterson