On Sat, May 10, 2008 at 11:17:49AM +0100, Ian Lynagh wrote:

On Fri, May 09, 2008 at 11:21:40PM -0700, Donald Bruce Stewart wrote:

...

It's currently a bug that anyone can (accidentally) release their own versions of the core libraries.

Yes, this mix-up is really our fault; we don't advertise or enforce our policies well enough (I'm not even sure if we've got total agreement on what they are?).

It's also raised an interesting question of who can upload the packages maintained by libraries@. I guess we just create a sensible looking list of people (roughly equal to those who release Haskell implementations probably makes sense).

Up to now, releases of these packages have been part of GHC releases; the versions on hackage have been images of the packages from GHC source releases. If we're going to do releases of them more often, that ought to be done via the libraries list. It's a special case of a broader problem with non-maintainer uploads (i.e. releases), which cause exactly the same problems for other packages too. If we had an agreed policy we could advertise and enforce it, but we don't. I don't think that mechanized enforcement is the priority; having a policy is. We also need to ensure that the version in the darcs repo is larger than the most recent release, but smaller than the release to follow.

Hi

password-protection mechanism i've proposed in previous message partially enforces this policy, although with many caveats. i hope,

Yay, another password... My suggestion would be that each account has a list of permissible packages it can upload. i.e. Ian/Ross/Simon would all have their accounts include unix as a permissible package. If a user uploads a new package, which has not been on hackage before, it gets added to their list. A little UI to allow logged in users to add additional package maintainers and we'd be all sort - but the UI could come later. In general it would enforce what we want, with no overhead in the common case. Thanks Neil

On Sat, 2008-05-10 at 11:51 +0100, Ross Paterson wrote:

It's a special case of a broader problem with non-maintainer uploads (i.e. releases), which cause exactly the same problems for other packages too. If we had an agreed policy we could advertise and enforce it, but we don't. I don't think that mechanized enforcement is the priority; having a policy is.

This seems like a good moment to revisit that discussion http://haskell.org/pipermail/libraries/2008-February/009343.html Here's a straw man policy: We want packages to be uploaded by maintainers or someone the maintainer/author has delegated that responsibility to. Packages can be forked at any time but with new names. Transferring maintenance of a package from one person to another is easy since it's just delegation. The tricky case is when the original maintainer/author disappears without delegating/nominating new maintainers and a new volunteer wants to pick up the package under the original name. We can borrow a policy here from some existing organisation, the procedure usually involves trying to find the maintainer, giving them time to respond, then announcing that you want to take over maintenance and seeking feedback and hopefully reaching a consensus. Duncan

On Sat, 2008-05-10 at 16:57 +0400, Bulat Ziganshin wrote:

Saturday, May 10, 2008, 4:00:28 PM, you wrote:

...

We want packages to be uploaded by maintainers or someone the maintainer/author has delegated that responsibility to.

...

Packages can be forked at any time but with new names. Transferring maintenance of a package from one person to another is easy since it's just delegation.

there is a difference: generally speaking, we have a list of persons that can upload new versions of package and list of persons who can change the first list

am i correctly understood that you propose to make these lists identical?

Yes, it's simpler. Duncan