
I'm pretty sure we'd be up for taking ownership of it as it is a rather
fundamental piece of infrastructure in the community, and easily falls
within our purview.
That said, if you're concerned that you haven't been able to really push
the random library forward the way it deserves to be pushed, realize that
handing it to the committee is going to trade having you as a passionate
but very distracted maintainer for several folks who will mostly act to
keep things alive, that aren't likely to go make big sweeping changes to it.
-Edward
On Fri, Aug 22, 2014 at 5:58 PM, Ryan Newton
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
haskell-core-libraries@googlegroups.com] On Behalf Of Edward Kmett 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
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
Peyton Jones 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