Maintaining base

[Simon Peyton Jones]

Dear CLC

There was a helpful discussion on this thread about the role of the CLC.

I had previously understood CLC to be the maintainer of base.  Indeed the home page says "The primary responsibility of CLC is maintenance of base package".  A I understand it, the maintainer of a library is normally responsible for all aspects of that library, including

1. its API
2. its code
3. its documentation

Of course it might manage these aspects differently; for example, (1) might go via the proposals process, and (2,3) via PRs.

But now I understand that perhaps it is responsible only for (1), the API.  In which case, who is responsible for (2) and (3)?  Who approves PRs and merges them?

Is that the GHC team?  That team is already pretty overstretched and I worry that, say, the I/O support in base might get less attention than it deserves, or the exception handling stuff.

What about something like splitting up base into smaller package(s)?  That would affect the API, but even once that was fixed there would be many internal implementation decisions about the structure of the code.  Again I worry that the GHC devs would struggle to do that.

Similarly putting all base PRs into the GHC issue tracker is possible, but risks them getting lost in a blizzard of other GHC tickets.

In practice, the distinction between (1) and (2) can get pretty fuzzy.

To put it more positively, it would be great to empower and manate a group of people to make the base library as good as it can be.   At the moment maybe everyone feels "I can't trespass on the GHC team's turf".   Conversely, if the GHC team think that the CLC is doing it, and the CLC team thinks the GHC team is doing it, we'll get misunderstandings. So it's worth clearing up.

Of course, base comes with GHC as part of its release, so there would need to be good coordination with the GHC team.

So my TL;DR is: who is responsible for the care and maintenance of base?  Does the CLC have a view?

Thanks

Simon

[Andrew Lelechenko]

Dear Simon,

But now I understand that perhaps it is responsible only for (1), the API.

CLC is responsible both for (1) and (2). Could you possibly clarify which of our external communications make you think that (2) is not in scope? Only trivial internal changes (indentation, etc.) are out.

I think such arrangement is most optimal for GHC, CLC and wider community. FWIW this is not an innovation and just codifies pre-existing practices. But I understand that you, as a GHC developer, find it suboptimal. Is this opinion shared by others in GHC team?

For example, if GHC team believes it is more productive, CLC can potentially take over a responsibility for any change in libraries/base subtree. I honestly doubt it is the best  approach, but open to discuss. 

Since we two are in the same time zone, happy to arrange a call, if it helps. 

Best regards,

Andrew

--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAJKmMz81uKkv_XzhUkiD1cXsBKvhUVK%3DYC4XjiPi9JTh312iLg%40mail.gmail.com.

[Simon Peyton Jones]

> Could you possibly clarify which of our external communications make you think that (2) is not in scope?

Perhaps I over-interpreted this response on the thread:

What about code changes that don't affect the API? In-scope or not?

Code changes that do not affect API / semantics / behaviour / performance, such as trivial renaming / reshuffling, are likely to be out of scope.

I read that as meaning that an internal refactoring, however large, that did not affect outward facing behaviour is out of scope.   But I now understand from what you say above that the the only things that are out of scope are:

• Documentation
• Purely cosmetic changes, such as indentation

There's always a grey area.  E.g. renaming an internal function is cosmetic; but a large scale renaming across the entire library might be regarded as more than cosmetic.

But I think you are saying that, say, addressing bugs in the I/O library is firmly in-scope for CLC.

I'm not expressing a GHC-team opinion -- or even my own opinion -- yet anyway!  I'm genuinely just trying to understand what the CLC intends.  I also want to know who is responsible for any aspects of base that are out of scope for CLC.   It's all fine... the reborn CLC is fairly new, so it's not surprising that we need to do a bit of communication to check that everyone knows who is doing what.

I'd be happy to have a call, thank you -- I think it would be helpful to include Ben.

Simon