Proposal: Change to library proposal process
simonpj at microsoft.com
Wed Jan 5 18:56:48 CET 2011
Some short thoughts on this thread
* Duncan makes a critical distinction between
Both changes presumably offer some benefit. Implementation
changes may impose some costs, but only on other
implementers (outright bugs aside). These costs are of the
form "how the devil does this new code work".
API changes impose costs on every user of that library, to
adapt his or her code to work with the new API. That's a
much larger population.
Gregory advocates a "by default apply patch" policy. That's
fine for implementation changes, but I think it is arguably
right for API changes to have to suffer a significantly higher bar.
(In fairness to Gregory, I believe that his proposals were
largely directed at implementation changes. When people offer
patches for GHC itself, we certainly use the "by default apply"
rule, because they are internal -- they fall under the
"implementation change" heading. Even then, if the patch
is big it sometimes take me a while to review because I am
aware that I'll be maintaining this code in 5 years time, when
the author is perhaps long gone.)
I think it'd be good if the library-change prcess acknowledged
the above distinction explicitly, and treated the two differently,
as Duncan suggests.
* I fully subscribe to Johan's view that each core library needs
a named, individual maintainer (or a small group of such). The
libraries@ mechanism does work, but I think it'd work better if
each lib had a named maintainer.
* Gregory writes "The fact of the matter is, I would definitely
like to contribute but I'm not going near our current process
with a 20-foot barge pole. And I'm unequivocally not the only
potential contributor who feels this way. From an interested
observer's perspective, it seems like libraries@ is where good
code goes to die, and I don't have the time, energy, or
patience to endure it."
Others may agree or disagree with this view, but it is a *fact*
that G feels this way, and that he believes that others do too.
That's alarming to me, and I think we need to take it
seriously, since G has done us the courtesy of explaining his
position (thank you Gregory). Quite what we might do to
address these concerns isn't so clear to me. I'm agnostic
about technology, my gut feel is that the core issues are not
technological ones (eg github vs darcs).
More information about the Libraries