Subject API evolution of array to CLC vote

[tomjaguarpaw]

array is maintainerless yet there are outstanding requests to change its API. Since array is a critical and fundamental ecosystem package I suggest that decisions about changing its API are brought to CLC vote in the same way as similar decisions about base.

There are other important maintainership tasks that don't involve changing the API (per @Bodigrim, "daily routine: updating for new GHC versions, supporting test suite / benchmarks, releasing and synchronising with GHC developers."). I don't suggest we make those the direct responsibility of CLC members. I'm sure the CLC will be grateful for volunteers willing to take responsibility for those aspects.

[phadej]

CLC current "charter" says

If CLC finds a Core Library in a neglected state, it can source and install new maintainers or resolve situation by other means.

Also

Maintainers of Core Libraries may at their own accord seek CLC approval for controversial changes, but are not required to do so. CLC does not interfere with daily development of Core Libraries as long as appointed maintainers keep them in an appropriate shape and support healthy communication with contributors.

---

So I'm very strongly against

Since array is a critical and fundamental ecosystem package I suggest that decisions about changing its API are brought to CLC vote

Especially as

I don't suggest we make those [daily maintenance] the direct responsibility of CLC members. I'm sure the CLC will be grateful for volunteers willing to take responsibility for those aspects.

You ask volunteers to take responsibility without giving them much if any power. That's not a good deal.

[tomjaguarpaw]

I think it's up to each individual to decide whether it's a good deal for them, isn't it? I would guess there are plenty of people who would like to be responsible for maintainership duties without bearing the heavy burden of responsibility for API evolution.

Are you saying that volunteers are only looking for "power"? If so, I disagree with that claim.

[phadej]

I think it's up to each individual to decide whether it's a good deal for them, isn't it? I would guess there are plenty of people who would like to be responsible for maintainership duties without bearing the heavy burden of responsibility for API evolution.

I agree with that. I'm saying

1. first find a maintainer (s)
2. ask them whether they are ok with subjecting array to CLC votes.

If you do 2. first you will make a pool if interested people smaller

[tomjaguarpaw]

I think the skills required for these two cases are different, and different people will have different levels of interest in each.

1. "daily routine: updating for new GHC versions, supporting test suite / benchmarks, releasing and synchronising with GHC developers"
2. Determining API evolution

I think it's important to decide what skills and interests we want to "hire" for, and then look for people that match. At the moment it seems ambiguous to me exactly what we are looking for, for array.

[phadej]

are looking for, for array.

maintainer(s).

[tomjaguarpaw]

Does "maintainer(s)" mean people who will perform 1, or 2, or both? They are different roles.

[phadej]

Does "maintainer(s)" mean people who will perform 1, or 2, or both? They are different roles.

I'd say at least 1, yet...

IIRC at some point of time GHC developers (cc @bgamari) have offered to do part of 1. i.e. the work needed to unblock GHC development, but ruled out doing anything else like triaging issues or discussing minor or major features. That is probably enough short term.

In fact Ben does make array revisions for GHC release needs: e.g. https://hackage.haskell.org/package/array-0.5.4.0/revisions/

[chessai]

What makes array special here compared to say, vector or primitive?

I will say that, certain Haskell GitHub org admins/hackage trustees/GHC developers will step up to do some quick unblocking work, where it's necessary and uncontroversial.

But for API changes, I believe we should instead just find a dedicated maintainer(s). We came up with this system of appointing maintainers and providing light oversight, but generally giving them free reign. These maintainers of course need to be trustworthy, available, and domain-knowledgeable. In other words, they don't need us managing them and coming to us for all improvements. And if something is genuinely breaking, we need to trust them to be able to weigh all of the appropriate considerations, consulting relevant domain experts/library users/Haskell community via social media/CLC members/etc where it makes sense. And of course treat the maintenance and development of the libraries with the seriousness they deserve.

Some notes on the old process and why things have changed:

• The old way of doing things, where CLC took over all maintenance of all core libraries, was a big inefficient mess. Nothing ever got done, there was too much bureaucracy, it was almost like a movie parody of a government office where everyone does nothing, takes siesta half the day, and keeps their job with pension. That's not to say that it has to be that way if we just take over one library, but it's an unnecessary line to cross. And CLC members can still maintain core and critical libraries as individuals. @Bodigrim has been going beast mode on multiple for a while. @mixphix has taken over maintainership of deepseq. @emilypi with mtl.
• After the CLC shakeup a couple years ago where we obliterated a lot of the old processes, I personally did a lot of maintainer hunting and placing for multiple core libraries, even conducting informal interviews. Unfortunately there weren't many active CLC members at the time, so we (primarily me and @emilypi) acted with not much voting, just to unblock the stagnant libraries in the first place. I would prefer to not do that and have a more committee-based vote driven process on appointing maintainers.

In my opinion this system of light oversight and putting trust into who we believe to be capable people, while not perfect, strikes a good balance of resources (mostly time) in a world where no one is around to pay our maintainers. After the so-called "shake up", a lot was achieved, and I think our core libraries are better off for it.

[Bodigrim]

I agree with @chessai.

Since array is a critical and fundamental ecosystem package I suggest that decisions about changing its API are brought to CLC vote in the same way as similar decisions about base.

array is actually one of the less used core libraries: with 1165 reverse dependencies it's 2x less popular than vector (2070 rev deps) and 6x less popular than bytestring (6575 rev deps). It's weird to install tighter control environment for array and not for other core packages.

As a maintainer of several core libraries, I'd vehemently oppose CLC from encroaching on their territory. We've had such arrangements before and it proved unproductive, essentially paralizing both sides of the equation. There are two reasons:

• We could not expect CLC members to have a good grasp and understanding of all core packages. It's already challenging to be (or pretend to be) an expert in all parts of base. To be an expert both in process and random, and in text and Win32 is next to impossible. It's very difficult to discuss API changes with people who are not well versed in the package and counterproductive to make them responsible for its evolution.

  Speaking of array, I almost never used this package and don't know its capabilities / limitations. It would be a shame to make me responsible to take decisions on its evolution.

• CLC is quite overloaded with requests regarding base even now. Most of the time we have 20+ proposals open simultaneously, and I dare to say that we barely manage this bandwidth. Many proposals could benefit from more attention of CLC members, so even if we get more resources we should funnel them to our primary task, not elsewhere.

  Increasing our workload to cover API changes in more packages does not seem sustainable to me, it will lead to bottlenecks and paralysis and burn out of us, maintainers and users.

[hasufell]

@Bodigrim I agree, but even the short time I've been on CLC has been a great learning experience.

I think it would be fantastic if CLC weighs in non-authoritative on core library matters. That is, we should encourage CLC members to do so, explicitly in a non-authoritative and supportive manner.

I would certainly welcome that for filepath and unix. Especially on filepath I sometimes feel I'm making the decisions alone and more opinions can be helpful, even if they're not expert opinions.

[Bodigrim]

Especially on filepath I sometimes feel I'm making the decisions alone and more opinions can be helpful, even if they're not expert opinions.

As a maintainer you can certainly ask for CLC input: https://github.com/haskell/core-libraries-committee/blob/1403168e5c861dcc5b553ec781d090652891d893/README.md?plain=1#L69-L70

---

@tomjaguarpaw how would you like to proceed? Shall we vote?

[tomjaguarpaw]

how would you like to proceed? Shall we vote?

OK, sure. My vote is +1

[hasufell]

-1

[Bodigrim]

Dear CLC members, let's vote on the proposal that decisions about changing API of array are brought to CLC vote in the same way as similar decisions about base.

A bit of background: array currently does not have any assigned maintainers. Back in October we found volunteers to pick it up, but have not installed them because this proposal came up.

@mixphix @chshersh @parsonsmatt @angerman

---

-1 from me, see https://github.com/haskell/core-libraries-committee/issues/103#issuecomment-1487607480.

[angerman]

While I see the appeal, I do agree that this seems the wrong way; and should be at the discretion of the volunteering maintainer.

-1

[chshersh]

-1 from me. Same reasons as those mentioned by @Bodigrim.

---

I use array only during technical interviews when applying for a new job because Lazy Dynamic Programming makes passing coding interviews much easier.

Other than that, I'd probably never use array in real code and would prefer vector instead.

[mixphix]

I'd be happy to let interested volunteers take over array. I've had no issues with getting enough community feedback on changes in deepseq that I thought were controversial without the involvement of the CLC. If array is such an ecosystem-critical package I trust that maintenance decisions made in good faith will be sufficiently transparent.

-1

[Bodigrim]

Thanks all, 5 votes out of 7 are enough to decline.

@tomjaguarpaw are you fine with CLC getting back to prospective maintainers as it was planned in October? Or do you have any alternative proposals in mind?

[tomjaguarpaw]

Yes, fine by me.