
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

On Mon, Aug 4, 2014 at 6:00 PM, Simon Peyton Jones
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@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
+1 for the general concept of an issue tracker, and +0.5 on doing it as part of the GHC tracker. That seems like it will be the most useful place to track issues, but I don't feel *that* strongly on it versus other options. Michael

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 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

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
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 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.

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:haskell-core-libraries@googlegroups.com] On Behalf Of Edward Kmett
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

Herbert/Austin, in the GHC Trac, when I set a ticket to component 'Core Libraries', ekmett is automatically set as owner. This might prevent others from working on that ticket, and I doubt Edward himself is working on all >100 of them. Please change the default to not set the owner. Thanks, Thomas

Alternately, I can make a blanket decree that anyone can feel free to steal
any ticket from me at any time as I mostly work through hvr, dfeuer, and
thoughtpolice anyways to chip away at these.
I lack a strong preference either way.
-Edward
On Sun, Nov 2, 2014 at 5:19 AM, Thomas Miedema
Herbert/Austin,
in the GHC Trac, when I set a ticket to component 'Core Libraries', ekmett is automatically set as owner. This might prevent others from working on that ticket, and I doubt Edward himself is working on all >100 of them. Please change the default to not set the owner.
Thanks, Thomas

Better to make them owner-less initially I think. After all, you might really take ownership of some tickets!
S
From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Edward Kmett
Sent: 02 November 2014 14:49
To: Thomas Miedema
Cc: core-libraries-committee@haskell.org; ghc-devs@haskell.org
Subject: Re: [core libraries] RE: Core libraries bug tracker
Alternately, I can make a blanket decree that anyone can feel free to steal any ticket from me at any time as I mostly work through hvr, dfeuer, and thoughtpolice anyways to chip away at these.
I lack a strong preference either way.
-Edward
On Sun, Nov 2, 2014 at 5:19 AM, Thomas Miedema

Sounds good to me.
On Sun, Nov 2, 2014 at 2:05 PM, Simon Peyton Jones
Better to make them owner-less initially I think. After all, you might *really* take ownership of some tickets!
S
*From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Edward Kmett *Sent:* 02 November 2014 14:49 *To:* Thomas Miedema *Cc:* core-libraries-committee@haskell.org; ghc-devs@haskell.org *Subject:* Re: [core libraries] RE: Core libraries bug tracker
Alternately, I can make a blanket decree that anyone can feel free to steal any ticket from me at any time as I mostly work through hvr, dfeuer, and thoughtpolice anyways to chip away at these.
I lack a strong preference either way.
-Edward
On Sun, Nov 2, 2014 at 5:19 AM, Thomas Miedema
wrote: Herbert/Austin,
in the GHC Trac, when I set a ticket to component 'Core Libraries', ekmett is automatically set as owner. This might prevent others from working on that ticket, and I doubt Edward himself is working on all >100 of them. Please change the default to not set the owner.
Thanks,
Thomas
participants (4)
-
Edward Kmett
-
Michael Snoyman
-
Simon Peyton Jones
-
Thomas Miedema