Random maintainership -- Was: [core libraries] RE: Core libraries bug tracker
Edward Kmett
ekmett at gmail.com
Fri Aug 22 23:25:19 UTC 2014
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 <rrnewton at gmail.com> wrote:
> Dear core library folks & others,
>
> > On Tue, Aug 19, 2014 at 10:31 AM, Simon Peyton Jones <
> simonpj at 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 <thomasmiedema at gmail.com>" 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 <simonpj at microsoft.com>
> 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 at googlegroups.com [mailto:
> haskell-core-libraries at googlegroups.com] On Behalf Of Edward Kmett
> > Sent: 19 August 2014 16:23
> > To: Simon Peyton Jones
> > Cc: core-libraries-committee at haskell.org; ghc-devs at 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 at 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 at haskell.org] On Behalf Of Simon
> Peyton Jones
> > Sent: 04 August 2014 16:01
> > To: core-libraries-committee at haskell.org
> > Cc: ghc-devs at 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
> 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 at 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 at googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140822/202975c9/attachment-0001.html>
More information about the ghc-devs
mailing list