[core libraries] Core libraries bug tracker

[Michael Snoyman]

On Mon, Aug 4, 2014 at 6:00 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

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

+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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140804/5bae45e1/attachment.html>