Christian, Libraries will change. You will have to update your code. This is inevitable unless you want us to freeze everything. If you're still on 6.10.4 you need to expect problems soon anyway. Few package authors support more than three compiler versions (and many only the one they're using themselves). If you want to hold off upgrading your code you can put an upper bound on the package dependency in the Cabal file (you should do that anyway). If someone changes something, assume that they do so for a reason. Don't so yelling on the list that someone should change it back just because you say to. Ask: "I see that X changed. I'm curious about the reason. Personally, it gives me problem Z and I would like to know if having Z is necessary." Working with the libraries process is annoying enough as it is that I don't really feel like also having to deal with people second guessing all the decisions we make. Johan

Ian Lynagh wrote:

This sort of disagreement is exactly what the process was designed to avoid: People shouldn't be surprised by changes, as they have been discussed and agreed on the mailing list.

Despite reading the libraries list, I've been uniformly surprised when I've run into changes in the wild. IMO It's too hard to keep track of an overview, amongst all the noise of discussions of individual proposals. Perhaps if we had a web page with a log of accepted proposals and those under discussion would help the situation, by gathering just the summaries together in one place. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

Ian Lynagh wrote:

On Thu, Dec 09, 2010 at 05:48:30PM -0000, Sittampalam, Ganesh wrote:

...

Ian Lynagh wrote:

...

This sort of disagreement is exactly what the process was designed to avoid: People shouldn't be surprised by changes, as they have been discussed and agreed on the mailing list.

Despite reading the libraries list, I've been uniformly surprised when I've run into changes in the wild. IMO It's too hard to keep track of an overview, amongst all the noise of discussions of individual proposals. Perhaps if we had a web page with a log of accepted proposals and those under discussion would help the situation, by gathering just the summaries together in one place.

I'm not sure I see how this would help. When you run into a change in the wild, don't you already know what it is? Are you wanting to be able to look up exactly what changed? Or when it changed? Or whether it was actually agreed, rather than an accidental change?

All of the above. The other purpose would be that I think reading the page every so often would help me to remember what's going on - it's hard to do that with the libraries list because as well as the proposals there's all the discussion around them. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

Am 09.12.2010 18:42, schrieb Ian Lynagh: [...]

http://www.haskell.org/pipermail/libraries/2010-September/014161.html

I think, I've even seen this message, but did not expect it would hit me.

Christian wrote:

...

ghc-6.10.4 is my production compiler for power-pc and sparc, due to problems with ghc-6.12.3 and ghc-7

I know, no tier 1 platforms.

Note that you are heading towards a bootstrapping problem: 6.10.4 won't be supported for compiling 7.2.

Well, I see milestones 7.0.2 and 7.0.3 before. Christian

Thanks Ian

On Fri, Dec 10, 2010 at 11:40:03AM +0100, Johan Tibell wrote:

Here's a proposal: don't have mailing lists maintain libraries. Calling libraries@ a maintainer is a bit of a misnomer:

* libraries@ doesn't clean up the code. * libraries@ doesn't write tests. * libraries@ doesn't consider APIs for completeness. * libraries@ doesn't polish documentation.

Libraries maintained by the mailing list are only maintained thanks to individuals (the Simons, Ian, other people with commit access) do some spring cleaning outside the libraries process.

A fair number of people, including you and I, have commit access. There is nothing to stop any of us from cleaning up the code, writing tests or polishing documentation, and most of us would be happy to commit such changes from occasional contributors. The only thing the current setup prevents us from doing is changing interfaces without getting wider agreement -- I think that's a feature.

On Fri, Dec 10, 2010 at 01:57:59PM +0100, Johan Tibell wrote:

On Fri, Dec 10, 2010 at 12:38 PM, Ross Paterson wrote:

...

The only thing the current setup prevents us from doing is changing interfaces without getting wider agreement -- I think that's a feature.

I'm not sure I agree. For example, IntMap didn't have strict versions insert and insertWith, making it practically impossible (due to crap performance) to efficiently keep an IntMap where the value was a counter of any kind (e.g. an Int). That took 4 months to fix as fixing it involved an API addition. FOUR MONTHS. If it had been my library it would have taken five minutes.

That would be this: http://hackage.haskell.org/trac/ghc/ticket/4257 The last 4 weeks of that period underline the problem with expecting Ian to apply all patches, especially when he was focussed on the stable branch. After the discussion period is up any committer could apply the patch, and we need a way of spreading that load. But most of the rest just shows the need for an active proposer.

Lets look at it another way, since the libraries maintained by libraries@ have a stricter process for API changes, they ought to have a better API than the ones that are maintained outside the process, right? At least in my opinion, the best libraries are all outside the libraries@ process: bytestring, binary, text, etc.

Don't you think the fact that these libraries are older, and their old interfaces have lots of users, might be a factor?

On Fri, Dec 10, 2010 at 01:57:59PM +0100, Johan Tibell wrote:

On Fri, Dec 10, 2010 at 12:38 PM, Ross Paterson wrote:

...

A fair number of people, including you and I, have commit access. There is nothing to stop any of us from cleaning up the code, writing tests or polishing documentation, and most of us would be happy to commit such changes from occasional contributors.

But it doesn't happen (to any large extent). We should ask ourselves why that is. Perhaps it's because since so many people are "responsible" (i.e. have commit access), no one feels responsible for the overall heath/design of the library.

Perhaps a good compromise would be for each package to have a maintainer, but for API changes to continue to use the current library process? That way there is a greater chance that someone will be doing the gardening, and they will be more motivated to ensure that proposals reach a conclusion, but for API changes the community will not be surprised by functions disappearing, appearing or changing.

...

The only thing the current setup prevents us from doing is changing interfaces without getting wider agreement -- I think that's a feature.

I'm not sure I agree. For example, IntMap didn't have strict versions insert and insertWith, making it practically impossible (due to crap performance) to efficiently keep an IntMap where the value was a counter of any kind (e.g. an Int). That took 4 months to fix as fixing it involved an API addition. FOUR MONTHS. If it had been my library it would have taken five minutes.

I think that gives an extremely misleading impression of how the process works. The first 2 weeks were required by the process, to give the community time to comment. It then took you 3 weeks to add "No objections within 5 weeks." to the ticket. After that, someone was working on fixing performance regressions in the package, and I didn't want to muddy the waters by pushing more changes into the package; like I said: > Could you please wait for the patches referrer to in #4257 and > #4278 to make it into the repo. They should be committed as soon > as Ian has time to look at them. I won't be pushing any container patches until the existing performance issue is resolved, either by fixing the regressions or by rolling back all the recent patches. I wouldn't have pushed them if I'd been the maintainer either. I also don't think the actual amount of time a patch takes to hit the repo is that important for the GHC boot libs, as to a large extent the only thing that matters in practice is which GHC major release they fall into.

Lets look at it another way, since the libraries maintained by libraries@ have a stricter process for API changes, they ought to have a better API than the ones that are maintained outside the process, right? At least in my opinion, the best libraries are all outside the libraries@ process: bytestring, binary, text, etc.

Those three have barely been "maintained" at all: They were recently designed as complete libraries (albeit as a rewrite in bytestring's case), rather than being the result of many years worth of accumulated code. Other old, core libraries which have had a maintainer in the past (e.g. Win32) haven't radically improved, as far as I can remember. Thanks Ian

| Here's a proposal: don't have mailing lists maintain libraries. | Calling libraries@ a maintainer is a bit of a misnomer: | | * libraries@ doesn't clean up the code. | * libraries@ doesn't write tests. | * libraries@ doesn't consider APIs for completeness. | * libraries@ doesn't polish documentation. | | Libraries maintained by the mailing list are only maintained thanks to | individuals (the Simons, Ian, other people with commit access) do some | spring cleaning outside the libraries process. | | My suggestion is that every library has a dedicated maintainer (or | two), empowered to make changes to the library. That means that | everyone want like every change they make, but it's much better than | the alternative. I agree with this. There could be more than two maintainers, but they should be named individuals. If a library has no individuals willing to take it on, maybe we don't need it! Simon

On Fri, Dec 10, 2010 at 05:08:20PM +0000, Malcolm Wallace wrote:

On 10 Dec 2010, at 10:40, Johan Tibell wrote:

...

Here's a proposal: don't have mailing lists maintain libraries.

My suggestion is that every library has a dedicated maintainer

A strong +1 from me. A certain amount of discussion about APIs on mailing lists is appropriate, perhaps especially for Platform packages. But ultimately, a real human maintainer must exist and take charge of the package(s) they own.

If that's the consensus then we need volunteers to maintain: array base containers directory extensible-exceptions haskell2010 haskell98 hpc integer-gmp mtl old-locale old-time pretty process random template-haskell unix (and probably a few more that are not in my GHC tree). Win32 is also not actively maintained at the moment, AFAIK. Thanks Ian

If that's the consensus then we need volunteers to maintain:

haskell2010 haskell98

These packages should now be fixed and immutable, save for errata. I suggest the relevant language report editor (or maintainer) would be responsible for applying errata patches?

array directory old-locale old-time random

Weren't these five basically the Haskell'98 standard libraries but with new hierarchical names? If so, then perhaps the two "old-" ones can simply be dropped, and the other three either folded back into the haskell2010 package (or an appropriate successor)? Unless a willing volunteer appears of course.

base

Isn't base already largely maintained de facto by the GHC team?

containers hpc mtl pretty

All of these either have obvious authors, or have recently seen love and attention from particular contributors. Perhaps those authors/ contributors could be encouraged to take on maintenance?

extensible-exceptions

integer-gmp process template-haskell unix win32

So I guess this bunch is the rump that may be trickier to find good homes for. Regards, Malcolm

Hi Johan Am 09.12.2010 17:54, schrieb Johan Tibell:

Christian,

Libraries will change. You will have to update your code. This is inevitable unless you want us to freeze everything. If you're still on 6.10.4 you need to expect problems soon anyway. Few package authors support more than three compiler versions (and many only the one they're using themselves).

granted. I appreciate the progress to better libraries (and your personal contributions).

If you want to hold off upgrading your code you can put an upper bound on the package dependency in the Cabal file (you should do that anyway).

I surely do want to upgrade.

If someone changes something, assume that they do so for a reason. Don't so yelling on the list that someone should change it back just because you say to. Ask: "I see that X changed. I'm curious about the reason. Personally, it gives me problem Z and I would like to know if having Z is necessary."

I did not mean to "yell", in fact, I asked. I wasn't curious about the reason, because the reason looked obvious to me: - avoid different names for the same thing - orthogonality to the prelude (foldl and foldr and no fold) The counter-arguments: - orthogonality to Data.IntMap is lost - there are other different names for the same thing (like toList) - intents to destroy backwards compatibility (for weak reasons) - may distract from more important deprecation warnings

Working with the libraries process is annoying enough as it is that I don't really feel like also having to deal with people second guessing all the decisions we make.

Why is it a problem to regret a decision being made? Is it such a big deal to remove (or keep) a deprecation warning? If this is the case, maybe someone (more patiently) wants to go ahead. Cheers Christian

Johan