Proposal: Make gcd total

[Johan Tibell]

On Thu, May 19, 2011 at 10:35 AM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> | > So if someone actually follows through with this as an official
> | > libraries submission (with a patch, deadline, etc.), the odds seem in
> | > favor of it.
> |
> | I'll try to see it through, although the process seems rather daunting.
> | It has annoyed me for too long.
>
> I think there is general agreement that
>  * The library submission process is too daunting, especially because you have to
>   come up with a complete implementation of a proposal before you even know
>   whether it's going to fly.
>  * The process gets stuck because achieving universal consensus is too difficult
>  * The maintainer "libraries at haskell.org" means that no individual feels responsible
>   for making a decision on a proposal.
>
> What we need is something to put in its place.  Simon and I have been cooking up a proposal.  Here it is:
>
>        http://www.haskell.org/haskellwiki/Library_submissions/NewDraft
>
> It is aimed just at libraries whose maintainer is listed as libraries at haskell.org.  (The thousands of other libraries with named maintainers can obviously do whatever their maintainer wants, although perhaps this new draft may be useful for them too.)
>
> It's a draft.  What do you think of it?  Do you think it would be better than the status quo?  Can you suggest any improvements?

Thanks for brining this issue up again. The draft is an improvement
over status quo and making some progress on this issue is important.
Some specific comments:

Section 2:

"widespread support" is a bit of a wishy-washy phrase. If 7 people
want it, is that widespread support?

What I've seen happen quite a number of times in the past is that some
person who uses a particular function composition a lot suggests that
it should be added to some core library. A few more people (say 7)
chime in and say that that they also have used this particular
composition a lot and that it therefore should be added.

We might say that 7 people is a lot (you rarely see many mother than
that in any email thread on haskell-cafe) and therefore the function
should be added. However, there's a strong selection bias here and
most likely the hundred (or whatever number) of other users of the
API, who will now have a slightly more complicated API, can't be
bothered to chime in on every request to add a function.

This is one of the places where having a real maintainer is crucial.
Because the maintainer is more likely to take the design of the whole
library into account when making decisions, while the (well meaning)
proposer is trying to address a particular pain point he/she is
experiencing. If the maintainer is "required" to accept such changes,
I'm afraid the overall quality (and simplicity) of our APIs will
suffer in the long run.

Section 3:

It's not clear when the "deadline for discussion" should be used. Does
it apply to any change or only public API changes? Does it apply even
if it's the maintainer that making the change? Having to spent two
weeks (even though most of the time is spent waiting) to make a single
change is too high an overhead for me. I suspect I would just not
bother making the change. To make things more concrete, what steps are
required of the (future) maintainer of containers who wants to add a
strict version of some function (many functions are missing a strict
version at the moment)?

> ALSO: does anyone (or two or three people) want to volunteer to act as maintainer for any of the "Volunteer needed" packages?  Johan, I was thinking you might serve for 'containers', perhaps in harness with someone else since it is such a crucial package.

Depends entirely on what the process ends up being. If I end up
maintaining it I'd ask Milan Straka to co-maintain it as he's probably
the one person that understands the code the best at the moment.

Johan