New libraries process

[Chris Dornan]

Hi All,

 

Is there any chance that we can allow (say) the Haskell committee to have a
veto if they think a mistake with systemic consequences is about to be made.

 

I don't expect it to be used, but it would signal that the stability or lack
thereof of the Haskell libraries has systemic consequences for all Haskell
users and other library maintainers.

 

I do not want a heavyweight process, but it would be good to see some
representation of the bigger picture in this process, even if it is
generally held in reserve.

 

Others have a much more experience in these matters - I may be bothering
over nothing and complicating things. It is just an idea.

 

Chris

 

 

From: libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org]
On Behalf Of Simon Peyton-Jones
Sent: 19 May 2011 13:19
To: 'Johan Tibell'
Cc: cvs-ghc at haskell.org; Haskell Libraries
Subject: New libraries process

 

[Changing subject line; sorry for the odd initial one!]


| "widespread support" is a bit of a wishy-washy phrase. If 7 people
| want it, is that widespread support?
| ...should be added. However, there's a strong selection bias here and
| ...This is one of the places where having a real maintainer is crucial.

I agree.  The maintainer should take account of selection bias.  I've added
words to that effect.

| experiencing. If the maintainer is "required" to accept such changes,

No, we intended that the  maintainer is never *required* to accept a change.
To quote "the community offers opinions; the maintainer decides".   If you
think that point should be made even more strongly, can you go ahead and
edit?

| 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.

Our intention was to make sure that the community had *some* opportunity to
comment on a change that may affect them.   You point about public APIs is a
good one -- for internal changes perhaps all a proposer needs to is to
persuade the maintainer.  (Or, if the proposer is the maintainer, persuade
himself.) 

| 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)?

So this is a public-API change, but you could argue that it's one that
cannot hurt a client because it's only widening the interface.

What about if you wanted to change the signature of a function in the API.
Wouldn't it be reasonably to give your community a chance to react?

| Depends entirely on what the process ends up being.

Good.  I'll be dissatisfied if we don't end up with a process that you think
is sane.

Simon

_______________________________________________
Libraries mailing list
Libraries at haskell.org
http://www.haskell.org/mailman/listinfo/libraries 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1325 / Virus Database: 1509/3646 - Release Date: 05/18/11

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110519/acbdcf48/attachment-0001.htm>