[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

On Thu, May 19, 2011 at 2:18 PM, Simon Peyton-Jones wrote:

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?

No, I think it's fine. Once I got down to do the detailed review I forgot that this important principle had already been stated.

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

Good to know that internal changes doesn't need review. Would an ask-for-forgiveness model work i.e. if the maintainer makes some radical change someone who reads the commit emails could complain and have the change reverted.

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

I don't think we need to equate "chance to react" with upfront review. Once can react by e.g. following commit messages.

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

I'd like to set some expectations here. My current belief is that the process that's used to managed e.g. bytestring, text, and network is fine. That is the default the-maintainer-knows-what-he's-doing open source approach. I'll try to be open to any restrictions to that, but this is the point I'm starting at. Cheers, Johan

Hi Simon, I have re-read the entire document and I'm willing to try it out in its current form. I'd like to use the remainder of this email to note my remaining reservations, to clarify my thinking on these issues if nothing else. Motivation and momentum ====================== Keeping oneself motivated is necessary in order to be productive, especially in open source where you don't get paid to work. Progress is often made in small spurts, often during weekends, when people find some inspiration to do a particular task. What sustains productivity is the feeling of progress when code gets submitted or when you can share your work in the form of e.g. a new library release. It's very gratifying to spend a weekend hacking on something -- making something better -- and then share the results with your fellow human beings. Having to wait weeks (i.e. the length of the discussion period) hurts productivity. By then end of the waiting period whatever enthusiasm you had at the start is likely gone. Even if you manage to keep yourself motivated through the waiting period there's a "pipeline stall" effect, where new changes you want to make are stalled by changes still under discussion. Entitlement and open source ======================= I was quite put of during earlier library discussions and often left the discussion annoyed. There's much more arguing for argument's sake: some discussions were up to 100 messages long and disproportionate to the magnitude of the proposed change. I haven't had a single unpleasant experience discussing changes with people outside the libraries process where discussion so far have been short, to the point, and almost always start by someone sending me a patch. I think there's a much stronger sense of entitlement around the core libraries. The libraries process implicitly says that the maintainer has to spend time talking to anyone that feels like having an argument. This is not the case in open source at large, where the size of your contribution, your prior "work" (in a very wide sense), and the relevance of what you have to say decides how much attention you get. Cheers, Johan

Hi Simon, On Fri, May 20, 2011 at 2:31 PM, Simon Peyton-Jones wrote:

But I understand you as saying "fine, let's try it and see".

Lets try and see.

There's a balance isn't there?  Changing the API of a widely used library imposes costs on lots of other people, and it's reasonable to take their concerns into account.

If "legalization" was needed to prevent maintainers from breaking APIs and upsetting users, we'd expect to see lots of upset users as the absolute majority of packages is not maintained using any such legislative document. We must therefore conclude that there must be something else that prevents maintainers from breaking their APIs (unnecessarily). These other effects (i.e. social dynamics) are much more flexible than prescriptive documents that by their nature typically are more absolutist. Cheers, Johan

Johan Tibell wrote:

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

Arguably, the right thing to do here is to have one proposal which says: "Let's add strict versions for these functions because ... and but not for these functions because ...". Having two weeks to discuss this doesn't seem that unreasonable. IMO, changing APIs one function at a time is usually not optimal. If a change is part of a larger design then it's much better to discuss the entire design at once. If it's completely isolated, then it often isn't really worthwhile anyway. Again, this is probably just my opinion but I think that proposals of the form "add this function" should be routinely rejected unless there are really good reasons to accept them. As you say, they often just complicate the API and don't contribute to the overall design. Roman

dead right; fixed | -----Original Message----- | From: Ivan Lazar Miljenovic [mailto:ivan.miljenovic@gmail.com] | Sent: 19 May 2011 13:14 | To: Simon Peyton-Jones | Cc: Haskell Libraries; cvs-ghc@haskell.org; Daniel Fischer | Subject: Re: Proposal: Make gcd total | | On 19 May 2011 18:35, Simon Peyton-Jones wrote: | > 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? | | Under section 3: | | "At the end of the discussion period, summarise your understanding of | the consensus (or lack thereof), including a link to the thread in the | mailing list archives, and send the summary to the moderator for | decision. " | | Should that be _maintainer_ rather than moderator? | | -- | Ivan Lazar Miljenovic | Ivan.Miljenovic@gmail.com | IvanMiljenovic.wordpress.com

| I don't have access to a Windows box, so *I* cannot ensure the code runs on | Windows. | And if the code involved doesn't make use of any OS-specific functions or | libraries, like purely numerical code in base, if it worked on one OS but | not on another, something lying deeper would be broken. | | So, can we weaken the above? I've weakened it to make it clearer that there's a continuum. Whaterver you don't do the maintainer may have to, and that'll affect how keen he or she is to adopt the idea. | I would be willing to be co-maintainer of random, mtl or containers. | I could be persuaded to become sole maintainer of some of them if | necessary. great thank you! Simon

On Thursday 26 May 2011 10:19:51, Johan Tibell wrote:

On Thu, May 26, 2011 at 9:37 AM, Simon Peyton-Jones

wrote:

...

Friends

Thanks to those who responded to the message below, about improving the process for developing the core Haskell libraries. http://www.haskell.org/haskellwiki/Library_submissions/NewDraft

Feedback has been broadly positive, with constructive suggestions that we've incorporated in the text. I suggest that we leave another week for debate and refinement, and (unless there are some substantial new points) adopt the new process from 9 June.

I hope that's agreeable. (We don't have a process for modifying the process :-)

Sounds good to me.

To me too.

Cheers, Johan

On 5/26/11 5:22 AM, Christian Maeder wrote:

Am 26.05.2011 09:37, schrieb Simon Peyton-Jones:

...

Friends

Thanks to those who responded to the message below, about improving the process for developing the core Haskell libraries. http://www.haskell.org/haskellwiki/Library_submissions/NewDraft

I see:

"Portability. Good code is portable. In particular, try to ensure the code runs in Hugs and GHC, and on Windows and Linux."

I believe Hugs is dead and Mac OS is also an important platform, so apart from testing on multiple platforms (automatically by "validate"?) I wonder what a good portability measure is. Maybe older versus most recent ghc versions, or as few extensions (that just ghc support) as possible (ideally none?).

While Hugs is dead, claiming Hugs portability does still serve a useful purpose IMO. In particular, the most recent Hugs is roughly contemporaneous with GHC 6.6, which captures an important point in the development of the type system. In particular, Hugs supports functional dependencies, MPTCs, and overloadable instances. This collection of features is relatively easy to implement[1] and served as the de-facto "standard Haskell" for a long time. While the revived Haskell committee hasn't yet blessed all these extensions, they are the sort of things that people expect of any "complete" Haskell compiler. Last time I checked, JHC and UHC haven't quite made it to that benchmark yet (though hopefully that'll be changing soon, if it hasn't already). After the GHC 6.6--6.8 era, the development of the type system began moving quickly again. Whereas this classic Haskell was focused on extensions to the typeclass system, newer GHC is focused on dependent type issues like GADTs, type families, etc. Because this newer work is still very much in flux and has much deeper consequences for the whole type system than does the typeclass stuff, there are good reasons for not expecting non-GHC compilers to follow it all, and for wanting core libraries to avoid using the extensions in order to retain portability. Saying that the code is portable to Hugs seems like a reasonable circumlocution for expressing all of this. Unfortunately, because of the death of Hugs, it really is a circumlocution. Though as I recall, there are some folks still *using* Hugs for embedded devices even though development and maintinence of the interpreter has ceased. For those folks, knowing that core libraries are still compatible is a nice thing. [1] The exception being fundeps which are notoriously difficult to implement correctly. -- Live well, ~wren

Thank you! So Johan and Milan will maintain 'containers'. Simon | -----Original Message----- | From: Milan Straka [mailto:fox@ucw.cz] | Sent: 26 May 2011 22:33 | To: Simon Peyton-Jones | Cc: Haskell Libraries; cvs-ghc@haskell.org; haskell-prime@haskell.org; Johan Tibell | Subject: Re: New libraries process | | Hi all, | | > Thanks to those who responded to the message below, about improving the process for | developing the core Haskell libraries. | > http://www.haskell.org/haskellwiki/Library_submissions/NewDraft | > | > Feedback has been broadly positive, with constructive suggestions that we've | incorporated in the text. I suggest that we leave another week for debate and | refinement, and (unless there are some substantial new points) adopt the new process | from 9 June. | > | > I hope that's agreeable. (We don't have a process for modifying the process :-) | | Johan pointed out the new library submission process to me -- thanks. | | I am interested in being the containers maintainer under the new library | submission process. | | I have been working on the containers code for some time now (I had | another data structure presentation on TFP 2011), my PhD thesis topic is | Functional persistent data structures and I have been programming in | Haskell for some time now -- I believe I can be the maintainer of | containers. With the proposed submission process, I would also like to | be the maintainer (this was not true with the previous submission | process -- I stopped working on the containers package because of it). | | I think the proposal is really a way forward. | | Cheers, | Milan Straka