Proposal: Change to library proposal process
marlowsd at gmail.com
Thu Jan 6 12:32:45 CET 2011
It's interesting to look at why we introduced the process in the first
"The idea is to reduce the number of 'bikeshed' discussions
we're having, ensure that submissions are not dropped, and
generally improve productivity."
that is, pretty much all the things that people are complaining that the
process is not doing. We had good intentions, but I guess it didn't
work. It didn't even ensure that submissions are not dropped, because
we did end up with plenty of abandoned proposals.
Some of us have been discussing this at length on IRC over the past
couple of days. With it being a new year this is great time to take a
critical look at our processes, and I agree with Simon that we should
take this quite seriously. I'd like to thank Greg and Johan for
sticking around to discuss this rather than giving up.
The underlying problem they've raised is that this community has become
a little too afraid of change. Nobody feels empowered to do anything
without first consulting "the community", and that typically ends up
nowhere except for very uncontentious issues. However, historically all
the progress has been made by individuals or small groups Just Doing It.
Hackage has enabled the community to share the fruits of each other's
productivity on non-core libraries, but very little movement is
happening at the core.
The slow rate of change is to some extent a reaction to a period of
instability we in the past (around GHC 6.8) when there was a lot of
upheaval and complaints from users that their code kept breaking with
new GHC releases. We took some positive steps to help with this (the
base-3 compatibility package, wider use of deprecation, and generally
shying away from breaking changes). There has always been a tension
between improving APIs and stability, and currently we're skewed towards
stability, at least for these core APIs.
Compulsory review of API changes is a good thing - we get lots of eyes
on the changes. However, the process would be more appropriate if we
were basically happy with the APIs we have. On the contrary, we have
plenty of large-scale changes that need making in base and other places,
and forcing all changes through the library process is making it hard to
get these cleanups done. Another thing making it hard is the lack of
people actually doing it, but it's difficult to tell whether that's due
to the obstacles we've put in the way, or whether there really aren't
people with the time and inclination. We'll only find out by actually
removing the obstacles.
The process is not applied consistently either - there are libraries
like bytestring which are not under the process but are arguably just as
"core" as containers.
I'm coming around to the view that this small-scale API change review
isn't getting us where we want to go. To really improve APIs we should
have a group of people looking at the whole, and making strategic
decisions. Let's figure out where we're going and how to get there,
rather than making a series of tiny incremental steps (slowly). Let's
really make FilePath an ADT, make binary Handles a different type, move
more of base out into separate packages, remove the Show superclass of
Num, overhaul the containers API, finish creating the Exception
hierarchy, etc. etc. We've had a period of stability, maybe now it's
time for change, and lots of it.
The changes being proposed by Greg and Johan, as I understand it, would
amount to the following. I'm willing to give it a try; we can always go
back if it doesn't work out.
- maintainers are empowered to make API changes.
- no formal review process for API changes, although there is an
expectation that non-trivial changes would still be discussed on
the list beforehand.
- we would still have a clearly documented path for contributions
- commit messages are copied to the list, and should
detail API changes sufficiently that the community
can keep an eye on what is happening and comment.
- we get more maintainers (presumably they'll just appear, or
Does anyone violently disagree? Suggestions for improvements?
More information about the Libraries