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