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

22 Aug 2014

      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

Ryan Newton

Edward Kmett

tags

participants (2)