Random maintainership -- Was: [core libraries] RE: Core libraries bug tracker

Dear core library folks & others,

On Tue, Aug 19, 2014 at 10:31 AM, Simon Peyton Jones < simonpj@microsoft.com> wrote: Some core libraries (e.g. random) have a maintainer that isn’t the committee.

Ah, since it came up, maybe this is a good time to discuss that particular maintainership. I'm afraid that since it isn't close to my current work (and I'm pre-tenure!) I haven't been able to really push the random library forward the way it deserves to be pushed these last three years. Shall we move maintainership of it to the core libraries committee? Also/alternatively "Thomas Miedema " has stepped forward as a volunteer for taking over maintainership. The library was in limbo in part because it was clear that some API changes needed to be made and but there wasn't a major consensus building design effort around that topic. One thing that was already agreed upon on via the libraries list decision process was to separate out SplittableGen. Duncan Coutts was in favor of this and also (I think) had some other ideas about API changes that should be made. On the implementation front, my hope was that "tf-random" could replace random as the default/standard library. Koen and Michal support this, but I think they didn't want to become the maintainers themselves yet. (I think that was to maintain some separation, and get buy-in from someone other than them, the implementors, before/during the transition). Best, -Ryan On Tue, Aug 19, 2014 at 5:55 PM, Simon Peyton Jones wrote:

If you don't mind the extra traffic in the ghc trac, I'm open to the plan

to work there.

OK great.

Let’s agree that:

· The “owner” of a Core Libraries ticket is the person responsible

for progressing it – or “Core Libraries Committee” as one possibility.

· The “component” should identify the ticket as belonging to the

core libraries committee, not GHC. We have a bunch of components like “libraries/base”, “libraries/directory”, etc, but I’m sure that doesn’t cover all the core libraries, and even if it did, it’s probably too fine grain. I suggest having just “Core Libraries”.

Actions:

· Edward: update the Core Libraries home page (where is that?) to

point people to the Trac, tell them how to correctly submit a ticket, etc?

· Edward: send email to tell everyone about the new plan.

· Austin: add the same guidance to the GHC bug tracker.

· Austin: add “core libraries committee” as something that can be

an owner.

· Austin: change the “components” list to replace all the

“libraires/*” stuff with “Core Libraries”.

Thanks

Simon

From: haskell-core-libraries@googlegroups.com [mailto:

Sent: 19 August 2014 16:23 To: Simon Peyton Jones Cc: core-libraries-committee@haskell.org; ghc-devs@haskell.org Subject: Re: [core libraries] RE: Core libraries bug tracker

Hi Simon,

If you don't mind the extra traffic in the ghc trac, I'm open to the plan to work there.

I was talking to Eric Mertens a few days ago about this and he agreed to take lead on getting us set up to actually build tickets for items that go into the libraries@ proposal process, so we have something helping to force us to come to a definitive conclusion rather than letting things trail off.

-Edward

On Tue, Aug 19, 2014 at 10:31 AM, Simon Peyton Jones < simonpj@microsoft.com> wrote:

Edward, and core library colleagues,

Any views on this? It would be good to make progress.

Thanks

Simon

From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Simon Peyton Jones Sent: 04 August 2014 16:01 To: core-libraries-committee@haskell.org Cc: ghc-devs@haskell.org Subject: Core libraries bug tracker

Edward, and core library colleagues,

This came up in our weekly GHC discussion

· Does the Core Libraries Committee have a Trac? Surely, surely you should, else you’ll lose track of issues.

· Would you like to use GHC’s Trac for the purpose? Advantages:

o People often report core library issues on GHC’s Trac anyway, so telling them to move it somewhere else just creates busy-work --- and maybe

haskell-core-libraries@googlegroups.com] On Behalf Of Edward Kmett they won’t bother, which leaves it in our pile.

o Several of these libraries are closely coupled to GHC, and you might

want to milestone some library tickets with an upcoming GHC release

· If so we’d need a canonical way to identify tickets as CLC

issues. Perhaps by making “core-libraries” the owner? Or perhaps the “Component” field?

· Some core libraries (e.g. random) have a maintainer that isn’t

the committee. So that maintainer should be the owner of the ticket. Or the CLC might like a particular member to own a ticket. Either way, that suggest using the “Component” field to identify CLC tickets

· Or maybe you want a Trac of your own?

The underlying issue from our end is that we’d like a way to

· filter out tickets that you are dealing with

· and be sure you are dealing with them

· without losing track of milestones… i.e. when building a

release we want to be sure that important tickets are indeed fixed before releasing

Simon

-- 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-libraries+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

-- 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-libraries+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs