On Thu, Nov 17, 2011 at 8:03 AM, Thomas E Enebo <tom.en...@gmail.com> wrote:
> I completely agree bugs like 'Math spec failing' suck since they don't
> really tell you what is broken and they also are also possibly
> open-ended depending on when we update our spec tags.
And we often have tags disappear without realizing we'd opened one of
those pointless bugs. Then we have "leaked" bugs into the tracker as a
result.
> I would like an issue filed at least for issues which we are working
> that fixes an invidual spec/expecation. I want this so we can report
> what got fixed when we put out a release. So this is sort of like
> your #2 but it is not dependent on useful discussion happening. We
> could do this so that if you fix a spec you also open a bug to
> indicate you are fixing it and then it doubles as documentation. So
> these issues only show up when someone tried to tackle fixing an
> individual spec failure. If they cannot finish we at least capture
> some information explaining what difficulties they ran into.
>
> So I still want people creating issues for spec failures, but I want
> them more fine-grained to capture individual problems and I only want
> them created if:
> a) You are a developer trying to fix the issue
> b) You are a user who ran into a real world issue and you happen to
> think fixing a particular spec error will fix your real world issue.
I think we're saying the same thing. So I'll try to summarize:
DO NOT:
* File a bug for a spec failure just because it's failing, such as
when updating specs.
DO:
* File a bug for a spec you're working on or will fix for a release.
Basically, give us something we can show in release notes.
* File a bug if there's a real-world user issue caused by a spec
failure. Generally, this will involve code *outside* RubySpec, and
have a reproduction using that code.
We can still proceed to resolve/incomplete the "dummy" bugs that serve
no actual purpose right now, especially if they've had no activity for
a long time. If you're working on a specific "dummy" spec bug, reopen
or add a comment so we don't resolve it.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
